JOB의 관리

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

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

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

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

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

JCL이 submit되면 TJES는 해당 JCL을 분석하여 JOB 엔트리를 구성하고, JOBID, SPOOL 등 JOB 관리에 필요한 리소스를 할당한 후 JOBQ에 저장한다. submit된 JOB의 정보는 스케줄러에 통보되어, 스케줄러에 의해 JOB이 Runner Slot에 할당될 수 있도록 한다.

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

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

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

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

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

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

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

JOB의 속성 중 하나로 JCL JOB 구문의 클래스 파라미터에 기술되는 한 개의 문자로, A-Z, 0-9 중 한 개의 값을 가져야 한다.

JCL에 클래스가 기술되어 있지 않을 때에는 OpenFrame 환경설정에 tjclrun 서브젝트, JOB 섹션의 CLASS 키에 기술된 디폴트 JOB CLASS를 사용한다. JOB CLASS는 해당 JOB이 실행될 수 있는 Runner Slot을 제한하는 용도로 JOB 스케줄링에 사용된다. A라는 JOB CLASS를 가진 JOB은 RUNNER CLASS에 CBA 또는 ABC와 같은 식으로 A를 포함한 Runner Slot에만 할당될 수 있다.

이외에도 JOB CLASS의 하위 속성인 HOLD에 따라 TJES의 동작방식이 달라진다. HOLD 속성이 명시된 JOB CLASS로 submit된 JOB은 JCL 상의 JOB 구문에 TYPRUN=HOLD가 지정되지 않았더라도 HOLD 상태로 submit된다.

Runner Slot의 속성 중 하나로 OpenFrame 환경설정에 tjes 서브젝트, INITDEF 섹션에 기술된다.

RUNNER CLASS는 JOB CLASS와 일치해야 하므로 JOB CLASS와 동일한 A-Z, 0-9 중 1개의 값을 가지며, 1개의 Runner Slot은 최대 8개의 클래스를 가질 수 있다.

복수의 RUNNER CLASS가 설정된 경우에는 앞에 기술된 클래스에 해당하는 JOB이 없을 때에만 뒤에 기술된 클래스가 사용될 수 있다. 즉, 제일 먼저 설정된 클래스가 최우선이고 맨 마지막에 설정된 클래스가 제일 낮은 우선순위를 갖는다. 또한 i번째에 기술된 클래스에 해당하는 JOB을 실행하기 위해서는, TJES의 모든 Runner Slot이 i번째 이전에 기술된 클래스로 해당 JOB을 실행할 수 없어야 한다.

예를 들면 TJES 내에 1번 Runner Slot은 RUNNER CLASS가 ABC이고, 2번 Runner Slot은 BCA였을 때, C의 JOB은 B의 JOB이 없을 때 2번 Runner Slot의 두 번째 클래스로 실행될 수 있지만, 1번 Runner Slot의 세 번째 클래스로 실행하기 위해서는 A와 B의 JOB이 없으면서, 2번 Runner Slot이 이미 JOB을 실행하고 있거나 active 상태가 아니어서, 두 번째 클래스로 JOB을 실행할 수 없어야 한다.

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

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

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

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

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

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

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

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

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

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

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

JOB이 submit 된다.

JOB을 Runner에 할당한다.

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

JOB의 실행이 종료된다.

JOB이 TJES에서 제거된다.

JOB이 일시정지된다.

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

JOB의 중앙 처리 장치의 사용시간에 대한 상대적인 우선순위를 설정한다.

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

JOB 수행이 취소된다.

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

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

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