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 CLASS와 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 애플리케이션을 실행하는 등 많은 세부작업으로 이루어져있다.

EXEC 문의 PGM 파라미터를 이용해 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 실행 단계에서 수행하는 다양한 세부 작업을 분류한 표이다.

작업	단계
실행	실행 초기화
입력 JOB 스트림 파싱
실행 과정
EXEC PGM 처리
EXEC PROC 처리
리소스	DD 처리
스페셜 DD
OUTPUT 처리
JOB SPOOL
컨트롤/모니터링	JOB CONTROL
JOB Level Report
STEP Level Report
기타	보안 (TACF support)
tjclrun 호출 (tjclrun 명령어 사용)
NICE를 통한 PERFORM 처리

작업

단계

실행

리소스

컨트롤/모니터링

기타

tjclrun 호출 (tjclrun 명령어 사용)

NICE를 통한 PERFORM 처리

2.1. 실행 초기화

다음은 Runner Slot 또는 SUBMITOR 등에 의해 Runner가 호출되기 전에 준비되는 필수 리소스들이다.

JOBID
JOBQ의 JOB 엔트리
Runner Slot
JOB SPOOL (INPJCL)

실행 초기화는 다음의 과정으로 진행된다.

명령어 라인 인수

Runner Slot은 tjclrun을 호출할 때 지정한 인수(args)를 검사하고 이로부터 JOBID 및 실행할 JCL 파일의 위치 그리고 기타 처리 파라미터를 전달받는다.

디버깅 목적 등의 특수한 경우에는 셸을 통해 tjclrun을 실행할 수 있지만, TJES의 Runner Slot를 통해 tjclrun을 실행하는 것이 일반적이다. TJES를 통하지 않고 tjclrun을 실행한 경우 TJES의 전체적인 JOB 관리대상에서 제외될 뿐만 아니라 요구되는 정상적인 단계를 실행하지 않을 수 있다.

환경설정 읽기

OpenFrame 환경설정에 tjclrun 서브젝트의 각 섹션과 키를 읽어서 해당 설정에 맞는 tjclrun 실행 방식을 결정한다.
실행 계정

기본적으로 JOB 실행될 때 tjclrun 프로세스의 소유자는 TJES 운영자의 운영체제 계정과 동일하다. 즉, TJES 시스템을 운영체제의 obm이라는 사용자 계정에서 기동한 경우 tjclrun 프로세스와 각 JOB STEP에서 실행되는 Batch 프로그램의 사용자 ID도 obm이 된다.

그러나 OpenFrame 환경설정에 tjclrun 서브젝트, ACCOUNT 섹션의 SETUID 키의 VALUE 항목을 YES로 설정하면 JCL JOB 문의 USER에 지정된 사용자로 tjclrun 프로세스를 실행할 수 있다. 자세한 내용은 보안의 setuid root tjclrun을 참고한다.
SYSLIB 초기화

tjclrun은 OpenFrame 환경설정에 tjclrun 서브젝트, SYSLIB 섹션에 설정된 디렉터리 위치에서 JOB STEP에 지정된 프로그램을 찾는다. SYSLIB 섹션을 설정하지 않은 경우 사용자의 환경변수에 지정된 디렉터리에서 프로그램을 찾는다. JCL에 JOBLIB DD 또는 STEPLIB DD가 있는 경우는 SYSLIB보다 JCL에 기술된 JOBLIB 및 STEPLIB이 우선한다.

일부 UNIX 시스템에서 tjclrun에 root 권한을 부여하여 운영하는 경우에 환경변수가 지워지는 문제가 있으므로 OpenFrame 환경설정의 tjclrun 서브젝트, SYSLIB 섹션을 반드시 설정해야 한다. 그렇지 않으면 tjclrun은 JCL에 지정된 프로그램을 실행하거나 tjclrun을 로딩하는 단계에서 실패하게 된다. 자세한 내용은 보안의 setuid root tjclrun을 참고한다.
SYSMSG DD 열기

tjclrun이 수행하는 일반적인 JOB 실행 단계에서 발생하는 에러 및 세부 작업의 결과 보고는 JOB SPOOL의 SYSMSG에 저장된다. tjclrun은 실행 초기화 단계에서 내부적인 로그 메시지를 저장하기 위해서 SYSMSG를 미리 열어둔다.

다음의 경우에 로그가 SYSMSG에 저장된다.
- tjclrun 내부적인 오류 및 시스템 함수 실패 등 문제 분석용으로 사용되는 tjclrun 인터널 로그
  
  tjclrun의 문제 분석용 로그를 출력하기 위해서는 OpenFrame 환경설정에 tjclrun 서브젝트, DEBUG 섹션의 PROFILE 키의 VALUE 항목을 YES로 지정해야 한다.
- OpenFrame 라이브러리에서 출력되는 stderr
  
  OpenFrame 라이브러리에서 출력되는 stderr는 OpenFrame 전체 로그 형식을 따르고 있어서 SYSMSG와는 출력 형식이 다르다.
JOB 시작 보고

tjclrun이 지정된 JOB을 실행하기 시작했음을 TJES에게 보고한다.
JOB SPOOL 열기

JOB의 실행단계에서 사용하기 위해 JOB SPOOL을 연다.

tjclrun 서브젝트에 대한 자세한 내용은 "OpenFrame 환경설정 안내서"를 참고한다.

2.2. 입력 JCL 파싱

tjclrun은 JOB SPOOL을 통해 전달된 JCL 파일(INPJCL)을 분석하여 JOB을 실행한다. tjclrun이 실행하는 JOB 문을 포함한 (JOB SPOOL에 저장된) JCL 파일을 JOB 스트림(JOB Stream)이라고 한다.

JCL 프러시저 파싱

tjclrun은 하나의 JOB을 실행하는 동안 여러 번 JCL을 파싱한다. 기본적으로 JOB 문을 포함하고 있는 INPJCL을 파싱하여 실행에 들어간다. INPJCL의 내용을 순차적으로 실행하는 중에 JCL 프러시저의 호출이 지정되어 있으면 해당 JCL 프러시저를 파싱하고 그 프러시저를 실행한다. 해당 프러시저의 실행이 끝나면 다시 이전 INPJCL을 계속 실행한다.

JCLLIB/JOBPARM PROCLIB

tjclrun은 JCLLIB 문장에 지정된 JCL 라이브러리(라이브러리, PDS 데이터 셋)에서 해당 JCL 프러시저를 찾는다. tjclrun은 JOB을 실행하는 중에 파싱이 필요한 JCL 프러시저나 INCLUDE JCL을 JCLLIB 문장 이외에도 JOBPARM 명령의 PROCLIB 파라미터에 기술된 ddname에 해당하는 JCL 라이브러리에서 찾는다. 파싱이 필요한 대상을 앞에서 설명한 JCL 라이브러리 상에서 찾을 수 없는 경우에는 마지막으로 SYS1.PROCLIB이라는 기본 위치에서 찾는다. 여기에서도 찾을 수 없는 경우 JOB은 비정상 종료 처리 즉, JOB은 FLUSH 상태로 종료된다.

INPJCL(JOB 스트림)에 JOBPARM 명령이 지정된 경우 이 명령의 PROCLIB 파라미터에 지정된 ddname은 환경설정 테이블의 tjes 서브젝트, PROCLIB 섹션에 키로 설정되어 있어야 한다.

INCLUDE

INCLUDE 문장의 처리될 때 INCLUDE되는 JCL도 앞에서 설명한 JCLLIB 문이나 JOBPARM 명령의 PROCLIB 파라미터에 지정된 JCL 라이브러리에서 찾는다.

2.3. 실행 과정

실행해야 하는 JOB의 INPJCL(JOB 스트림)을 파싱한 이후에 tjclrun은 JCL에 기술된 순서에 따라 JOB STEP을 실행한다.

JCL의 JOB 문에 RESTART 파라미터가 지정된 경우 RESTART 파라미터에 지정된 JOB STEP부터 실행한다.

실행 단계

파싱 이후의 JOB 실행은 다음과 같이 크게 2단계로 이루어진다.

Lock phase

해당 JOB에서 사용되는 데이터셋에 대한 Lock을 설정하는 단계이다.
Exec phase

실제로 JOB STEP을 순서대로 실행하는 단계이다.

tjclrun은 미리 INPJCL 및 JCL 프러시저를 분석하여 해당 JOB에서 사용할 데이터셋의 리스트를 얻고 실제 실행 단계에 들어가기 전에 해당 데이터셋들에 대해 일괄적으로 Lock을 요청함으로써 서로 다른 여러 개의 JOB이 동시에 동일한 데이터셋을 독점적(exclusive)으로 사용하는 경우 빈번하게 발생되는 Dead Lock 상황을 방지한다.

JOB에서 사용하는 데이터셋들에 대한 Lock 요청 단계가 성공적으로 수행되면 실제 실행 단계를 수행한다. 실제 실행 단계(Exec phase)는 다음과 같이 처리된다.

EXEC PGM STEP

처리해야 하는 JOB STEP이 Batch 프로그램을 실행하는 경우(EXEC 문의 PGM) 지정된 Batch 프로그램을 실행한다. tjclrun은 Batch 프로그램을 자신의 자식 프로세스로서 실행하고 그 프로그램의 실행이 종료될 때까지 기다린다. 실행한 Batch 프로그램의 실행이 종료되기를 기다리는 중에 주기적으로 Batch 프로그램이 수행한 데이터셋 I/O 통계 등의 정보를 TJES에 보고한다.
EXEC PROC STEP

처리해야 하는 JOB STEP이 JCL 프러시저를 호출하는 경우(EXEC 문의 PROC) 지정된 JCL 프러시저를 파싱하고 그 결과를 가지고 해당 프러시저를 실행한다. 호출된 JCL 프러시저에서 또다시 다른 JCL 프러시저를 호출할 수 있다. 이것을 중첩된(nested) JCL 프러시저 호출이라고 한다. 중첩된 JCL 프러시저는 최대 15 레벨까지 호출될 수 있다.

JCL 프러시저 STEP을 실행하고 나면 해당 JCL 프러시저를 호출한 원래의 STEP으로 돌아가서 그 다음 STEP부터 계속 실행해 나간다.

조건 실행

다음과 같이 서로 다른 방식으로 JOB을 구성하는 JOB STEP을 조건적으로 실행할 수 있다.

EXEC COND

실행한 이전 JOB STEP의 종료 상태에 따라서 다음에 실행할 JOB STEP을 처리할지 건너뛸지를 결정한다. 이러한 방식의 조건적인 JOB STEP의 실행은 EXEC 문의 COND 파라미터를 이용하여 지정한다.
JOB COND

실행한 Batch 프로그램이 종료하면 프로그램의 종료 상태가 JOB 문의 COND(예외상황)를 만족하는지 검사하고 JOB 문의 COND를 만족하면 더 이상의 JOB STEP을 실행하지 않는다.

JOB 문의 COND가 만족되지 않는 경우는 다음 JOB STEP을 계속해서 실행한다.
IF-THEN/ELSE/ENDIF

IF-THEN/ELSE/ENDIF 문에 기술된 조건을 평가하여 조건적으로 JOB STEP을 실행한다.

2.4. EXEC 프로그램 처리

tjclrun의 가장 중요한 역할이 바로 사용자가 지정한 Batch 프로그램을 실행하는 것이며, 다음과 같은 세부 작업으로 이루어진다.

EXEC COND

EXEC PGM STEP을 실행하기 전에 먼저 해당 EXEC 문에 기술된 COND 파라미터를 평가하여 이전 STEP의 실행 결과가 EXEC COND를 만족하는 경우(예외 상황인 경우) 해당 EXEC PGM STEP을 실행하지 않고 건너뛴다.

JOB에서 실행되는 첫 번째 JOB STEP은 항상 EXEC COND가 만족하지 않는 것으로 평가된다.

EXEC COND가 만족되지 않는 경우는 해당 JOB STEP (EXEC PGM STEP)을 다음과 같은 절차로 실행한다.

STEP 진행 보고

해당 EXEC PGM STEP의 처리 시작을 TJES에게 보고한다.
PGM 실행 권한

EXEC PGM에 지정된 Batch 프로그램이 주요 유틸리티인 경우 JOB USER가 해당 프로그램을 실행할 수 있는 권한이 있는지 검사한다. OpenFrame 환경설정에 tjclrun 서브젝트, TACF 섹션의 CHECK_UTAUTH 키의 VALUE 항목이 YES로 설정되어 있는 경우에만 권한 검사를 수행한다.
STEP DD 할당

EXEC PGM STEP에서 호출할 Batch 프로그램이 사용할 데이터셋을 지정하는 DD 문을 처리하여 데이터셋을 할당한다. 한 STEP에서 중복 DD가 발견된 경우에는 나중에 지정된 DD는 tjclrun에서 임의의 DD로 변경하여 Batch 프로그램에서 사용되지 않도록 한다. JOB STEP 레벨의 스페셜 DD문에 대한 부가적인 처리도 이 단계에서 처리된다.

JOB STEP 레벨의 스페셜 DD 문으로는 STEPCAT DD 및 STEPLIB DD 문이 있다.
PGM 파라미터

EXEC PGM에 지정된 Batch 프로그램에 전달될 실행 파라미터를 만든다. Batch 프로그램은 이 파라미터를 일반적인 UNIX 프로그램의 argc 또는 argv를 통해서 얻을 수 있다.

EXEC PROC에 지정된 PARM은 호출되는 JCL 프러시저 내부에 포함된 EXEC PGM의 PARM의 값을 덮어쓰도록 전달한다.
호출/실행

실제로 시스템 함수를 이용하여 EXEC PGM에 지정된 Batch 프로그램을 호출(fork)하는 단계이다. TJES에서 Batch 프로그램은 tjclrun 프로세스의 자식 프로세스(child process)로서 실행된다. 그러기 위해서 먼저 호출(fork)를 실행하여 자식 프로세스를 생성하고 자식 프로세스에서 EXEC를 실행하여 지정된 Batch 프로그램을 시작한다.

SYSIN/SYSOUT 파이프

OpenFrame에서는 Batch 프로그램이 사용하는 SYSIN DD와 SYSOUT DD를 일반적인 UNIX 프로그램의 stdin과 stdout으로 구현하였다.

tjclrun은 비유적으로 볼 때 셸의 명령어 라인을 이용하여 Batch 프로그램을 실행하는 사용자와 같은 역할을 수행한다고 볼 수 있다. 그런 의미에서 tjclrun은 SYSIN DD의 내용을 읽어서 애플리케이션의 stdin에 write하여 애플리케이션의 stdin으로부터 SYSIN의 내용을 읽을 수 있도록 해준다.

반대로 애플리케이션에서 stdout으로 출력한 내용은 tjclrun이 읽어서 SYSOUT DD에 해당하는 데이터셋이나 JOB SPOOL에 대신 출력해준다.

SYSIN DD와 SYSOUT DD를 UNIX 시스템의 프로그램들이 공통적으로 사용하는 stdin과 stdout으로 연결함으로써 OpenFrame의 데이터셋 API를 사용하지 않고 만들어진 대부분의 UNIX 애플리케이션들도 OpenFrame Batch 시스템에서 별도의 처리없이 Batch 프로그램으로 실행하는 것이 가능하다.

UNIX 애플리케이션의 stderr는 SYSOUT DD에 stdout의 내용과 함께 기록된다. stdout 및 stderr 모두 애플리케이션의 기본적인 출력 스트림이고 Mainframe에는 stderr에 해당하는 약속된 DD가 없기 때문에 stderr를 SYSOUT DD에 함께 저장하고 있다.
tjclrun은 JCL에 기술된 SYSOUT DD와 SYSPRINT DD를 동의어로 처리한다. 하나의 JOB STEP에 둘 다 지정된 경우는 SYSOUT DD만 사용하고 SYSPRINT DD는 무시된다.

모니터링 보고/대기

tjclrun은 EXEC PGM에 지정된 Batch 프로그램을 실행하고 해당 프로그램이 종료할 때까지 기다리면서 주기적으로 애플리케이션에서 수행한 데이터셋 I/O 카운트를 TJES에 보고한다.
STEP DD 후처리

JOB STEP에서 실행된 Batch 프로그램이 종료하면 그 종료 상태에 따라서 DD 문의 DISP 파라미터에 지정된 후처리 작업을 수행한다.

JOB STEP에서 실행된 Batch 프로그램이 정상 종료한 경우에는 Normal Disposition에 지정된 후처리를 수행하고 비정상 종료한 경우에는 Abnormal Disposition에 지정된 후처리를 수행한다. DISP의 종류는 PASS, KEEP, CATLG, UNCATLG, DELETE가 있다.

JOB COND

실행한 Batch 프로그램이 종료되면서 반환한 종료 상태(Exit status)가 JOB COND에 해당하는지 평가하여 만족되는 경우는 이후 JOB STEP을 실행시키지 않고 종료한다. 프로그램의 종료상태가 JOB COND에 해당하지 않는 경우는 뒤따르는 다음 JOB STEP을 계속하여 실행한다.

Return Code check

JOB COND를 통과했다면 tjclrun은 실행한 Batch 프로그램이 종료되면서 반환한 코드를 가지고 해당 STEP을 정상으로 처리할지, 에러로 처리할지를 결정한다. 정상으로 판단되면 뒤따르는 다음 STEP을 계속하여 실행한다. 그리고 에러로 판단되면 해당 STEP을 비정상 종료하고 뒤따르는 STEP들 중에 STEP COND가 비정상일 경우 실행하도록 지정된 STEP만을 실행한다. 비정상일 경우 실행되도록하는 조건에는 EVEN과 ONLY 파라미터가 있다.

Return Code는 OpenFrame 환경설정에 rc 서브젝트에 설정한다. 자세한 내용은 OpenFrame Batch "환경설정 안내서"를 참고한다.

2.5. EXEC PROC 처리

JOB 실행과정에서 설명했듯이 처리해야 하는 JOB STEP이 JCL 프러시저를 호출하는 EXEC PROC STEP인 경우, tjclrun은 지정된 JCL 프러시저를 파싱하고 해당 프러시저의 내용을 실행한다. 해당 프러시저의 마지막 STEP까지 실행을 한 후에는 해당 프러시저를 호출한 JOB STEP의 다음 JOB STEP들을 이어서 실행한다.

JCL 프러시저는 프러시저의 내용이 정의된 위치에 따라서 다음과 같이 2가지로 구분된다.

입력 스트림 프러시저 (INSPROC)

입력 스트림 프러시저는 해당 프러시저를 호출하는 INPJCL에 프러시저의 내용이 정의되어 있다. 입력 스트림 프러시저는 해당 프러시저가 정의되어 있는 INPJCL에서만 호출할 수 있다.
카탈로그 프러시저 (CATPROC)

카탈로그 프러시저는 JCL 프러시저들을 멤버로 갖는 JCL 라이브러리에 등록되어 있는 JCL 프러시저이다. 카탈로그 프러시저를 호출할 때는 JCL 라이브러리에 등록되어 있는 멤버이름을 EXEC PROC=procname 문의 procname에 지정해야 한다. 자주 사용되는 JCL 프러시저들을 모아놓은 JCL 라이브러리를 PROCLIB이라고 부르며, 카탈로그 프러시저는 여러 다른 JCL에서 호출할 수 있다.

tjclrun은 EXEC PROC 문에 지정된 프러시저를 INPJCL에서 먼저 찾아보고, 없는 경우에 카탈로그 프러시저로 간주하고 JCLLIB 문이나 JOBPARM 명령의 PROCLIB 파라미터에 지정된 JCL 라이브러리들에서 프러시저를 찾는다.

하나의 JCL 라이브러리에서 지정된 프러시저를 찾은 경우 그 뒤의 나머지 JCL 라이브러리에 대해서는 더 이상 검색하지 않는다.

JCLLIB 문이 존재하지 않는 경우에만 JOBPARM 명령의 PROCLIB 파라미터에 의해 지정된 DD에서 프러시저를 찾는다. (JCLLIB 문이 우선한다.)

JOBPARM PROCLIB=ddname에 지정할 수 있는 ddname은 OpenFrame 환경설정에 tjes 서브젝트, PROCLIB 섹션에 키로 설정되어 있어야 한다. 하나의 ddname에 여러 개의 JCL 라이브러리의 이름을 지정할 수 있으며, JCLLIB과 비슷하게 여러 개의 JCL 라이브러리에서 앞에서부터 순서대로 지정된 프러시저를 찾도록 설정할 수 있다.

카탈로그 프러시저를 찾은 경우, 카탈로그 프러시저를 파싱하기 전에 tjclrun은 파싱에 사용한 카탈로그 프러시저의 내용을 JOB SPOOL의 CATPROC DD에 저장해둔다. 이 CATPROC은 파싱 실행 당시의 카탈로그 프러시저의 내용을 보관함으로써 JOB 실행 결과를 검토하거나 문제점을 분석할 때 도움이 된다.
입력 스트림 프러시저(INSPROC)의 경우 INPJCL에 포함되어 있으므로 따로 저장하지 않는다.
tjes 서브젝트 설정방법에 대한 자세한 내용은 OpenFrame Batch "환경설정 안내서"를 참고한다.

2.6. DD 처리

tjclrun은 JCL의 DD 문에 기술된 Batch 프로그램이 사용할 데이터셋을 할당하여 Batch 프로그램에서 사용할 수 있도록 해준다. 일반적인 Batch 프로그램은 자신이 사용할 데이터셋을 스스로 할당하지 않고 JCL에 DD 문을 기술함으로써 tjclrun이 할당하게 하고 그 결과를 상속받아서 사용한다.

데이터셋 할당 작업은 EXEC PGM STEP에서 Batch 프로그램을 실행하기 전에 수행된다. Batch 프로그램이 종료된 이후에는 할당한 데이터셋에 대한 후처리 작업을 tjclrun이 해준다. 할당된 데이터셋은 JOB이 종료될 때 즉, tjclrun이 종료될 때에 할당 해제된다.

데이터셋의 할당 작업은 DD 문에 기술된 데이터셋의 특성에 따라서 서로 다르게 처리되는데 크게 다음과 같이 구분할 수 있다.

Normal 데이터셋

가장 일반적인 경우로 DSNAME 파라미터에 할당할 데이터셋의 이름이 주어진 경우이다. OpenFrame의 데이터셋 할당 모듈을 호출하여 데이터셋을 할당하고 애플리케이션이 이 데이터셋을 사용할 수 있도록 그 결과를 애플리케이션의 환경으로 전달한다.

SYSOUT 데이터셋

DD문에 SYSOUT 파라미터가 지정된 데이터셋이다. SYSOUT 데이터셋은 JOB SPOOL에 JOB의 실행 결과로 생성되는 출력 데이터를 저장하기 위해서 생성된다.

ddname이 SYSOUT인 경우와 DD에 SYSOUT 파라미터가 있는 경우는 엄밀히 얘기하면 서로 다른 데이터셋이다. SYSOUT 데이터셋은 후자이다. SYSOUT DD는 단지 DD 이름이 SYSOUT인 경우이다. 일반적으로는 SYSOUT DD SYSOUT=* 와 같이 코딩하기 때문에 혼동하는 경우가 많다.

임시 데이터셋

DD 문의 DSNAME 파라미터에 지정된 데이터셋 이름이 '&&'로 시작되거나 DSNAME 파라미터가 지정되지 않은 SYSOUT 데이터셋 외의 데이터셋 역시 임시 데이터셋이다. 이 경우 tjclrun은 내부적으로 임시 데이터셋에 유일한 이름을 부여한다. 임시 데이터셋은 JOB의 실행 과정에서 생성되고 JOB이 종료될 때 삭제되는 임시 데이터셋이다.

tjclrun은 사용자가 지정한 임시 데이터셋 이외에도 내부적인 용도로 몇 개의 임시 데이터셋을 사용한다.

다음에 설명한 입력 스트림 데이터셋의 처리도 그 한가지 예이다.
- 입력 스트림 데이터셋
  
  INPJCL(JOB 스트림)에 DD * 또는 DD DATA의 형태로 기술된 데이터셋을 말한다.
  
  tjclrun은 입력 스트림 데이터셋을 JOB SPOOL에 따로 저장해 둔 다음에 내부적인 데이터셋 이름을 부여한다. 그 이후는 일반적인 데이터셋과 동일한 OpenFrame 데이터셋 처리 모듈을 이용해서 할당하고 Batch 프로그램에서 이 데이터셋을 사용할 수 있게 된다. tjclrun은 JOB SPOOL에 임시로 저장한 입력 스트림 데이터셋이 JOB 종료할 때 제거될 수 있도록 임시 데이터셋으로 생성한다.

2.7. 스페셜 DD

DD 문장은 다음의 형태로 JCL에 코딩된다.

//ddname DD [parameters,...]

시스템에서 특수한 용도로 사용하기 위해 예약되어있는 ddname을 갖는 DD 문을 스페셜 DD 문이라고 부른다.

사용자는 특수한 용도로 사용하기 위해 예약된 스페셜 DD의 ddname을 약속된 이외의 용도로 사용할 수 없다.

TJES는 다음과 같은 스페셜 DD를 지원한다.

SYSIN DD

현재 실행 중인 JOB STEP에 SYSIN DD 문이 지정된 경우 tjclrun은 SYSIN DD 문에 지정된 데이터셋의 내용을 읽어서 tjclrun이 실행한 Batch 애플리케이션의 stdin으로 전달한다. 즉, 애플리케이션은 SYSIN DD에 의해 할당된 데이터셋의 내용을 stdin으로부터 읽을 수 있다.
SYSOUT DD/SYSPRINT DD

현재 실행 중인 JOB STEP에 SYSOUT DD 또는 SYSPRINT DD가 존재하는 경우, tjclrun이 호출하는 Batch 프로그램 대신 이 DD가 지정하는 데이터셋을 개방하고, Batch 프로그램이 stdout이나 stderr로 출력하는 내용을 읽어서 SYSOUT DD 또는 SYSPRINT DD에 의해 할당된 데이터셋에 Batch 프로그램을 대신하여 출력한다. 이렇게 하는 이유는 OpenFrame 데이터셋 I/O 함수를 사용하지 않고 stdout이나 stderr에 직접 메시지를 출력하는 대부분의 애플리케이션을 JCL에 의해서 자연스럽게 실행할 수 있게 하기 위함이다.

SYSOUT DD와 SYSPRINT DD는 동일한 의미로 취급한다. 2개의 DD가 둘 다 존재하는 경우에는 항상 SYSOUT DD를 사용하고 SYSPRINT DD는 사용하지 않는다.

JOBLIB DD/STEPLIB DD

JOBLIB DD와 STEPLIB DD는 tjclrun이 EXEC PGM=pgmname에 지정된 Batch 애플리케이션을 찾는 PDS 데이터셋(라이브러리 경로)을 지정한다.

구분	설명
JOBLIB DD	JOBLIB DD는 INPJCL의 JOB 문과 첫 번째 EXEC 문장 사이에 지정될 수 있고, 해당 JOB에서 호출되는 프로그램을 찾는 PDS(라이브러리)를 지정한다. DD 문의 concatenation 기능을 이용하여 여러 PDS에서 프로그램을 찾아보도록 지정할 수 있다.
STEPLIB DD	해당 JOB STEP의 EXEC 문 다음에 위치하며, JOB STEP에서 호출하는 프로그램을 찾을 PDS(라이브러리)를 지정한다. 역시 DD 문의 concatenation을 이용하여 여러 PDS에서 프로그램을 찾아보도록 지정할 수 있다. STEPLIB DD가 지정되어 있으면 JOB STEP에서 호출하는 프로그램을 STEPLIB DD가 지정하는 PDS(라이브러리)들에서 찾는다. 이 경우 JOBLIB DD는 사용되지 않는다.

구분

설명

JOBLIB DD

JOBLIB DD는 INPJCL의 JOB 문과 첫 번째 EXEC 문장 사이에 지정될 수 있고, 해당 JOB에서 호출되는 프로그램을 찾는 PDS(라이브러리)를 지정한다. DD 문의 concatenation 기능을 이용하여 여러 PDS에서 프로그램을 찾아보도록 지정할 수 있다.

STEPLIB DD

해당 JOB STEP의 EXEC 문 다음에 위치하며, JOB STEP에서 호출하는 프로그램을 찾을 PDS(라이브러리)를 지정한다. 역시 DD 문의 concatenation을 이용하여 여러 PDS에서 프로그램을 찾아보도록 지정할 수 있다. STEPLIB DD가 지정되어 있으면 JOB STEP에서 호출하는 프로그램을 STEPLIB DD가 지정하는 PDS(라이브러리)들에서 찾는다. 이 경우 JOBLIB DD는 사용되지 않는다.

JOBLIB DD는 STEPLIB DD가 없는 JOB STEP에서 사용된다. JOBLIB DD와 STEPLIB DD가 둘 다 지정되지 않은 경우는 OpenFrame 환경설정에 tjclrun 서브젝트, SYSLIB 섹션에 지정된 위치에서 실행할 Batch 프로그램을 찾는다.

JOBLIB이나 STEPLIB DD의 concatenation 기능에 대해서는 Mainframe의 "JCL Reference Guide"를 참고한다.

JOBCAT DD/STEPCAT DD

JOBCAT DD와 STEPCAT DD는 JOB 및 JOB STEP에서 사용할 데이터셋 카탈로그를 지정한다. 2가지 경우 모두 DD문의 concatenation을 이용해서 여러 데이터셋 카탈로그를 지정할 수 있다.

구분	설명
JOBCAT DD	JOB 스트림의 JOB 문장과 첫 번째 EXEC 문장 사이에만 지정될 수 있고, 그 JOB에서 기본적으로 사용할 데이터셋 카탈로그들을 지정한다.
STEPCAT DD	JOB STEP의 EXEC 문 다음에 위치하며, 그 JOB STEP에서 사용할 데이터셋 카탈로그를 지정한다.

구분

설명

JOBCAT DD

JOB 스트림의 JOB 문장과 첫 번째 EXEC 문장 사이에만 지정될 수 있고, 그 JOB에서 기본적으로 사용할 데이터셋 카탈로그들을 지정한다.

STEPCAT DD

JOB STEP의 EXEC 문 다음에 위치하며, 그 JOB STEP에서 사용할 데이터셋 카탈로그를 지정한다.

JOBCAT과 STEPCAT이 모두 지정된 경우는 STEPCAT이 사용된다. JOBCAT이 지정되어 있고 STEPCAT이 지정되어 있지 않은 JOB STEP에서는 JOBCAT이 사용된다. JOBCAT 및 STEPCAT이 전혀 지정되지 않은 JOB에서는 OpenFrame 시스템의 마스터 카탈로그가 사용된다.

JOBCAT이나 STEPCAT이 지정된 경우도 지정된 카탈로그에 데이터셋이 카탈로깅되어 있지 않은 경우는 마스터 카탈로그에서 데이터셋에 대한 카탈로그 정보검색을 시도한다.

2.8. OUTPUT 처리

JCL OUTPUT 문은 JOB SPOOL에 생성되는 SYSOUT 데이터셋의 출력처리 방법을 나타내거나 제어하기 위한 JCL 문장이다. SYSOUT 데이터셋을 나타내는 DD 문은 하나 이상의 OUTPUT 문을 참조하여 해당 출력을 처리하기 위한 방법을 지정할 수 있다.

OUTPUT 문에 지정할 수 있는 대부분의 파라미터는 OUTPUT 문을 통하지 않고 직접 SYSOUT 데이터셋을 나타내는 DD 문에 지정할 수도 있다. 그러나 DD 문의 고유한 용도에 혼동을 줄 수 있고, 출력제어를 좀 더 엄밀하고 여러 DD에 중복으로 코딩하는 일을 피하기 위해서 OUTPUT 문을 통해서 출력제어를 나타내는 것을 권장한다. 실제로 OUTPUT 문에는 지정 가능하지만 SYSOUT DD 문에는 지정할 수 없는 파라미터가 존재한다.

2.9. JOB SPOOL

tjclrun은 JOB을 수행하는 여러 단계에서 다양한 목적으로 JOB SPOOL을 사용한다.

tjclrun이 JOB SPOOL에 생성하는 데이터셋과 각각의 용도는 다음과 같다.

INPJCL

tjclrun이 실행하는 JOB 스트림을 담고 있는 JCL 파일이다.

JOB SPOOL의 다른 대부분의 파일은 tjclrun에 의해 생성되는 것에 반하여 INPJCL은 TJES의 SUBMITOR(obmjmsvr)가 JOB의 submit 처리를 하는 경우 추후에 tjclrun이 사용할 수 있도록 JOB SPOOL에 미리 만들어둔다. 그 내용은 사용자가 submit한 JCL 파일과 동일하다.
CATPROC

tjclrun이 JOB을 실행하는 과정에서 카탈로그 프러시저를 처리할 때 사용한 카탈로그 프러시저의 내용을 저장하는 SPOOL 데이터셋이다.

하나의 JOB에서 여러 개의 카탈로그 프러시저를 호출할 수 있기 때문에 CATPROC에는 JOB에서 사용한 여러 카탈로그 프러시저의 내용이 저장된다. tjclrun이 카탈로그 프러시저를 파싱한 순서대로 그 내용이 CATPROC에 저장되고, 부가적으로 어떤 JOB STEP에서 해당 카탈로그 프러시저가 호출되었는지를 나타내는 메시지가 각 프러시저의 내용 앞에 추가된다.

INSDSET

INPJCL에 다음과 같은 형태로 기술되어 있는 입력 스트림 데이터셋을 tjclrun이 내부적으로 사용하기 위해서 JOB SPOOL에 생성하는 임시 데이터셋이다.

다음은 입력 스트림 데이터셋을 설정하는 예이다.

//ddname DD *
 line1
 line2
 ...
 lineN
/*

위의 예제의 경우 INSDSET은 line1, line2,..., lineN을 내용으로 하는 임시 데이터셋으로 해당 DD를 사용하는 JOB STEP에서 생성되며, 해당 JOB STEP이 종료될 때 삭제되는 임시 데이터셋이다. 이러한 동작을 INSDSET SHUNT라고 부른다.

임시 데이터셋을 생성할 때 레코드 길이는 OpenFrame 환경설정에 tjclrun 서브젝트, DD 섹션의 INSDSET_LRECL 키의 VALUE 항목 지정에 따른다. 해당 값은 1부터 4096까지 지정할 수 있으며, 지정하지 않는 경우 기본 길이는 80이고 입력 스트림이 레코드 길이보다 작을 경우 부족한 부분은 스페이스로 채운다. 기본 길이보다 큰 경우에는 뒤 부분은 버려진다.

tjclrun이 INSDSET SHUNT를 하는 이유는 입력 스트림 데이터셋은 일반 Non-VSAM 데이터셋과 함께 concatenation될 수 있기 때문에 입력 스트림 데이터셋을 INPJCL에서 축출하여 데이터셋으로 SHUNT해둠으로써 Non-VSAM SDS의 concatenation 로직을 이용하여 일관된 방식으로 concatenation 처리를 지원하기 위함이다.
INSDSET_LRECL의 설정에 대한 자세한 내용은 OpenFrame Batch "환경설정 안내서"의 "INSDSET_LRECL"을 참고한다.

JESJCL

tjclrun이 파싱한 INPJCL, INSPROC 및 카탈로그 프러시저를 파싱한 결과인 parse tree를 텍스트 형태로 출력한 내용을 갖는 파일이다. 주로 문제 분석할 때 참고 자료로 사용된다.
JESMSG

tjclrun이 종료하는 경우 그 tjclrun을 실행한 Runner Slot가 해당 JOB SPOOL에 기록하는 데이터셋이다. 그 내용은 실행된 JOB에 관련된 기본적인 정보와 JOB의 실행 과정에서 보고된 여러 가지 통계정보 그리고 JOB STEP에 관련된 정보를 포함한다. JOB의 실행에 관련하여 TJES 시스템에서 관심이 되는 사항에 대한 요약적인 정보를 담고 있다.
SYSMSG

SYSMSG는 tjclrun의 주요 메시지 로그이다. JOB을 실행하는 과정에서 필요한 여러 하위 단계의 진행상태 및 중요 결과 메시지뿐만 아니라 작업 처리할 때 발생한 에러 메시지도 SYSMSG에 저장된다.

JOB의 실행이 비정상적으로 종료된 경우 원인분석을 위해서 우선 SYSMSG의 내용을 검토해야 한다. SYSMSG의 내용은 tjclrun이 JOB의 JOB STEP을 실행한 순서에 따라서 세부 작업이나 동작이 발생한 시간순서대로 기록된다.

SYSMSG에 출력되는 내용은 다음과 같다.
- 수행 중인 JOB STEP 이름
- JOB 수행 중에 할당한 데이터셋 정보
- tjclrun이 호출한 PGM 이름과 프로세스 ID(pid)
- tjclrun이 호출한 PGM의 종료 상태
- tjclrun이 현재 수행 중인 동작
- tjclrun의 주요 동작의 성공 여부
- tjclrun 내부 OpenFrame 라이브러리의 stderr 메시지
SYSOUT

SYSOUT 데이터셋은 다음과 같이 DD 문에 SYSOUT 파라미터가 지정된 경우를 말한다. SYSOUT 데이터셋은 다른 데이터셋과 달리 JOB SPOOL에 저장되고 일반적으로 출력용 데이터를 저장한다.

다음은 SYSOUT 데이터셋을 설정한 예이다.
```
//REPORT EXEC PGM=MONTHLY
//SYSIN    DD *
2007-07-01,2007-08-01
/*
//SYSOUT   DD SYSOUT=*
//RPTOUT   DD SYSOUT=*
//RPTERR   DD SYSOUT=*
```
위에서 설명한 다른 JOB SPOOL의 데이터셋은 TJES가 JOB을 효율적으로 실행하기 위해 사용하는 데이터셋인 반면에 SYSOUT 데이터셋은 사용자가 Batch 프로그램을 위하여 요청한 데이터셋으로 JOB SPOOL에 저장되도록 특별히 지정한 경우로 볼 수 있다.

SYSOUT 데이터셋은 하나의 JOB이나 JOB STEP에서 여러 개 지정할 수 있다. 위의 예제에서 SYSOUT, RPTOUT, RPTERR가 SYSOUT 데이터셋이다. SYSOUT 데이터셋의 내용은 사용자가 지정한 Batch 프로그램에서 출력하는 내용이다.

TJES는 SYSOUT 데이터셋에 그 이외의 정보를 가감하지 않는다. Batch 프로그램에서 SYSOUT 데이터셋의 사용을 마치면 TJES는 SYSOUT 데이터셋의 OUTPUT CLASS에 따라서 사용자가 출력한 내용을 추후에 프린터나 화면으로 출력하는 과정을 관리할 뿐이다.

2.10. 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.11. 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.12. 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.13. 보안

TACF 지원 기능

tjclrun은 다음 2가지의 TACF 보안기능을 지원한다.

JOB STEP의 EXEC PGM에 지정된 프로그램을 실행할 권한이 있는지 검사하는 기능이다.
DD 문에 지정된 데이터셋들에 접근할 권한이 있는지 검사하는 기능이다.

어느 경우나 권한이 없는 경우는 JOB의 실행은 비정상 종료로 처리된다.

TACF를 이용하여 특정 TACF 사용자에 대하여 프로그램 및 데이터셋에 대한 권한을 제어하는 방법에 대해서는 OpenFrame TACF "운영자 안내서"를 참고한다.

TACF 대리자

일반적으로 JOB을 특정 사용자 권한으로 수행하기 위해서 JCL의 JOB 문에 USER와 PASSWORD 파라미터를 지정한다. JCL의 JOB 문의 PASSWORD를 지정할 때에는 암호화하지 않은 상태로 지정하기 때문에 JCL 파일 자체에 대한 보안이 엄격히 관리되지 않는 환경에서 사용자의 비밀번호가 노출될 위험이 발생한다.

이러한 위험을 방지하기 위해서 TJES에서는 대리자(Surrogate User)로 지정된 사용자가 실행 사용자(Execution User)를 대신하여 비밀번호를 지정하지 않고 실행 사용자 권한으로 JOB을 실행하도록 JOB을 submit할 수 있다.

대리자가 실행 사용자를 대신하여 JOB을 submit하는 경우에도 JOB은 실행 사용자의 권한으로 실행된다. 대리자는 단순히 JOB을 실행 사용자 대신 submit할 수 있을 뿐이다. 대리자에 의한 JOB submit은 JCL의 JOB 문에 PASSWORD 파라미터가 지정되지 않은 경우에만 동작한다.

TACF에서 JOB 실행을 위한 대리자를 지정하는 방법은 OpenFrame TACF "운영자 안내서"를 참고한다.

setuid root tjclrun

UNIX 시스템에서 실행 프로그램을 실행하는 사용자가 아니라 해당 프로그램 파일의 소유자 권한으로 프로그램을 실행하기 위해서 실행 프로그램의 소유자와 파일 퍼미션을 적절하게 변경하여 프로그램 실행시 프로세스가 프로그램 파일의 소유자 권한으로 실행되도록 설정하는 작업을 setuid 작업이라고 한다. 물론 setuid된 프로그램인 경우라도 실행하는 사용자에게 해당 프로그램의 실행 권한이 있는 경우에만 실행할 수 있다. setuid root 작업은 특정 프로그램을 실행시 프로그램을 실행한 사용자가 아닌 root 사용자 권한으로 프로세스가 실행되게끔 설정하는 작업을 의미한다.

여기서 말하는 프로세스의 사용자는 UNIX 프로세스의 유효 사용자(effective userid)를 말한다. tjclrun은 프로세스가 실행되는 동안 프로세스의 실제 사용자 정보(real userid)를 tjclrun 환경설정과 관계없이 전혀 변경하지 않는다. UNIX 시스템에서 파일 및 시스템 자원에 대한 권한 검사는 프로세스의 유효 사용자에 대해서 이루어진다.

실제 사용자 정보는 실제적으로 프로세스를 호출한 사용자를 구분하기 위한 용도로 사용된다. 또한 여기서 말하는 사용자는 TACF 사용자와는 직접적인 관련이 없는 운영 시스템의 사용자를 의미한다.

다음의 2가지 사항을 고려하여 필요한 경우 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 키의 VALUE 항목을 YES로 설정해야 할 뿐만 아니라 tjclrun 프로그램을 설치할 때 root 실행 권한을 부여해야 한다.

UNIX 운영 시스템에서 프로세스를 실행하는 사용자 정보를 프로그램 실행 중에 변경하기 위해서는 특권 유저(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 u+s 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 제품에 포함된 라이브러리들이다.

다른 UNIX 플랫폼의 경우(예를 들면 Linux의 경우) ld.so.conf 파일 등과 같은 trusted 라이브러리를 등록하는 설정을 통해서 OpenFrame 제품에서 제공되는 라이브러리를 공유 라이브러리 search 환경 변수에 의존하지 않고 찾을 수 있도록 설정할 수 있다.
tjclrun을 setuid root 권한으로 설치하여 운영하는 경우는 OpenFrame 환경설정의 tjclrun 서브젝트, SYSLIB 섹션의 LIB_PATH, BIN_PATH 키를 명시적으로 설정해 주어야 한다. 특히 IBM AIX와 같이 필요한 환경변수가 되어버리는 시스템에서는 필수적인 설정이다. 그렇지 않은 경우라도 OpenFrame 환경설정에 tjclrun 서브젝트, SYSLIB 섹션에 설정된 search path에서만 프로그램이나 공유 라이브러리를 찾게끔 하는 것이 보안 및 시스템 성능상으로 더 유리하다. 물론 OpenFrame 설정에 대한 변경 권한을 엄격하게 관리해야 한다.

2.14. tjclrun 호출

tjclrun은 다음과 같은 실행 인자와 함께 실행되어야 한다.

TJES의 Runner Slot은 JOB의 실행을 할당 받은 당시의 TJES의 상태에 기반하여 적절한 실행인자와 함께 실행된다.

tjclrun RUNMODE JOBID INITINDEX JOBSTREAM JOBPOS [keyword args ...]

다음은 tjclrun의 인자에 대한 설명이다.

인자	설명
RUNMODE	JOB (normal run) 또는 JEM (JOB Emulation) 테스트
JOBID	유일한 JOBID (예: JOBnnnnn)
INITINDEX	Runner Slot 인덱스
JOBSTREAM	JCL 문을 포함하고 있는 JOB 스트림의 경로
JOBPOS	JOB 스트림에 JOB이 여러 개 있는 것을 고려한 실행할 JOB의 위치

인자

설명

RUNMODE

JOB (normal run) 또는 JEM (JOB Emulation) 테스트

JOBID

유일한 JOBID (예: JOBnnnnn)

INITINDEX

Runner Slot 인덱스

JOBSTREAM

JCL 문을 포함하고 있는 JOB 스트림의 경로

JOBPOS

JOB 스트림에 JOB이 여러 개 있는 것을 고려한 실행할 JOB의 위치

[keyword args]

RESTART=*|stepname|stepname.procstepname

재시작할 JOB STEP을 지정한다. 애스터리스크(*)는 첫 번째 JOB 또는 PROC STEP을 의미하고, stepname은 stepname으로 지정된 JOB STEP을 의미하며, stepname.procstepname은 stepname.procstepname의 PROC STEP을 의미한다.

tjclrun을 셸의 명령어 라인에서 직접 실행하는 것도 가능하기는 하지만 이렇게 실행된 경우는 TJES의 JOB 관리의 submit 및 스케줄링 단계를 건너뛰고 직접 실행하는 경우이므로 정상적인 JOB의 실행이 보장되지 않는다.

2.15. NICE를 통한 PERFORM 처리

JCL의 문법 중에 JOB 문과 STEP 문에 PERFORM이라는 파라미터가 있다. Mainframe에서는 이 파라미터가 JOB이나 JOB STEP에 대한 퍼포먼스 그룹을 지정하여 해당 JOB이나 JOB STEP의 실행 중의 우선순위를 조절하게 된다.

하지만 UNIX에서는 퍼포먼스 그룹이 존재하지 않고 프로세스 기반으로 NICE라는 기능을 통해 CPU 우선순위 정도를 사용자들이 조절할 수 있다. OpenFrame에서는 PERFORM 파라미터에 대해서 UNIX의 NICE와 매핑을 하여 지원을 하고 있다.

PERFORM 파라미터를 이용할지 여부와 PERFORM의 값과 NICE의 값을 매핑은 OpenFrame 환경설정에 tjclrun 서브젝트, PERFORM 섹션에 키 설정으로 할 수 있다. 이에 대한 내용은 "OpenFrame 환경설정 안내서"를 참고한다.

UNIX에서 프로세스의 NICE의 값을 변경하기 위해서는 Supper User의 권한이 필요하다. 그러므로 PERFORM을 사용하고자 하는 경우에는 setuid 기능을 함께 사용하여야 한다.
NICE의 값을 변경함으로써 CPU 사용의 우선순위를 높일 수 있다. 이는 CPU 사용시간이 많은 JOB에는 도움이 된다. 하지만 I/O 처리에 많은 시간을 소비하는 JOB에는 효과가 거의 없다고 볼 수 있다.