JOB Execution
본 장에서는 실제로 JOB을 실행하는 Runner인 tjclrun의 동작방식과 기능에 대해 기술한다. 또한 JCL Parsing, JOB 실행과 JOB 실행의 산출물 등에 대한 설명을 포함한다.
1. 개요
TJES가 제공하는 Batch JOB을 관리 및 처리하는 단계 중의 하나인 JOB Execution (이하 JOB 실행)은 사용자가 submit한 JOB이 스케줄러에 의해서 스케줄링되면 해당 JOB을 실제로 운영체계 상에서 실행하는 단계이다. JOB 실행단계는 tjclrun에 의해서 수행된다.
다음은 tjclrun에 의해 JOB이 실행되는 단계에 대한 설명이다.
-
스케줄러가 제출한 JOB의 JOB Group과 priority 등의 스케줄링 파라미터와 현재 시스템에서 사용 가능한 Runner Slot의 상태에 따라서 특정 Runner Slot에서 JOB을 수행하도록 할당(스케줄링)한다.
-
해당 Runner Slot은 tjclrun을 실행하기 위한 자료를 JOB SPOOL에 기록하고 tjclrun을 호출한다.
-
tjclrun은 JOB SPOOL을 통해 전달된 해당 JOB의 JCL에 적힌 내용에 따라서 JOB을 실행한다.
-
JOB의 실행이 끝나면 tjclrun은 자신을 호출한 Runner Slot에게 JOB의 실행 결과를 보고한다.
JOB 실행 결과는 최종적으로 TJES가 관리하는 JOBQ에 저장된다. 또 실행이 완료된 JOB의 OUTPUT 및 JOBQ에 저장된 JOB에 대한 정보는 이후 TJES에 의해서 관리된다. 사용자는 실행이 완료된 JOB의 실행 결과를 검토하거나 출력할 수 있으며, 해당 JOB에 대한 정보가 더 이상 필요하지 않다면 해당 JOB 정보를 제거하게 된다.
본 장에서는 JOB 실행 단계를 책임지는 tjclrun의 동작과 기능에 대해서 설명하며, 이와 관련된 JCL 구문이나 문법에 대해서는 상세히 다루지 않는다. 자세한 내용은 Mainframe의 "JCL Reference Guide"를 참고한다. |
2. JOB 실행
TJES의 JOB 처리 단계에 따라서 tjclrun이 호출되면, tjclrun은 실행을 위한 몇 가지 초기화 작업을 수행한 후에 JOB SPOOL을 통해 전달된 JCL을 파싱하고, 파싱된 결과에 따라서 JOB을 실행한다.
tjclrun은 JOB을 구성하는 JOB STEP을 JCL에 기술된 순서대로 실행한다. 각각의 JOB STEP은 해당 JOB STEP에서 사용되는 데이터셋을 할당하고 사용자가 지정한 Batch 애플리케이션을 실행하는 등 많은 세부작업으로 이루어져 있다.
EX 문에 기술한 프로그램을 이용해 JOB STEP에 지정된 Batch 프로그램을 실행한 후에는 해당 프로그램이 종료하기를 기다리면서 프로그램 실행에 관한 모니터링 정보를 TJES에 주기적으로 보고한다. 또한 실행한 Batch 프로그램에게 SYSIN 데이터셋의 내용을 전달하고, SYSOUT 데이터셋을 전달받아 JOB SPOOL에 기록한다. 실행한 Batch 프로그램이 종료되면, 그 종료결과를 TJES에 보고하고 JOB STEP의 종료상태에 따라 그 다음 JOB STEP을 실행하거나, 예외조건이 만족하는 경우에는 JOB 수행을 중단한다.
위와 같은 방식으로 JCL에 기술된 마지막 JOB STEP까지 모두 실행한 후에 tjclrun은 JOB의 실행 결과를 TJES에 보고하고 JOB 실행 단계에서 할당한 데이터셋 등의 자원을 반환한 후에 종료한다.
다음은 tjclrun이 JOB 실행 단계에서 수행하는 다양한 세부작업을 분류한 표이다.
작업 | 단계 |
---|---|
실행 |
|
리소스 |
|
컨트롤/모니터링 |
|
기타 |
|
2.1. 실행 초기화
다음은 Runner Slot 또는 SUBMITOR 등에 의해 Runner가 호출되기 전에 준비되는 필수 리소스들이다.
-
JOBID
-
JOBQ 상의 JOB 엔트리
-
Runner Slot
-
JOB SPOOL(EXPJCL)
실행 초기화는 다음의 과정으로 진행된다.
-
명령어 라인 인수 검사
Runner Slot은 tjclrun을 호출할 때 지정한 인수(args)를 검사하고 이로부터 JOBID 및 실행할 JCL 파일의 위치 그리고 기타 처리 파라미터를 전달받는다.
디버깅 목적 등의 특수한 경우에는 쉘을 통해 tjclrun을 실행할 수 있지만, TJES의 Runner Slot를 통해 tjclrun을 실행하는 것이 일반적이다. TJES를 통하지 않고 tjclrun을 실행한 경우 TJES의 전체적인 JOB 관리대상에서 제외될 뿐만 아니라 요구되는 정상적인 단계를 실행하지 않을 수 있다.
-
환경 설정 읽기
OpenFrame 환경 설정의 tjclrun 서브젝트의 각 섹션과 키를 읽어서 해당 설정에 맞는 tjclrun의 실행 방식을 결정한다.
-
실행 계정
기본적으로 JOB을 실행할 때 tjclrun 프로세스의 소유자는 TJES 운영자의 OS 계정과 동일하다. 즉, TJES 시스템을 운영체제 상의 obm이라는 사용자 계정에서 기동한 경우 tjclrun 프로세스와 각 JOB STEP에서 실행되는 Batch 프로그램의 사용자 아이디도 obm이 된다.
그러나 OpenFrame 환경설정의 tjclrun 서브젝트, ACCOUNT 섹션의 SETUID 키의 VALUE 항목을 YES로 설정하면 JCL USER 문에 지정된 사용자로 tjclrun 프로세스를 실행할 수 있다. 자세한 내용은 보안의 "setuid root tjclrun"을 참고한다.
-
SYSLIB 초기화
tjclrun은 OpenFrame 환경설정의 tjclrun 서브젝트, SYSLIB 섹션에 설정된 디렉터리 위치에서 JOB STEP에 지정된 프로그램을 찾는다. SYSLIB 섹션을 설정하지 않은 경우 사용자의 환경변수에 지정된 디렉터리에서 프로그램을 찾는다.
JCL에 PRGLIB FD가 있는 경우는 SYSLIB보다 JCL에 기술된 PRGLIB이 우선한다.
-
실행 우선순위
-
PRGLIB FD가 있는 경우 PRGLIB의 path에 있는 프로그램
-
PRGLIB FD가 없는 경우 tjclrun 설정의 SYSLIB 섹션의 path에 있는 프로그램
-
PRGLIB FD가 없고 tjclrun 설정의 SYSLIB 섹션의 설정도 없는 경우 사용자 환경변수(PATH)에 지정된 path의 프로그램
-
일부 UNIX 시스템에서, tjclrun에 root 권한을 부여하여 운영하는 경우에 환경변수가 지워지는 문제가 있으므로 OpenFrame 환경설정의 tjclrun 서브젝트, SYSLIB 섹션을 반드시 설정해야 한다. 그렇지 않으면 tjclrun은 JCL에 지정된 프로그램을 실행하거나 tjclrun을 로딩하는 단계에서 실패하게 된다. 자세한 내용은 보안의 "setuid root tjclrun"을 참고한다.
-
-
JOB 시작 보고
tjclrun이 지정된 JOB을 실행하기 시작했음을 TJES에게 보고한다.
-
JOB SPOOL 열기
JOB의 실행단계에서 사용하기 위해 JOB SPOOL을 연다.
tjclrun 서브젝트에 대한 자세한 내용은 OpenFrame Batch "환경설정 안내서"를 참고한다. |
2.2. 입력 JCL 파싱
tjclrun은 JOB SPOOL을 통해 전달된 JCL 파일(EXPJCL)을 분석하여 JOB을 실행한다.
tjclrun이 실행하는 JOB 문을 포함한 (JOB SPOOL에 저장된) JCL 파일을 Job Stream이라고 부른다. |
2.3. 실행 과정
실행해야 하는 JOB의 EXPJCL(Job Stream)을 파싱한 이후에 tjclrun은 JCL에 기술된 순서에 따라 JOB STEP을 실행한다.
실행 단계
파싱 이후의 JOB 실행은 다음과 같이 크게 두 단계로 이루어진다.
-
Lock phase
해당 JOB에서 사용되는 데이터셋에 대한 Lock을 설정하는 단계이다.
-
Exec phase
실제로 JOB STEP을 순서대로 실행하는 단계이다.
tjclrun은 미리 EXPJCL을 분석하여 해당 JOB에서 사용할 데이터셋의 리스트를 얻고 실제 실행 단계에 들어가기 전에 해당 데이터셋들에 대해 일괄적으로 Lock을 요청한다. 이러한 방식은 서로 다른 여러 개의 JOB이 동시에 동일한 데이터셋을 독점적(exclusive)으로 사용하는 경우 빈번하게 발생되는 교착상태(Dead Lock)를 방지한다.
JOB에서 사용하는 데이터셋들에 대한 Lock 요청 단계가 성공적으로 수행되면 실제 실행 단계를 수행한다. 실제 실행단계(exec phase)는 다음과 같이 처리된다.
-
EX PGM STEP
처리해야 하는 JOB STEP이 Batch 프로그램을 실행하는 경우(EX 문) 지정된 Batch 프로그램을 실행한다. tjclrun은 Batch 프로그램을 자신의 자식 프로세스로서 실행하고 그 프로그램의 실행이 종료될 때까지 기다린다. 실행한 Batch 프로그램의 실행이 종료되기를 기다리는 중에 주기적으로 Batch 프로그램이 수행한 데이터셋 I/O 통계 등의 정보를 TJES에 보고한다.
조건 실행
다음과 같은 방식으로 JOB을 구성하는 JOB STEP을 조건적으로 실행할 수 있다.
-
EX COND
실행한 이전 JOB STEP의 종료상태에 따라서 다음에 실행할 JOB STEP을 처리할지 건너뛸지를 결정한다. 이러한 방식의 조건적인 JOB STEP의 실행은 EX 문의 COND 파라미터를 이용하여 지정한다.
2.4. EX 프로그램 처리
tjclrun의 가장 중요한 역할이 바로 사용자가 지정한 Batch 프로그램을 실행하는 것이며, 다음과 같은 세부 작업으로 이루어진다.
EX COND
EX PGM step을 실행하기 전에 먼저 해당 EX 문에 기술된 COND 파라미터를 평가하여 이전 step의 실행 결과가 EX COND를 만족하지 않는 경우 (즉, 예외 상황인 경우) 해당 EX PGM step을 실행하지 않고 건너뛴다. JOB에서 실행되는 첫 번째 JOB STEP은 항상 EX COND가 만족하는 것으로 평가된다.
EX COND가 만족되는 경우는 해당 JOB STEP(EX PGM step)을 다음과 같은 절차로 실행한다.
-
스텝 진행 보고
해당 EX PGM step의 처리 시작을 TJES에게 보고한다.
-
Step FD 할당
EX PGM step에서 호출할 Batch 프로그램이 사용할 데이터셋을 지정하는 FD 문을 처리하여 데이터셋을 할당한다. JOB STEP 레벨의 스페셜 FD 문에 대한 부가적인 처리도 이 단계에서 처리된다. JOB STEP 레벨의 스페셜 FD 문으로는 STEPCAT FD 및 PRGLIB FD 문이 있다.
-
PARA 구문 처리
해당 스텝에 PARA 구문이 있는 경우, EX 문에 지정된 Batch 프로그램에 전달될 실행 파라미터를 만든다. Batch 프로그램은 이 파라미터를 일반적인 UNIX 프로그램의 argc 또는 argv를 통해서 얻을 수 있다.
-
호출/실행
실제로 시스템 함수를 이용하여 EX 문에 지정된 Batch 프로그램을 호출(fork)하는 단계이다. TJES에서 Batch 프로그램은 tjclrun 프로세스의 자식 프로세스(child process)로서 실행된다. 그러기 위해서 먼저 fork를 실행하여 자식 프로세스를 생성하고, 자식 프로세스에서 AIM 유틸리티인 OSAMFRUN을 실행(shared object)하여 지정된 Batch 프로그램을 시작하거나 해당 프로그램을 직접 실행(executable)한다.
-
SYSIN/SYSOUT 파이프
OpenFrame에서는 Batch 프로그램이 사용하는 SYSIN(입력) FD와 SYSOUT(출력) FD를 일반적인 UNIX 프로그램의 stdin과 stdout으로 구현하였다.
tjclrun은 비유적으로 볼 때 쉘의 명령어 라인을 이용하여 Batch 프로그램을 실행하는 사용자와 같은 역할을 수행한다고 볼 수 있다. 그런 의미에서 tjclrun은 SYSIN FD의 내용을 읽어서 애플리케이션의 stdin에 write하여 애플리케이션의 stdin으로부터 SYSIN의 내용을 읽을 수 있도록 해준다.
반대로 애플리케이션에서 stdout으로 출력한 내용은 tjclrun이 읽어서 SYSOUT FD에 해당하는 데이터셋이나 JOB SPOOL에 대신 출력해 준다.
SYSIN FD와 SYSOUT FD를 UNIX 시스템 상의 프로그램들이 공통적으로 사용하는 stdin과 stdout으로 연결함으로써 OpenFrame의 데이터셋 API를 사용하지 않고 만들어진 대부분의 UNIX 애플리케이션들도 OpenFrame Batch에서 별도의 처리 없이 Batch 프로그램으로 실행하는 것이 가능하다.
UNIX 애플리케이션의 stderr는 SYSOUT FD에 stdout의 내용과 함께 기록된다. stdout 및 stderr 모두 애플리케이션의 기본적인 출력 스트림이고 Mainframe에는 stderr에 해당하는 약속된 FD가 없기 때문에 stderr를 SYSOUT FD에 함께 저장하고 있다.
-
모니터링 보고/대기
tjclrun은 EX 문에 지정된 Batch 프로그램을 실행하고 해당 프로그램이 종료할 때까지 기다리면서 주기적으로 애플리케이션에서 수행한 데이터셋 I/O 카운트를 TJES에 보고한다.
-
Step FD 후처리
JOB STEP에서 실행된 Batch 프로그램이 종료하면 그 종료 상태에 따라서 FD 문의 DISP 파라미터에 지정된 후처리 작업을 수행한다. DISP의 종류는 CONT, LOCK, DLT, CAT, UNCAT, KEEP 등이 있다.
2.5. FD 처리
tjclrun은 JCL의 FD 문에 기술된 Batch 프로그램이 사용할 데이터셋을 할당하여 Batch 프로그램에서 사용할 수 있도록 해준다. 일반적인 Batch 프로그램은 자신이 사용할 데이터셋을 스스로 할당하지 않고 JCL에 FD 문을 기술함으로써 tjclrun이 할당하게 하고 그 결과를 상속받아서 사용한다.
데이터셋 할당 작업은 EX PGM step에서 Batch 프로그램을 실행하기 전에 수행된다. Batch 프로그램이 종료된 이후에는 할당한 데이터셋에 대한 후처리 작업을 tjclrun이 해준다. 할당된 데이터셋은 JOB의 종료 시 즉, tjclrun이 종료할 때 할당이 해제된다.
데이터셋의 할당 작업은 FD 문에 기술된 데이터셋의 특성에 따라서 서로 다르게 처리되는데 크게 다음과 같이 구분할 수 있다.
-
Normal 데이터셋
가장 일반적인 경우로 FILE 파라미터에 할당할 데이터셋의 이름이 주어진 경우이다. OpenFrame의 데이터셋 할당 모듈을 호출하여 데이터셋을 할당하고 애플리케이션이 이 데이터셋을 사용할 수 있도록 그 결과를 애플리케이션의 환경으로 전달한다.
-
Sysout 데이터셋
FD 문에 SOUT 파라미터가 지정된 데이터셋이다. Sysout 데이터셋은 JOB SPOOL에 JOB의 실행 결과로 생성되는 출력 데이터를 저장하기 위해서 생성된다.
-
임시 데이터셋
FD 문의 FILE 파라미터가 지정되지 않은 Sysout 데이터셋 외의 데이터셋은 임시 데이터셋이다. 이 경우 tjclrun은 내부적으로 임시 데이터셋에 유일한 이름을 부여한다. 임시 데이터셋은 JOB의 실행 과정에서 생성되고 JOB이 종료될 때 삭제되는 데이터셋이다.
tjclrun은 사용자가 지정한 임시 데이터셋 이외에도 내부적인 용도로 몇 개의 임시 데이터셋을 사용한다. 다음에 설명한 입력 스트림 데이터셋의 처리도 그 한 가지 예이다.
-
입력 스트림 데이터셋
EXPJCL(Job Stream)에 'FD access name=*'의 형태로 기술된 데이터셋을 말한다.
tjclrun은 입력 스트림 데이터셋을 JOB SPOOL에 따로 저장해 둔 다음에 내부적인 데이터셋 이름을 부여한다. 그 이후는 일반적인 데이터셋과 동일한 OpenFrame 데이터셋 처리 모듈을 이용해서 할당하고 Batch 프로그램에서 이 데이터셋을 사용할 수 있게 된다. tjclrun은 JOB SPOOL에 임시로 저장한 입력 스트림 데이터셋이 JOB이 종료될 때에 제거될 수 있도록 임시 데이터셋으로 생성한다.
-
2.6. 스페셜 FD
FD 문장은 다음의 형태로 JCL에 코딩된다.
¥[label] FD access name=[parameters,...]
시스템에서 특수한 용도로 사용하기 위해 예약되어있는 access name을 갖는 FD 문을 스페셜 FD 문이라고 부른다.
사용자는 특수한 용도로 사용하기 위해 예약된 스페셜 FD의 access name을 약속된 이외의 용도로 사용할 수 없다. |
TJES는 다음과 같은 스페셜 FD를 지원한다.
-
PRGLIB
PRGLIB FD는 tjclrun이 EX 문에 지정된 Batch 애플리케이션을 찾는 PDS 데이터셋(라이브러리 경로)을 지정한다. PRGLIB FD는 해당 JOB STEP의 EX 문 다음에 위치하며, JOB STEP에서 호출하는 프로그램을 찾을 PDS(라이브러리)를 지정한다. FD 문의 concatenation(CF) 기능을 이용하여 여러 PDS에서 프로그램을 찾도록 지정할 수 있다.
PRGLIB FD의 concatenation 기능에 대해서는 Fujitsu의 "XSP JCL 문법서"를 참고한다.
PRGLIB FD가 지정되지 않은 경우는 OpenFrame 환경설정의 tjclrun 서브젝트, SYSLIB 섹션에 지정된 위치에서 실행할 Batch 프로그램을 찾는다.
-
STEPCAT
STEPCAT FD는 JOB STEP에서 사용할 데이터셋 카탈로그를 지정한다. STEPCAT의 경우도 FD 문의 concatenation(CF) 기능을 이용하여 여러 데이터셋 카탈로그를 지정할 수 있다.
STEPCAT FD는 JOB STEP의 EX 문 다음에 위치하며, 그 JOB STEP에서 사용할 데이터셋 카탈로그를 지정한다. STEPCAT이 지정되지 않은 경우에는 OpenFrame 시스템의 마스터 카탈로그가 사용된다. STEPCAT이 지정된 경우도 지정된 카탈로그에 데이터셋이 카탈로깅 되어있지 않은 경우는 마스터 카탈로그에서 데이터셋에 대한 카탈로그 정보검색을 시도한다.
2.7. OUTPUT 처리
JCL FD 문에는 JOB SPOOL에 생성되는 Sysout 데이터셋의 출력처리 방법을 나타내거나 제어하기 위한 SOUT, OG, FORM, CHARS 등의 파라미터들이 있다. Sysout 데이터셋을 나타내는 FD 문은 하나 이상의 파라미터 값을 참조하여 해당 출력을 처리하기 위한 방법을 지정할 수 있다.
2.8. JOB SPOOL
tjclrun은 JOB을 수행하는 여러 단계에서 다양한 목적으로 JOB SPOOL을 사용한다.
tjclrun이 JOB SPOOL에 생성하는 데이터셋과 각각의 용도는 다음과 같다.
-
INPJCL
최초 submit할 때의 JCL 파일이다. JOB SPOOL의 다른 대부분의 파일은 tjclrun에 의해 생성되는 것에 반하여 INPJCL은 TJES의 SUBMITOR(obmjmsvr)가 JOB의 submit를 처리할 때에 JOB SPOOL에 미리 만들어둔다. 그 내용은 사용자가 submit한 JCL 파일과 기본적으로 동일하다.
-
EXPJCL
tjclrun이 실행하는 Job Stream을 담고 있는 JCL 파일이다. EXPJCL은 tjclrun이 사용하기 위해서 TJES의 SUBMITOR(obmjmsvr)가 JOB의 submit처리시에 JOB SPOOL에 만들어놓는 파일이다. EXPJCL은 INPJCL에서 XSP Macro 처리를 하고난 후의 파일이다.
-
INSDSET
INPJCL에 다음과 같은 형태로 기술되어 있는 입력 스트림 데이터셋을 tjclrun이 내부적으로 사용하기 위해서 JOB SPOOL에 생성하는 임시 데이터셋이다.
다음은 입력 스트림 데이터셋을 설정하는 예이다.
¥label FD AccessName=* line1 line2 ... lineN
위의 예제의 경우 INSDSET은 line1, line2, …, lineN을 내용으로 하는 임시 데이터셋으로 해당 FD를 사용하는 JOB STEP에서 생성되며, 해당 JOB STEP의 종료될 때에 삭제되는 임시 데이터셋이다. 이러한 동작을 INSDSET SHUNT라고 부른다.
tjclrun이 INSDSET SHUNT를 하는 이유는 입력 스트림 데이터셋은 일반 Non-VSAM 데이터셋과 함께 concatenation될 수 있기 때문이다. 입력 스트림 데이터셋을 INPJCL에서 축출하여 데이터셋으로 SHUNT하면 Non-VSAM SDS의 concatenation 로직을 이용하여 일관된 방식으로 concatenation 처리를 지원하도록 한다.
-
JESJCL
tjclrun이 파싱한 EXPJCL을 파싱한 결과인 parse tree를 텍스트 형태로 출력한 내용을 갖는 파일이다. 주로 문제를 분석할 때 참고 자료로 사용된다.
-
JESMSG
tjclrun이 종료하는 경우 그 tjclrun을 실행한 Runner Slot이 해당 JOB SPOOL에 기록하는 데이터셋이다. 그 내용은 실행된 JOB에 관련된 기본적인 정보와 JOB의 실행 과정에서 보고된 여러 가지 통계 정보 그리고 JOBSTEP에 관련된 정보를 포함한다. JOB의 실행에 관련하여 TJES 시스템에서 관심이 되는 사항에 대한 요약적인 정보를 담고 있다.
-
SYSMSG
SYSMSG는 tjclrun의 주요 메시지 로그이다. 즉, JOB을 실행하는 과정에서 필요한 여러 하위단계의 진행상태 및 중요 결과 메시지뿐만 아니라 작업을 처리할 때 발생한 에러 메시지도 SYSMSG에 저장된다. JOB의 실행이 비정상적으로 종료된 경우 원인분석을 위해서 우선 SYSMSG의 내용을 검토해야 한다.
SYSMSG의 내용은 tjclrun이 JOB의 JOB STEP을 실행한 순서에 따라서 세부 작업이나 동작이 발생한 시간 순서대로 기록된다.
SYSMSG에 출력되는 내용은 다음과 같다.
-
수행 중인 JOBSTEP 이름
-
JOB 수행 중에 할당한 데이터셋 정보
-
tjclrun이 호출한 PGM 이름과 프로세스 아이디(pid)
-
tjclrun이 호출한 PGM의 종료 상태
-
tjclrun이 현재 수행 중인 동작
-
tjclrun의 주요 동작의 성공 여부
-
-
SYSOUT
SYSOUT 데이터셋은 다음과 같이 FD 문에 SOUT 파라미터가 지정된 경우를 말한다. SYSOUT 데이터셋은 다른 데이터셋과 달리 JOB SPOOL에 저장되고 일반적으로 출력용 데이터를 저장한다.
다음은 SYSOUT 데이터셋을 설정한 예이다.
¥ EX MONTHLY ¥ FD SYSIN=* 2007-07-01,2007-08-01 ¥ FD SYSOUT=DA,SOUT=A ¥ FD RPTOUT=DA,SOUT=B ¥ FD RPTERR=DA,SOUT=C
위에서 설명한 다른 JOB SPOOL의 데이터셋은 TJES가 JOB을 효율적으로 실행하기 위해 사용하는 데이터셋인 반면에 SYSOUT 데이터셋은 사용자가 Batch 프로그램을 위하여 요청한 데이터셋으로 JOB SPOOL 상에 저장되도록 특별히 지정한 경우로 볼 수 있다. SYSOUT 데이터셋은 하나의 JOB이나 JOB STEP에서 여러 개 지정할 수 있다. 위의 예제에서 SYSOUT, RPTOUT, RPTERR가 SYSOUT 데이터셋이다.
SYSOUT 데이터셋의 내용은 사용자가 지정한 Batch 프로그램에서 출력하는 내용이다. TJES는 SYSOUT 데이터셋에 그 이외의 정보를 가감하지 않는다. Batch 프로그램에서 SYSOUT 데이터셋의 사용을 마치면 TJES는 SYSOUT 데이터셋의 출력 클래스에 따라서 사용자가 출력한 내용을 추후에 프린터나 화면으로 출력하는 과정을 관리할 뿐이다.
2.9. JOB CONTROL
TJES에서는 스케줄링 단계 이후의 실행 중인 JOB을 SUSPEND(일시정지)/RESUME(실행재개)/STOP(강제종료)시킬 수 있다.
JOB의 실행을 위해서 실행 중인 여러 하위 프로세스에 대한 위와 같은 3가지 제어를 TJES에서는 JOB CONTROL이라고 한다. tjesmgr 또는 OpenFrame Manager의 [Batch] 메뉴와 같은 사용자 인터페이스를 이용하여 실행 중인 JOB에 대해서 JOB CONTROL을 할 수 있다.
JOB CONTROL에 대한 자세한 명령 사용법은 TJESMGR 명령어 및 OpenFrame Manager "사용자 안내서"를 참고한다. |
사용자가 실행 중인 JOB에 대해서 JOB CONTROL 명령을 입력하면 다음과 같은 순서로 처리된다.
-
TJES는 tjclrun에게 JOB CONTROL을 위해 약속된 시그널(SIGUSR1)을 보낸다.
-
tjclrun은 SIGUSR1을 받으면 부가적으로 전달되는 정보를 참조하여 SUSPEND/RESUME/STOP 중에서 어떤 동작이 요청되었는지를 알아낸다.
-
각각에 해당하는 UNIX 시스템의 JOB CONTROL 시그널(SIGSTOP/SIGCONT/SIGKILL)을 tjclrun이 JOB STEP에서 실행한 하위 프로세스에 보낸다.
-
시그널을 받은 하위 프로세스는 시그널 종류에 따라서 실행이 일시정지되거나 실행재개 또는 강제종료된다.
-
하위 프로그램에 대한 JOB CONTROL을 수행한 후 tjclrun은 그 결과를 TJES에게 보고한다.
-
tjclrun 프로세스 자체는 SUSPEND인 경우 스스로 자신에게 SIGSTOP을 보내서 실행을 일시 정지한다. STOP인 경우는 tjclrun은 실행을 종료(exit)한다. RESUME의 경우에는 TJES에서 tjclrun에 SIGCONT를 보내서 tjclrun을 실행 재개한다. 실행이 재개된 경우 tjclrun은 위에 설명한 것과 같이 자신이 실행한 하위 프로세스에 SIGCONT를 보낸다.
tjclrun의 JOB CONTROL 구현은 UNIX 시스템의 JOB CONTROL 시그널 (SIGSTOP/SIGCONT/SIGKILL)을 이용하여 구현되었기 때문에 프로세스의 유효사용자(effective userid)가 상이한 경우 시그널을 하위 프로세스에 전달하는 과정에서 권한 부족에 의한 에러가 발생할 수 있고, 이러한 경우 JOB CONTROL은 완벽하게 이루어지지 않을 수 있다. 이러한 상황을 고려하여 항상 완벽한 JOB CONTROL을 수행하기 위해서 시스템 운영자는 tjclrun에 root 권한을 부여해야 한다. 이에 대한 자세한 내용은 보안의 setuid root tjclrun을 참고한다. |
2.10. JOB Level Report
tjclrun은 주어진 JOB을 실행하는 과정에서 발생한 여러 가지 사항을 TJES에 보고한다. tjclrun이 TJES에 보고하는 정보는 크게 JOB 전반에 해당하는 내용과 특정 JOB STEP에 해당하는 내용으로 구분할 수 있다.
tjclrun이 TJES에 보고하는 JOB에 관한 정보는 다음과 같다.
-
JOB START/FINISH
tjclrun이 주어진 JOB을 처리하기 시작했음을 알린다. tjclrun이 정상적으로 종료하는 경우에는 명시적으로 해당 JOB의 처리를 끝마쳤음을 TJES에 보고한다. JOB의 종료를 보고할 경우에 JOB의 수행이 정상인지 여부를 나타내는 종료상태와 종료코드가 함께 보고된다.
-
JOB CONTROL 상태
TJES는 tjclrun이 수행 중인 JOB을 SUSPEND/RESUME/STOP시킬 수 있다. tjclrun은 이와 같은 JOB CONTROL을 수행한 후의 JOB 상태를 TJES에 보고한다.
-
데이터셋 Lock 대기
tjclrun은 JOB을 처리하기 전에 미리 해당 JOB에서 사용될 데이터셋에 대해서 데이터셋 Lock을 요청한다. 다른 JOB에서 동일한 데이터셋에 이미 Lock을 설정해서 사용 중인 경우 tjclrun은 자신이 요청한 Lock이 성공할 때까지 JOB을 처리하지 않고 기다린다. 이때 JOB의 수행이 대기하는 원인이 되는 다른 JOB과 Lock 요청이 대기 중인 데이터셋이 무엇인지를 TJES에 보고한다. 이 보고 내용을 검토하여 운영자는 여러 JOB 사이에 공유되어 사용되는 데이터셋에 따른 JOB의 대기 문제를 쉽게 식별하고 해결할 수 있다.
2.11. STEP Level Report
tjclrun이 수행하는 보고 작업 중에서 JOB STEP 수준에서 보고되는 정보는 다음과 같다.
-
STEP START/FINISH
JOB의 어떤 JOB STEP을 실행하고 있는지 TJES에 알려주기 위해서 tjclrun은 JOB을 이루는 각 JOB STEP을 처리하기 시작할 때와 종료할 때 TJES에 STEP의 START/FINISH 보고를 한다.
STEP START의 경우에는 현재 실행 중인 JOB STEP의 JOB 스트림에서의 위치를 의미하는 STEP의 경로(STEPPATH) 정보와 해당 JOB STEP의 타입(PGM 또는 PROC) 등을 보고한다. STEP FINISH를 보고할 경우 해당 JOB STEP의 종료상태 및 종료코드와 해당 JOB STEP을 수행하는 데 걸린 시간정보를 보고한다.
-
데이터셋 할당
tjclrun은 JOB STEP에 지정된 Batch 프로그램을 호출하기 전에 Batch 프로그램이 사용할 데이터셋을 미리 할당한다(할당할 데이터셋은 JCL의 DD 문에 의해서 지정된다).
데이터셋의 할당정보는 전체 OpenFrame 시스템에서 매우 중요한 정보이기 때문에 tjclrun은 할당한 ddname과 데이터셋의 이름을 JOB SPOOL의 SYSMSG에 남길 뿐만 아니라 추가적으로 데이터셋의 할당정보가 OpenFrame의 데이터셋 할당 모듈 자체적으로 OpenFrame_HOME/log/sys 디렉터리의 dsalc 로그에 기록된다.
-
데이터셋 I/O 보고
tjclrun이 할당해 준 데이터셋을 Batch 프로그램에서 사용함에 따라 변경되는 해당 데이터셋에 대한 I/O 카운트 정보가 반영된다. tjclrun은 Batch 프로그램이 실행되는 동안 수행한 데이터셋 I/O 통계정보를 주기적으로 TJES에 보고한다. 이를 통해서 운영자(사용자)는 특정 데이터셋에 대해서 JOB STEP별로 몇 건을 READ/ WRITE하고 있는지를 모니터링할 수 있다.
2.12. 보안
TACF 대리자
일반적으로 JOB을 특정 사용자 권한으로 수행하기 위해서 JCL의 USER 문에 user id와 password를 지정한다. JCL USER 문에 password를 지정할 때에는 암호화하지 않은 상태로 지정하기 때문에 JCL 파일 자체에 대한 보안이 엄격히 관리되지 않는 환경에서 사용자의 비밀번호가 노출될 위험이 발생한다.
이러한 위험을 방지하기 위해서 TJES에서는 대리자(Surrogate User)로 지정된 사용자가 실행 사용자(Execution User)를 대신하여 password를 지정하지 않고 실행 사용자 권한으로 JOB을 실행하도록 JOB을 submit할 수 있다. 대리자가 실행 사용자를 대신하여 JOB을 submit하는 경우에도 JOB은 실행 사용자의 권한으로 실행된다. 대리자는 단순히 JOB을 실행 사용자 대신 submit할 수 있을 뿐이다. 대리자에 의한 JOB submit은 JCL의 USER 문에 password가 지정되지 않은 경우에만 동작한다.
TACF에서 JOB 실행을 위한 대리자를 지정하는 방법은 OpenFrame TACF "운영자 안내서"를 참고한다. |
setuid root tjclrun
UNIX 시스템에서 실행 프로그램을 실행하는 사용자가 아니라 해당 프로그램 파일의 소유자 권한으로 프로그램을 실행하기 위해서 실행 프로그램의 소유자와 파일 퍼미션을 적절하게 변경하여 프로그램 실행시 프로세스가 프로그램 파일의 소유자 권한으로 실행되도록 설정하는 작업을 setuid 작업이라고 한다. 물론 setuid된 프로그램인 경우라도 실행하는 사용자에게 해당 프로그램의 실행 권한이 있는 경우에만 실행할 수 있다. 다시 말해, setuid root 작업은 특정 프로그램을 실행시 프로그램을 실행한 사용자가 아닌 root 사용자 권한으로 프로세스가 실행되도록 설정하는 작업을 의미한다.
여기서 말하는 프로세스의 사용자는 UNIX 프로세스의 유효 사용자(effective userid)를 말한다. tjclrun은 프로세스가 실행되는 동안 프로세스의 실제 사용자 정보(real userid)를 tjclrun의 환경설정과 관계없이 전혀 변경하지 않는다. UNIX 시스템에서 파일 및 시스템 자원에 대한 권한 검사는 프로세스의 유효 사용자에 대해서 이루어진다.
실제 사용자 정보는 실제적으로 프로세스를 호출한 사용자를 구분하기 위한 용도로 사용된다. 또한 여기서 말하는 사용자는 TACF 사용자와는 직접적인 관련이 없는 운영 시스템 상의 사용자를 의미한다.
다음의 두 가지 사항을 고려하여 필요한 경우 OpenFrame TJES를 설치한 후에 tjclrun 프로그램에 대하여 root 실행 권한을 부여할지 여부를 결정한다.
-
JOB CONTROL을 수행하는 경우 tjclrun이 실행한 Batch 프로그램이 tjclrun을 실행하는 프로세스의 유효 사용자와 다른 유효 사용자로 실행되는 경우 tjclrun은 UNIX JOB CONTROL 시그널에 기반한 JOB CONTROL을 권한 부족의 이유로 성공적으로 수행할 수 없다. 이러한 경우에도 성공적으로 JOB CONTROL을 하려면 tjclrun 프로그램에 root 실행 권한을 부여하는 것을 고려해야 한다.
혹은 위와 같은 상황은 매우 예외적인 상황으로 운영자가 직접 root 사용자로 로그인해서 해당 프로세스에 대해서 JOB CONTROL 시그널을 보낼 수도 있지만 이러한 수작업은 더디고 운영자의 업무부담을 높이는 요소가 될 수 있다. 예를 들면, tjclrun이 실행하는 Batch 프로그램에 대해서 tjclrun 프로세스의 유효 사용자가 아닌 다른 사용자로 setuid 처리가 되어 있는 경우에 이러한 문제가 발생한다.
-
JOB을 수행하는 tjclrun 및 JOB STEP에서 실행되는 Batch 프로그램을 실행하는 프로세스를 JOB에 지정된 USER의 권한으로 실행하기 위해서는 OpenFrame 환경설정의 tjclrun 서브젝트, ACCOUNT 섹션의 SETUID=YES로 설정해야 할 뿐만 아니라 tjclrun 프로그램을 설치할 때 root 실행 권한을 부여해야 한다.
UNIX 운영 시스템에서 프로세스를 실행하는 사용자 정보를 프로그램 실행 중에 변경하기 위해서는 특권 User(root)의 권한이 필요하기 때문이다. 이러한 제약을 피하기 위해서 TJES 시스템 자체를 root로 운영하는 것도 하나의 방법이지만 시스템 보안 및 관리상의 이유로 root로 서비스를 운영하는 것은 권장하지 않는다. 그 대신 tjclrun 프로그램만 다음과 같이 setuid root 작업을 해주면 tjclrun 프로그램을 실행하는 사용자가 root가 아니더라도 tjclrun 실행할 때에 tjclrun 프로그램 파일의 소유자(root)의 권한으로 tjclrun이 실행된다.
다음의 예는 setuid root 절차를 보여준다.
$ cd $OPENFRAME_HOME/bin
$ su
$ chown 0:0 tjclrun
$ chmod s+u tjclrun
$ ls -l tjclrun
-rwsr-xr--x root system {size} {date-time} tjclrun
$ exit
파일 퍼미션이 -rwsr-xr- -x이고 소유자가 root로 변경된 것을 확인한다. 자세한 사항은 UNIX 안내서의 "man chmod" 및 "man chown"를 참고한다.
프로그램이 실행된 직후에 tjclrun은 root 권한을 가지고 있으므로 JCL에 지정된 USER의 권한으로 프로세스 사용자를 변경할 수 있다. tjclrun은 실행 초기의 매우 제한된 작업만을 root 권한으로 수행하고 JOB을 수행하는 대부분의 작업은 JCL에 지정한 사용자의 권한으로 실행된다.
JOB의 프로세스 어카운팅과 STOP과 같은 JOB CONTROL을 사용하지 않는 경우라면 tjclrun 프로그램에 대한 setuid 절차와 tjclrun 환경설정의 setuid 관련 설정은 필요하지 않다.
IBM AIX의 경우 setuid root된 프로그램을 실행하는 경우 보안상의 이유로 공유 라이브러리를 찾는 환경 변수인 LIBPATH가 클리어되어 버리기 때문에 tjclrun을 실행하면 tjclrun이 사용하는 OpenFrame 제품의 공유 라이브러리들을 로딩할 수 없는 문제가 있다. 이를 해결하는 방법은 tjclrun 프로그램을 고객사에 설치한 이후에 재링크하는 것이다. 이렇게 하면 환경 변수 LIBPATH에 의존하지 않고 링크를 수행할 때 찾았던 디렉터리에서 필요한 공유 라이브러리를 찾는다. 즉, IBM AIX 운영 시스템의 경우 외부 사용자에 의해 악의적으로 변경된 공유 라이브러리가 root 권한을 갖는 프로세스에서 사용되는 것을 방지하기 위한 운영 시스템상의 정책이라고 볼 수 있다. |
다음의 예는 IBM AIX에서 tjclrun을 재링크하는 방법을 보여준다.
$ cd $OPENFRAME_HOME/bin
$ cp tjclrun tjclrun.bak
$ cc -q64 -brtl -o tjclrun.new ¥
> ./tjclrun ¥
> -L$OPENFRAME_HOME/lib -L$TB_HOME/client/lib -L$TMAXDIR/lib64 ¥
> -ljcl -licf -ldsio -lspool -ltjes -ljmcliout -lsms -lsaf ¥
> -ldsalc -lpgmdd -lams -lbinfmt -lofcom -llockm -lcli
$ cp tjclrun.new tjclrun
OpenFrame 운영 사용자 환경에서 재링크 작업을 수행한 후에 위에서 설명한 setuid root 절차를 수행한다. 재링크할 때 함께 링크 해주어야 하는 라이브러리들은 (위의 예제에서 -ljcl 부터 -lcli 부분까지) ldd tjclrun 명령으로 출력되는 tjclrun이 사용하는 라이브러리 중에서 OpenFrame 제품에 포함된 라이브러리이다.
|
2.13. tjclrun 호출
tjclrun은 다음과 같은 실행 인자와 함께 실행된다.
TJES의 Runner Slot은 JOB의 실행을 할당 받은 당시의 TJES의 상태에 기반하여 적절한 실행인자와 함께 실행된다.
tjclrun RUNMODE JOBID INITINDEX JCLPATH JOBPOS RESTART
인자 | 설명 |
---|---|
RUNMODE |
JOB(normal run) 또는 SCAN (syntax test) 테스트이다. |
JOBID |
유일한 JOBID이다. (예: JOBnnnnn) |
INITINDEX |
Runner Slot 인덱스이다. |
JCLPATH |
실행 대상인 JCL의 경로 정보이다. |
JOBPOS |
Job Stream에 JOB이 여러 개 있는 것을 고려한 실행할 JOB의 위치이다. |
RESTART |
재시작할 JOB STEP을 지정한다.
|
tjclrun을 쉘의 명령어 라인에서 직접 실행하는 것은 TJES의 JOB 관리의 submit 및 스케줄링 단계를 건너뛰고 직접 실행하는 경우이므로 정상적인 JOB의 실행이 보장되지 않는다. |
2.14. XSP 지원표
다음은 XSP statement 지원 여부를 설명한 표이다.
-
XSP JCL statement
Statement Parameter 지원여부 비고 JOBG
Job grpup name
O
WAIT
O
REL
O
MULTI
O
PRTY
O
ACCT
X
DVAL
O
LB
X
PGID
X
RSIZE
X
ASR
X
CODE
Job code
X
작업 식별 기능은 JOBID로 대체됨
JOB
Job name
O
LIST
X
ACCT
X
PSW
X
PRTY
O
TIME
X
ML
O
RSIZE
X
PARA
O
LANG
X
OG
X
HOLD
O
OHOLD
X
RSTEP
O
MULTI
X
MKEY
X
FORM
X
FORMS
X
BURST
X
BOXNO
X
EX
Program name
O
VSPEC
X
RSIZE
X
PRTY
X
TIME
X
COND
O
OPT
X
PARA
O
LANG
X
NOMNT
X
PARAGRP
X
PARA
Parameters
O
FD
Access name
O
FILE
O
VOL
O
DISP
O
MEMBER
O
영역할당
O
RSV
X
DRTY
X
PSW
X
PROTECT
X
RETPD
X
PRTYPE
X
SOUT
O
OG
O
LIMIT
X
FORM
O
FORMS
O
CHARS
O
COPIES
O
FLASH
O
BURST
X
MODIFY
X
DATA
X
SW
O
FCB
O
AMP
X
DIAG
X
PSIZE
X
ISF
X
SW
Access name
O
STEP
O
FILE
O
VOL
O
DISP
O
MEMBER
O
PROTECT
X
PRTYPE
X
FCB
O
AMP
X
PAUSE
message
O
MSG
message
O
NOTE
message
X
JEND
O
JGEND
O
FIN
O
SYSIN
UNIT
X
FILE
O
VOL
X
MEMBER
X
DISP
X
매크로 소환문
params
O
CHAM
FILE
O
VOL
O
PSW
X
MACRO
params
X
MEND
X
FDR
X
FDDS
FD 이름
O
DATA
X
DISP
O
VOL
X
FDDE
O
STACK
FILE
O
VOL
O
MEMBER
O
RJ
X
RJS
O
JG
X
OG
X
지령문
FSOUT
X
JALT
O
STACK
O
CAT
FILE
X
VOL
X
DISP
X
UNCAT
FILE
X
DISP
X
DATA
UNIT
O
FILE
O
VOL
O
DISP
X
MEMBER
O
영역할당 params
X
DRTY
X
PSW
X
PROTECT
X
RETPD
O
DATA
X
JOBG
O
END
O
SCAN
*
X
SCAN 기능만 지원
JN
X
LIST
X
FILE
X
VOL
X
DISP
X
MEMBER
X
영역할당 params
X
DRTY
X
PSW
X
PROTECT
X
RETPD
X
DATA
X
SCEND
O
USER
이용자 식별명
O
UPSW
O
GROUP
O
UEND
O
NOP
O
주석문
O
입력데이터 단락문
O
EOF 카드
O
-
XSP JCM(매크로) statement
Statement Parameter 지원여부 비고 DEFINE
O
정의 본체문
O
SKIP
O
IF
O
IFN
O
SET
O
MSG
X
WTO
X
WTOR
X
NOP
O
DEXIT
O
DEFEND
O