소개

본 장에서는 TJES의 특징, 구성요소, 멀티 노드 TJES 구성, TJES 시스템 부트와 다운방식 그리고 TJES 시스템 테이블에 대해 기술한다.

1. 개요

OpenFrame TJES(Tmax Job Entry Subsystem, 이하 TJES)는 Mainframe의 JES에 대응하는 OpenFrame 시스템의 Batch JOB 관리 모듈이다. TJES는 멀티 노드 구성과 자동화된 에러복구 지원을 위해 TmaxSoft의 TP-Monitor 제품인 Tmax에 구현되었다.

TJES는 MVS JCL을 UNIX에서 IBM Mainframe과 가장 유사하게 지원하는 Batch 처리 솔루션이다. 또한 검증된 미들웨어를 이용한 멀티 노드 클러스터링을 통해 UNIX 시스템의 성능 한계를 뛰어넘어, 대단위 Mainframe도 문제없이 안정적으로 리호스팅할 수 있는 뛰어난 확장성을 제공한다.

TJES는 JCL을 통해 사용자로부터 JOB을 받아들이고, 이를 시스템의 자원 상황에 맞춰 스케줄링하여 Runner를 통해 수행하고, JOB의 수행 결과를 프린트하며, JOB의 수행상황을 조회하는 등 OpenFrame에서 일어나는 JOB에 관한 모든 수행을 관장한다.

TJES의 가장 중요한 역할과 특성은 다음과 같다.

  • JCL을 통해 JOB을 submit 받는다.

    • IBM Mainframe의 MVS JCL 지원

    • CONTROL-M, A-AUTO 등 외부 스케줄러와 연동 지원

    • 인터널 리더(Internal Reader) 지원

    • External Writer 지원

  • submit된 JOB을 스케줄링한다.

    • JOB CLASS, JOB priority에 따라 스케줄링

    • 멀티 노드 스케줄링 지원

  • JOB의 OUTPUT을 처리한다.

    • IBM 프린트 포맷을 지원하는 INFOPRINT 지원

본 안내서에서는 JOB을 관리하고 실행하는 단계, SPOOL 관리, OUTPUT 처리단계 등에 대하여 기술하고 TJES를 운영할 때 유용한 명령어와 로그 및 에러 처리방법, TJES 관련 환경설정에 대하여 기술한다.

2. 특징

TJES는 Mainframe의 Batch 프로그램(유틸리티, COBOL 프로그램, PL/I 프로그램)을 구동할 수 있는 것 이외에도, 기본적으로 UNIX 셸 스크립트, C 프로그램 등 UNIX에서 실행 가능한 모든 프로그램을 구동할 수 있다. UNIX에서 셸 스크립트와 cron을 통해 Batch 처리할 경우에는 체계화된 JOB 스케줄링 및 관리의 부재 그리고 리소스 통제 미비로 인해 어려움을 겪기 쉽다.

TJES는 다음의 사항을 통해 체계적인 Batch 시스템을 제공한다.

  • JOB CLASS와 RUNNER CLASS에 따른 스케줄링

  • Runner Slot 개수 제한으로 동시에 수행될 수 있는 Batch JOB의 개수 제어

  • JOB의 진행 사항 및 결과 확인

  • JOB의 속성 변경 및 일시 정지, 재개, 중단 등의 제어

  • OUTPUT 관리

  • 데이터셋 Lock을 통한 데이터 무결성 보장

  • TACF를 통한 보안성 향상

3. 구성 요소

TJES는 다음의 그림과 같이 구성된다.

figure 1 1 rev3
TJES 구성 요소
TJES 컴포넌트

  • obmjschd

    JOB 스케줄러이다. obmjschd는 TJES 전체 도메인에서 한 개만 기동되는 서버로 TJES의 JOB 스케줄링을 주로 담당하고 이외에 JOBID 발급과 각 노드의 Boot 상태를 관리한다.

  • ofrpmsvr

    프린터 관리 서버이다. TJES 전체 도메인에서 1개만 기동되는 서버로 OUTPUTQ에 등록된 OUTPUT을 조건에 맞는 프린터로 출력한다.

  • obmjhist

    JOB 히스토리 서버이다. TJES 전체 도메인에서 1개만 기동되는 서버로 JOB의 상태를 변경하는 모든 액션에 대한 정보를 저장하는 서버이다.

  • obmjmsvr

    JOB 관리 서버이다. TJES의 JOB과 OUTPUT의 관리 및 조회를 담당하는 서버이다.

  • obmjspbk

    SPOOL 백업 서버이다. TJES 전체 도메인에서 1개의 노드에서만 기동되어야 하는 서버로 실행이 종료된 JOB을 TJES에서 제거하면서 해당 JOB의 SPOOL을 별도의 저장소로 백업하고 이후 조회하는 기능을 제공한다. 백업된 SPOOL은 TJES 상에서와 동일한 형태로 조회가 가능하다.

  • obmjinit

    Runner와 Runner Slot을 관리하는 서버이다. obmjinit는 TJES의 각 노드마다 1개씩 기동되는 서버로, 자기 노드에 할당된 Runner와 Runner Slot를 관리하고 JOB을 Runner에 할당하는 역할을 담당한다.

    장애 발생 등의 원인으로 Tmax의 failover 관리를 통해 자동으로 재기동 되는 경우, obmjinit은 기존에 WORKING 또는 SUSPEND 상태의 JOB들을 STOP 상태로 변경하고 해당 Runner 프로세스들을 강제로 종료시킨다. 만약 사용자가 수동으로 obmjinit 서버를 재기동한 경우에는 WORKING/SUSPEND 상태의 JOB들을 STOP 상태로 변경하는 것은 동일하나 이 경우 Runner 프로세스를 자동으로 종료시키지는 않는다. 재기동 시점이 명확하지 않고 Runner의 PID가 자신의 것이라고 확신할 수 없기 때문에 사용자의 판단에 맡기기 위함이다.

  • obmtscmd (optional)

    ISPF 서비스를 통해 Clist를 수행하는 경우 Clist에 기술된 TSO 명령어를 처리하는 서버이다.

    ISPF 서비스를 사용하는 환경에만 제공되는 서버이며 ISPF 서비스와 JSON 형태로 데이터를 주고받기 때문에 Linux 환경에 jansson (jansson.h, libjansson.so)이 설치되어 있어야 한다.

  • tjclrun

    JCL을 실제로 구동하는 모듈이다. JCL에 기술된 하나의 JOB을 STEP 순서대로 실행한다.

OpenFrame 기타 제품

  • OpenFrame Base

    OpenFrame(Batch, OSC, OpenFrame Manager 등)이 구동되기 위해 필수적으로 필요한 제품이다.

    OpenFrame Base는 NVSM, TSAM 등의 데이터셋 지원, 카탈로그 관리, 데이터셋 Lock 관리 등을 지원한다.

    OpenFrame Base에 대한 자세한 내용은 OpenFrame Base "Base 안내서"를 참고한다.

  • OpenFrame TACF

    OpenFrame의 보안을 담당하는 제품이다. OpenFrame TJES는 OpenFrame TACF와 연동되어야 사용자 인증이나 데이터셋, JOB 이름 등의 자원에 대한 권한 체크등의 강력한 보안 기능을 사용할 수 있다.

    OpenFrame TACF에 대한 자세한 내용은 OpenFrame TACF "운영자 안내서"를 참고한다.
TJES 사용 자원

  • Runner Slot

    Runner Slot은 Runner의 운용 정보를 저장하고 있는 영역으로 Runner 1개당 1개의 Runner Slot이 할당된다. Runner와 obmjinit 사이의 데이터 교환 창구로 사용된다. Runner Slot은 obmjinit이 정상적으로 기동될 때 생성되며 obmjinit이 정상적으로 종료될 때 제거된다. 시스템 테이블 OFM_BATCH_RUNNER로 구현되어 있다.

  • SPOOL

    TJES가 사용하는 특별한 데이터셋이다. JOB 구동에 필요한 자원이나 JOB의 진행상황과 결과를 저장하기 위해 사용한다. JOB을 submit할 때 JOBID와 동일한 이름으로 디렉터리를 생성하여 이 디렉터리의 하위 공간을 사용하며, SPOOL을 구성하는 정보성 내용들은 설정에 따라 SPOOL 디렉터리의 멤버 또는 시스템 테이블로 관리된다. JOB SPOOL은 REMOVE나 CANCEL 명령이 실행되면 삭제된다.

  • TJES 시스템 테이블

    TJES가 내부 정보 저장을 위해 사용하는 시스템 테이블이다. JOBQ, JESST, OUTPUTQ가 있다. 자세한 내용은 TJES 시스템 테이블 을 참조한다.

Interface

  • textrun

    OpenFrame 제품이 아닌, 3 rd party 스케줄러에서 TJES에 JOB을 submit하고, 진행 상황과 결과를 모니터링할 수 있는 모듈이다. UNIX 상의 3 rd party 스케줄러들은 JOB의 시작과 끝을 프로세스의 시작과 종료로 구분한다. 따라서 textrun은 자신이 submit한 JOB이 끝날 때까지 종료되지 않고 계속 실행 중에 있다가 JOB이 종료되면 그 결과를 반환하고 종료한다.

  • tjesmgr

    시스템 관리자를 대상으로 하는 명령어 기반의 사용자 인터페이스이다. BOOT와 SHUTDOWN 명령을 포함한 TJES의 모든 기능을 사용할 수 있다.

  • OpenFrame Manager의 [Batch] 메뉴

    일반 사용자를 대상으로 하는 GUI 기반의 사용자 인터페이스이다. TJES 시스템을 Boot, Shutdown하는 등의 TJES 관리 기능을 제외한, JOB을 submit하고 조회 및 관리하는 기능을 제공한다.

외부 제품

  • External Scheduler

    TJES는 JOB CLASS와 priority에 따른 스케줄링만을 제공하며, JOB A의 수행 종료 후 JOB B의 수행 등 JOB 간의 상관관계에 따른 스케줄링을 지원하지 않는다. 이런 상관관계에 따른 스케줄링이나 일간, 주간, 월간 배치 등 자동화된 JOB submit을 위해서 External Scheduler가 사용된다. Control-m, A-Auto 등이 있다.

4. 멀티 노드 TJES 구성

TJES는 JOB의 처리 성능을 높이거나 서비스 가용성을 높이기 위해 여러 대의 UNIX 머신을 하나의 머신처럼 사용할 수 있는 멀티 노드 환경을 지원한다. 본 절에서는 TJES를 멀티 노드로 구성할 때 각 컴포넌트들이 어떻게 배치되어 동작하는지에 대해서 설명한다.

다음 그림은 2개의 노드로 TJES를 구성했을 때의 컴포넌트 다이어그램이다.

figure 1 2 rev2
멀티 노드 환경

멀티 노드로 TJES를 구성하기 위해서는 SPOOL, DATASET, TSAM 등의 데이터 저장소가 공유되어 있어야 한다. TJES는 공유된 자원을 통해 여러 노드에서 같은 데이터셋을 이용하거나, 다른 노드에서 구동된 JOB의 결과를 확인하는 등의 작업을 하나의 TJES 이미지로 사용자에게 서비스하게 된다.

NODE1에만 존재하는 ofrsasvr, ofrpmsvr, obmjschd, obmjhist, obmjspbk, obmtsmgr는 전체 도메인에서 동시에 1개만 존재할 수 있는 Tmax 서버이다. 만약 NODE1에 문제가 발생하여 이 서버들을 더 이상 서비스할 수 없을 경우(failover) Tmax에 의해 자동으로 NODE2를 기동시킴으로써 서비스 가용성을 높일 수 있다.

NODE1과 NODE2에 모두 존재하는 Tmax 서버인 obmjmsvr, ofrdsedt, ofrlhsvr, ofruisvr, obmjinit는 멀티 노드 서비스를 제공하기 위해 각 노드에 1개 이상 존재해야 하며, 그 중 obmjinit는 각 노드에 1개만 존재해야 한다.

tjclrun은 요구-응답방식(on-demand)으로 구동되는 프로세스이므로 각 노드마다 현재 실행(working)중인 JOB의 개수만큼 존재하고, 실행 중인 JOB이 없다면 존재하지 않는다. obmjinit와 tjclrun 사이에서 정보전달 창구역할을 담당하는 TJES Runner Slot은 obmjinit가 정상적으로 기동될 때 생성되고, 정상적으로 종료될 때 삭제된다.

외부 U/I에 해당하는 textrun, OpenFrame Manager, tjesmgr는 Tmax를 통해 어떤 노드에도 연결될 수 있다.

5. TJES Boot와 Down

Boot는 TJES가 JOB을 수행할 수 있는 상태이며, Down은 TJES가 더 이상 JOB을 실행할 수 없는 상태이다. 시스템 관리자는 tjesmgr의 노드 명령어 중 BOOT와 SHUTDOWN 명령어를 통해 이를 제어할 수 있다.

자세한 사용방법은 INITIATOR 명령어에서 BOOT와 SHUTDOWN을 참고한다.

5.1. Boot

Boot는 TJES가 Down되어 있는 상태에서만 동작하며, 이미 Boot되어 있는 상태라면 BOOT 명령은 무시된다. Boot는 TJES의 각 노드에서 자신의 Runner Slot 상태를 사용할 수 있는 상태로 초기화한 후, TJES의 obmjschd에게 Runner Slot의 현재 상태를 보고하여 JOB이 스케줄링될 수 있도록 한다.

TJES가 성공적으로 Boot되었다면 OFM_BATCH_NODEST 시스템 테이블에 해당 노드가 Boot되었음을 기록된다. 이후 DB 연결 실패 등과 같은 장애(disaster) 발생으로 인한 TJES 자동 복구 절차에서 Boot 상태를 유지할 수 있도록 한다.

멀티 노드 TJES 환경에서는 TJES가 Boot될 때, TJES 전체 도메인에 속한 모든 노드에 BOOT 명령을 전달하게 된다. 그리고 멀티 노드 환경에서도 개별 노드 별로 Boot하는 방법을 제공한다. Boot될 때 해당 노드의 Runner Slot 상태는 Downed에서 Down되기 전의 Active 또는 Inactive 상태로 복구되고, Boot된 적이 없다면 OpenFrame 환경설정에 tjes 서브젝트, INITDEF 섹션에 적용된 기본 상태로 복구된다.

5.2. WarmBoot와 ColdBoot

  • WarmBoot

    시스템을 초기화한 후 운영 중에 사용하는 일반적인 Boot이다. TJES Runner Slot 테이블을 초기화하고, 스케줄러에게 Runner Slot의 현재 상태 정보를 보고하여 JOB 스케줄링이 일어날 수 있도록 한다. tjesmgr의 BOOT 명령을 통해 WarmBoot를 한다.

  • ColdBoot

    OpenFrame TJES를 초기화하는 역할을 하는 특수목적의 Boot로 tjesinit 툴을 사용하여 시스템 테이블을 초기화한다. ColdBoot 이후에도 실제 JOB을 수행하기 위해서는 WarmBoot를 해야 한다.

    다음의 경우에 ColdBoot를 한다.

    • OpenFrame TJES 설치 후

    • 시스템 테이블 내용 변경 등 주요 시스템 업그레이드 후

    • OpenFrame 환경설정에 tjes 서브젝트에 다음과 같은 변경사항을 시스템에 적용할 때

      • JOBDEF 섹션의 JOBNUM 범위 변경 후

      • JOBCLASS 섹션 변경 후

      • OUTDEF 섹션의 OUTNUM 범위 변경 후

tjesinit 툴에 대한 자세한 내용은 OpenFrame Batch "툴 참조 안내서"의 "tjesinit"을 참고한다.

5.3. Shutdown

Down은 obmjinit가 Boot되어 있는 상태에서만 동작하며, 이미 Down되어 있는 상태라면 SHUTDOWN 명령은 무시된다. SHUTDOWN 명령이 수행될 때 TJES는 해당 노드의 상태를 ‘Not booted’로 변경하여 시스템이 Down된 이후에 발생되는 추가적인 JOB의 스케줄링을 제한한다.

Down되기 전에 스케줄링되어 수행 중인 JOB은 기본적으로 종료될 때까지 정상적인 절차를 밟아 수행되지만, 사용자가 강제 종료할 것을 명시했다면, SHUTDOWN 명령을 받은 즉시 정지된다.

실행 중인 JOB을 모두 종료하고 나서 시스템을 Down시키려면, STOP 명령을 통해 명시적으로 실행 중인 JOB을 종료하고 SHUTDOWN 명령으로 TJES 시스템을 Down시킨다.

TJES가 성공적으로 Down되었다면 OFM_BATCH_NODEST 시스템 테이블에 해당 노드가 Down되었음을 기록하여, 이후 DB 연결 실패 등과 같은 장애(disaster) 발생으로 인한 TJES 자동 복구 절차에서 Down 상태를 유지할 수 있도록 한다.

멀티 노드 TJES 환경에서는 TJES가 Down될 때 TJES 전체 도메인에 속한 모든 노드에 SHUTDOWN 명령을 전달하여 시스템을 Down하는 방법 외에도 개별 노드별로 시스템을 Down할 수 있다.

  • 전체 시스템 Down시키는 명령어

     shutdown

  • 개별 시스템 Down시키는 명령어

     shutdown node=nodename

SHUTDOWN 명령을 받으면 해당 노드의 Runner Slot들의 상태는 기본적으로 Downed로 변경된다. JOB이 수행 중인 경우 Runner Slot의 상태를 working으로 유지하되 JOB의 수행이 끝난 시점에 Runner Slot의 상태를 Downed 상태로 변경한다.

6. TJES 시스템 테이블

TJES는 시스템 설정과 각종 자원에 대한 정보를 노드간에 공유하기 위해 다음과 같은 시스템 테이블에 저장한다.

6.1. JESST

다음과 같은 TJES의 시스템 레벨 정보(JESST)는 종류에 따라 3개의 시스템 테이블(OFM_BATCH_JESST, OFM_BATCH_JCLSST, OFM_BATCH_NODEST)에 나뉘어 저장된다.

시스템 레벨 정보 설명

노드 정보

시스템 상에 존재하는 노드들의 이름과 각각의 노드들의 Boot 상태를 저장한다. 시스템 테이블 OFM_BATCH_NODEST에 저장된다.

JOBID 정보

JOBID 범위와 마지막 JOBID 정보를 저장한다. 시스템 테이블 OFM_BATCH_JESST에 저장된다.

OUTPUTQ 정보

OUTPUTQ 크기 정보를 저장한다. 시스템 테이블 OFM_BATCH_JESST에 저장된다.

JOB CLASS 정보

JOB CLASS별 기본 속성 정보를 저장한다. 시스템 테이블 OFM_BATCH_JCLSST에 저장된다.

  1. JESST의 테이블은 OFM_BATCH_JESST, OFM_BATCH_JCLSST, OFM_BATCH_NODEST의 3개로 구성되며 OpenFrame을 설치할 때 설치되어야 한다.

  2. ColdBoot 단계 중에 기록해야 하는 JESST 시스템 테이블들의 JOBID 정보, OUTPUTQ 정보는 tjesinit 툴을 통해서만 갱신된다. 이후에 OpenFrame 환경설정에 tjes 서브젝트를 변경한다면 tjesinit 툴을 통해 시스템 테이블들에 해당 변경 사항을 반영해야 한다.

6.2. JOBQ

TJES에서 JOB을 관리하는데 필요한 정보를 저장하는 시스템 테이블로, 실제 테이블 이름은 OFM_BATCH_JOBQ이다.

JOBID, JOBNAME, JOBCLASS, JOBPRTY, JOBSTATUS, JCLPATH, USER ACCOUNT 등이 JOBQ에 저장된다. JOBID에 대해서 기본 인덱스가 설정되어 있다.

6.3. OUTPUTQ

TJES에서 수행된 JOB의 결과물인 OUTPUT을 관리하는 데 필요한 정보를 저장하는 시스템 테이블로, 실제 테이블 이름은 OFM_BATCH_OUTPUTQ이다.

OUTPUTID, JOBID, JOBNAME 등 OUTPUT을 검색 관리하기 위한 정보와 data file path, OUTPUT CLASS, OUTPUT DISP 등 실제 OUTPUT을 출력하기 위한 정보가 OUTPUTQ에 저장된다.

TJES에서 사용하는 모든 시스템 테이블들은 OpenFrame을 설치할 때 batchinit 툴을 사용해 설치한다. batchinit의 실행에 관해서는 OpenFrame Batch "툴 참조 안내서"의 "batchinit"을 참고한다.

OpenFrame을 최초 설치한 후에는 tmboot 전 OpenFrame에서 제공하는 ColdBoot용 UNIX 툴인 tjesinit을 통해 시스템 테이블을 초기화해야 한다.