소개

본 장에서는 TJES의 특징, 구성요소, 멀티 노드 TJES 구성, TJES 시스템 Boot와 Down 방식 그리고 TJES 시스템 데이터셋에 대해 기술한다.

1. 개요

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

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

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

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

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

    • Fujitsu XSP Mainframe의 JCL 지원

    • JOB Group 개념 지원

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

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

    • JOB Group의 우선순위, 다중도, 직렬 수행 등의 속성과 시스템 다중도, JOB priority에 따라 스케줄링

    • 멀티 노드 스케줄링 지원

  • JOB의 output을 처리한다.

2. 특징

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

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

  • JOB Group 속성에 따른 스케줄링

  • 시스템 다중도 제한으로 동시에 수행될 수 있는 Batch JOB의 개수 제어

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

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

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

  • OUTPUT 관리

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

  • TACF를 통한 보안성 향상

3. 구성요소

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

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

  • obmjschd

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

  • ofrpmsvr

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

  • obmjhist

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

  • obmjspbk

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

  • obmjinit

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

  • obmjmsvr

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

  • tjclrun

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

  • obmtsmgr

    TSO 관리 서버이다. OpenFrame에서 TSO 화면에 로그인하면 TSO 명령이 배치 JOB으로 실행되는데, 이때 화면과 JOB을 연계하고 관리하는 역할을 담당한다.

OpenFrame 기타 제품

  • OpenFrame Base

    OpenFrame(Batch, AIM, OpenFrame Manager 등)이 구동되기 위해 필수적으로 필요한 제품이다. OpenFrame Base는 NON-VSAM, 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 Slot은 Runner와 obmjinit 사이의 데이터 교환 창구로 사용된다. Runner Slot은 obmjinit이 정상적으로 기동될 때 생성되며 obmjinit이 정상적으로 종료될 때 제거된다. RDB 테이블의 레코드로 구현되어 있다.

  • SPOOL

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

  • TJES 시스템 테이블

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

인터페이스

  • textrun

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

  • tjesmgr

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

  • OpenFrame Manager

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

외부 제품

  • External Scheduler

    OpenFrame은 JOB Group과 JOB의 속성에 따른 TJES의 기본적인 스케줄링만을 제공하며, 실제 업무에서 필요한 복잡한 스케줄링을 지원하지 않는다. 일간, 주간, 월간 배치 등 자동화된 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 설치 후

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

    • tjes 설정의 다음과 같은 변경사항을 시스템에 적용할 때

      • [JOBDEF] 절의 JOBNUM 범위 변경 후

      • OUTPUTQ 사이즈 변경 후

      • JOB GROUP 설정 변경 후

ColdBoot에 대한 자세한 내용은 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_JOBGST, OFM_BATCH_NODEST)에 나뉘어 저장된다.

시스템 테이블명 설명

노드 정보

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

JOBID 정보

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

OUTPUTQ 정보

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

JOB Group 정보

JOB Group별 속성 정보를 저장한다. 시스템 테이블 OFM_BATCH_JOBGST에 저장된다.

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

6.2. JOBQ

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

JOBID, JOBNAME, JOB_STATUS, JOBCLASS, JOBPRTY, JOBGNAME, 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을 통해 시스템 테이블을 초기화해야 한다.