잡 엔트리 서브시스템 2/3
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
잡 엔트리 서브시스템(JES)은 IBM 메인프레임 환경에서 작업 관리를 위해 개발된 시스템으로, JES2와 JES3로 나뉜다. JES2는 NASA를 위해 설계된 HASP에서 유래되었으며 단일 플랫폼 환경에 적합하고, JES3는 네트워크 환경에 더 적합하다. JES는 MVS 운영 체제에서 잡의 투입, 출력, 실행 스케줄을 제어하며, 스풀링, 스케줄링, 관리를 제공하여 MVS의 효율성을 높인다. 2017년 IBM은 JES2를 "전략적" JES로 삼고 JES3는 지원 종료를 발표했으며, 대한민국에서는 주로 금융권 및 공공기관의 대규모 전산 시스템에서 활용되고 있다.
더 읽어볼만한 페이지
- IBM 메인프레임 운영 체제 - OS/390
OS/390은 1995년에 출시된 IBM의 운영 체제 패키지로, MVS 운영 체제 핵심 요소를 통합하여 신뢰성, 가용성, 서비스 가능성을 향상시켰으며, 2004년에 지원이 종료되었다. - IBM 메인프레임 운영 체제 - OS/360
OS/360은 IBM System/360 제품군을 위해 개발된 범용 운영 체제로, 상업 및 과학 기술 계산을 지원하고 일괄 처리 시스템에서 발전하여 EBCDIC 문자 코드를 채용하고 자기 디스크 장치를 다루는 최초의 OS가 되었으며, 현재의 IBM 메인프레임 OS인 z/OS의 계승자로서 퍼블릭 도메인으로 공개되어 Hercules 에뮬레이터를 통해 실행 가능하다. - 어셈블리어 소프트웨어 - 터보 파스칼
필립 칸이 개발하고 안데르스 헤일스베르그가 기반을 다진 터보 파스칼은 저렴한 가격, 빠른 컴파일, 사용하기 쉬운 IDE를 특징으로 1980년대 PC 프로그래밍에 혁신을 가져왔으며, 여러 기능 추가를 거쳐 델파이 등장 후 레거시 기술이 되었고 일부 버전은 프리웨어로 배포된다. - 어셈블리어 소프트웨어 - MS-DOS
MS-DOS는 마이크로소프트가 개발한 개인용 컴퓨터용 디스크 운영 체제로, IBM PC의 표준 운영 체제로 널리 사용되었으며, 단일 작업 환경과 명령줄 인터페이스를 특징으로 한다.
| 잡 엔트리 서브시스템 2/3 |
|---|
2. 역사
JES는 1960년대 중반부터 IBM 메인프레임 환경에서 작업 관리를 위해 발전해왔다.
JES2(잡 엔트리 서브시스템 2)는 1960년대 중반에 NASA를 위해 IBM이 설계한 '''HASP''' (the Houston 자동 스풀링 프로그램)에서 유래했다. JES3(잡 엔트리 서브시스템 3)는 OS/360의 레코드 I/O 시스템 '''ASP''' (the Attached Support Processor)에서 유래했다.[1]
HASP는 스케줄링과 잡 흐름 제어와 같은 잡 관리, 데이터 관리, 태스크 관리 기능을 제공하는 컴퓨터 프로그램 (군, 컴퓨터 서브시스템)이다. JES2를 구성하는 대부분의 프로그램 이름과 JES가 오퍼레이터 앞으로 출력하는 메시지 속에 HASP가 여전히 남아 있다. JES2는 HASP II의 기능(받은 잡의 시스템 투입, 잡이 생성·출력한 모든 아웃풋 데이터 처리)의 확장 중 하나이다.[1]
JES3는 JES2보다 네트워크를 사용한 시스템에 적합하다.[1] JES2는 단일 플랫폼, 싱글 태스크 환경에 더 적합한 시스템이다.[1]
JES는 MVS 아래에서 잡을 투입하고 아웃풋을 출력하며, 그들의 실행 스케줄을 제어한다. JES는 OS MVS를 위해 효과적인 스풀링, 스케줄링, 관리를 제공하도록 설계되었다. 기본적으로, 많은 태스크에 대한 잡 프로세싱 기능을 분리함으로써 MVS가 더 효율적으로 작동하는 것을 목표로 했다. 대부분의 경우, 시스템 자원은 각 잡에 할당된 태스크에 의해 혼잡해지고, 다른 태스크는 자원을 사용할 수 있게 되기를 기다리고 있는 상태가 된다. 그래서 간단하게, MVS를, 잡 및 시스템 자원 관리 기능과 OS의 더 기본적인 기능으로 나눈 것이다. 이것에 의해, (애플리케이션) 프로그램이 데이터를 처리하기 전과 후의 잡 관리를 JES가 담당하고, 이 관리와 평행하여, OS 본체 (MVS)는 (애플리케이션) 프로그램에 의한 데이터 처리의 제어를 담당하게 되었다.[1]
2. 1. 초기 개발
OS/360의 일괄 작업 처리는 운영 유연성과 성능이 제한적이었는데, 이는 현장에서 개발된 두 개의 패키지인 ''휴스턴 자동 스풀 우선순위'' (''HASP'')와 ''연결 지원 프로세서'' (''ASP'')를 통해 해결되었다.[1]JES2(잡 엔트리 서브시스템 2)는 1960년대 중반에 NASA를 위해 IBM이 설계한 '''HASP''' (the Houston 자동 스풀링 프로그램)에서 유래했다. JES3(잡 엔트리 서브시스템 3)는 OS/360의 레코드 I/O 시스템 '''ASP''' (the Attached Support Processor)에서 유래했다.[1]
HASP는 스케줄링과 잡 흐름 제어와 같은 잡 관리, 데이터 관리, 태스크 관리 기능을 제공하는 컴퓨터 프로그램 (군, 컴퓨터 서브시스템)이다. JES2를 구성하는 대부분의 프로그램 이름과 JES가 오퍼레이터 앞으로 출력하는 메시지 속에 HASP가 여전히 남아 있다. JES2는 HASP II의 기능(받은 잡의 시스템 투입, 잡이 생성·출력한 모든 아웃풋 데이터 처리)의 확장 중 하나이다.[1]
JES는 MVS 아래에서 잡을 투입하고 아웃풋을 출력하며, 그들의 실행 스케줄을 제어한다. JES는 OS MVS를 위해 효과적인 스풀링, 스케줄링, 관리를 제공하도록 설계되었다. 기본적으로, 많은 태스크에 대한 잡 프로세싱 기능을 분리함으로써 MVS가 더 효율적으로 작동하는 것을 목표로 했다. 대부분의 경우, 시스템 자원은 각 잡에 할당된 태스크에 의해 혼잡해지고, 다른 태스크는 자원을 사용할 수 있게 되기를 기다리고 있는 상태가 된다. 그래서 간단하게, MVS를, 잡 및 시스템 자원 관리 기능과 OS의 더 기본적인 기능으로 나눈 것이다. 이것에 의해, (애플리케이션) 프로그램이 데이터를 처리하기 전과 후의 잡 관리를 JES가 담당하고, 이 관리와 평행하여, OS 본체 (MVS)는 (애플리케이션) 프로그램에 의한 데이터 처리의 제어를 담당하게 되었다.[1]
2. 1. 1. HASP (JES2의 기원)
HASP는 원래 휴스턴의 존슨 우주 센터에서 IBM 연방 시스템 부서 계약자에 의해 개발되었다. 초기에는 단일 OS/360 컴퓨터의 작업 스케줄링, 인쇄 및 출력 관리를 담당했다. 이후, 여러 컴퓨터가 공통 작업 큐 및 출력 큐를 공유할 수 있는 기능이 추가되었다.1972년 System/370의 도입과 함께 IBM은 HASP를 시스템의 표준 구성 요소로 재작성하고 JES2 (Job Entry Subsystem 2)로 명명했다. JES2는 1973년 MVS 운영 체제와 함께 공식적으로 도입되었다. JES2의 소스 코드에는 여전히 HASP의 흔적이 남아 있으며, 발행되는 메시지는 `$HASP`로 시작한다. 또한, 하위 호환성을 위해 일부 명령어는 `JES2`와 `HASP`를 모두 지원한다.
JES2(잡 엔트리 서브시스템 2)는 1960년대 중반에 NASA를 위해 IBM이 설계한 '''HASP''' (Houston 자동 스풀링 프로그램)에서 유래했다.
2. 1. 2. ASP (JES3의 기원)
ASP (첨부 지원 프로세서(Attached Support Processor))는 원래 여러 시스템에서 공유 작업을 효율적으로 사용하기 위해 개발되었다. 중앙 시스템이 여러 연결된 시스템에 작업을 분산할 수 있도록 설계되었으며, ASP는 OS/360, SVS 및 360/65 주 프로세서에서 7090 에뮬레이션을 혼합하여 실행할 수 있었지만, 다른 S/360 및 S/370 모델에서는 OS/360 및 SVS만 지원했다. ASP는 1967년 3월에 발표되었으며, 그해 "매우 안정적으로 실행되고 있다"고 보고되었다.ASP는 7094/7040 직접 연결 시스템의 설계를 기반으로 하여 채널 대 채널 통신을 사용했다.[1]
일반적인 ASP 구성에서 360/40과 같은 소형 메인프레임은 ''지원'' 시스템이라고 불리며, 하나 이상의 360/65 또는 ''주'' 시스템이라고 불리는 더 큰 프로세서를 제어했다. 컴퓨터는 단거리, 점대점 컴퓨터 네트워킹의 초기 형태인 선택 채널을 통해 각 호스트에 연결되었고, 채널 간 어댑터에 연결되었다.
ASP는 작업을 실행하는 호스트의 입출력을 관리하기 위해 추가 컴퓨터를 구매해야 했는데, 이는 프린터와 펀치 카드 판독 장치를 구동하는 데 필요한 독립형 바이트 멀티플렉서 채널의 높은 비용으로 인해 경제적으로 정당화되었다. 360/50 및 더 작은 시스템에는 내장형 바이트 멀티플렉서 채널이 있었지만, 더 빠른 360/65 및 더 큰 시스템에는 상대적으로 비싼 독립형 장치가 필요했다.
향상된 신뢰성은 추가 하드웨어 비용을 상쇄하는 또 다른 장점이었다. 하나 이상의 ''주'' 시스템이 고장나거나 유지 보수를 위해 오프라인 상태가 되어도 전체 복합 시스템이 중단되지 않았다.
ASP는 주로 최대 6개의 360/65를 별도의 ASP 머신에서 스케줄링하고 관리해야 하는 대규모 정부 기관 및 방위 산업체를 대상으로 했다. 흔하지 않은 변형인 ''로컬 ASP''(LASP)는 ASP 기능이 동일한 머신에서 실행되는 단일 대형 머신이었다.
1973년 IBM은 ASP를 다시 작성하여 JES3 (잡 엔트리 서브시스템 3)로 이름을 변경하고 MVS만 지원했다.
2. 2. 발전과 현재
1960년대 중반에 NASA를 위해 IBM이 설계한 '''HASP''' (the Houston 자동 스풀링 프로그램)에서 JES2(잡 엔트리 서브시스템 2)가 유래했다. JES3(잡 엔트리 서브시스템 3)는 OS/360의 레코드 I/O 시스템 '''ASP''' (the Attached Support Processor)에서 유래했다.JES3는 JES2보다 네트워크를 사용한 시스템에 적합하다. JES2는 단일 플랫폼, 싱글 태스크 환경에 더 적합한 시스템이다.
HASP는 스케줄링과 잡 흐름 제어와 같은 잡 관리, 데이터 관리, 태스크 관리 기능을 제공하는 컴퓨터 프로그램 (군, 컴퓨터 서브시스템)이다. JES2를 구성하는 대부분의 프로그램 이름과 JES가 오퍼레이터 앞으로 출력하는 메시지 속에 HASP가 여전히 남아 있다. JES2는 HASP II의 기능(받은 잡의 시스템 투입, 잡이 생성·출력한 모든 아웃풋 데이터 처리)의 확장 중 하나이다.
JES는 MVS 아래에서 잡을 투입하고 아웃풋을 출력하며, 그들의 실행 스케줄을 제어하는 기능을 담당한다. JES는 OS MVS를 위해 효과적인 스풀링, 스케줄링, 관리를 제공하도록 설계되었다. 이는 많은 태스크에 대한 잡 프로세싱 기능을 분리함으로써 MVS가 더 효율적으로 작동하도록 하기 위함이었다. 시스템 자원은 각 잡에 할당된 태스크에 의해 혼잡해지고, 다른 태스크는 자원을 사용할 수 있게 되기를 기다리는 경우가 많았기 때문에, MVS를 잡 및 시스템 자원 관리 기능과 OS의 더 기본적인 기능으로 나누었다. 이에 따라 (애플리케이션) 프로그램이 데이터를 처리하기 전과 후의 잡 관리를 JES가 담당하고, 이 관리와 평행하여 OS 본체 (MVS)는 (애플리케이션) 프로그램에 의한 데이터 처리의 제어를 담당하게 되었다.
2017년, IBM은 향후 모든 개발 노력이 JES3가 아닌 JES2에 집중될 것이라는 의미로 JES2를 "전략적" JES로 삼겠다는 방향 발표를 했다. IBM은 JES3가 지원 종료일이 발표될 때까지 계속 지원될 것이라고 고객에게 다시 한 번 확인했다. 2019년 2월, IBM은 z/OS 2.5(2021년 출시 예정)가 JES3를 포함하는 마지막 z/OS 버전이 될 것이라고 발표했다.[3] 2019년 10월, 피닉스 소프트웨어 인터내셔널(Phoenix Software International)은 IBM으로부터 JES3 소스 코드를 라이선스하여 유지 관리 및 개선 작업을 인수할 것이라고 발표했다.[4]
대한민국에서는 JES가 주로 대규모 전산 시스템에서 사용되어 왔으며, 특히 금융권 및 공공기관에서 중요한 역할을 담당하고 있다.
3. 주요 특징 및 기능
3. 1. 작업 관리
JCL은 오픈 시스템 환경에서 MS-DOS나 Windows의 배치 파일, UNIX 계열의 쉘 스크립트 등에 해당하지만, 오픈 시스템의 이러한 것들이 보조적인 것과는 달리 MVS 계열의 JCL(및 JCL을 처리하는 JES)은 필수적이며, 프로그램(프로그래머)과 운영 관리(오퍼레이터)를 분리하고 있다.MVS 계열에서는 JCL 상에서 명시적으로 지정하지 않는 한, 프로그램이 디스크상의 파일(데이터 세트)을 읽는 것도 쓰는 것도 일절 할 수 없다(다이나믹 할당도 기본적으로는 마찬가지). JCL을 기술하고 유지 보수하는 수고가 드는 반면, 해당 프로그램이 프로그램 자체의 지식이 없더라도 사용되는 파일(데이터 세트)을 파악할 수 있으며, 파일명이나 배치 장소의 변경 등도 용이하게(프로그램 자체나 설정 파일의 변경 위험을 감수하지 않고) 수행할 수 있다.
"사용자가 컴퓨터 전체를 지배한다. 사용자가 편리한 것이 좋다"는 오픈 시스템과, "처음부터 기업을 위해 역할 분담이 되어 있다. 관리되는 것이 좋다"는 메인 프레임의 기본 사상 및 문화의 차이라고 할 수 있다.
3. 2. 데이터 관리
JCL은 오픈 시스템 환경에서 MS-DOS나 Windows의 배치 파일, UNIX 계열의 쉘 스크립트 등에 해당하지만, 오픈 시스템의 이러한 것들이 보조적인 것과는 달리 MVS 계열의 JCL(및 JCL을 처리하는 JES)은 필수적이며, 프로그램(프로그래머)과 운영 관리(오퍼레이터)를 분리하고 있다.MVS 계열에서는 JCL 상에서 명시적으로 지정하지 않는 한, 프로그램이 디스크상의 파일(데이터 세트)을 읽는 것도 쓰는 것도 일절 할 수 없다. JCL을 통해 프로그램이 사용할 데이터 세트(파일)를 명시적으로 지정할 수 있다. 이를 통해 프로그램 자체를 변경하지 않고도 데이터 세트의 위치나 이름을 변경할 수 있다.
"사용자가 컴퓨터 전체를 지배한다. 사용자가 편리한 것이 좋다"는 오픈 시스템과, "처음부터 기업을 위해 역할 분담이 되어 있다. 관리되는 것이 좋다"는 메인 프레임의 기본 사상 및 문화의 차이라고 할 수 있다.
3. 3. 태스크 관리
OS/VS1에는 종종 JES1로 불리는 JES도 있었다. JES는 시스템에서 실행되는 다양한 태스크를 관리하고, 자원 할당 및 우선순위를 조정하는 기능을 제공한다. 또한, MVS에 내장된 ''마스터''(MSTR) 서브시스템은 ''마스터 스케줄러''와 기본 JES 자체를 포함하여 기본 JES의 제어 외부에 있는 작업을 시작할 수 있다.[2] 원래 마스터 서브시스템의 JCL은 IBM에서 제공하는 로드 모듈에 있었지만, MVS에서 z/OS에 이르는 현재 버전에서는 시스템 매개변수 라이브러리(PARMLIB)의 멤버로 제공될 수 있다.3. 4. 사용자 정의 기능
JES는 처리의 핵심 지점에서 JES에서 사용자 프로그램으로 제어를 전달하는 일련의 종료 지점을 제공한다. 이를 통해 특수 명령어, 사용자 정의 인쇄 페이지 머리글, 비표준 작업 처리와 같은 사용자 정의 기능을 추가할 수 있다.4. 구성 요소
4. 1. JES2
4. 2. JES3
5. JCL (작업 제어 언어)
JCL은 오픈 시스템 환경에서 MS-DOS나 Windows의 배치 파일, 유닉스 계열의 쉘 스크립트 등에 해당하지만, 오픈 시스템의 이러한 것들이 보조적인 것과는 달리 MVS 계열의 JCL(및 JCL을 처리하는 JES)은 필수적이며, 프로그램(프로그래머)과 운영 관리(오퍼레이터)를 분리하고 있다.
MVS 계열에서는 JCL 상에서 명시적으로 지정하지 않는 한, 프로그램이 디스크상의 파일(데이터 세트)을 읽는 것도 쓰는 것도 일절 할 수 없다(다이나믹 할당도 기본적으로는 마찬가지). JCL을 기술하고 유지 보수하는 수고가 드는 반면, 해당 프로그램이 프로그램 자체의 지식이 없더라도 사용되는 파일(데이터 세트)을 파악할 수 있으며, 파일명이나 배치 장소의 변경 등도 용이하게(프로그램 자체나 설정 파일의 변경 위험을 감수하지 않고) 수행할 수 있다.
"사용자가 컴퓨터 전체를 지배한다. 사용자가 편리한 것이 좋다"는 오픈 시스템과, "처음부터 기업을 위해 역할 분담이 되어 있다. 관리되는 것이 좋다"는 메인 프레임의 기본 사상 및 문화의 차이라고 할 수 있다.
5. 1. JCL의 역할
JCL은 오픈 시스템 환경에서 MS-DOS나 Windows의 배치 파일, 유닉스 계열의 쉘 스크립트 등에 해당하지만, 오픈 시스템의 이러한 것들이 보조적인 것과는 달리 MVS 계열의 JCL 및 JCL을 처리하는 JES는 필수적이며, 프로그램(프로그래머)과 운영 관리(오퍼레이터)를 분리하고 있다.MVS 계열에서는 JCL 상에서 명시적으로 지정하지 않는 한, 프로그램이 디스크상의 파일(데이터 세트)을 읽는 것도 쓰는 것도 일절 할 수 없다. JCL을 통해 프로그램이 사용할 데이터 세트(파일)를 명시적으로 지정하여, 프로그램 자체를 변경하지 않고도 데이터 세트의 위치나 이름을 변경할 수 있다. JCL은 프로그램 실행에 필요한 자원을 할당하고, 실행 순서를 제어하는 등의 역할을 한다.
이는 "사용자가 컴퓨터 전체를 지배한다. 사용자가 편리한 것이 좋다"는 오픈 시스템과, "처음부터 기업을 위해 역할 분담이 되어 있다. 관리되는 것이 좋다"는 메인 프레임의 기본 사상 및 문화의 차이라고 할 수 있다.
5. 2. 오픈 시스템과의 비교
JCL은 오픈 시스템 환경에서 MS-DOS나 Windows의 배치 파일, 유닉스 계열의 셸 스크립트 등에 해당한다. 하지만 오픈 시스템에서는 이러한 요소들이 보조적인 반면, MVS 계열의 JCL (및 JCL을 처리하는 JES)은 필수적이다. JCL은 프로그램(프로그래머)과 운영 관리(오퍼레이터)를 분리한다.MVS 계열에서는 JCL 상에서 명시적으로 지정하지 않는 한, 프로그램이 디스크상의 파일(데이터 세트)을 읽거나 쓰는 것이 불가능하다(다이나믹 할당도 기본적으로 마찬가지). JCL을 기술하고 유지 보수하는 수고가 필요하지만, 해당 프로그램 자체의 지식이 없더라도 사용되는 파일(데이터 세트)을 파악할 수 있다. 또한 파일명이나 배치 장소 변경 등을 프로그램 자체나 설정 파일 변경 없이 수행할 수 있다.
이는 "사용자가 컴퓨터 전체를 지배한다. 사용자가 편리한 것이 좋다"는 오픈 시스템과, "처음부터 기업을 위해 역할 분담이 되어 있다. 관리되는 것이 좋다"는 메인프레임의 기본 사상 및 문화의 차이를 보여준다.
6. 한국 내 활용 사례
6. 1. 금융권
6. 2. 공공기관
6. 3. 기타 산업
7. 미래 전망
참조
[1]
논문
The Evolution of the MVS Operating System
https://pdfs.semanti[...]
2019-10-08
[2]
manual
OS/VS2 System Logic Library Volume 3 - VS2.03.804 - VS2.03.807 - VS2.03.810
http://bitsavers.org[...]
IBM
2022-06-12
[3]
웹사이트
Preview: IBM z/OS Version 2 Release 4
https://www-01.ibm.c[...]
2019-05-03
[4]
간행물
Phoenix Software International Announces IBM® JES3 Licensing Agreement
http://www.globenews[...]
2019-11-01
[5]
웹인용
The job entry subsystem of OS/VS1, by J. H. Baily, J. A. Howard, and T. J. Szczygielski, IBM Systems Journal, Volume 13 (1974), No 3, Page 253
http://domino.resear[...]
2014-03-17
[6]
서적
OS/Virtual Storage 1 Features Supplement
http://bitsavers.inf[...]
[7]
문서
이 이름은 최종적으로 "비대칭 다중 처리 시스템"(Asymmetric Multiprocessing System)으로 변경됨.
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com