JOB의 관리

본 장에서는 JOB이 가질 수 있는 상태의 종류와 JOB group에 대한 설명 및 JOB이 실행되는 단계 및 결과 조회 그리고 JOB을 관리하는 방법에 대해서 설명한다. OpenFrame에서는 JOB을 관리하는 방법은 tjesmgr와 OpenFrame Manager 2가지가 있다. 본 안내서에서는 tjesmgr를 사용하여 JOB을 관리하는 방법에 대해서만 다루도록 한다.

OpenFrame Manager를 사용하여 JOB을 관리하는 방법에 대해서는 OpenFrame Manager "사용자 안내서"를 참고한다.

1. JOB 상태

TJES는 다음 그림과 같이 JOB을 START, HOLD, WORKING, SUSPEND, DONE, ERROR, STOP, FLUSH의 8가지 상태로 구분하여 관리한다.

JOB 상태 흐름도

READY는 SUBMIT 단계 처리 중인 상태이고, PURGE는 JOB이 TJES에서 제거됨을 의미한다.

다음은 TJES의 각 상태에 관한 설명이다.

상태	내용
START	JCL을 통해 JOB이 submit되어 실행되기 전까지의 상태로 JOB 스케줄링의 대상이고 아직 Runner Slot 에 할당되지 않은 상태이다. HOLD 명령을 통해 JOB을 HOLD 상태로 변경하거나 CANCEL 명령을 통해 JOBQ에서 제거할 수 있다.
HOLD	JCL을 통해 JOB이 submit되어 실행되기 전까지의 상태로, START와 다르게 JOB 스케줄링의 대상이 되지 않는다. HOLD 상태에 해당하는 경우는 다음과 같다. JCL의 JOB 문에 HOLD 오퍼랜드를 기술하여 Submit한 경우 START 상태의 JOB을 HOLD 명령을 통해 상태를 변경한 경우
WORKING	tjclrun이 JOB을 실행 중인 상태이다. 실행 중인 STEP의 특성에 따라 복수의 UNIX 프로세스로 구동될 수 있다. SUSPEND 명령을 통해 실행 중인 JOB을 일시적으로 정지시킬 수 있고, STOP 명령을 통해 JOB 수행을 끝내고 STOP 상태로 바꿀 수 있다.
SUSPEND	JOB의 실행이 일시적으로 멈춘 상태이다. RESUME 명령을 통해 WORKING 상태로 복원할 수 있고, STOP 명령을 통해 JOB 수행을 끝내고 STOP 상태로 바꿀 수 있다. 3^rd party 유틸리티를 사용할 경우, 유틸리티 내부에서 세션을 새로 설정한다면 해당 프로세스와 그 하위 프로세스는 SUSPEND되지 않는다는 점을 주의해야 한다.
DONE	JCL 상에 요청된 대로 JOB이 정상적으로 실행된 상태이다. 사용자 프로그램이 의도한 결과를 산출했는지의 여부는 SPOOL 데이터의 조회(PODD)나 각 STEP의 반환 코드(PSJOB) 등을 조회하여 별도로 확인하여야 한다. REMOVE 명령을 통해 JOBQ에서 제거할 수 있다. DONE 상태가 JCL에서 요청된 대로 JOB의 모든 STEP이 수행되었고, 반환 코드가 COND문이나 rc 설정 등을 통해 지정한 허용 범위 이내라는 것을 의미하는 것이지, 각 STEP에 지정된 프로시저나 프로그램이 업무적으로 정상 실행되었다는 것을 의미하는 것은 아니다.
ERROR	JOB의 실행결과가 COND문이나 rc 환경설정에서 지정한 반환 코드 허용범위를 벗어난 상태이다. REMOVE 명령을 통해 JOBQ에서 제거할 수 있다.
STOP	WORKING 중인 상태의 JOB에 사용자가 명시적으로 STOP 명령을 통해 JOB을 강제 종료시키거나, 장애복구 플랜(Disaster Recovery Plan)에 의해 TJES가 자동으로 재기동될 때 JOB이 강제 종료된 상태이다. 이때 JOB 실행에 필요했던 모든 자원을 반납하고 종료하게 된다. REMOVE 명령을 통해 JOBQ에서 제거할 수 있다.
FLUSH	JOB 수행 중에 Runner에서 에러가 발생하여 더 이상 JOB을 수행하지 못하는 상태이다. JCL 런타임 파싱 에러나 FD 할당 에러 등이 FLUSH 상태의 주요 원인이다. REMOVE 명령을 통해 JOBQ에서 제거 할 수 있다.

상태

내용

START

JCL을 통해 JOB이 submit되어 실행되기 전까지의 상태로 JOB 스케줄링의 대상이고 아직 Runner Slot 에 할당되지 않은 상태이다.

HOLD 명령을 통해 JOB을 HOLD 상태로 변경하거나 CANCEL 명령을 통해 JOBQ에서 제거할 수 있다.

HOLD

JCL을 통해 JOB이 submit되어 실행되기 전까지의 상태로, START와 다르게 JOB 스케줄링의 대상이 되지 않는다.

HOLD 상태에 해당하는 경우는 다음과 같다.

JCL의 JOB 문에 HOLD 오퍼랜드를 기술하여 Submit한 경우
START 상태의 JOB을 HOLD 명령을 통해 상태를 변경한 경우

WORKING

tjclrun이 JOB을 실행 중인 상태이다. 실행 중인 STEP의 특성에 따라 복수의 UNIX 프로세스로 구동될 수 있다. SUSPEND 명령을 통해 실행 중인 JOB을 일시적으로 정지시킬 수 있고, STOP 명령을 통해 JOB 수행을 끝내고 STOP 상태로 바꿀 수 있다.

SUSPEND

JOB의 실행이 일시적으로 멈춘 상태이다. RESUME 명령을 통해 WORKING 상태로 복원할 수 있고, STOP 명령을 통해 JOB 수행을 끝내고 STOP 상태로 바꿀 수 있다.

3^rd party 유틸리티를 사용할 경우, 유틸리티 내부에서 세션을 새로 설정한다면 해당 프로세스와 그 하위 프로세스는 SUSPEND되지 않는다는 점을 주의해야 한다.

DONE

JCL 상에 요청된 대로 JOB이 정상적으로 실행된 상태이다.

사용자 프로그램이 의도한 결과를 산출했는지의 여부는 SPOOL 데이터의 조회(PODD)나 각 STEP의 반환 코드(PSJOB) 등을 조회하여 별도로 확인하여야 한다. REMOVE 명령을 통해 JOBQ에서 제거할 수 있다.

DONE 상태가 JCL에서 요청된 대로 JOB의 모든 STEP이 수행되었고, 반환 코드가 COND문이나 rc 설정 등을 통해 지정한 허용 범위 이내라는 것을 의미하는 것이지, 각 STEP에 지정된 프로시저나 프로그램이 업무적으로 정상 실행되었다는 것을 의미하는 것은 아니다.

ERROR

JOB의 실행결과가 COND문이나 rc 환경설정에서 지정한 반환 코드 허용범위를 벗어난 상태이다. REMOVE 명령을 통해 JOBQ에서 제거할 수 있다.

STOP

WORKING 중인 상태의 JOB에 사용자가 명시적으로 STOP 명령을 통해 JOB을 강제 종료시키거나, 장애복구 플랜(Disaster Recovery Plan)에 의해 TJES가 자동으로 재기동될 때 JOB이 강제 종료된 상태이다. 이때 JOB 실행에 필요했던 모든 자원을 반납하고 종료하게 된다.

REMOVE 명령을 통해 JOBQ에서 제거할 수 있다.

FLUSH

JOB 수행 중에 Runner에서 에러가 발생하여 더 이상 JOB을 수행하지 못하는 상태이다. JCL 런타임 파싱 에러나 FD 할당 에러 등이 FLUSH 상태의 주요 원인이다.

REMOVE 명령을 통해 JOBQ에서 제거 할 수 있다.

1.1. 명령어를 통한 JOB의 상태 변경

사용자는 명령어를 사용하여 원하는 JOB의 상태로 변경할 수있다.

다음은 JOB의 상태 변경과 관련된 tjesmgr 명령어를 정리한 표이다. 첫 번째 칼럼의 현재 상태에서 두 번째 칼럼의 명령어를 사용하면 세 번째 칼럼의 상태로 변경된다.

현재 상태	명령어	변경될 상태
-	RUN	START, HOLD
START	CANCEL	JOB 실행 전 JOBQ에서 해당 JOB 삭제됨
HOLD	HOLD
HOLD	CANCEL	JOB 실행 전 JOBQ에서 해당 JOB 삭제됨
START	START
WORKING	SUSPEND	SUSPEND
STOP	STOP
SUSPEND	STOP	STOP
RESUME	WORKING
DONE	REMOVE	JOB 실행 후 JOBQ에서 해당 JOB 삭제됨
ERROR	REMOVE	JOB 실행 후 JOBQ에서 해당 JOB 삭제됨
STOP	REMOVE	JOB 실행 후 JOBQ에서 해당 JOB 삭제됨
FLUSH	REMOVE	JOB 실행 후 JOBQ에서 해당 JOB 삭제됨

현재 상태

명령어

변경될 상태

RUN

START, HOLD

START

CANCEL

JOB 실행 전 JOBQ에서 해당 JOB 삭제됨

HOLD

CANCEL

JOB 실행 전 JOBQ에서 해당 JOB 삭제됨

START

WORKING

SUSPEND

STOP

SUSPEND

STOP

RESUME

WORKING

DONE

REMOVE

JOB 실행 후 JOBQ에서 해당 JOB 삭제됨

ERROR

REMOVE

JOB 실행 후 JOBQ에서 해당 JOB 삭제됨

STOP

REMOVE

JOB 실행 후 JOBQ에서 해당 JOB 삭제됨

FLUSH

REMOVE

JOB 실행 후 JOBQ에서 해당 JOB 삭제됨

JOBQ는 OpenFrame 환경설정에 tjes 서브젝트, JOBDEF 섹션에 설정된 크기만큼만 저장을 할 수 있기 때문에 필요하지 않는 JOB들은 JOBQ에서 삭제할 필요가 있다.

CANCEL이나 REMOVE는 모두 JOBQ에서 JOB을 삭제하는 명령이지만 CANCEL은 JOB이 실행되기 전에 REMOVE는 JOB이 실행된 후에 삭제된다는 점이 다르다. HOLD 상태에 있는 JOB들은 스케줄링이 되지 않기 때문에 HOLD 상태인 JOB을 실행하고자 하면 START 상태로 상태를 바꾸어야 한다. 이때 START 명령어를 사용하여 상태를 변경할 수 있다.

tjes 서브젝트에 대한 자세한 내용은 OpenFrame Batch "환경설정 안내서"를 참고한다.
각 명령어 사용법은 TJESMGR 명령어를 참고한다.

2. JOB Group

XSP TJES는 다수의 JOB을 그룹화하는 JOB Group을 지원한다. 모든 JOB은 하나의 JOB Group에 속하게 되며, 시스템 기본 JOB Group인 SYSGRP 또는 JCL 상에 기술된 JOB Group으로 편입된다.

JOB Group은 해당 JOB Group에 속한 JOB의 기본 속성을 결정하거나 스케줄 개시조건 지정, JOB 순차실행 및 다중도 제한 등의 JOB 스케줄링 정책을 결정한다.

스케줄링에 관한 자세한 내용은 Schedule 단계를 참고한다.

JOB Group 종류

XSP TJES의 JOB Group에는 System JOB Group, 상주 JOB Group 및 임시 JOB Group이 있다.

구분	설명
System JOB Group	시스템을 초기 설정하는 경우 자동으로 설정되는 SYSGRP으로 시스템 운용 중 항상 유용하며 삭제할 수 없다.
상주 JOB Group	시스템 초기 설정 시에 등록되거나 시스템 운용 중에 tjesmgr을 통해 등록된 JOB Group으로 사용자의 명시적인 삭제 전까지 유효하다.
임시 JOB Group	JCL의 JOBG문으로 등록되는 작업 그룹으로 JOB Group에 속한 작업이 모두 실행 종료되었고 새로운 JOB이 입력 중이 아니라면 자동으로 삭제된다.

구분

설명

System JOB Group

시스템을 초기 설정하는 경우 자동으로 설정되는 SYSGRP으로 시스템 운용 중 항상 유용하며 삭제할 수 없다.

상주 JOB Group

시스템 초기 설정 시에 등록되거나 시스템 운용 중에 tjesmgr을 통해 등록된 JOB Group으로 사용자의 명시적인 삭제 전까지 유효하다.

임시 JOB Group

JCL의 JOBG문으로 등록되는 작업 그룹으로 JOB Group에 속한 작업이 모두 실행 종료되었고 새로운 JOB이 입력 중이 아니라면 자동으로 삭제된다.

JOB Group 속성

JOB Group은 다음의 5가지 속성을 가진다.

다중도

XSP TJES에서 동시에 실행되는 JOB의 수를 나타낸다. JOB Group에 다중도가 지정되어 있는 경우, 동시에 실행되는 JOB의 개수는 다중도에 지정된 개수를 넘지 못한다. JOB Group의 다중도가 포화에 이르지 않았더라도, 시스템 다중도(시스템 전체의 다중도 제한)에 의해 동시에 실행되는 JOB의 수가 제한될 수 있다. 다중도 지정을 생략하는 경우 기본값은 1이다.
REL

JOB Group 내 JOB의 순차 실행을 의미한다. 기본적으로 TJES는 JOB Group 내의 JOB을 우선순위(JOB Priority) 및 전송시간(JOB submit time)에 따라 실행하지만, REL을 지정하면 우선순위를 무시하고 전송시간에 따라 순차적으로 실행한다. REL을 지정하는 경우 다중도는 1이 된다. 즉, 동시에 실행되는 JOB의 개수는 1이다.
JOB Group Priority

JOB의 작업그룹 우선순위를 의미하며, 스케줄링할 때 JOB Group의 선택에 사용된다. 높은 우선순위의 작업 그룹부터 스케줄링된다.
JOB Default Parameter

JCL의 JOB문에 파라미터가 생략되었을 경우 기본적으로 주어질 파라미터를 설정한다. JOB Priority 등을 설정할 수 있다.

처리 개시 대기

XSP TJES에서 JOB Group은 다음의 속성 중 하나에 대해 처리 개시 대기를 지정할 수 있다. 대기요건이 충족되거나 관리자에 의해 해제되지 않는 한 해당 JOB Group은 스케줄링에서 제외된다.

구분	설명
오퍼레이터 응답 대기	오퍼레이터로부터 처리개시에 대한 응답 요청이 올 때까지 대기한다.
처리 개시시각 대기	hh:mm으로 지정된 시각까지 대기한다. 지정된 hh:mm이 이미 지났다면 다음날의 시각으로 지정된다. N일 후의 시각을 지정하기 위해서는 N*24+hh:mm 으로 시각을 지정한다.
데이터 완료 대기	JCL 상의 DATA문을 통한 데이터 작성 완료 통보를 기다린다.
타 작업그룹 완료 대기	타깃(Target) 작업그룹이 완료되어 소멸될 때까지 대기한다.

구분

설명

오퍼레이터 응답 대기

오퍼레이터로부터 처리개시에 대한 응답 요청이 올 때까지 대기한다.

처리 개시시각 대기

hh:mm으로 지정된 시각까지 대기한다.
지정된 hh:mm이 이미 지났다면 다음날의 시각으로 지정된다.
N일 후의 시각을 지정하기 위해서는 N*24+hh:mm 으로 시각을 지정한다.

데이터 완료 대기

JCL 상의 DATA문을 통한 데이터 작성 완료 통보를 기다린다.

타 작업그룹 완료 대기

타깃(Target) 작업그룹이 완료되어 소멸될 때까지 대기한다.

3. JOB 처리단계

TJES를 통해 실행되는 모든 JOB은 다음의 단계로 진행된다.

Submit : TJES로부터 JCL을 받아들이는 단계
Schedule : 조건을 충족하는 Runner Slot에 JOB을 할당하는 단계
Execution : 실제로 Runner가 JOB을 수행하는 단계
Output : JOB의 수행이 끝나고 그 Output이 처리되는 단계
Remove : 수행이 끝난 JOB을 TJES에서 제거하는 단계

3.1. Submit 단계

JCL을 받아 이를 분석하여 JOB Group별로 JOB을 TJES에 편입시키는 단계이다.

JCL이 submit되면 TJES는 해당 JCL을 분석하여, JOB Group과 JOB 정보를 획득한다. TJES에 해당 JOB Group 이름이 존재하지 않는다면 JOB Group을 등록한다. 이후 JOB 엔트리를 구성하고, JOBID, SPOOL 등 JOB 관리에 필요한 리소스를 할당한 후 JOBQ에 저장한다.

Submit된 JOB의 정보는 해당 JOB Group에 편입되어, 스케줄러에 의해 JOB이 Runner Slot에 할당될 수 있도록 한다.

TJES는 다음과 같은 리소스들을 JOB에게 할당한다.

리소스	설명
JOBID	TJES가 JOB을 구분하여 관리하기 위해서는 각각의 JOB에 유일한 ID를 부여해야 한다. 이를 JOBID라 하며, TJES에서 관리하는 JOBID는 'JOBnnnnn’의 형식을 갖는다. 이 형식은 OpenFrame 환경설정에 tjes서브젝트, JOBDEF섹션의 ENDNUM 키로 결정한다. 앞의 두 가지 형식에 의하여 JOB에 부여할 수 있는 JOBID 범위는 00001부터 99999 또는 000001부터 999999이다. JOBID는 Submit할 때 발급되어 JOB이 CANCEL이나 REMOVE를 통해 제거될 때 반환된다. 반환된 JOBID는 로테이션하여 재사용된다.
SPOOL	TJES는 한 개의 JOB마다 독립적인 SPOOL 공간을 할당하며, 이 공간은 SPOOL 볼륨에 JOBID로 생성된 디렉터리이다. SPOOL에는 Submit 받은 시점의 JCL을 보존하기 위하여 복사한 INPJCL, INPJCL에서 호출한 매크로의 내용을 전개해서 실제 실행 대상이 되는 EXPJCL, JOB의 수행결과인 SYSOUT, TJES가 JOB의 수행 상태를 보고하기 위해 내부적으로 사용하는 SYSMSG 파일 등이 저장된다. 내부적으로 관리하는 파일들은 설정에 따라 시스템 테이블에 저장할 수도 있다. SPOOL은 tjesinit 툴을 통해 초기화한다.
JOBQ	TJES는 JOB의 검색과 변경 등을 용이하게 하기 위해 시스템 테이블에 JOB의 기본 정보를 저장한다. JOBQ에 저장된 JOB의 정보는 tjesinit 툴을 통해 초기화할 수 있다.

리소스

설명

JOBID

TJES가 JOB을 구분하여 관리하기 위해서는 각각의 JOB에 유일한 ID를 부여해야 한다. 이를 JOBID라 하며, TJES에서 관리하는 JOBID는 'JOBnnnnn’의 형식을 갖는다. 이 형식은 OpenFrame 환경설정에 tjes서브젝트, JOBDEF섹션의 ENDNUM 키로 결정한다. 앞의 두 가지 형식에 의하여 JOB에 부여할 수 있는 JOBID 범위는 00001부터 99999 또는 000001부터 999999이다.

JOBID는 Submit할 때 발급되어 JOB이 CANCEL이나 REMOVE를 통해 제거될 때 반환된다. 반환된 JOBID는 로테이션하여 재사용된다.

SPOOL

TJES는 한 개의 JOB마다 독립적인 SPOOL 공간을 할당하며, 이 공간은 SPOOL 볼륨에 JOBID로 생성된 디렉터리이다.

SPOOL에는 Submit 받은 시점의 JCL을 보존하기 위하여 복사한 INPJCL, INPJCL에서 호출한 매크로의 내용을 전개해서 실제 실행 대상이 되는 EXPJCL, JOB의 수행결과인 SYSOUT, TJES가 JOB의 수행 상태를 보고하기 위해 내부적으로 사용하는 SYSMSG 파일 등이 저장된다. 내부적으로 관리하는 파일들은 설정에 따라 시스템 테이블에 저장할 수도 있다.

SPOOL은 tjesinit 툴을 통해 초기화한다.

JOBQ

TJES는 JOB의 검색과 변경 등을 용이하게 하기 위해 시스템 테이블에 JOB의 기본 정보를 저장한다.

JOBQ에 저장된 JOB의 정보는 tjesinit 툴을 통해 초기화할 수 있다.

TJES에서 JCL을 submit 받는 단계는 다음과 같다.

JOB Group 등록 및 잠금(JOB이 submit되는 동안 JOB Group의 스케줄링 방지)설정을 한다.
JOBID를 발급한다.
SPOOL을 생성한다.
Submit된 JCL을 SPOOL에 INPJCL로 복사한다.
Macro를 전개한다.
JCL 구문 에러를 확인한다.
Macro가 전개된 JCL의 SPOOL에 EXPJCL로 복사한다.
JCL에 기술된 내용 중 JOB에 대한 정보를 JOBQ에 저장한다.
obmjschd의 해당 JOB Group으로 편입한다.
JOB Group 잠금 해제한다.

Submit 단계 중에 에러가 발생하면 OpenFrame 환경설정의 ofsys 서브젝트, DIRECTORY 섹션의 LOG_DIR 키에 지정된 경로에 job 하위 디렉터리에 submit_YYYYMMDD.log의 이름으로 파일이 저장된다. 성공적으로 submit된 JOB은 START와 HOLD 상태 중 하나의 상태로 남는다.

tjesmgr의 RUN 명령어를 통해서 JCL을 정상적으로 submit하게 되면, submit하여 생성된 JOB들이 JOBQ에 등록되어 있는 것을 확인할 수 있다.

Submit Log의 형식에 대한 자세한 내용은 Submit 로그를 참고한다.
JOBQ의 Output에 대한 자세한 내용은 PS(Print Screen)을 참고한다.
tjes 서브젝트에 대한 자세한 내용은 OpenFrame Batch "환경설정 안내서"를 참고한다.

OpenFrame에서는 다음과 같이 JCL을 submit하는 여러 가지 방법을 지원한다.

tjesmgr의 RUN 명령어를 통한 방법(TJESMGR 명령어의 RUN을 참고한다.)
textrun 툴을 사용하는 방법(OpenFrame Batch "툴 참고 안내서"의 "textrun"을 참고한다.)
OpenFrame Batch Manager(BM)를 통한 방법( OpenFrame Manager "사용자 안내서"를 참고한다.)

3.2. Schedule 단계

START 상태의 JOB을 스케줄링 정책에 따라 Runner Slot에 배정하는 단계이다. Schedule 단계에서 TJES는 기본적으로 다음의 조건을 만족하는 Runner Slot에게 현재 START 상태인 JOB을 배정한다.

Runner Slot의 상태가 Active로 활성화되어 있어야 하며, 다른 JOB을 수행하고 있는 중이 아니어야 한다.
JOB submit하는 경우 특정 노드에서 JOB이 실행되도록 명시했을 경우, 그 노드와 Runner Slot이 속한 노드가 일치해야 한다.

스케줄링은 기본적으로 JOB Group의 속성과 JOB의 우선순위에 따라 이루어진다.

시스템 실행 다중도(시스템 전체에서 동시에 실행할 수 있는 JOB의 수)가 포화 상태에 이르지 않았다면 스케줄링한다.
우선순위가 높은 JOB Group부터 라운드 로빈 방식으로 JOB을 스케줄링한다.
JOB Group의 실행 다중도(해당 JOB Group에서 동시에 실행할 수 있는 JOB의 수)가 포화 상태에 이르지 않았다면 스케줄링한다.
JOB Group의 REL 속성이 YES이면 JOB의 우선순위와 무관하게 submit된 순서대로 스케줄링 한다.
JOB Group의 REL 속성이 NO이면, JOB의 우선순위에 따라 스케줄링한다. 단, 우선순위가 같을 경우에는 submit된 순서대로 스케줄링한다.

다음은 스케줄링 메소드를 pseudo code로 나타낸 것이다.

   While working_job_count < system multiplicity
 Select a available job group with highest priority in round robin manner
 IF no job group is selectd, BREAK
 IF the job group has REL property
  Get a oldest job in the job group
 ELSE
  get a job with highest priority in the job group
 ENDIF
Check node affinity. If fails, continue
Assign the job to the runner and break

3.3. Execution 단계

Runner가 실제로 JCL에 기술된 대로 JOB을 실행하는 단계이다.

Runner는 SPOOL에 복사되어 있는 EXPJCL을 파싱하고, 그 결과에 따라 JOB을 실행한다. 하나의 JOB은 하나 이상의 JOB STEP으로 구성되는데, Runner는 이 JOB STEP을 JCL에 기술된 순서대로 순차적으로 실행한다. JOB을 실행할 때 필요한 데이터셋을 할당하는 일도 Execution 단계에서 일어난다.

3.4. Output 단계

JOB 수행 중 생성된 SYSOUT을 처리하는 단계이다. SYSOUT은 Output이라는 단위로 처리되는데, OUTPUT CLASS에 따라 처리할 수 있는 프린터와 기본 후처리가 결정된다.

Output은 외부 프린터로 출력되거나 그 외 시스템에서 지원하는 writer를 통해 처리된다. 자세한 내용은 OUTPUT Processing을 참고한다.

3.5. Remove 단계

Output 단계로 진입한 JOB을 사용자의 명시적인 명령에 의해 TJES에서 삭제하는 단계이다.

JOB에 할당되었던 JOBID, SPOOL, JOBQ 등과 같은 모든 리소스가 시스템으로 반환된다. TJES에서 삭제한 JOB의 결과를 추후에 다시 접근하기 위해서는 SPOOL 백업 명령어를 통해 백업해야 한다. 백업에 성공하면 SPOOL에서 자동으로 JOB이 제거된다.

4. JOB 조회

submit된 JOB은 JCL의 파라미터에 기술된 값에 따라 START 또는 HOLD 상태로 JOBQ에 등록된다. JOBQ에 등록되어 있는 모든 JOB은 tjesmgr의 PS 명령어를 통해서 JOB의 상태를 확인할 수 있다.

START 상태의 JOB은 스케줄링을 통해 WORKING 상태로 바뀌면서 실행되고, ERROR나 DONE 또는 FLUSH 등으로 종료가 된다.

다음과 같은 tjesmgr 명령어를 통해서 JOB의 상세한 정보를 조회할 수 있다.

명령어	설명
PSJOB	JOB의 상세 정보를 보여준다.
PSIO	JOB에서 사용한 데이터셋들의 I/O 정보를 보여준다.
POSPOOL	JOB에서 생성한 SPOOL들의 정보를 보여준다.
PODD	JOB에서 생성한 SPOOL들의 내용을 보여준다.
POJOB	JOB과 관련한 Output 상세정보를 보여준다.

명령어

설명

PSJOB

JOB의 상세 정보를 보여준다.

PSIO

JOB에서 사용한 데이터셋들의 I/O 정보를 보여준다.

POSPOOL

JOB에서 생성한 SPOOL들의 정보를 보여준다.

PODD

JOB에서 생성한 SPOOL들의 내용을 보여준다.

POJOB

JOB과 관련한 Output 상세정보를 보여준다.

JOB의 정보 조회에 대한 상세한 설명과 기능은 JOB/OUTPUT 명령어를 참고한다.

5. 로그

TJES는 운영에 대한 자료로 사용하거나 운영할 때 발생할 수 있는 각종 사건들의 책임 소재를 분명히 하는 용도로 사용하기 위해서 TJES에서 일어나는 여러 가지 이벤트에 대하여 로그를 남긴다.

OpenFrame Batch for XSP 7.3에서 TJES는 다음의 2가지의 로그를 남긴다.

JCL의 Submit에 대한 정보를 저장하는 Submit 로그
JOB의 모든 상태 변화에 대한 JOB 로그

매일 방대한 양의 로그가 기록될 수 있으므로 정리작업 없이 장기간 운영하면 로그 파일의 크기가 상당히 커질 수 있다. 이러한 문제점을 해결하기 위해서 날짜별로 로그를 생성하는 옵션을 제공한다.

5.1. Submit 로그

Submit 로그는 OpenFrame 환경설정에 ofsys 서브젝트, DIRECTORY 섹션의 LOG_DIR 키에 지정된 경로에 job 이라는 이름의 하위 디렉터리에 submit_YYYYMMDD.log의 이름으로 파일이 저장된다. Submit 로그는 성공과 실패를 구분하지 않고, obmjmsvr에서 인지한 JCL을 submit하려는 모든 시도에 대해 기록한다.

Submit 로그의 기본적인 형식은 다음과 같다.

>> timestamp    jclpath
submit_result

항목	설명
timestamp	yyyymmddHHMMSS 형태의 14자리 숫자이다.
jclpath	submit된 JCL의 UNIX 절대 경로이다.
submit_result	submit 결과를 나타내는 문구이다.

항목

설명

timestamp

yyyymmddHHMMSS 형태의 14자리 숫자이다.

jclpath

submit된 JCL의 UNIX 절대 경로이다.

submit_result

submit 결과를 나타내는 문구이다.

5.2. JOB 로그

JOB 로그는 OpenFrame 환경설정에 ofsys 서브젝트, DIRECTORY 섹션의 LOG_DIR 키에 지정된 경로에 job 하위 디렉터리에 job_YYYYMMDD.log의 이름으로 파일이 저장된다.

JOB 로그의 기본적인 형식은 다음과 같다.

[YYYY-MM-DDTHH:MI:SS.FFFFFF][MODULE(PID)][MSG_LEVEL][MSG_CODE] CMD=operation,NODE=nodename,USER=userid,JOBID=jobid,JOBNAME=jobname,additional info

다음은 공통 항목에 대한 설명이다.

항목	설명
CMD	operation의 종류를 설정한다. SUBMIT : JOB이 submit된다. EXECUTE : JOB을 Runner에 할당한다. CHANGE : JOB의 속성이 실행 전에 변경되었다. FINISH : JOB의 실행이 종료된다. REMOVE : JOB이 TJES에서 제거된다. SUSPEND : JOB이 일시정지된다. RESUME : 일시정지된 JOB이 다시 수행된다. STEP : JOB의 특정 STEP의 수행 정보이다. CANCEL : JOB 수행이 취소된다.
NODE	JOB이 수행될 노드의 이름이다. JCL에 JOB들이 실행될 execution_node를 지정하지 않았거나 OpenFrame 환경설정에 tjesmgr 서브젝트, DEFAULT_OPTION 섹션의 DEFAULT_RUNNING_NODE 키의 VALUE 항목을 MY로 설정하지 않았다면 모든 노드에서 실행될 수 있도록 애스터리스크(*)가 설정된다.
USER	JOB을 수행한 유저의 이름이다. CMD=FINISH인 경우 TJES로 출력된다.
JOBID	submit된 JOB ID이다.
JOBNAME	JOB의 이름이다.
additional info	additional info는 CMD=operation 값에 따라 다르다.

항목

설명

CMD

operation의 종류를 설정한다.

SUBMIT : JOB이 submit된다.
EXECUTE : JOB을 Runner에 할당한다.
CHANGE : JOB의 속성이 실행 전에 변경되었다.
FINISH : JOB의 실행이 종료된다.
REMOVE : JOB이 TJES에서 제거된다.
SUSPEND : JOB이 일시정지된다.
RESUME : 일시정지된 JOB이 다시 수행된다.
STEP : JOB의 특정 STEP의 수행 정보이다.
CANCEL : JOB 수행이 취소된다.

NODE

JOB이 수행될 노드의 이름이다.

JCL에 JOB들이 실행될 execution_node를 지정하지 않았거나 OpenFrame 환경설정에 tjesmgr 서브젝트, DEFAULT_OPTION 섹션의 DEFAULT_RUNNING_NODE 키의 VALUE 항목을 MY로 설정하지 않았다면 모든 노드에서 실행될 수 있도록 애스터리스크(*)가 설정된다.

USER

JOB을 수행한 유저의 이름이다. CMD=FINISH인 경우 TJES로 출력된다.

JOBID

submit된 JOB ID이다.

JOBNAME

JOB의 이름이다.

additional info

additional info는 CMD=operation 값에 따라 다르다.

SUBMIT

JOB이 submit 된다.

사용법

CLASS=class,STATUS=status,JCL=path

항목	설명
CLASS	submit된 JOB CLASS이다(XSP에서는 의미가 없다).
STATUS	JOB의 Submit 상태에 따라 설정된다. S : START 상태 H : HOLD 상태 D : DONE 상태
JCL	복사된 INPJCL의 경로가 아니라 submit된 JCL의 원본 파일경로이다.

항목

설명

CLASS

submit된 JOB CLASS이다(XSP에서는 의미가 없다).

STATUS

JOB의 Submit 상태에 따라 설정된다.

S : START 상태
H : HOLD 상태
D : DONE 상태

JCL

복사된 INPJCL의 경로가 아니라 submit된 JCL의 원본 파일경로이다.

EXECUTE

JOB을 Runner에 할당한다.

사용법

INDEX=index,PID=pid,CLASS=class

항목	설명
INDEX	JOB을 실행 중인 Runner Slot의 인덱스이다. 실행 중인 노드에서만 유효한 값이다.
PID	JOB을 실행 중인 Runner의 프로세스 ID이다. 실행 중인 노드에서만 유효한 값이다.
CLASS	Runner Slot에 할당된 복수의 클래스 중 현재 JOB을 실행하기 위해 사용하고 있는 클래스이다(XSP에서는 의미가 없다).

항목

설명

INDEX

JOB을 실행 중인 Runner Slot의 인덱스이다. 실행 중인 노드에서만 유효한 값이다.

PID

JOB을 실행 중인 Runner의 프로세스 ID이다. 실행 중인 노드에서만 유효한 값이다.

CLASS

Runner Slot에 할당된 복수의 클래스 중 현재 JOB을 실행하기 위해 사용하고 있는 클래스이다(XSP에서는 의미가 없다).

CHANGE

JOB의 속성이 실행 전에 변경되었다.

사용법

CLASS=class,PRIORITY=priority,STATUS=status

항목	설명
CLASS	변경된 후의 JOB CLASS이다(XSP에서는 의미가 없다).
PRIORITY	변경된 후의 JOB의 우선순위 값이다.
STATUS	변경된 후의 JOB 상태이다. S : START 상태 H : HOLD 상태

항목

설명

CLASS

변경된 후의 JOB CLASS이다(XSP에서는 의미가 없다).

PRIORITY

변경된 후의 JOB의 우선순위 값이다.

STATUS

변경된 후의 JOB 상태이다.

S : START 상태
H : HOLD 상태

FINISH

JOB의 실행이 종료된다.

사용법

INDEX=index,PID=pid,STATUS=status,RCODE=exitcode

항목	설명
INDEX	JOB을 실행 중인 Runner Slot의 인덱스이다. 실행 중인 노드에서만 유효한 값이다.
PID	JOB을 실행 중인 Runner의 프로세스 ID이다. 실행 중인 노드에서만 유효한 값이다.
STATUS	JOB의 종료 상태이다. D : DONE 상태 E : ERROR 상태 T : STOP 상태 F : FLUSH 상태
RCODE	JOB의 EXIT CODE이다. 자세한 내용은 JOB EXIT CODE를 참고한다.

항목

설명

INDEX

JOB을 실행 중인 Runner Slot의 인덱스이다. 실행 중인 노드에서만 유효한 값이다.

PID

JOB을 실행 중인 Runner의 프로세스 ID이다. 실행 중인 노드에서만 유효한 값이다.

STATUS

JOB의 종료 상태이다.

D : DONE 상태
E : ERROR 상태
T : STOP 상태
F : FLUSH 상태

RCODE

JOB의 EXIT CODE이다. 자세한 내용은 JOB EXIT CODE를 참고한다.

REMOVE

JOB이 TJES에서 제거된다.

사용법
```
STATUS=status
```
항목 설명
STATUS
remove된 JOB의 종료 상태이다.

D : DONE 상태

E : ERROR 상태

T : STOP 상태

F : FLUSH 상태

항목	설명
STATUS	remove된 JOB의 종료 상태이다. D : DONE 상태 E : ERROR 상태 T : STOP 상태 F : FLUSH 상태

SUSPEND

JOB이 일시정지된다.

사용법

INDEX=index,PID=pid,STATUS=status

항목	설명
INDEX	JOB을 실행 중인 Runner Slot의 인덱스이다. 실행 중인 노드에서만 유효한 값이다.
PID	JOB을 실행 중인 Runner의 프로세스 ID이다. 실행 중인 노드에서만 유효한 값이다.
STATUS	suspend된 JOB의 상태이다. P : SUSPEND 상태

항목

설명

INDEX

JOB을 실행 중인 Runner Slot의 인덱스이다. 실행 중인 노드에서만 유효한 값이다.

PID

JOB을 실행 중인 Runner의 프로세스 ID이다. 실행 중인 노드에서만 유효한 값이다.

STATUS

suspend된 JOB의 상태이다.

P : SUSPEND 상태

RESUME

일시정지된 JOB이 다시 수행된다.

사용법

INDEX=index,PID=pid,STATUS=status

항목	설명
INDEX	JOB을 실행 중인 Runner Slot의 인덱스이다. 실행 중인 노드에서만 유효한 값이다.
PID	JOB을 실행 중인 Runner의 프로세스 ID이다. 실행 중인 노드에서만 유효한 값이다.
STATUS	resume된 JOB의 상태이다. W : WORKING 상태

항목

설명

INDEX

JOB을 실행 중인 Runner Slot의 인덱스이다. 실행 중인 노드에서만 유효한 값이다.

PID

JOB을 실행 중인 Runner의 프로세스 ID이다. 실행 중인 노드에서만 유효한 값이다.

STATUS

resume된 JOB의 상태이다.

W : WORKING 상태

STEP

JOB의 특정 STEP의 수행 정보이다.

사용법

STEPNAME=stepname,SKIP=skip,STEPSEQ=seqnum,RCODE=exitcode

항목	설명
STEPNAME	JOB STEP의 이름이다.
SKIP	JOB STEP 수행의 skip 여부이다. Y : 수행이 되지 않는다. N : 수행된다.
STEPSEQ	JOB STEP의 순서번호이다. 1부터 시작한다.
RCODE	JOB의 EXIT CODE이다. 자세한 내용은 JOB EXIT CODE를 참고한다.

항목

설명

STEPNAME

JOB STEP의 이름이다.

SKIP

JOB STEP 수행의 skip 여부이다.

Y : 수행이 되지 않는다.
N : 수행된다.

STEPSEQ

JOB STEP의 순서번호이다. 1부터 시작한다.

RCODE

JOB의 EXIT CODE이다. 자세한 내용은 JOB EXIT CODE를 참고한다.

CANCEL

JOB 수행이 취소된다.

사용법
```
STATUS=status
```
항목 설명
STATUS
취소된 JOB의 상태이다.

S : START 상태

H : HOLD 상태

항목	설명
STATUS	취소된 JOB의 상태이다. S : START 상태 H : HOLD 상태

6. JOB 백업

많은 JOB을 실행하게 되면 JOBQ에 JOB이 계속 쌓이게 되어 더이상 JOB을 submit할 수 없는 상태까지 될 수 있다. 따라서 오래된 JOB에 대해서는 JOBQ에서 삭제해야 하며, 삭제할 JOB들의 정보를 남겨놓고 싶을 때는 SPOOL을 백업한다.

다음은 SPOOL 백업과 관련한 명령어와 기능을 간단히 정리한 표이다.

명령어	설명
SPOOLBACKUP	JOBQ에서 JOB을 삭제하고, 삭제된 JOB의 SPOOL을 백업한다.
SPOOLBACKUPLIST	SPOOL이 백업된 날짜들을 보여준다.
SPOOLPS	해당 날짜에 백업된 JOB들을 보여준다.
SPOOLRESTORE	백업된 JOB들을 임시 디렉터리에 복원한다.
SPOOLPSJOB	복원된 JOB들의 상세 정보를 보여준다. (PSJOB과 동일한 정보 출력)
SPOOLPSIO	복원된 JOB들의 I/O 정보를 보여준다. (PSIO과 동일한 정보 출력)
SPOOLPOSPOOL	복원된 JOB들의 SPOOL 리스트를 보여준다. (POSPOOL과 동일한 정보 출력)
SPOOLPODD	복원된 JOB들의 SPOOL 내용을 보여준다. (PODD과 동일한 기능)
SPOOLCLEAR	임시 디렉터리에 복원된 JOB들을 제거한다.

명령어

설명

SPOOLBACKUP

JOBQ에서 JOB을 삭제하고, 삭제된 JOB의 SPOOL을 백업한다.

SPOOLBACKUPLIST

SPOOL이 백업된 날짜들을 보여준다.

SPOOLPS

해당 날짜에 백업된 JOB들을 보여준다.

SPOOLRESTORE

백업된 JOB들을 임시 디렉터리에 복원한다.

SPOOLPSJOB

복원된 JOB들의 상세 정보를 보여준다. (PSJOB과 동일한 정보 출력)

SPOOLPSIO

복원된 JOB들의 I/O 정보를 보여준다. (PSIO과 동일한 정보 출력)

SPOOLPOSPOOL

복원된 JOB들의 SPOOL 리스트를 보여준다. (POSPOOL과 동일한 정보 출력)

SPOOLPODD

복원된 JOB들의 SPOOL 내용을 보여준다. (PODD과 동일한 기능)

SPOOLCLEAR

임시 디렉터리에 복원된 JOB들을 제거한다.

상세한 설명과 기능은 SPOOL 백업 명령어를 참고한다.

7. JOB EXIT CODE

다음은 TJES에서 JOB과 STEP의 EXIT CODE를 정의한다.

7.1. STEP EXIT CODE

각 STEP은 종료될 때 다음의 형식으로 반환 코드를 보고한다.

XNNNN

EXIT STATUS로 R, S, U, A의 4가지 문자 중 하나를 갖고, 의미는 다음과 같다.

항목	설명
R	Normal Condition으로 해당 애플리케이션이 정상적으로 종료했음을 의미한다.
S	SYSTEM ABEND로 해당 애플리케이션이 시그널로 종료했음을 의미한다. SIGPIPE, SIGSEGV, SIGABEND, SIGBUG 등의 시그널 중에 프로세스를 종료시키는 시그널로 인해 프로세스가 이상 종료한 경우이다.
U	USER ABEND로 해당 애플리케이션이 정한 ABEND 상황임을 보고하고 WAASABND를 통해 종료했음을 의미한다.
A	Application ABEND로 해당 애플리케이션은 정상적으로 종료했으나, 그 RC 값을 호출한 프로그램에서 판단했을 때 조건을 만족하지 못해 JOB을 종료해야 함을 의미한다.

항목

설명

Normal Condition으로 해당 애플리케이션이 정상적으로 종료했음을 의미한다.

SYSTEM ABEND로 해당 애플리케이션이 시그널로 종료했음을 의미한다. SIGPIPE, SIGSEGV, SIGABEND, SIGBUG 등의 시그널 중에 프로세스를 종료시키는 시그널로 인해 프로세스가 이상 종료한 경우이다.

USER ABEND로 해당 애플리케이션이 정한 ABEND 상황임을 보고하고 WAASABND를 통해 종료했음을 의미한다.

Application ABEND로 해당 애플리케이션은 정상적으로 종료했으나, 그 RC 값을 호출한 프로그램에서 판단했을 때 조건을 만족하지 못해 JOB을 종료해야 함을 의미한다.

NNNN

0~4096까지의 숫자로 애플리케이션의 반환 값이다(255 이상은 external rc module을 통해 반환 코드가 보고된다).

7.2. JOB EXIT CODE

JOB EXIT CODE는 JOB의 종료 상황에 대한 부가 정보로 XNNNNN 형태를 가진다. (X : 6가지 문자(R, S, U, A, F, M)와 2가지 기호문자(+, -), N : 0-9)

다음은 각 상태별 JOB의 EXIT CODE의 형식에 대한 설명이다.

DONE
```
XNNNNN
```
마지막 STEP의 EXIT CODE이다(X는 STEP EXIT CODE와 동일하다).
ERROR
```
XNNNNN
```
ERROR를 발생시킨 STEP의 EXIT CODE이다(X는 STEP EXIT CODE와 동일하다).
STOP

사용자가 STOP을 명령한 경우이므로 EXIT CODE는 무의미하다.

FLUSH

[+-]NNNNN

구분	설명
+	Runner에서 비정상적인 상태를 감지하여 종료한 경우이며, 이때 NNNNN은 Runner가 반환한 값이다. 에러 상황이 OpenFrame의 에러 코드로 정의된 명확한 상황은 Error Code를 반환하고 이외에 세분화하여 정의되지 않은 상황은 1이 반환된다.
-	Runner가 UNIX 시그널에 의해 비정상 종료한 경우이며, 이때 NNNNN은 UNIX 시그널 번호이다.

구분

설명

Runner에서 비정상적인 상태를 감지하여 종료한 경우이며, 이때 NNNNN은 Runner가 반환한 값이다. 에러 상황이 OpenFrame의 에러 코드로 정의된 명확한 상황은 Error Code를 반환하고 이외에 세분화하여 정의되지 않은 상황은 1이 반환된다.

Runner가 UNIX 시그널에 의해 비정상 종료한 경우이며, 이때 NNNNN은 UNIX 시그널 번호이다.