openframe tjes 안내서 - kr.tmaxsoft.com · resume.....96 stop ... compiler mf-cobol

OpenFrame TJES 안내서

소프트웨어

OpenFrame/Batch v4.0

안내서 버전 v1.2

Copyright © 2008 TmaxSoft Co., Ltd. All Rights Reserved.

OpenFrame TJES 안내서 2

Copyright Notice

Copyright © 2008 TmaxSoft Co., Ltd. All Rights Reserved.

TmaxSoft Co., Ltd.

서울특별시 강남구 대치동 946-1글라스타워 18층 우)135-708

Restricted Rights Legend

This software and documents are made available under the terms of the TmaxSoft License Agreement and may only be used or copied in accordance with the terms of this agreement. No part of this document may be reproduced, transmitted, or translated in any form or by any means, electronic, mechanical, manual, or optical, without the prior written consent of TmaxSoft Co., Ltd.

이 소프트웨어 및 안내서는 오직 TmaxSoft Co., Ltd.와의 사용권 계약 하에서만 이용이 가능하며, 사용권 계약에 따라서 사용하거나 복사할 수 있습니다. 또한 이 안내서에서 언급하지 않은 정보에 대해서는 보증 및 책임을 지지 않습니다. 이 안내서에 대한 권리는 저작권에 보호되므로 발행자의 허가 없이 전체 또는 일부를 어떤 형식이나, 사진 녹화, 기록, 정보 저장 및 검색 시스템과 같은 그래픽이나 전자적, 기계적 수단으로 복제하거나 사용할 수 없습니다.

Trademarks

Tmax, WebtoB, WebT, JEUS and OpenFrame are registered trademarks of TMAXSoft Co., Ltd. Other products, titles or services may be registered trademarks of their respective companies.

TMAX Tmax, WebtoB, WebT, JEUS, OpenFrame은 TMAXSoft Co., Ltd.의 등록 상표입니다. 기타 모든 제품들과 회사 이름은 각각 해당 소유주의 상표로서 참고용으로만 사용됩니다.

안내서 정보

안내서 제목: OpenFrame TJES 안내서

발행일: 2008년7월15일

소프트웨어 버전: OpenFrame/Batch v4.0

안내서 버전: v1.2


연락처

Korea TmaxSoft Co., Ltd. 18F Glass Tower, 946-1, Daechi-Dong, Kangnam-Gu, Seoul 135-708 South Korea Tel: 82-2-6288-2114 Fax: 82-2-6288-2115 Email: [email protected] Website: http://www.tmax.co.kr

USA TmaxSoft, Inc. US Headquarter (San Jose) 130 Rio Robles San Jose, CA 95134, USA Tel: 1-408-321-2400 Fax: 1-408-321-2444 Email: [email protected] Website: http://www.tmaxsoft.com Sales Office (New Jersey) 560 Sylvan Ave, Englewood Cliffs NJ 07632, USA Tel: 1-201-567-8266 Fax: 1-201-567-7339 Email: [email protected] Website: http://www.tmaxsoft.com

Japan TmaxSoft Japan Co., Ltd. 5F Sanko Bldg, 3-12-16 Mita, Minato-Ku, Tokyo, 108-0073 Japan Tel: 81-3-5765-2550 Fax: 81-3-5765-2567 Email: [email protected] Website: http://www.tmaxsoft.co.jp

mailto:[email protected]

http://www.tmax.co.kr/


http://www.tmaxsoft.com/


http://www.tmaxsoft.com/


http://www.tmaxsoft.co.jp/


China TmaxSoft China Co., Ltd. Beijing Silver Tower, RM 1508, 2# North Rd Dong San Huan, Chao yang District, Beijing, China, 100027 Tel: 86-10-6410-6145~8 Fax: 86-10-6410-6144 Email: [email protected] Website: http://www.tmaxsoft.com.cn Shanghai Office Room 4123, 41 Floor, China Development Bank Building, No.500 Pudong Road(s), Shanghai, China, 200120 Tel: 86-21-6109-5751 Fax: 86-21-6109-5750 Email: [email protected] Website: http://www.tmaxsoft.com.cn


http://www.tmaxsoft.com.cn/


http://www.tmaxsoft.com.cn/


내용 목차

안내서에 대하여 ............................................................................................... 12

안내서의 대상 ........................................................................................................ 12

안내서의 전제 조건 ............................................................................................... 12

안내서 구성,........................................................................................................... 13

안내서 규약............................................................................................................ 14

시스템 사용 환경 ................................................................................................... 15

관련 안내서............................................................................................................ 16

제1장 TJES...................................................................................................... 17

1.1 TJES 특징 ....................................................................................................... 18

1.2 TJES 구성요소 ................................................................................................ 19

1.3 멀티 노드 TJES 구성 ..................................................................................... 23

1.4 TJES 부트와 다운 방식 .................................................................................. 24

Boot .............................................................................................................................. 24

Warm Boot와 Cold Boot ............................................................................................ 25

Shutdown..................................................................................................................... 26

1.5 TJES 시스템 데이터 셋 .................................................................................. 27

제2장 JOB의 관리........................................................................................... 33

2.1 JOB STATUS................................................................................................... 34

JOB의 상태 변경 ......................................................................................................... 36

JOB CLASS ................................................................................................................. 37

RUNNER CLASS ......................................................................................................... 38

2.2 JCL의 관리 ...................................................................................................... 38

2.3 JOB 처리단계 .................................................................................................. 39

Submit 단계 ................................................................................................................. 39

Schedule 단계 ............................................................................................................. 41

Execution 단계 ............................................................................................................ 41

Output 단계 ................................................................................................................. 42

Remove 단계 ............................................................................................................... 42

2.4 JOB의 조회 ..................................................................................................... 42

2.5 JOB Logging................................................................................................... 43


2.6 JOB의 BACKUP ............................................................................................. 46

2.7 JOB EXIT CODE ............................................................................................. 47

STEP EXITCODE ......................................................................................................... 47

JOB STATUS와 EXITCODE........................................................................................ 47

제3장 JOB Execution ..................................................................................... 49

3.1 JOB 실행 ......................................................................................................... 49

실행 초기화................................................................................................................... 51

입력 JCL 파싱.............................................................................................................. 53

실행 과정 ...................................................................................................................... 54

EXEC PGM 처리 .......................................................................................................... 55

EXEC PROC 처리 ........................................................................................................ 58

DD 처리 ........................................................................................................................ 59

스페셜 DD..................................................................................................................... 61

OUTPUT 처리 .............................................................................................................. 63

JOB SPOOL ................................................................................................................. 63

JOB Control................................................................................................................. 67

JOB Level Report........................................................................................................ 68

STEP Level Report...................................................................................................... 68

보안 ............................................................................................................................... 69

tjclrun 호출 .................................................................................................................. 73

tjclrun 인터널 로그...................................................................................................... 74

제4장 SPOOL.................................................................................................. 77

4.1 SPOOL 데이터 셋 ........................................................................................... 77

4.2 SPOOL BACKUP ............................................................................................ 86

제5장 OUTPUT Processing............................................................................ 87

5.1 OUTPUT .......................................................................................................... 87

5.2 OUTPUT 처리.................................................................................................. 88

OUTPUT CLASS.......................................................................................................... 88

OUTPUT DISPOSITION............................................................................................... 89

Internal Reader............................................................................................................ 91

제6장 TJESMGR 명령어 ................................................................................. 93

6.1 JOB 실행 명령어............................................................................................. 94

RUN .............................................................................................................................. 94

START .......................................................................................................................... 95


HOLD............................................................................................................................ 95

CANCEL ....................................................................................................................... 95

SUSPEND..................................................................................................................... 95

RESUME....................................................................................................................... 96

STOP ............................................................................................................................ 96

REMOVE ...................................................................................................................... 96

OUTQUEUEPURGE..................................................................................................... 96

INQUEUEclass............................................................................................................. 97

6.2 JOB/OUTPUT 명령어...................................................................................... 97

PS (Print Screen)......................................................................................................... 97

PSJOB (Print Screen JOB detail information) ......................................................... 98

PSIO (Print Screen Input/Output information) ......................................................... 99

PO (Print Output status)........................................................................................... 100

POLIST (Print Output detail LIST) ........................................................................... 100

POJOB (Print Output of JOB) .................................................................................. 101

POSPOOL (Print Output SPOOL of JOB) ............................................................... 102

PODD (Print Output DD Information) ...................................................................... 102

PSHISTORY (Print Screen of JOB History) ............................................................ 103

6.3 INITIATOR 명령어 ......................................................................................... 104

BOOT.......................................................................................................................... 104

SHUTDOWN............................................................................................................... 104

NODESTATUS(NODEST) .......................................................................................... 104

PSJCLRUN(PSR)....................................................................................................... 105

JCLRUNACTIVE(RA)/JCLRUNINACTIVE(RI) .......................................................... 106

JCLRUNclass(RC)..................................................................................................... 106

PSclass(PSC) ............................................................................................................ 107

6.4 데이터 셋 명령어 .......................................................................................... 107

PSCATALOG(PSCAT)................................................................................................ 108

SETCATALOG(SETCAT) ........................................................................................... 109

PSDS .......................................................................................................................... 109

PSENTRY ....................................................................................................................111

DATASETCREATE(DSCREATE)............................................................................... 112

DATASETDELETE(DSDELETE)................................................................................ 114

DATASETCOPY(DSCOPY)........................................................................................ 114

DATASETEXPORT(DSEXPORT) .............................................................................. 115

DATASETIMPORT(DSIMPORT) ................................................................................ 115


GDGCREATE ............................................................................................................. 116

GDGDELETE.............................................................................................................. 116

RECATALOG(RECAT) ............................................................................................... 117

UNCATALOG(UNCAT)............................................................................................... 118

PSLOCK(PSL)............................................................................................................ 118

LOCKCLEAR ............................................................................................................. 119

PSVOLUME(PSV) ...................................................................................................... 120

6.5 SPOOL 백업 명령어 ..................................................................................... 121

SPOOLBACKUP(SPBK)............................................................................................ 121

SPOOLBACKUPLIST(SPBL) .................................................................................... 121

SPOOLPS(SPPS)....................................................................................................... 122

SPOOLRESTORE(SPRE).......................................................................................... 122

SPOOLCLEAR(SPCL) ............................................................................................... 123

SPOOLPSIO(SPPSIO) ............................................................................................... 123

SPOOLPSJOB(SPPSJ) ............................................................................................. 123

SPOOLPOSPOOL(SPPOSPOOL) ............................................................................ 124

SPOOLPODD(SPPODD) ........................................................................................... 124

6.6 기타 명령어 ................................................................................................... 125

HELP........................................................................................................................... 125

CLS............................................................................................................................. 125

VERSION.................................................................................................................... 125

LICENSE .................................................................................................................... 125

EDIT............................................................................................................................ 126

PSPRINT(PSP)........................................................................................................... 126

제7장 환경설정 .............................................................................................. 127

7.1 TMAX 설정 .................................................................................................... 127

TMAX server .............................................................................................................. 128

7.2 TJES 설정 ..................................................................................................... 131

OpenFrame 환경 파일 형식 ..................................................................................... 131

TJES 환경 파일 ......................................................................................................... 131

7.3 TJESMGR 설정 ............................................................................................. 139

7.4 OUTPUT 설정................................................................................................ 141

7.5 TJCLRUN 설정.............................................................................................. 142

7.6 Return Code 설정......................................................................................... 148


그림 목차

[그림 1-1] TJES 구성요소 .......................................................................................................... 19

[그림 1-2] 멀티 노드 환경 ......................................................................................................... 23

[그림 2-1] JOB 상태 흐름도....................................................................................................... 34

[그림 5-1] OUTPUT DISP에 따른 처리과정 .............................................................................. 89


표 목차

[표 0-1] 안내서 규약 .................................................................................................................. 14

[표 0-2] 시스템 사용 환경 ......................................................................................................... 15

[표 0-3] OpenFrame 관련 안내서 .............................................................................................. 16

[표 0-4] IBM 참고 안내서........................................................................................................... 16

[표 2-1] JOB 상태 변경 명령어 ................................................................................................. 36

[표 2-2] JOB 정보 조회 명령어 ................................................................................................. 42

[표 2-3] SPOOL 백업 명령어 ..................................................................................................... 46

[표 3-1] tjclrun의 JOB 실행 작업 리스트 .................................................................................. 50

[표 4-1] JESMSG상의 JOB 정보 ............................................................................................... 80

[표 4-2] JESMSG상의 JOBSTEP 정보...................................................................................... 80

[표 6-1] PS 디스플레이 정보 ..................................................................................................... 97

[표 6-2] PSJOB 디스플레이 정보 .............................................................................................. 99

[표 6-3] PSJOB – 모니터링 디스플레이 정보........................................................................... 99

[표 6-4] PSIO – 데이터 셋 I/O 디스플레이 정보.................................................................... 100

[표 6-5] PO – OUTPUT 상태 디스플레이 정보 ....................................................................... 100

[표 6-6] POLIST – OUTPUT 리스트 디스플레이 정보............................................................ 101

[표 6-7] POJOB – OUTPUT 디스플레이 정보 ......................................................................... 101

[표 6-8] POSPOOL – SPOOL 디스플레이 정보 ...................................................................... 102

[표 6-9] PSHISTORY – 입력 파라미터 .................................................................................... 103

[표 6-10] NODESTATUS – 노드 정보...................................................................................... 105

[표 6-11] PSJCLRUN – runner 상태 정보 ............................................................................... 105

[표 6-12] PSCATALOG - 데이터 셋 디스플레이 정보 ............................................................ 108

[표 6-13] PSDS – 데이터 셋 디스플레이 정보 ....................................................................... 110

[표 6-14] PSDS – 멤버 디스플레이 정보 .................................................................................111

[표 6-15] PSENTRY – 데이터 셋 디스플레이 정보 ................................................................ 112

[표 6-16] PSENTRY - 멤버 디스플레이 정보.......................................................................... 112

[표 6-17] DATASETCREATE – 입력 파라미터 ........................................................................ 113

[표 6-18] GDGCREATE – 입력 파라미터 ................................................................................ 116

[표 6-19] RECATALOG – 입력 파라미터................................................................................. 118

[표 6-20] PSLOCK – 디스플레이 정보 .................................................................................... 119

[표 6-21] PSVOLUME – 볼륨 디스플레이 정보...................................................................... 120

[표 6-22] SPOOLPS – 백업된 SPOOL 리스트 디스플레이 정보 .......................................... 122


[표 6-23] PSPRINT – 프린터 디스플레이 정보....................................................................... 126

[표 7-1] TJES 서버 ................................................................................................................... 128

[표 7-2] TJES 관련 서버 .......................................................................................................... 128

안내서에 대하여



안내서의 대상

본 안내서는 OpenFrame 리호스팅 솔루션인 OpenFrame Batch v4.0 시스템의 엔

진 역할을 수행하는 TJES를 통해 JOB을 실행하고 관리하는 사용자를 대상으로

기술한다.

안내서의 전제 조건

본 안내서를 정확히 사용하려면 OpenFrame Batch v4.0의 개념을 이해하고 있어

야 한다. OpenFrame Batch v4.0에 대한 이해를 돕기 위해 “Batch 안내서”를 먼저

숙지할 것을 권장한다.



안내서 구성,

TJES 안내서는 총 7개의 장으로 구성되어 있다.

각 장의 주요 내용은 다음과 같다.

제1장: TJES 개요

TJES의 특징, 구성요소, 멀티 노드 TJES 구성, TJES 시스템 부트와 다운방

식 그리고 TJES 시스템 데이터 셋에 대해 기술한다.

제2장: JOB 관리

JOB STATUS와 상태 변경, CLASS 개요, JCL 관리, JOB 처리단계, JOB 조회

방법, JOB Logging, JOB 백업방법 및 JOB의 EXIT CODE에 대해 기술한다.

제3장: JOB 실행

실제로 JOB을 실행하는 runner인 tjclrun의 동작방식과 기능에 대해 기술한다.

또한 JCL Parsing, JOB 실행과 JOB 실행의 산출물 등에 대한 설명을 포함한

다.

제4장: SPOOL

SPOOL 데이터 셋과 SPOOL 백업방법에 대해 기술한다.

제5장: OUTPUT Processing

OUTPUT 개요, OUTPUT 처리방식에 대해 기술한다.

제6장: TJESMGR 명령어

JOB 실행 명령어, JOB/OUTPUT 명령어, runner slot 명령어, 데이터 셋 명령

어, SPOOL 백업 명령어와 기타 TJESMGR 명령어에 대해 기술한다.

제7장: 환경설정

TJES에서 필요로 하는 각종 환경파일에 대해 기술한다.



안내서 규약

표기 의미

AaBbCc123 명령어

AaBbCc123 명령어 수행 후 화면에 출력된 결과물

참고: 참고 또는 주의 사항

{ } 필수 인수값

[ ] 옵션 인수값

| 선택 인수값

“ ” (따옴표) 다른 관련 안내서 또는 안내서 내의 다른 장 및 절

언급

하이퍼링크 메일계정, 웹 사이트, 다른 장 및 절 참고

진하게 강조

<AaBbCc123> 프로그램 소스 코드의 파일명, 디렉터리 이름

Courier New 파일, 디렉터리 이름, 환경설정 변수

$ 명령어 프롬프트

; (세미콜론)

: (콜론) 파라미터 구분자

이탤릭체 사용자 정의 인수값

[그림 1-1] 그림 이름

[표 1-1] 표 이름

[표 0-1] 안내서 규약



시스템 사용 환경

요구사항

Platform IBM AIX 5.x

HP-UX 11.xx

Solaris 9 (SunOS 5.9)

Hardware 최소 120MB 하드디스크 공간

256MB 이상 메모리 공간

1GB 이상 하드디스크와 512MB 이상 메모리 공간 권장

Database Tibero 3.0

Oracle 9i 또는 10g

Compiler MF-Cobol 컴파일러

[표 0-2] 시스템 사용 환경



관련 안내서

제품 안내서

OpenFrame 유틸리티 참고 안내서

OpenStudio 운영자 안내서

TACF 운영자 안내서

데이터 셋 안내서

[표 0-3] OpenFrame 관련 안내서

제품 안내서

Mainframe JES2 Introduction

MVS JCL Reference

MVS JCL User’s Guide

JCL Reference Guide

[표 0-4] IBM 참고 안내서

제1장 TJES


제1장 TJES

TJES는 TMAX Job Entry Subsystem의 약자로, Mainframe의 JES에 대응하는

OpenFrame 시스템의 배치 JOB 관리 모듈이다. TJES는 멀티 노드 구성과 자동

화된 에러복구 지원을 위해 TP-Monitor 제품인 TMAX 상에 구현되었다.

TJES는 JCL을 통해 사용자로부터 JOB을 받아들이고, 이를 시스템의 자원 상황

에 맞춰 스케줄링하여 runner를 통해 수행하고, JOB의 수행 결과를 프린트하며,

JOB의 수행상황을 조회하는 등 OpenFrame에서 일어나는 JOB에 관한 모든 수

행을 관장한다.

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

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

IBM Mainframe의 MVS JCL 지원

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

인터널 리더 지원

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

JOB class, JOB priority에 따라 스케줄링

멀티노드 스케줄링 지원

3. JOB의 output을 처리한다.

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

OpenFrame TJES는 MVS JCL을 UNIX 상에서 IBM Mainframe과 가장 유사하게

지원하는 배치 처리 솔루션이다. 또한 검증된 미들웨어를 이용한 멀티노드 클러

스터링을 통해 UNIX 시스템의 성능 한계를 뛰어넘어, 대단위 Mainframe도 문제

없이 안정적으로 리호스팅 할 수 있는 뛰어난 확장성을 제공한다.

본 안내서에서는 JOB을 관리하고 실행하는 단계, SPOOL 관리 그리고 OUTPUT

처리단계 등에 대하여 알아보고, TJES를 운영 시 유용한 명령어와 TJES 운영 시

발생한 로그와 에러 처리방법에 대해서 설명할 것이다. 마지막으로 TJES 관련

환경설정에 대하여 알아본다.

제1장 TJES


1.1 TJES 특징

OpenFrame의 TJES는 Mainframe 배치 프로그램(유틸리티, 코볼 프로그램, PL/I

프로그램)을 구동할 수 있는 것 이외에도, 기본적으로 UNIX 쉘 스크립트, C 프로

그램 등 UNIX에서 실행 가능한 모든 프로그램을 구동할 수 있다.

UNIX에서 쉘 스크립트와 cron을 통해 배치 처리할 경우에는 체계화된 JOB 스케

줄링과 관리의 부재 그리고 리소스 통제 미비로 인해 어려움을 겪기 쉽다.

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

- JOB class와 runner class에 따른 스케줄링

- Runner slot 개수 제한으로 동시에 수행될 수 있는 배치 JOB의 개수 제어

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

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

- OUTPUT 관리

- 데이터 셋 lock을 통한 데이터 무결성 보장

- TACF를 통한 보안성 향상

제1장 TJES


1.2 TJES 구성요소

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

[그림 1-1] TJES 구성요소

OpenFrame 기본 컴포넌트

ofrlmsvr

데이터 셋 lock 관리 서버이다. JOB을 실행 중에 사용되는 데이터 셋에 대한

lock을 관리한다.

ofrsasvr

보안인증 서버이다. TJES에서 사용자 인증과 사용자의 자원에 대한 인증을 수행

한다.

제1장 TJES


TJES 컴포넌트

obmjmsvr

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

다.

obmjschd

JOB 스케줄러이다. obmjschd는 TJES 전체 도메인에서 한 개만 기동되는 서버

로 TJES의 JOB 스케줄링을 주로 담당하고 이외에 JOB ID 발급과 각 노드의 부

트상태를 관리한다.

obmjinit

Runner와 runner slot을 관리하는 서버이다. obmjinit는 TJES의 각 노드마다 한

개씩 기동되는 서버로, 자기 노드에 할당된 runner와 runner slot를 관리하고 JOB

을 runner에 할당하는 역할을 담당한다.

obmjhist

JOB 히스토리 서버이다. TJES 전체 도메인에서 1개만 기동되는 서버로 JOB의

상태를 변경하는 모든 액션에 대한 정보를 저장하는 서버이다.

obmjspbk

SPOOL 백업 서버이다. TJES 전체 도메인에서 한 개의 노드에서만 기동되어야

하는 서버로 실행이 종료된 JOB을 TJES에서 제거하면서 해당 JOB의 SPOOL을

별도의 저장소로 백업하고 이후 조회하는 기능을 제공한다. 백업된 SPOOL은

TJES 상에서와 동일한 형태로 조회가 가능하다.

tjclrun

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

대로 실행한다.

ofrpmsvr

프린터 관리 서버이다. TJES 전체 도메인에서 한 개만 기동되는 서버로

OUTPUTQ에 등록된 OUTPUT을 조건에 맞는 프린터로 출력한다.

제1장 TJES


Data Repository

TJES Shared memory

UNIX 공유 메모리 영역이다. Runner와 obmjinit 사이의 데이터 교환 창구로 사용

된다. 1개의 runner 당 1개의 runner slot을 할당하여 관리하게 되며, 이 runner

slot의 배열이 TJES 공유 메모리이다.

TJES 공유 메모리는 obmjinit이 정상적으로 기동될 때 생성되며 obmjinit이 정상

적으로 종료될 때 제거된다.

SPOOL

TJES가 사용하는 특별한 데이터 셋이다. JOB 구동에 필요한 자원이나 JOB의 진

행상황과 결과를 저장하기 위해 사용한다. JOB submit 시에 JOBID와 동일한 이

름으로 디렉터리를 생성하여 이 디렉터리의 하위 공간을 사용한다.

JOB SPOOL은 REMOVE나 CANCEL 명령 시에 삭제된다.

DATA SET

JOB 구동 시에 JOB에서 사용하는 OpenFrame Non-VSAM 데이터 셋이다.

TSAM

Mainframe의 VSAM 기능을 제공하는 OpenFrame 버전의 TSAM 모듈이다. TSAM

을 통해 KSDS으로 구성된 TJES 시스템 데이터 셋에 접근한다.

U/I

textrun

OpenFrame 제품이 아닌, 3rd party 스케줄러에서 TJES에 JOB을 submit하고, 진

행 상황과 결과를 모니터링할 수 있는 모듈이다.

UNIX 상의 3rd party 스케줄러들은 JOB의 시작과 끝을 프로세스의 시작과 종료로

구분한다. 따라서 textrun은 자신이 submit한 JOB이 끝날 때까지 종료되지 않

고 계속 실행 중에 있다가 JOB이 종료되면 그 결과를 반환하고 종료한다.

External Scheduler

TJES는 JOB의 class와 priority에 따른 스케줄링만을 제공하며, JOB A의 수행 종

료 후 JOB B의 수행 등 JOB간의 상관관계에 따른 스케줄링을 지원하지 않는다.

이런 상관관계에 따른 스케줄링이나 일간, 주간, 월간 배치 등 자동화된 JOB

submit을 위해서 external scheduler가 사용된다.

제1장 TJES


tjesmgr

시스템 관리자를 대상으로 하는 명령어 기반의 사용자 인터페이스이다. Boot,

shutdown 명령을 포함한 TJES의 모든 기능을 사용할 수 있다.

OpenStudio

일반 사용자를 대상으로 하는 GUI 기반의 사용자 인터페이스이다. TJES 시스템

을 boot, shutdown 하는 등의 TJES 관리기능을 제외한, JOB을 submit하고 조회

및 관리하는 기능을 제공한다.

제1장 TJES


1.3 멀티 노드 TJES 구성

TJES는 JOB의 처리 성능을 높이거나 서비스 가용성을 높이기 위해 여러 대의

UNIX 머신을 하나의 머신처럼 사용할 수 있는 멀티 노드 환경을 지원한다.

이번 장에서는 TJES를 멀티 노드로 구성할 때 각 컴포넌트들이 어떻게 배치되어

동작하는지에 대해서 설명한다.

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

[그림 1-2] 멀티 노드 환경

멀티 노드 TJES를 구성하기 위해서는 SPOOL, DATA SET, TSAM 등의 데이터 저

장소가 공유되어 있어야 한다. TJES는 공유된 자원을 통해 여러 노드에서 같은

데이터 셋을 이용하거나, 다른 노드에서 구동된 JOB의 결과를 확인하는 등의 작

업을 하나의 TJES 이미지로 사용자에게 서비스하게 된다.

점선으로 표시된 ofrlmsvr, ofrsasvr, ofrpmsvr, obmjschd, obmjhist,

obmjspbk는 전체 도메인에서 동시에 1개만 존재할 수 있는 TMAX 서버이다.

제1장 TJES


만약 NODE1에 문제가 발생하여 이 서버들을 더 이상 서비스할 수 없을 경우

(failover) TMAX에 의해 자동으로 NODE2를 기동시킴으로써 서비스 가용성을 높

일 수 있다.

점선 박스 외의 영역에 존재하는 TMAX 서버인 obmjmsvr, ofruisvr,

obmjinit는 멀티 노드 서비스를 제공하기 위해 각 노드에 1개 이상 존재해야

하며, 그 중 obmjinit는 각 노드에 1개만 존재해야 한다.

tjclrun은 요구-응답방식(on-demand)으로 구동되는 프로세스라 각 노드마다 현재

실행(working)중인 JOB의 개수만큼 존재하고, 실행중인 JOB이 없다면 존재하지

않는다.

obmjinit와 tjclrun 사이에서 정보전달 창구역할을 담당하는 TJES Shared

Memory는 obmjinit가 정상적으로 기동될 때 생성되고, 정상적으로 종료될 때

삭제된다.

외부 U/I에 해당하는 textrun, OpenStudio, tjesmgr는 TMAX를 통해 어떤 노

드에도 연결될 수 있다.

1.4 TJES 부트와 다운 방식

부트는 TJES가 JOB을 수행할 수 있는 상태이며, 다운은 TJES가 더 이상 JOB

을 실행할 수 없는 상태이다.

시스템 관리자는 tjesmgr의 노드 명령어 중 BOOT와 SHUTDOWN 명령어를 통해

이를 제어할 수 있다. 자세한 사용방법은 “INITIATOR 명령어”에서 “BOOT”와

“SHUTDOWN”을 참고한다.

Boot

부트는 TJES가 다운되어 있는 상태에서만 동작하며, 이미 부트되어 있는 상태라

면 BOOT 명령은 무시된다. 부트는 TJES의 각 노드에서 자신의 runner slot 상태

를 사용할 수 있는 상태로 초기화한 후, TJES의 obmjschd에게 runner slot의 현

재 상태를 보고하여 JOB이 스케줄링될 수 있도록 한다.

http://docs.google.com/View?docid=dffg96c6_13cj2ngg&revision=_latest






제1장 TJES


TJES가 성공적으로 부트 되었다면 SYS1.JESST 시스템 데이터 셋에 해당 노드

가 부트 되었음을 기록하여, 이후 DB 연결 실패 등과 같은 장애(disaster) 발생으

로 인한 TJES 자동복구절차에서 부트상태를 유지할 수 있도록 한다.

멀티 노드 TJES 환경에서는 TJES 부트 시에, TJES 전체 도메인에 속한 모든 노

드에 BOOT 명령을 전달하게 된다. 그리고 멀티 노드 환경에서도 개별 노드 별

로 부트하는 방법을 제공한다.

부트시에 해당 노드의 runner slot 상태는 Downed에서 다운되기 전의 Active 또

는 Inactive 상태로 복구되고, 부트된 적이 없다면 tjes.conf [INITDEF] 섹션

에 설정된 기본상태로 복구된다.

Warm Boot와 Cold Boot

웜 부트란 시스템을 초기화한 후 운영 중에 사용하는 일반적인 부트이다. TJES

shared memory를 초기화하고, 스케줄러에게 runner slot의 현재 상태정보를 보고

하여 JOB 스케줄링이 일어날 수 있도록 한다. tjesmgr의 BOOT 명령을 통해 웜

부트를 한다.

콜드 부트란 OpenFrame TJES를 초기화하는 역할을 하는 특수목적의 부트이다.

tjesinit 툴을 사용하여 시스템 데이터 셋을 초기화한다.

콜드 부트 이후에도 실제 JOB을 수행하기 위해서는 웜 부트를 해야 한다.

다음의 경우에 콜드 부트를 한다.

- OpenFrame TJES 설치 후

- 시스템 데이터 셋 구조변경 등 주요 시스템 업그레이드 후

- tjes.conf의 다음과 같은 변경사항을 시스템에 적용 시

[JOBDEF] 섹션의 JOBNUM 범위 변경 후

[JOBCLASS] 섹션 변경 후

OUTPUTQ 사이즈 변경 후

참고: 콜드부트에 대한 자세한 내용은 “툴 참조 안내서”의 “tjesinit”을 참고한다.

제1장 TJES


Shutdown

다운은 obmjinit가 부트되어 있는 상태에서만 동작하며, 이미 다운되어 있는

상태라면 SHUTDOWN 명령은 무시된다. Shutdown 명령 시 TJES는 해당 노드의

상태를 ‘Not booted’로 변경하여 시스템이 다운된 이후에 발생되는 추가적인 JOB

의 스케줄링을 제한한다.

다운되기 전에 스케줄링 되어 수행중인 JOB은 기본적으로 종료될 때까지 정상적

인 절차를 밟아 수행되지만, 사용자가 강제종료 할 것을 명시했다면,

SHUTDOWN 명령을 받은 즉시 정지된다.

실행중인 JOB을 모두 종료하고 나서 시스템을 다운시키려면, STOP 명령을 통해

명시적으로 실행중인 JOB을 종료하고 SHUTDOWN 명령으로 TJES 시스템을 다

운시킨다.

TJES가 성공적으로 다운되었다면 SYS1.JESST 시스템 데이터 셋에 해당 노드가

다운되었음을 기록하여, 이후 DB 연결 실패 등과 같은 장애(disaster) 발생으로

인한 TJES 자동복구절차에서 다운상태를 유지할 수 있도록 한다.

멀티 노드 TJES 환경에서는 TJES 다운 시에, TJES 전체 도메인에 속한 모든 노

드에 SHUTDOWN 명령을 전달하여 시스템을 다운하는 방법 외에도 개별 노드별

로 시스템을 다운할 수 있다.

전체 시스템 다운시키는 명령어

$ shutdown

개별 시스템 다운시키는 명령어

$ shutdown node=nodename

SHUTDOWN 명령을 받으면 해당 노드의 runner slot들의 상태는 기본적으로

Downed로 변경된다. JOB이 수행 중이었으면 runner slot의 상태를 working으로

유지하되 JOB의 수행이 끝난 시점에 runner slot의 상태를 Downed 상태로 변경

한다.

제1장 TJES


1.5 TJES 시스템 데이터 셋

TJES는 TJES 시스템의 설정과 각종 자원에 대한 정보를 노드간에 공유하기 위

해 다음과 같은 VSAM 데이터 셋에 저장한다.

JESST

다음과 같은 TJES의 시스템 레벨 정보를 저장하는 VSAM KSDS 데이터 셋이다.

- 노드 정보: 시스템 상에 존재하는 노드들의 정보와 각각의 노드들의 부트 상

태를 저장한다.

- JOBQ 정보: JOBID 범위 등 JOBQ에 대한 개괄적인 정보를 저장한다.

- OUTPUTQ 정보: OUTPUTQ 크기 등 OUTPUTQ에 대한 개괄적인 정보를 저

장한다.

- JOB CLASS 정보: JOB CLASS 별 Default 속성 정보를 저장한다.

- Runner slot 정보: 각 노드의 runner slot에 대한 index, class 및 status 등의

속성 정보를 저장한다. (차후 지원예정)

JESST의 실제 데이터 셋 이름은 tjes.conf [SYSTEM_DS] TJES_STAT에 지정

된다. TJES_STAT=SYS1.JESST 으로 설정할 것을 권장한다.

JOBQ

TJES에서 JOB을 관리하는데 필요한 정보를 저장하는 VSAM KSDS 데이터 셋이

다.

JOBID, JOBNAME, JOBCLASS, JOBPRTY, JOBSTATUS, JCLPATH, USER

ACCOUNT 등이 JOBQ에 저장된다.

JOBID에 대한 기본 인덱스 이외에도 성능향상을 위해 JOBNAME과

JOBSTATUS에 대한 보조 인덱스와 submit 순서대로 조회하기 위한 보조 인덱스

를 구성한다.

JOBQ의 실제 데이터 셋 이름은 tjes.conf [SYSTEM_DS] JOBQ에 지정된다.

JOBQ=SYS1.JOBQ 으로 설정할 것을 권장한다.

OUTQ

TJES에서 수행된 JOB의 결과물인 OUTPUT을 관리하는데 필요한 정보를 저장하

는 VSAM KSDS 데이터 셋이다.

http://docs.google.com/View?docid=dffg96c6_12d2k2r4&revision=_latest

http://docs.google.com/View?docid=dffg96c6_12d2k2r4&revision=_latest

제1장 TJES


시스템 데이터 셋은 OpenFrame 설치 단계에서 생성되며, tmboot 전 OpenFrame

에서 제공하는 콜드 부트용 UNIX 툴인 tjesinit을 통해 시스템 데이터 셋을 초기

화해야 한다.

참고: 콜드 부트 단계 중에 기록해야 하는 SYS1.JESST의 JOBQ 정보, OUTPUTQ 정보 등은 tjesinit을 통해서만 갱신된다. 이후에 tjes.conf의 설정을 변경한다면, tjesinit 을 통해 SYS1.JESST에 변경 사항을 반영해야 한다.

다음은 각 시스템 데이터 셋을 생성하는 스크립트이다.

모두 SYS1.XXXX로 설정한다고 가정하였다. 다른 이름의 시스템 데이터 셋을 사

용하려면 스크립트를 변경하고, IDCAMS를 통해 새로 시스템 데이터 셋을 생성하

여야 하며, 스크립트 변경 시에는 색으로 표시된 데이터 셋 이름만을 고치는 것

을 강력히 추천한다. 색으로 표시된 데이터 셋 이름은 한 스크립트 내에서는 모

두 동일하여야 한다.

#!/bin/sh

# JESST Creating Script (TJES v.4)

# Define SYS1.JESST

IDCAMS<<EOF

DELETE SYS1.JESST CLUSTER PURGE

DEFINE CLUSTER ( NAME (SYS1.JESST) -

VOL(100000) -

INDEXED -

KEYS(24 0) -

UNIQUE -

SHR(2 3) ) -

DATA ( NAME(SYS1.JESST.DATA) -

KB(4096 4096) -

FREESPACE(00 00) CISZ(4096) -

RECSZ(1024 1024) ) -

INDEX ( NAME(SYS1.JESST.INDEX) )

EOF

<SYS1.JESST>

제1장 TJES


#!/bin/sh

# JOBQ Creating Script (TJES v.4)

# Define SYS1.JOBQ (16, 8)

# Define SYS1.JOBQ.ID (AIX on JOB_ID) (8, 16)

# Define SYS1.JOBQ.NAME (AIX on JOB_NAME) (0, 24)

# Define SYS1.JOBQ.STAT (AIX on JOB_STAT) (31, 17)

# Define path SYS1.JOBQ.PMAIN

# Define path SYS1.JOBQ.PNAME

# Define path SYS1.JOBQ.PSTAT

IDCAMS<<EOF

DELETE SYS1.JOBQ CLUSTER PURGE

DEFINE CLUSTER ( NAME (SYS1.JOBQ) -

VOL(100000) -

INDEXED -

KEYS(8 16) -

UNIQUE -

SHR(2 3) ) -

DATA ( NAME(SYS1.JOBQ.DATA) -

KB(37450 37450) -

FREESPACE(00 00) CISZ(4096) -

RECSZ(1024 1024) ) -

INDEX ( NAME(SYS1.JOBQ.INDEX) )

DEFINE ALTERNATEINDEX ( NAME(SYS1.JOBQ.ID) -

UPGRADE -

RELATE(SYS1.JOBQ) -

VOLUMES(100000) -

KEYS(16 8) )

DEFINE ALTERNATEINDEX ( NAME(SYS1.JOBQ.NAME) -

UPGRADE -

RELATE(SYS1.JOBQ) -

제1장 TJES


VOLUMES(100000) -

KEYS(24 0) )

DEFINE ALTERNATEINDEX ( NAME(SYS1.JOBQ.STAT) -

UPGRADE -

RELATE(SYS1.JOBQ) -

VOLUMES(100000) -

KEYS(17 31) )

DEFINE PATH ( NAME (SYS1.JOBQ.PMAIN) -

PATHENTRY(SYS1.JOBQ) )

DEFINE PATH ( NAME (SYS1.JOBQ.PID) -

PATHENTRY(SYS1.JOBQ.ID) )

DEFINE PATH ( NAME (SYS1.JOBQ.PNAME) -

PATHENTRY(SYS1.JOBQ.NAME) )

DEFINE PATH ( NAME (SYS1.JOBQ.PSTAT) -

PATHENTRY(SYS1.JOBQ.STAT) )

EOF

<SYS1.JOBQ>

#!/bin/sh

IDCAMS<<EOF

DELETE SYS1.OUTPUTQ PURGE

DEFINE CLUSTER ( NAME(SYS1.OUTPUTQ) -

KB(32768 1024) -

VOLUMES(100000) -

RECSZ(512,512) -

SHR(2 3) -

IXD -

UNIQUE -

제1장 TJES


CISZ(4096) -

FSPC(20 10) -

KEYS(8 16)) -

DATA ( NAME(SYS1.OUTPUTQ.DATA)) -

INDEX ( NAME(SYS1.OUTPUTQ.INDEX))

DEFINE ALTERNATEINDEX(NAME(SYS1.OUTPUTQ.JOBID) -

RELATE(SYS1.OUTPUTQ) -

VOLUMES(100000) -

KEYS(16 8) -

RECSZ(100,100))

DEFINE PATH( NAME( SYS1.OUTPUTQ.PJOBID) -

PATHENTRY(SYS1.OUTPUTQ.JOBID) )

DEFINE ALTERNATEINDEX(NAME(SYS1.OUTPUTQ.JOBNAME) -

RELATE(SYS1.OUTPUTQ) -

VOLUMES(100000) -

KEYS(24 0) -

RECSZ(100,100))

DEFINE PATH( NAME( SYS1.OUTPUTQ.PJOBNAME) -

PATHENTRY(SYS1.OUTPUTQ.JOBNAME) )

EOF

<SYS1.OUTQ>

제2장 JOB의 관리



이번 장에서는 JOB이 가질 수 있는 상태의 종류와 JOB이 실행되는 단계 및 결

과조회 그리고 JOB을 관리하는 방법에 대해서 설명한다.

OpenFrame에서는 JOB을 관리하기 위해 tjesmgr와 OpenStudio를 사용할 수 있

지만 본 안내서에서는 tjesmgr를 사용하여 JOB을 관리하는 방법에 대해서만 다

루도록 한다.

참고: OpenStudio를 사용하여 JOB을 관리하는 방법에 대해서는 “OpenStudio BM 안내서”

를 참고하기 바란다.



2.1 JOB STATUS

TJES는 다음 그림과 같이 JOB을 START, HOLD, WORKING, SUSPEND, DONE,

ERROR, STOP, FLUSH의 8가지 상태로 구분하여 관리한다.

[그림 2-1] JOB 상태 흐름도

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

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

START

JCL을 통해 JOB이 submit되어 실행되기 전까지의 상태로써 JOB 스케줄링의 대

상이 된다. JOB class를 변경할 수 있고, HOLD 명령을 통해 JOB을 HOLD 상태

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



HOLD

JCL을 통해 JOB이 submit되어 실행되기 전까지의 상태이지만 JOB 스케줄링의

대상이 되지 않는다. JCL상에 TYPRUN=HOLD 구문을 기술하여 submit 하거나,

HOLD로 설정된 JOB CLASS로 submit 한 경우, START 상태의 JOB을 HOLD 명

령을 통해 상태를 변경한 경우에 해당한다.

START 명령을 통해 START 상태로 변경하거나 CANCEL 명령을 통해 JOBQ에

서 제거할 수 있다.

WORKING

tjclrun이 JOB을 실행중인 상태이다. 실행 중인 STEP의 특성에 따라 복수의

UNIX 프로세스로 구동될 수 있다. SUSPEND 명령을 통해 실행중인 JOB을 일시

적으로 정지시킬 수 있고, STOP 명령을 통해 JOB 수행을 끝내고 STOP 상태로

바꿀 수 있다.

SUSPEND

SUSPEND 명령에 의하여 JOB의 실행이 일시적으로 멈춘 상태이다. RESUME

명령을 통해 WORKING 상태로 복원할 수 있고, STOP 명령을 통해 JOB 수행을

끝내고 STOP 상태로 바꿀 수 있다.

3rd party 유틸리티를 사용할 경우, 유틸리티 내부에서 세션을 새로 설정한다면 해

당 프로세스와 그 하위 프로세스는 SUSPEND되지 않는다는 점을 주의해야 한다.

DONE

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

주의할 점은 DONE 상태가 JCL에서 요청된 대로 JOB의 모든 STEP이 수행되었

고 반환 코드가 COND 문이나 rc.conf 등을 통해 지정한 허용 범위 이내라는

것을 의미하는 것이지, 각 STEP에 지정된 프로시저나 프로그램이 업무적으로 정

상 실행되었다는 것을 의미하는 것은 아니다.

사용자 프로그램이 의도한 결과를 산출했는지의 여부는 SPOOL 데이터의 조회

(PODD)나 각 STEP의 반환 코드(PSJOB) 등을 조회하여 별도로 확인하여야 한

다. REMOVE 명령을 통해 JOBQ에서 제거한다.

ERROR

JOB의 실행 결과가 COND 문이나 rc.conf에서 지정한 반환 코드 허용범위를

벗어난 상태이다. REMOVE 명령을 통해 JOBQ에서 제거한다.



STOP

WORKING 중인 상태의 JOB에 사용자가 명시적으로 STOP 명령을 통해 JOB을

강제 종료시키거나, 장애복구 플랜(Disaster Recovery Plan)에 의해 TJES가 자동

으로 재기동될 때 JOB이 강제 종료된 상태이다. 이때 JOB 실행에 필요했던 모

든 자원을 반납하고 종료하게 된다. REMOVE 명령을 통해 JOBQ에서 제거한다.

FLUSH

JOB 수행 중에 tjclrun에서 에러가 발생하여 더 이상 JOB을 수행하지 못하는 상

태이다. JCL 런타임 파싱 에러나 DD 할당 에러 등이 FLUSH 상태의 주요 원인이

다. REMOVE 명령을 통해 JOBQ에서 제거한다.

JOB의 상태 변경

사용자는 원하는 경우 JOB의 상태를 변경할 수 있다.

다음은 JOB의 상태 변경과 관련된 tjesmgr 명령어를 정리한 표이다.

현재 상태 명령어 변경될 상태

없음 RUN START, HOLD

START CANCEL JOBQ에서 삭제

START HOLD HOLD

HOLD CANCEL JOBQ에서 삭제

HOLD START START

WORKING SUSPEND SUSPEND

WORKING STOP STOP

SUSPEND STOP STOP

SUSPEND RESUME WORKING

DONE REMOVE JOBQ에서 삭제

ERROR REMOVE JOBQ에서 삭제

STOP REMOVE JOBQ에서 삭제

FLUSH REMOVE JOBQ에서 삭제

[표 2-1] JOB 상태 변경 명령어

참고: 각각의 명령어 사용법은 “JOB 실행 명령어”를 참고하라.



JOBQ는 tjes.conf [JOBDEF] 섹션에 설정된 크기만큼만 저장을 할 수 있기

때문에 필요로 하지 않는 JOB들은 JOBQ에서 삭제할 필요가 있다. (“7.2 TJES 설

정”을 참고한다.)

CANCEL이나 REMOVE는 모두 JOBQ에서 JOB을 삭제하는 명령이지만

CANCEL은 JOB이 실행되기 전에 그리고 REMOVE는 JOB이 실행되고 나서 삭

제된다는 점이 다르다.

HOLD 상태에 있는 JOB들은 스케줄링이 되지 않기 때문에 HOLD 상태인 JOB을

실행하고자 하면 START 상태로 상태를 바꾸어야 한다. 이때 START 명령을 사

용하여 상태를 변경할 수 있다.

WORKING 중인 JOB들을 일시 정지를 하고 싶다면 SUSPEND 명령을 사용한다.

일시 정지되어 있는 JOB을 다시 실행하고자 할 때는 RESUME 명령을 사용한다.

WORKING 중인 JOB들을 중지시키고 싶다면 STOP 명령을 사용한다.

JOB CLASS

JOB의 속성 중 하나로 JCL JOB 구문의 CLASS 파라미터에 기술되는 한 개의

문자로, A-Z, 0-9 중 한 개의 값을 가져야 한다.

JCL에 CLASS가 기술되어 있지 않을 때는, tjclrun.conf [JOB] CLASS에 기

술된 디폴트 JOB CLASS를 사용한다.

JOB CLASS는 해당 JOB이 실행될 수 있는 runner slot을 제한하는 용도로 JOB

스케줄링에 사용된다. A 라는 JOB CLASS를 가진 JOB은 runner class에 CBA 혹

은 ABC와 같은 식으로 A를 포함한 runner slot에만 할당될 수 있다.

스케줄링에 관한 자세한 사항은 “Schedule 단계”를 참고한다.

이외에도 JOB CLASS 의 하위 속성에 따라, TJES 의 동작방식이 달라진다.

OpenFrame Batch 4.0 Version 에서 JOB CLASS 의 HOLD 속성이 추가되었다.

HOLD 속성이 명시된 JOB CLASS로 submit 된 JOB 은 JCL 상의 JOB 구문에

TYPRUN=HOLD 가 지정되지 않았더라도, HOLD 상태로 Submit 된다.



RUNNER CLASS

Runner slot의 속성 중 하나로 tjes.conf [INITDEF] 섹션에 기술된다.

Runner class는 JOB CLASS와 일치되어야 하므로 JOB CLASS와 동일한 A-Z, 0-9

중 한 개의 값을 가지며, 1개의 runner slot은 최대 8개의 class를 가질 수 있다.

복수의 runner class가 설정된 경우에는, 앞에 기술된 class에 해당하는 JOB이 없

을 때에만 뒤에 기술된 class가 사용될 수 있다. 즉, 제일 먼저 설정된 class가

최우선이고 맨 마지막에 설정된 class가 제일 낮은 우선순위를 갖는다.

또한 i 번째에 기술된 class에 해당하는 JOB을 실행하기 위해서는, TJES의 모든

runner slot이 i 번째 이전에 기술된 해당 class로 JOB을 실행할 수 없어야 한다.

예를 들면 TJES 내에 1번 runner slot은 runner class가 ABC이고, 2번 runner slot

은 BCA였을 때, JOB CLASS C의 JOB은 B class의 JOB이 없을 때 2번 runner

slot의 두번째 class로 실행될 수 있지만, 1번 runner slot의 세번째 class로 실행

되기 위해서는, A와 B class의 JOB이 없으면서, 2번 runner slot이 이미 JOB을 실

행하고 있어, 두번째 class로 JOB을 실행할 수 없어야 한다.

2.2 JCL의 관리

OpenFrame에서는 기존의 Mainframe에서 사용하던 JCL들을 그대로 가져와서 실

행을 할 수 있다.

JCL들을 일반 디렉터리에 관리해도 되지만, tjes.conf [PROCLIB] JCLLIB에

등록된 데이터 셋의 멤버로 등록해 놓기를 권장하며, JCL들이 많다면 별도의

PDS 데이터 셋을 생성해서 멤버로 관리하길 권장한다.

OpenFrame에서 PDS 데이터 셋은 실제 디렉터리로 만들어져 있기 때문에 해당

볼륨의 PDS 데이터 셋 이름 디렉터리에 JCL들을 복사해 놓으면 PDS의 멤버가

된다.

JCL들을 PDS 데이터 셋의 멤버로 등록해 놓으면 JCL을 submit 할 때 UNIX 전

체 파일 경로를 주지 않고도 데이터 셋 이름과 멤버명 만으로도 대상 JCL을 찾

을 수 있다.

특별히 JCL이 tjes.conf [PROCLIB] JCLLIB에 등록된 데이터 셋의 멤버로



등록된 경우에는 멤버명만 있어도 대상 JCL을 찾을 수 있다.

2.3 JOB 처리단계

TJES를 통해 실행되는 모든 JOB은 다음의 단계를 거치게 된다.

Submit: TJES로부터 JCL을 받아 들이는 단계

Schedule: 조건을 충족하는 runner slot에게 JOB을 할당하는 단계

Execution: 실제로 runner가 JOB을 수행하는 단계

Output: JOB의 수행이 끝나고 그 output이 처리될 수 있는 단계

Remove: 수행이 끝난 JOB을 TJES에서 제거하는 단계

Submit 단계

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

이다.

JCL이 submit되면 TJES는 해당 JCL을 분석하여 JOB 엔트리를 구성하고, JOBID,

SPOOL 등 JOB 관리에 필요한 리소스를 할당한 후 JOBQ에 저장한다. 새로운

JOB의 정보는 스케줄러에 통보되어, 스케줄러에 의해 JOB이 runner slot에 할당

될 수 있도록 한다.

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

JOBID

TJES가 JOB을 구분하여 관리하기 위해서는 각각의 JOB에 유니크한 ID를 부여

해야 한다. 이를 JOBID라 하며, JOBID는 'JOBnnnnn'의 형식을 갖는다. JOB에 부

여할 수 있는 JOBID 범위는 00001부터 99999이다.

JOBID는 submit 시에 발급되어 JOB이 CANCEL이나 REMOVE를 통해 제거될

때 반환된다. 반환된 JOBID는 재사용된다.

SPOOL

TJES는 한 개의 JOB 마다 독립적인 SPOOL 공간을 할당하며, 이 공간은

SPOOL 볼륨에 JOBID로 생성된 디렉터리이다.

SPOOL에는 submit 받은 시점의 JCL을 보존하기 위하여 복사한 INPJCL, 카탈로

http://docs.google.com/View?docid=dffg96c6_33c72xwp&revision=_latest

http://docs.google.com/View?docid=dffg96c6_33c72xwp&revision=_latest



그를 복사한 CATPROC, JOB의 수행결과인 SYSOUT과 TJES가 JOB의 수행상태

를 보고하기 위해 사용하는 파일 등이 저장된다.

SPOOL은 tjesinit 툴을 통해 초기화 할 수 있다.

JOBQ

TJES는 JOB의 검색과 변경 등을 용이하게 하기 위해 TSAM KSDS 데이터 셋으

로 JOB의 기본 정보를 저장한다.

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

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

- JCL 구문 에러 확인 (프로시저의 유무와 구문 오류는 이 시점에서는 확인되

지 않고, tjclrun에서 JCL을 파싱할 때 확인된다.)

- JOBID 발급

- SPOOL 생성

- Submit된 JCL을 SPOOL에 INPJCL로 복사

- JCL에 기술된 내용 중 JOB에 대한 정보를 JOBQ에 저장

- TYPRUN=HOLD가 기술되지 않았다면 obmjschd에게 통보

이 단계 중에 에러가 발생하면 tjes.conf [LOG] submitLOG에 지정된 로그

파일에 그 내용이 저장된다.

성공적으로 submit된 JOB은 START와 HOLD 상태 중 하나의 상태를 가진다.

- START: JOB 스케줄링의 대상이지만 아직 runner slot에게 할당되지 않은 상

태

- HOLD: JCL의 JOB 구문에 TYPRUN=HOLD라고 기술되거나 JOB CLASS 속성

에 HOLD가 기술되어 있어 schedule 단계로의 전이가 보류되는 상태이다.

Schedule 단계로 넘어가기 위해서는 START 상태로 변경되어야 한다.

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

tjesmgr의 RUN 명령어를 통한 방법 (제6장 TJESMGR 명령어의 RUN 참고)

textrun 툴 사용하는 방법 (툴 참고 안내서의 textrun 참고)

OpenStudio Batch Manager(BM)를 통한 방법(OpenStudio BM 안내서를 참고)

tjesmgr의 RUN 명령어를 통해서 JCL을 정상적으로 submit하게 되면, submit하여

생성된 JOB들이 JOBQ에 등록되어 있는 것을 확인할 수 있다. (TJESMGR 명령

어의 “PS (Print Screen)”를 참고한다.)



Schedule 단계

Schedule 단계는 START 상태의 JOB을 schedule 정책에 따라 runner slot에 배정

하는 단계이다.

Schedule 단계에서 TJES는 기본적으로 다음의 조건을 만족하는 runner slot에게

현재 START 상태인 JOB을 배정한다.

- Runner slot의 상태가 Active로 활성화되어 있어야 하며, 다른 JOB을 수행하

고 있는 중이 아니어야 한다.

- Runner class가 JOB class와 일치해야 한다.

- JOB submit 시 특정 노드에서 JOB이 실행되도록 명시했을 경우, 그 노드와

runner slot이 속한 노드가 일치해야 한다.

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

Priority aging

For i = 1 to 8 /* to iterate runner classes */

For each idle runner {

Get the list of job which matches the ith class of the runner

For each job in descending priority order {

Check node affinity. If fails, try next job

Check jobname duplication. If fails, try next job

Assign the job to the runner and break

}

}

Execution 단계

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

Runner는 SPOOL에 복사되어 있는 JCL을 파싱하고, 그 결과에 따라 JOB을 실

행한다. 하나의 JOB은 한 개 이상의 JOB STEP으로 구성되는데, Runner는 이

JOB STEP을 JCL에 기술된 순서대로 순차적으로 실행한다.

JOB 실행 시 필요한 데이터 셋을 할당하는 일 역시 Execution 단계에서 일어난

다



Output 단계

JOB 수행 중 생성된 SYSOUT을 처리하는 단계이다. SYSOUT은 OUTPUT 이라

는 단위로 처리되는데, OUPUT CLASS에 따라 처리할 수 있는 프린터와 기본 후

처리가 결정된다.

OUTPUT은 프린터로 출력되거나 인터널 리더를 통해 TJES로 submit된다.

참고: 자세한 내용은 “제5장 OUTPUT Processing”을 참고하기 바란다.

Remove 단계

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

는 단계이다. JOB에 할당되었던 SPOOL, JOBID, JOBQ 등과 같은 모든 자원이

시스템으로 반환된다. TJES에서 삭제한 JOB의 결과를 추후에 다시 접근하기 위

해서는 SPOOL 백업 명령어를 통해 백업해야 한다. 백업 성공 시에 SPOOL에서

자동으로 JOB이 제거된다.

2.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 상세정보를 보여준다.

[표 2-2] JOB 정보 조회 명령어



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

2.5 JOB Logging

TJES는 운영에 대한 자료로 사용하거나 운영 시 발생할 수 있는 각종 사건들의

책임 소재를 분명히 하는 용도로 사용할 수 있도록 JOB의 모든 상태 변화에 대

해서 로그를 남긴다.

JOB 로그는 tjes.conf [LOG] JOBLOG에 설정한 파일경로에 저장된다. 매일

방대한 양의 로그가 기록될 수 있으므로 정리작업 없이 장기간 운영 시에는 JOB

로그 파일의 크기가 상당히 커질 수 있다. 이러한 문제점을 해결하기 위해서 날

짜 별로 JOB 로그를 생성하는 옵션을 제공한다.

JOB 로그 파일경로 설정시 &SYSDATE를 filename 중간에 기입하면, &SYSDATE

부분이 YYYYMMDD 형태의 날짜 파일명으로 치환되어 날짜별로 JOB 로그를 생성

할 수 있다.

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

nodename;timestamp;jobid;userid;opertation;additional info

Additional info는 오퍼레이션에 따라 다르며, 오퍼레이션의 종류와 그에 대한 설

명은 다음과 같다.

SUBMIT

JOB이 submit 된다.

status=S|H;class=job_class;node=execution_node;jcl=jcl_path

- status

JOB의 submit 상태에 따라 설정된다. START 상태로 submit될 경우에 S가

설정되고, HOLD 상태로 submit될 경우에는 H가 설정된다.

- class

submit된 JOB의 class이다.



- node

JOB이 수행될 노드의 이름이다. JCL에 JOB들이 실행될 execution_node를

지정하지 않았다면 또는 tjesmgr.conf [DEFAULT_OPTION] 섹션의

DEFAULT_RUNNING_NODE=MY를 설정하지 않았다면, 모든 노드에서 실행될

수 있도록 * 가 설정된다.

- jcl

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

EXECUTE

JOB을 runner에 할당한다.

index=runner_index;pid=runner_pid;class=working_class

- index

JOB을 실행중인 runner slot의 인덱스이다. 이 값은 실행중인 노드에서만 유

효하다.

- pid

JOB을 실행중인 runner의 프로세스 아이디이다. 이 값은 실행중인 노드에서

만 유효하다.

- class

Runner slot에 할당된 복수의 class 중 현재 JOB을 실행하기 위해 사용하고

있는 class이다.

SUSPEND

JOB이 일시 정지된다.

index=runner_index;pid=runner_pid

- index


효하다.

- pid




만 유효하다.

RESUME

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

index=runner_index;pid=runner_pid

- index


효하다.

- pid


만 유효하다.

FINISH

JOB의 실행이 종료된다.

index=runner_index;pid=runner_pid;status=exit_status;exitcode=exit_code

- index


효하다.

- pid


만 유효하다.

- status

JOB의 종료 상태이다. DONE, ERROR, STOP, FLUSH 중 하나의 값을 갖는

다.

- exitcode

JOB의 EXIT CODE이다. (자세한 내용은 “2.7 JOB EXIT CODE”를 참고한다.)

REMOVE

JOB이 TJES에서 제거된다.



2.6 JOB의 BACKUP

많은 JOB들을 실행하게 되면 JOBQ에 JOB들이 계속 쌓이게 되어 더이상 JOB

을 submit 할 수 없는 상태까지 이를 수 있다. 따라서 오래된 JOB들에 대해서는

JOBQ에서 삭제해야 하며, 삭제하고자 하는 JOB들의 정보를 남겨놓고 싶을 때는

SPOOL을 백업한다.

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

세한 설명과 기능은 “[표 2-3] 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들을 제거한다.

[표 2-3] SPOOL 백업 명령어



2.7 JOB EXIT CODE

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

STEP EXITCODE

각 STEP은 종료 시 XNNNN 형식으로 반환 코드를 보고한다.

X는 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

값을 호출한 프로그램(IKJEFT01 등)에서 판단했을 때 조건을 만족하지 못해

JOB을 종료해야 한다.

NNNN은 0~4096까지의 숫자로 응용프로그램의 반환 값이다. (255 이상은 external

rc module을 통해 반환 코드가 보고된다.)

JOB STATUS와 EXITCODE

JOB의 EXITCODE는 JOB 의 종료 상황을 나타낼 수 있는 부가 정보로, JOB

STATUS인 DONE, ERROR, STOP, FLUSH 별로 다음의 의미를 가진다.

- DONE: 마지막 STEP의 EXITCODE이다.

- ERROR: ERROR를 발생시킨 STEP의 EXITCODE이다.

- STOP: N.A., 사용자가 STOP을 명령한 경우이므로 무의미하다.

- FLUSH: runner 의 return value 혹은 runner 가 시그널로 비정상 종료한 경우

에는 signal 번호이다.



UNIX system 의 process return 값이 0~255 이기에, textrun 통한 JOB 수행 등을

감안하여 현재 JOB 의 EXITCODE 범위도 0~255 이다. DONE 이나 ERROR 시

에는 마지막 STEP 의 EXITCODE 가 255 초과일 수 있으며, 이때는 overflow 발

생을 방지하면서 초과되었음을 명시하기 위해 99로 변경한다.

제3장 JOB Execution



TJES가 제공하는 배치 JOB을 관리 및 처리하는 단계중의 하나인 JOB Execution

(이하 JOB 실행)은 사용자가 submit한 JOB이 스케줄러에 의해서 스케줄링되면

해당 JOB을 실제로 운영체계 상에서 실행하는 단계이다.

JOB 실행단계는 tjclrun에 의해서 수행된다. 스케줄러가 제출한 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”를 참고하기 바란다.

3.1 JOB 실행

TJES의 JOB 처리 단계에 따라서 tjclrun이 호출되면, tjclrun은 실행을 위한 몇 가

지 초기화 작업을 수행한 후에 JOB SPOOL을 통해 전달된 JCL을 파싱하고, 파

싱된 결과에 따라서 JOB을 실행한다.



tjclrun은 JOB을 구성하는 job step을 JCL에 기술된 순서대로 실행한다. 각각의

job step은 해당 job step에서 사용되는 데이터 셋을 할당하고 사용자가 지정한 배

치 응용프로그램을 실행하는 등 많은 세부작업으로 이루어져있다.

EXEC문의 PGM 파라미터를 이용해 job step에 지정된 배치 프로그램을 실행한

후에는 해당 프로그램이 종료하기를 기다리면서 프로그램 실행에 관한 모니터링

정보를 TJES에 주기적으로 보고한다. 또한 실행한 배치 프로그램에게 SYSIN 데

이터 셋의 내용을 전달하고, SYSOUT 데이터 셋을 전달받아 JOB SPOOL에 기록

한다. 실행한 배치 프로그램이 종료되면, 그 종료결과를 TJES에 보고하고 job

step의 종료상태에 따라 그 다음 job step을 실행하거나, 예외조건이 만족하는 경

우에는 JOB 수행을 중단한다.

위와 같은 방식으로 JCL에 기술된 마지막 job step까지 모두 실행한 후에 tjclrun

은 JOB의 실행 결과를 TJES에 보고하고 JOB 실행 단계에서 할당한 데이터 셋

등의 자원을 반환한 후에 종료한다.

다음은 tjclrun이 JOB Execution 단계에서 수행하는 다양한 세부작업을 분류한 표

이다.

작업 단계

실행 실행 초기화

입력 JOB 스트림 파싱

실행 과정

EXECC PGM 처리

EXEC PROC 처리

리소스 DD 처리

스페셜 DD

OUTPUT 처리

JOB SPOOL

컨트롤/모니터링 JOB Control

Job Level Report

Step Level Report

기타 보안 (TACF support)

tjclrun 호출 (tjclrun 명령어 사용)

tjclrun 인터널 로그 (tjclrun.nnnn.log)

[표 3-1] tjclrun의 JOB 실행 작업 리스트



실행 초기화

다음은 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 관리대상에서 제

외될 뿐만 아니라 요구되는 정상적인 단계를 실행하지 않을 수 있다.

설정파일 읽기

tjclrun.conf 설정파일에 저장된 tjclrun의 실행 방식을 결정하는 설정을 읽어

들인다.

참고: tjclrun.conf에 대한 자세한 내용은 “7.5 TJCLRUN 설정”을 참고한다.)

실행 계정

기본적으로 JOB 실행 시 tjclrun 프로세스의 소유자는 TJES 운영자의 OS 계정과

동일하다. 즉, TJES 시스템을 운영체제 상의 obm 이라는 사용자 계정에서 기동

한 경우 tjclrun 프로세스와 각 job step에서 실행되는 배치 프로그램의 사용자 아

이디도 obm이 된다.

그러나 tjclrun.conf [ACCOUNT] SETUID=YES로 설정하면 JCL JOB문의

USER에 지정된 사용자로 tjclrun 프로세스를 실행할 수 있다.

참고: 자세한 내용은 “setuid root tjclrun”을 참고한다.



SYSLIB 초기화

tjclrun은 tjclrun.conf [SYSLIB] 섹션에 설정된 디렉터리 위치에서 job step

에 지정된 프로그램을 찾는다. [SYSLIB] 섹션을 설정하지 않은 경우 사용자의

환경변수에 지정된 디렉터리에서 프로그램을 찾는다.

JCL에 JOBLIB DD 또는 STEPLIB DD가 있는 경우는 SYSLIB 보다 JCL에 기술

된 JOBLIB 및 STEPLIB이 우선한다.

일부 UNIX 시스템에서, tjclrun에 root 권한을 부여하여 운영하는 경우에 환경변수

가 지워지는 문제가 있으므로 [SYSLIB] 섹션을 반드시 설정해야 한다. 그렇지

않으면 tjclrun은 JCL에 지정된 프로그램을 실행하거나 로딩하는 단계에서 실패하

게 된다.

참고: 자세한 내용은 “setuid root tjclrun”을 참고한다.

Internal log open

tjclrun이 수행하는 일반적인 JOB 실행 단계에서 발생하는 에러 및 세부 작업의

결과 보고는 JOB SPOOL의 SYSMSG에 저장된다.

반면 tjclrun 내부적인 오류 및 시스템 함수 실패 등 문제 분석용으로 사용되는

tjclrun 인터널 로그는 tjclrun.nnnn.log에 저장된다. tjclrun은 실행 초기화 단

계에서 내부적인 로그 메시지를 저장하기 위해서 인터널 로그 파일을 미리 열어

둔다. 특히 tjclrun 실행 초기화 단계에서 JOB SPOOL 초기화 이전에 발생한 문

제는 SYSMSG에 해당 에러를 출력할 수 없기 때문에 tjclrun 인터널 로그로 에러

가 보고된다. (nnnn은 runner slot 번호를 의미한다.)

Job 시작 보고

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

Job spool 열기

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



입력 JCL 파싱

tjclrun은 JOB SPOOL을 통해 전달된 JCL 파일(INPJCL)을 분석하여 JOB을 실행

한다.

참고: tjclrun이 실행하는 JOB문을 포함한 (JOB SPOOL에 저장된) JCL파일을 잡스트림(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(잡스트림)에 JOBPARM 명령이 지정된 경우 이 명령의 PROCLIB 파라미터

에 지정된 ddname은 tjes.conf [PROCLIB] 섹션에 설정되어 있어야 한다.

INCLUDE

INCLUDE 문장의 처리 시에 INCLUDE되는 JCL도 앞에서 설명한 JCLLIB 문이나

JOBPARM 명령의 PROCLIB 파라미터에 지정된 JCL 라이브러리에서 찾는다.



실행 과정

실행해야 하는 JOB의 INPJCL(잡스트림)을 파싱한 이후에 tjclrun은 JCL에 기술된

순서에 따라 job step을 실행한다.

참고: JCL의 JOB 문장에 RESTART 파라미터가 지정된 경우 RESTART 파라미터에 지정

된 job step부터 실행한다.

실행 단계

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

Lock phase

해당 JOB에서 사용되는 데이터 셋에 대한 lock을 잡는 단계

Exec phase

실제로 job step을 순서대로 실행하는 단계

tjclrun은 미리 INPJCL 및 JCL 프로시저를 분석하여 해당 JOB에서 사용할 데이

터 셋의 리스트를 얻고 실제 실행 단계에 들어가기 전에 해당 데이터 셋들에 대

해 일괄적으로 lock을 요청함으로써 서로 다른 여러 개의 JOB이 동시에 동일한

데이터 셋을 독점적(exclusive)으로 사용하는 경우 빈번하게 발생되는 Dead Lock

상황을 방지한다.

JOB에서 사용하는 데이터 셋들에 대한 lock 요청 단계가 성공적으로 수행되면

실제 실행 단계를 수행한다.

실제 실행 단계(exec phase)는 다음과 같이 처리된다.

EXEC PGM 스텝

처리해야 하는 job step이 배치 프로그램을 실행하는 경우(EXEC PGM문) 지정된

배치 프로그램을 실행한다. tjclrun은 배치 프로그램을 자신의 자식 프로세스로서

실행하고 그 프로그램의 실행이 종료될 때까지 기다린다. 실행한 배치 프로그램

의 실행이 종료되기를 기다리는 중에 주기적으로 배치 프로그램이 수행한 데이터

셋 I/O 통계 등의 정보를 TJES에 보고한다.



EXEC PROC 스텝

처리해야 하는 job step이 JCL 프로시저를 호출하는 경우(EXEC PROC문) 지정된

JCL 프로시저를 파싱하고 그 결과를 가지고 해당 프로시저를 실행한다. 호출된

JCL 프로시저에서 또다시 다른 JCL 프로시저를 호출할 수 있다. 이것을 중첩된

(nested) JCL 프로시저 호출이라고 한다. 중첩된 JCL 프로시저는 최대 16 레벨까

지 호출될 수 있다. JCL 프로시저 스텝을 실행하고 나면 해당 JCL 프로시저를

호출한 원래의 스텝으로 돌아가서 그 다음 스텝부터 계속 실행해 나간다.

조건 실행

다음과 같이 서로 다른 방식으로 JOB을 구성하는 job step을 조건적으로 실행할

수 있다.

JOB COND

실행한 배치 프로그램이 종료하면 프로그램의 종료 상태가 JOB COND(예외

상황)를 만족하는지 검사하고 JOB COND를 만족하면 더 이상의 job step을

실행하지 않고 JOB을 에러로 종료한다.

JOB COND가 만족되지 않는 경우는 다음 job step을 계속해서 실행한다.

EXEC COND

실행한 이전 job step의 종료상태에 따라서 다음에 실행할 job step을 처리할

지 건너뛸지를 결정한다. 이러한 방식의 조건적인 job step의 실행은 EXEC

문의 COND 파라미터를 이용하여 지정한다.

IF-THEN/ELSE/ENDIF

IF-THEN/ELSE/ENDIF 문에 기술된 조건을 평가하여 조건적으로 job step을

실행한다.

EXEC PGM 처리

tjclrun의 가장 중요한 역할이 바로 사용자가 지정한 배치 프로그램을 실행하는

것이며, 다음과 같은 세부 작업으로 이루어진다.

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)을 다음과

같은 절차로 실행한다.

스텝 진행 보고

해당 EXEC PGM step의 처리 시작을 TJES에게 보고한다.

PGM 실행 권한

EXEC PGM에 지정된 배치 프로그램이 주요 유틸리티인 경우 JOB USER가 해당

프로그램을 실행할 수 있는 권한이 있는지 검사한다.

tjclrun.conf [TACF] CHECK_UTAUTH=YES가 설정되어 있는 경우에만 권한

검사를 수행한다.

스텝 DD 할당

EXEC PGM step에서 호출할 배치 프로그램이 사용할 데이터 셋을 지정하는 DD

문을 처리하여 데이터 셋을 할당한다. Job step 레벨의 스페셜 DD 문에 대한 부

가적인 처리도 이 단계에서 처리된다. Job step 레벨의 스페셜 DD 문으로는

STEPCAT DD 및 STEPLIB DD 문이 있다.

PGM 파라미터

EXEC PGM에 지정된 배치 프로그램에 전달될 실행 파라미터를 만든다. 배치 프

로그램은 이 파라미터를 일반적인 UNIX 프로그램의 argc 또는 argv를 통해서 얻

을 수 있다.

참고: EXEC PROC에 지정된 PARM은 호출되는 JCL 프로시저 내부에 포함된 EXEC PGM의 PARM의 값을 오버라이드하도록 전달한다.

호출/실행

실제로 시스템 함수를 이용하여 EXEC PGM에 지정된 배치 프로그램을 호출

(fork)하는 단계이다. TJES에서 배치 프로그램은 tjclrun 프로세스의 자식 프로세스

(child process)로서 실행된다. 그러기 위해서 먼저 fork를 실행하여 자식 프로세스

를 생성하고 자식 프로세스에서 exec을 실행하여 지정된 배치 프로그램을 시작

한다.



SYSIN/SYSOUT 파이프

OpenFrame에서는 배치 프로그램이 사용하는 SYSIN DD와 SYSOUT DD를 일반

적인 UNIX 프로그램의 stdin과 stdout으로 구현하였다.

tjclrun은 비유적으로 볼 때 쉘의 명령어 라인을 이용하여 배치 프로그램을 실행

하는 사용자와 같은 역할을 수행한다고 볼 수 있다. 그런 의미에서 tjclrun은

SYSIN DD의 내용을 읽어서 응용프로그램의 stdin에 write하여 응용프로그램의

stdin으로부터 SYSIN의 내용을 읽을 수 있도록 해준다.

반대로 응용프로그램에서 stdout으로 출력한 내용은 tjclrun이 읽어서 SYSOUT

DD에 해당하는 데이터 셋이나 JOB SPOOL에 대신 출력해준다.

SYSIN DD와 SYSOUT DD를 UNIX 시스템상의 프로그램들이 공통적으로 사용하

는 (또는 인식하는) stdin과 stdout으로 연결함으로써 OpenFrame의 데이터 셋

API를 사용하지 않고 만들어진 대부분의 UNIX 응용프로그램들도 OpenFrame 배

치에서 별도의 처리 없이 배치 프로그램으로 실행하는 것이 가능하다.

참고: 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에 지정된 배치 프로그램을 실행하고 해당 프로그램이 종료

할 때까지 기다리면서 주기적으로 응용프로그램에서 수행한 데이터 셋 I/O 카운

트를 TJES에 보고한다.

스텝 DD 후처리

Job step에서 실행된 배치 프로그램이 종료하면 그 종료 상태에 따라서 DD문의

DISP 파라미터에 지정된 후처리 작업을 수행한다.



Job step에서 실행된 배치 프로그램이 정상 종료한 경우에는 Normal Disposition

에 지정된 후처리를 수행하고 비정상 종료 한 경우에는 Abnormal Disposition에

지정된 후처리를 수행한다. DISP의 종류는 PASS, KEEP, CATLG, UNCATLG,

DELETE가 있다.

JOB COND

실행한 배치 프로그램이 종료되면서 반환한 종료상태(Exit status)가 JOB COND에

해당하는지 평가하여 만족되는 경우는 예외상황으로 간주하여 tjclrun은 자신이

보유하고 있는 데이터 셋 및 데이터 셋 lock 등의 자원을 해제한 후에 에러로

JOB의 실행을 종료한다. 프로그램의 종료상태가 JOB COND에 해당하지 않는 경

우는 뒤따르는 다음 job step을 계속하여 실행한다.

EXEC PROC 처리

Job 실행과정에서 설명했듯이 처리해야 하는 job step이 JCL 프로시저를 호출하

는 EXEC PROC step인 경우, tjclrun은 지정된 JCL 프로시저를 파싱하고 해당 프

로시저의 내용을 실행한다.

해당 프로시저의 마지막 스텝까지 실행을 한 후에는 해당 프로시저를 호출한 job

step의 다음 job step들을 이어서 실행한다.

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

로 구분된다.

1. 입력 스트림 프로시저 (INSPROC)

입력 스트림 프로시저는 해당 프로시저를 호출하는 INPJCL에 프로시저의 내

용이 정의되어 있다. 입력 스트림 프로시저는 해당 프로시저가 정의되어 있

는 INPJCL에서만 호출할 수 있다.

2. 카탈로그 프로시저 (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은 tjes.conf

[PROCLIB] 섹션에 설정되어 있어야 한다. 하나의 ddname에 여러 개의 JCL 라

이브러리의 이름을 지정할 수 있으며, JCLLIB과 비슷하게 여러 개의 JCL 라이브

러리에서 앞에서부터 순서대로 지정된 프로시저를 찾도록 설정할 수 있다.

참고: 카탈로그 프로시저를 찾은 경우, 카탈로그 프로시저를 파싱하기 전에 tjclrun은 파싱

에 사용한 카탈로그 프로시저의 내용을 JOB SPOOL의 CATPROC DD에 저장해둔다. 이 CATPROC은 파싱 실행 당시의 카탈로그 프로시저의 내용을 보관함으로써 JOB 실행결과를 검토하거나 문제점을 분석할 때 도움이 된다. 입력 스트림 프로시저(INSPROC)의 경우 INPJCL에 포함되어 있으므로 따로 저장하

지 않는다.

DD 처리

tjclrun은 JCL의 DD 문에 기술된 배치 프로그램이 사용할 데이터 셋을 할당하여

배치 프로그램에서 사용할 수 있도록 해준다.

일반적인 배치 프로그램은 자신이 사용할 데이터 셋을 스스로 할당하지 않고

JCL에 DD문을 기술함으로써 tjclrun이 할당하게 하고 그 결과를 상속받아서 사용

한다.

데이터 셋 할당 작업은 EXEC PGM step에서 배치 프로그램을 실행하기 전에 수

행된다. 배치 프로그램이 종료된 이후에는 할당한 데이터 셋에 대한 후처리 작업

을 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(잡스트림)에 DD *의 형태로 기술된 데이터 셋을 말한다.

tjclrun은 입력 스트림 데이터 셋을 JOB SPOOL에 따로 저장해둔 다음에 내부적

인 데이터 셋 이름을 부여한다. 그 이후는 일반적인 데이터 셋과 동일한

OpenFrame 데이터 셋 처리 모듈을 이용해서 할당하고 배치 프로그램에서 이 데

이터 셋을 사용할 수 있게 된다. tjclrun은 JOB SPOOL에 임시로 저장한 입력 스

트림 데이터 셋이 JOB 종료 시에 제거될 수 있도록 임시 데이터 셋으로써 생성

한다.



스페셜 DD

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

//ddname DD [parameters,...]

시스템에서 특수한 용도로 사용하기 위해 예약되어있는 ddname을 갖는 DD문을

스페셜 DD 문이라고 부른다.

주의: 사용자는 특수한 용도로 사용하기 위해 예약된 스페셜 DD의 ddname을 약속된 이

외의 용도로 사용할 수 없다.

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

- SYSIN

- SYSOUT 및 SYSPRINT

- JOBLIB 및 STEPLIB

- JOBCAT 및 STEPCAT

각각의 스페셜 DD는 다음과 같이 처리된다.

SYSIN DD

현재 실행중인 job step에 SYSIN DD문이 지정된 경우 tjclrun은 SYSIN DD문에

지정된 데이터 셋의 내용을 읽어서 tjclrun이 실행한 배치 응용프로그램의 stdin으

로 전달한다. 즉, 응용프로그램은 SYSIN DD에 의해 할당된 데이터 셋의 내용을

stdin으로부터 읽을 수 있다.

SYSOUT DD/SYSPRINT DD

현재 실행중인 job step에 SYSOUT DD 또는 SYSPRINT DD가 존재하는 경우,

tjclrun이 호출하는 배치 프로그램 대신 이 DD가 지정하는 데이터 셋을 개방하고,

배치 프로그램이 stdout이나 stderr로 출력하는 내용을 읽어서 SYSOUT DD 또는

SYSPRINT DD에 의해 할당된 데이터 셋에 배치 프로그램을 대신하여 출력한다.

이렇게 하는 이유는 OpenFrame 데이터 셋 I/O 함수를 사용하지 않고 stdout이나

stderr에 직접 메시지를 출력하는 대부분의 응용프로그램을 JCL에 의해서 자연스

럽게 실행할 수 있게 하기 위함이다.



SYSOUT DD와 SYSPRINT DD는 동일한 의미로 취급한다. 두 개의 DD가 둘 다

존재하는 경우에는 항상 SYSOUT DD를 사용하고 SYSPRINT DD는 사용하지 않

는다.

JOBLIB DD/STEPLIB DD

JOBLIB DD와 STEPLIB DD는 tjclrun이 EXEC PGM=pgmname에 지정된 배치 응

용프로그램을 찾는 PDS 데이터 셋(라이브러리 경로)을 지정한다.

JOBLIB DD는 INPJCL의 JOB 문장과 첫번째 EXEC 문장 사이에 지정될 수 있고,

해당 JOB에서 호출되는 프로그램을 찾는 PDS (라이브러리)를 지정한다.

DD문의 concatenation 기능을 이용하여 여러 PDS에서 프로그램을 찾아보도록

지정할 수 있다.

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

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가 둘 다 지정되지 않은 경우는 tjclrun.conf

[SYSLIB] 섹션에 지정된 위치에서 실행할 배치 프로그램을 찾는다.

JOBCAT DD/STEPCAT DD

JOBCAT DD와 STEPCAT DD는 JOB 및 job step에서 사용할 데이터 셋 카탈로그

를 지정한다. 두 가지 경우 모두 DD문의 concatenation을 이용해서 여러 데이터

셋 카탈로그를 지정할 수 있다.

JOBCAT DD는 잡스트림의 JOB 문장과 첫 번째 EXEC 문장 사이에만 지정될 수

있고, 그 JOB에서 기본적으로 사용할 데이터 셋 카탈로그들을 지정한다.



STEPCAT DD는 job step의 EXEC문 다음에 위치하며, 그 job step에서 사용할 데

이터 셋 카탈로그를 지정한다.

JOBCAT과 STEPCAT이 모두 지정된 경우는 STEPCAT이 사용된다. JOBCAT이

지정되어 있고 STEPCAT이 지정되어 있지 않은 job step에서는 JOBCAT이 사용

된다. JOBCAT 및 STEPCAT이 전혀 지정되지 않은 JOB에서는 OpenFrame 시스

템의 마스터 카탈로그가 사용된다.

JOBCAT이나 STEPCAT이 지정된 경우도 지정된 카탈로그에 데이터 셋이 카탈로

깅 되어있지 않은 경우는 마스터 카탈로그에서 데이터 셋에 대한 카탈로그 정보

검색을 시도한다.

OUTPUT 처리

JCL OUTPUT 문장은 JOB SPOOL에 생성되는 Sysout 데이터 셋의 출력처리 방

법을 나타내거나 제어하기 위한 JCL 문장이다.

Sysout 데이터 셋을 나타내는 DD 문은 하나 이상의 OUTPUT 문장을 참조하여

해당 출력을 처리하기 위한 방법을 지정할 수 있다.

참고: OUTPUT 문장에 지정할 수 있는 대부분의 파라미터는 OUTPUT 문장을 통하지 않

고 직접 Sysout 데이터 셋을 나타내는 DD문에 지정할 수도 있다. 그러나 DD 문장의 고유한 용도에 혼동을 줄 수 있기 때문에, 또한 출력제어를 좀더 엄밀하고 여러 DD에 중복으로 코딩하는 일을 피하기 위해서 OUTPUT 문장을 통해

서 출력제어를 나타내는 것을 권장한다. 실제로 OUTPUT 문에는 지정 가능하지만 Sysout DD문에는 지정할 수 없는 파라미터가 존재한다.

JOB SPOOL

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

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



INPJCL

tjclrun이 실행하는 잡스트림을 담고 있는 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라고 부른다.



참고: tjclrun이 INSDSET SHUNT를 하는 이유는 입력 스트림 데이터 셋은 일반 Non-VSAM 데이터 셋과 함께 concatenation될 수 있기 때문에 입력 스트림 데이터 셋을 INPJCL에서 축출하여 데이터 셋으로 SHUNT해둠으로써 Non-VSAM SDS의 concatenation 로직을 이용하여 일관된 방식으로 concatenation 처리를 지원하기 위

함이다.

JESJCL

tjclrun이 파싱한 INPJCL, INSPROC 및 카탈로그 프로시저를 파싱한 결과인

parse tree를 텍스트 형태로 출력한 내용을 갖는 파일이다. 주로 문제 분석 시에

참고 자료로 사용된다.

JESMSG

tjclrun이 종료하는 경우 그 tjclrun을 실행한 runner slot가 해당 JOB SPOOL에 기

록하는 데이터 셋으로, 그 내용은 실행된 JOB에 관련된 기본적인 정보와 JOB의

실행 과정에서 보고된 여러 가지 통계정보 그리고 JOBSTEP에 관련된 정보를

포함한다. JOB의 실행에 관련하여 TJES 시스템에서 관심이 되는 사항에 대한 요

약적인 정보를 담고 있다.

SYSMSG

SYSMSG는 tjclrun의 주요 메시지 로그이다. 즉, JOB을 실행하는 과정에서 필요

한 여러 하위단계의 진행상태 및 중요 결과 메시지뿐만 아니라 작업 처리시 발생

한 에러 메시지도 SYSMSG에 저장된다.

JOB의 실행이 비정상적으로 종료된 경우 원인분석을 위해서 우선 SYSMSG의

내용을 검토해야 한다.

SYSMSG의 내용은 tjclrun이 JOB의 job step을 실행한 순서에 따라서 세부 작업

이나 동작이 발생한 시간순서대로 기록된다.

SYSMSG에 출력되는 내용은 다음과 같다.

- 수행중인 JOBSTEP 이름

- JOB 수행 중에 할당한 데이터 셋 정보

- tjclrun이 호출한 PGM 이름과 프로세스 아이디(pid)

- tjclrun이 호출한 PGM의 종료 상태



- tjclrun이 현재 수행중인 동작

- tjclrun의 주요 동작의 성공 여부

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 데이터 셋은 사용자가 배치

프로그램을 위하여 요청한 데이터 셋으로 JOB SPOOL 상에 저장되도록 특별히

지정한 경우로 볼 수 있다. Sysout 데이터 셋은 하나의 JOB이나 job step에서 여

러 개 지정할 수 있다. 위의 예제에서 SYSOUT, RPTOUT, RPTERR가 Sysout 데

이터 셋이다.

Sysout 데이터 셋의 내용은 사용자가 지정한 배치 프로그램에서 출력하는 내용

이다. TJES는 Sysout 데이터 셋에 그 이외의 정보를 가감하지 않는다. 배치 프로

그램에서 Sysout 데이터 셋의 사용을 마치면 TJES는 Sysout 데이터 셋의

OUTPUT CLASS에 따라서 사용자가 출력한 내용을 추후에 프린터나 화면으로

출력하는 과정을 관리할 뿐이다.



JOB Control

TJES에서는 스케줄링 단계 이후의 실행중인 JOB을 SUSPEND(일시정

지)/RESUME(실행재개)/STOP(강제종료) 시킬 수 있다. JOB의 실행을 위해서 실

행중인 여러 하위 프로세스에 대한 위와 같은 세가지 제어를 TJES에서는 JOB

CONTROL이라고 부른다.

tjesmgr 혹은 OpenStudio와 같은 사용자 인터페이스를 이용하여 실행중인 JOB에

대해서 JOB CONTROL을 할 수 있다.

참고: 자세한 명령 사용법은 “제6장 TJESMGR 명령어” 및 “OpenStudio BM 안내서”를 참

고하기 바란다.

사용자가 실행중인 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”을 참고한다.



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의 대기

문제를 쉽게 식별하고 해결할 수 있다.

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의 잡스트림 상에서의 위치를 의미하

는 스텝의 경로(STEPPATH) 정보와 해당 job step의 타입(PGM 혹은 PROC)등을

보고한다. STEP FINISH 보고 시에는 해당 job step의 종료상태 및 종료코드와 해

당 job step을 수행하는데 걸린 시간정보를 보고한다.

데이터 셋 할당

tjclrun은 job step에 지정된 배치 프로그램을 호출하기 전에 배치 프로그램이 사

용할 데이터 셋을 미리 할당한다. (할당할 데이터 셋은 JCL의 DD문에 의해서 지

정된다.)

데이터 셋의 할당정보는 전체 OpenFrame 시스템상에서 매우 중요한 정보이기

때문에 tjclrun은 할당한 ddname과 데이터 셋의 이름을 JOB SPOOL의 SYSMSG

에 남길 뿐만 아니라 추가적으로 데이터 셋의 할당정보가 OpenFrame의 데이터

셋 할당 모듈 자체적으로 OpenFrame_HOME/log 디렉터리의 dsalc 로그에 기록

된다.

데이터 셋 I/O 보고

tjclrun이 할당해 준 데이터 셋을 배치 프로그램에서 사용함에 따라 변경되는 해

당 데이터 셋에 대한 I/O 카운트 정보가 반영된다. tjclrun은 배치 프로그램이 실

행되는 동안 수행한 데이터 셋 I/O 통계정보를 주기적으로 TJES에 보고한다. 이

를 통해서 운영자(사용자)는 특정 데이터 셋에 대해서 job step 별로 몇 건을

READ/ WRITE하고 있는지를 모니터링 할 수 있다.

보안

TACF 지원 기능

tjclrun은 TACF 보안기능을 지원하며, 크게 두 가지가 있다.

첫째는 job step의 EXEC PGM에 지정된 프로그램을 실행할 권한이 있는지 검사

하는 것이고, 다른 하나는 DD문에 지정된 데이터 셋들에 접근할 권한이 있는지

검사하는 기능이다. 어느 경우나 권한이 없는 경우는 JOB의 실행은 비정상 종료

처리된다.

참고: TACF를 이용하여 특정 TACF 사용자에 대하여 프로그램 및 데이터 셋에 대한 권한

을 제어하는 방법에 대해서는 “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 실행을 위한 대리자를 지정하는 방법은 “TACF 운영자 안내서”를 참

고한다.

setuid root tjclrun

UNIX 시스템에서 실행 프로그램을 실행하는 사용자가 아니라 해당 프로그램 파

일의 소유자 권한으로 프로그램을 실행하기 위해서 실행 프로그램의 소유자와 파

일 퍼미션을 적절하게 변경하여 프로그램 실행시 프로세스가 프로그램 파일의 소

유자 권한으로 실행되게끔 설정하는 작업을 setuid 작업이라고 한다. (물론 setuid

된 프로그램인 경우라도 실행하는 사용자에게 해당 프로그램의 실행 권한이 있는

경우에만 실행할 수 있다.) 다시 말해, setuid root 작업은 특정 프로그램을 실행시

프로그램을 실행한 사용자가 아닌 root 사용자 권한으로 프로세스가 실행되게끔

설정하는 작업을 의미한다.

여기서 말하는 프로세스의 사용자는 UNIX 프로세스의 유효 사용자(effective

userid)를 말한다. tjclrun은 프로세스가 실행되는 동안 프로세스의 실제 사용자 정

보(real userid)를 tjclrun.conf의 설정과 관계없이 전혀 변경하지 않는다. UNIX

시스템에서 파일 및 시스템 자원에 대한 권한 검사는 프로세스의 유효 사용자에

대해서 이루어진다.



실제 사용자 정보는 실제적으로 프로세스를 호출한 사용자를 구분하기 위한 용도

로 사용된다. 또한 여기서 말하는 사용자는 TACF 사용자와는 직접적인 관련이

없는 운영 시스템 상의 사용자를 의미한다.

다음의 두 가지 사항을 고려하여 필요한 경우 OpenFrame TJES를 설치한 후에

tjclrun 프로그램에 대하여 root 실행 권한을 부여할지 여부를 결정한다.

1. JOB CONTROL시에 tjclrun이 실행한 배치 프로그램이 tjclrun을 실행하는 프

로세스의 유효 사용자와 다른 유효 사용자로 실행되는 경우 tjclrun은 UNIX

JOB CONTROL 시그널에 기반한 JOB CONTROL을 권한 부족의 이유로 성

공적으로 수행할 수 없다. 이러한 경우에도 성공적으로 JOB CONTROL을 하

려면 tjclrun 프로그램에 root 실행 권한을 부여하는 것을 고려해야 한다.

혹은 위와 같은 상황은 매우 예외적인 상황으로 운영자가 직접 root 사용자

로 로그인해서 해당 프로세스에 대해서 JOB CONTROL 시그널을 보낼 수도

있지만 이러한 수작업은 더디고 운영자의 업무부담을 높이는 요소가 될 수

있다.

예를 들면, tjclrun이 실행하는 배치 프로그램에 대해서 tjclrun 프로세스의 유

효 사용자가 아닌 다른 사용자로 setuid 처리가 되어 있는 경우에 이러한 문

제가 발생한다.

2. JOB을 수행하는 tjclrun 및 job step에서 실행되는 배치 프로그램을 실행하는

프로세스를 JOB에 지정된 USER의 권한으로 실행하기 위해서는

tjclrun.conf [ACCOUNT] SETUID=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 s+u 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.conf의 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 library를 등록하는 설정을 통해서 OpenFrame 제품에서 제공되는 라이브러리를 공

유 라이브러리 search 환경 변수에 의존하지 않고 찾을 수 있도록 설정할 수 있다.

주의: tjclrun을 setuid root 권한으로 설치하여 운영하는 경우는 tjclrun.conf [SYSLIB] 섹션을 명시적으로 설정해주어야 한다. 특히 IBM AIX와 같이 필요한 환경변수가 되어버리는 시스템에서는 필수적인 설정이

다. 그렇지 않은 경우라도 tjclrun이 [SYSLIB]에 설정된 search path에서만 프로그램

이나 공유 라이브러리를 찾게끔 하는 것이 보안 및 시스템 성능상으로 더 유리하다. 물론 OpenFrame 설정파일들에 대한 변경 권한을 엄격하게 관리해야 한다.

tjclrun 호출

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

TJES의 runner slot은 JOB의 실행을 할당 받은 당시의 TJES의 상태에 기반하여

적절한 실행인자와 함께 실행된다.

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

- RUNMODE

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



- JOBID

유니크한 JOBID (예, JOBnnnnn)

- INITINDEX

Runner slot 인덱스

- JOBSTREAM

JCL 문을 포함하고 있는 잡스트림

- JOBPOS

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

[keyword args]

- RESTART=*|stepname|stepname.procstepname

재시작할 job step을 지정한다.

Asterisk(*)는 첫번째 JOB 또는 PROC step을 의미하고, stepname은

stepname으로 지정된 JOB step을 의미하며, stepname.procstepname은

stepname.procstepname의 PROC step을 의미한다.

주의: tjclrun을 쉘의 명령어 라인에서 직접 실행하는 것도 가능하기는 하지만 이렇게 실행

된 경우는 TJES의 JOB 관리의 submit 및 스케줄링 단계를 건너뛰고 직접 실행하

는 경우이므로 정상적인 JOB의 실행이 보장되지 않는다.

tjclrun 인터널 로그

tjclrun은 내부적인 디버깅이나 오류분석을 위한 용도로 로그 메시지용 파일을 하

나 더 사용한다.

OPENFRAME_HOME\log 디렉터리에 존재하는 tjclrun.nnnn.log 파일이 그것

이다. 여기서 nnnn은 runner slot의 슬롯 인덱스를 나타내는 숫자이다.

하나의 runner slot에는 동시에 하나 이상의 JOB의 처리가 할당될 수 없기 때문

에 결과적으로 특정 tjclrun.nnnn.log는 동시에 하나의 tjclrun에 의해서만 사

용된다. tjclrun.nnnn.log는 특정 runner slot가 다음 JOB을 할당 받은 경우에

기존의 내용을 삭제하지 않고 계속 추가하는 방식으로 로그 메시지가 누적되므로,

시간적으로 해당 runner slot를 거쳐서 실행된 여러 개의 JOB에 대한 tjclrun의 내

부 로그 메시지가 저장되게 된다.



tjclrun.nnnn.log에 저장되는 tjclrun의 내부 로그 메시지는 주로 tjclrun 구현

에 사용된 내부 함수나 시스템 함수 호출시의 에러 등이 저장된다. 메시지의 내

용은 디버깅이나 문제 분석을 위한 것들로 tjclrun 버전 별로 크게 바뀔 수 있는

부분이다.

TJES를 이용하는 중에 tjclrun 자체의 버그나 시스템 오류와 관련된 문제로 의심

되는 경우에는 버그 및 문제 보고 시에 해당 JOB을 실행한

tjclrun.nnnn.log의 내용을 검토하고 첨부하면 좀더 구체적인 원인 파악에

도움이 된다.

제4장 SPOOL


제4장 SPOOL

SPOOL은 JOB 수행에 필요한 입력 및 JOB 수행으로 생성된 결과물인 SPOOL

데이터 셋을 담고 있는 볼륨을 지칭하거나 또는 SPOOL 데이터 셋을 사용하는

오퍼레이션을 뜻한다.

JCL이 submit되면, TJES에서는 JOB에 유니크한 JOBID를 부여하고 JOBQ에 등

록한다. 이 때 부여된 JOBID 이름으로 SPOOL 볼륨에 SPOOL 공간이 할당된다.

그리고 INPJCL이라는 SPOOL 데이터 셋이 생성된 후 JCL을 INPJCL에 복사한

다. 이후의 JOB 수행에서는 INPJCL이 입력으로 사용된다.

tjclrun은 JOBID로 생성된 SPOOL 공간에 JESMSG, JESJCL, SYSMSG,

CATPROC라는 이름의 SPOOL 데이터 셋들과 JCL에 기술된 SYSOUT DD에 대

한 SPOOL 데이터 셋을 생성하고 JOB 수행에 사용한다.

생성된 SPOOL 데이터 셋은 tjesmgr나 OpenStudio를 통해서 내용을 확인할 수

있다.

4.1 SPOOL 데이터 셋

SPOOL 데이터 셋은 JOB이 수행될 때 기본적으로 생성되는 데이터 셋 (INPJCL,

JESMSG, JESJCL, SYSMSG, CATPROC)과 JCL에 SYSOUT으로 기술되어 생성되

는 데이터 셋이 있다.

다음은 데이터 셋 TEST.DATASET1의 내용을 데이터 셋 TEST.DATASET2,

TEST.DATASET3으로 복사한 후 TEST.DATASET1을 삭제하는 JCL의 예이다.

//TESTPROC JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1)

//STEP01 EXEC IBGPROC

//PS010.SYSUT1 DD DSN=TEST.DATASET1,DISP=(SHR,KEEP)

//PS010.SYSUT2 DD DSN=TEST.DATASET2,DISP=(NEW,CATLG),

// DCB=(RECFM=FB,LRECL=10,BLKSIZE=100)


제4장 SPOOL


//PS010.SYSUT1 DD DSN=TEST.DATASET1,DISP=(SHR,DELETE)



<TESTPROC JCL>

이 JCL은 CATALOGED PROCEDURE인 IBGPROC를 사용하는 두 개의 STEP으

로 되어 있다. IBGPROC의 내용은 다음과 같고 IEBGENER 유틸리티를 수행한다.

//PS010 EXEC PGM=IEBGENER

//STEPLIB DD DSN=PROD.BAT.OBJLIB,DISP=SHR

// DD DSN=SYS1.TEMPLIB,DISP=SHR

//SYSPRINT DD SYSOUT=*

//SYSUT1 DD DUMMY

//SYSUT2 DD DUMMY

<IBGPROC>

JCL TESTPROC을 submit하여 실행하면 다음과 같은 SPOOL 데이터 셋이 생성

된다.

SPOOL LIST:

---------------------------------------------------------------------------

NO STEP DDNAME SIZE DSNAME

---------------------------------------------------------------------------

0 -------- INPJCL 410 INPJCL

1 -------- JESMSG 1K JESMSG

2 -------- JESJCL 9K JESJCL

3 -------- SYSMSG 4K SYSMSG

4 -------- CATPROC 1K CATPROC

5 STEP01/PS010 SYSPRINT 400 oftest.TESTPROC.JOB00012.D000004

6 STEP02/PS010 SYSPRINT 400 oftest.TESTPROC.JOB00012.D000009

위의 SPOOL LIST의 SPOOL 데이터 셋 내용은 다음과 같다.

1. INPJCL - submit된 JCL이 복사되어있다. 이후의 JOB 실행에서는 INPJCL의

내용을 사용한다.

//TESTPROC JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1)

제4장 SPOOL



//PS010.SYSUT1 DD DSN=TEST.DATASET1,DISP=(SHR,KEEP)




//PS010.SYSUT1 DD DSN=TEST.DATASET1,DISP=(SHR,DELETE)



<INPJCL>

2. JESMSG - JOB과 관련된 정보와 각각의 STEP에 대한 정보가 저장된다.

---< JOB INFO >------------------------------------------------------------

JOB ID : JOB00012

JOB NAME : TESTPROC NODENAME : NODE1

JOB class : A , JOB STATUS : D(000) , JOB PRTY : 0 , RUNNER INDEX : 0

JOB USER : ROOT

JCL PATH : /home/saza/OpenFrame/volume_default/SYS1.JCLLIB/TESTPROC

TIME STAMP : SUBM 20070201004636, EXEC 20070201004637, TERM 20070201004639

RES USAGE : CPU - 0s (p:2s) , 0%

---<STEP INFO>-------------------------------------------------------------

STEP : [STEP01/PS010]

CPU 0s(p: 0s).

SYSUT1 TEST.DATASET1 R:2742 W:0


STEPLIB PROD.BAT.OBJLIB R:0 W:0

SYS1.TEMPLIB R:0 W:0

SYSPRINT JOB00012(saza.TESTPROC.JOB00012.D000004) R:0 W:5

STEP : [STEP02/PS010]

CPU 0s(p: 0s)



STEPLIB PROD.BAT.OBJLIB R:0 W:0

SYS1.TEMPLIB R:0 W:0

제4장 SPOOL


SYSPRINT JOB00012(saza.TESTPROC.JOB00012.D000009) R:0 W:5

다음은 JESMSG에 저장되는 JOB 정보에 대해 설명한 표이다.

필드 설명

JOB ID 할당된 JOB의 고유번호이다.

JOB NAME JOB 이름이다.

NODENAME JOB이 실행된 TJES 노드 이름이다.

JOB class JOB 클래스이다.

JOB STATUS JOB의 현재 상태(반환 값)이다.

JOB PRTY 실행한 JOB의 JOB 스케줄링 우선순위이다.

RUNNER INDEX JOB을 실행한 runner slot 번호이다.

JOB USER JOB을 실행한 USER이다.

JCL PATH USER가 submit한 JCL 파일의 위치 및 파일이름이다.

TIME STAMP JOB이 submit된 시각, JOB 실행의 시작 및 종료 시각이다.

RES USAGE JOB 실행에 사용된 CPU 시간을 나타낸다.

CPU-

0s - tjclrun 및 fork된 자식 프로세스의 CPU 사용량의 합.

현재는 프로세스가 종료되었으므로 0

(p:2s) - tjclrun이 fork된 시점부터 종료 시까지의 시간 즉,

JOB 수행시간

0% - JOB 수행시간 대비 CPU 사용량

[표 4-1] JESMSG상의 JOB 정보

다음은 JESMSG에 저장되는 STEP 정보에 대해 설명한 표이다.

필드 설명

STEP 해당 JOBSTEP의 이름이다.

CPU 해당 JOBSTEP 처리에 사용된 CPU 시간(실제 처리시간)

SYSUT1 해당 JOBSTEP에서 발생한 SYSUT1에 대한 I/O 카운트

SYSUT2 해당 JOBSTEP에서 발생한 SYSUT2에 대한 I/O 카운트

STEPLIB 해당 JOBSTEP에서 발생한 STEPLIB에 대한 I/O 카운트

SYSPRINT 해당 JOBSTEP에서 발생한 SYSPRINT에 대한 I/O 카운트

[표 4-2] JESMSG상의 JOBSTEP 정보

3. JESJCL - INPJCL에 대하여 JCL 문장의 parse tree가 저장된다.

제4장 SPOOL


JOB STREAM=[/home/saza/OpenFrame/spool/JOB00012/INPJCL], JOBPOS=[0]

========================================================================

/JOB[name=TESTPROC]={

|lineno=1

|param[keyword=class]={

| |type=VAL_STR

| |value=[A]

|}

|param[keyword=MSGCLASS]={

| |type=VAL_STR

| |value=[X]

|}

|param[keyword=MSGLEVEL]={

| |type=VAL_SUBPARAMS

| |value={

| | |param[position=1]={

| | | |type=VAL_STR

| | | |value=[1]

| | |}

| | |param[position=2]={

| | | |type=VAL_STR

| | | |value=[1]

| | |}

| |}

|}

|---------- child statements ----------

|/EXEC[name=STEP01]={

| |lineno=2

| |param[position=1]={

| | |type=VAL_STR

| | |value=[IBGPROC]

| |}

|}

제4장 SPOOL


...

<JESJCL>

4. SYSMSG - JOB이 실행되는 동안 tjclrun이 생성한 메시지를 저장한다.

--------------------------- STEP01 EXEC PROC step ------------------------

(JCX0210I) Start parsing Cataloged Procedure ...

---------------------------- PS010 EXEC PGM step -------------------------

(JCX0320I) SYSUT1 DD ALLOC - DSNAME=TEST.DATASET1


(JCX0320I) STEPLIB DD ALLOC - DSNAME=PROD.BAT.OBJLIB

(JCX0320I) CONCATED DD ALLOC - DSNAME=SYS1.TEMPLIB

(JCX0321I) SYSPRINT DD ALLOC - DSNAME=JOB00012(saza.TESTPROC.JOB00012.D000004)



(JCX0341W) 'SYSIN DD *' delimited by EOF found and ignored

---------------------------- PS010 EXEC PGM step -------------------------








---------------------------- PS010 EXEC PGM step -------------------------

EXEC PGM=IEBGENER






(JCX0044I) dsalc_report_start OK

제4장 SPOOL


(JCX0240I) SYSPRINT DD in STEP01/PS010 open

(JCX0335I) SYSUT1 DD in STEP01 exported


(JCX0058I) pgm pid=1642

(JCX0060I) Entering exec_pipe_loop() ...

(JCX0301I) SYSIN DD to PGM done

(JCX0245I) PGM closed stdout pipe

(JCX0061I) Leaving exec_pipe_loop() ...

(JCX0063I) pipe work done with coprocess child (PGM)

(JCX0080I) PGM pid[1642] EXITED

(JCX0065I) PS010 EXEC PGM step done with RC=0

(JCX0073I) dsalc_report_info OK

(JCX0069I) step res usage: real[ 0.05] user[ 0.01] system[ 0.01] cuser[ 0.01] csystem[ 0.00]

(JCX0070I) res usage: cpu_time[ 0.03] proc_time=[ 0.05] memory_size=[-1Kb]

(JCX0345I) SYSUT1 DD DISPOSE COND=NORMAL


(JCX0345I) STEPLIB DD DISPOSE COND=NORMAL

(JCX0345I) CONCATED DD DISPOSE COND=NORMAL

(JCX0345I) SYSPRINT DD DISPOSE COND=NORMAL



(JCX0341W) 'SYSIN DD *' delimited by EOF found and ignored

---------------------------- PS010 EXEC PGM step -------------------------

EXEC PGM=IEBGENER






(JCX0044I) dsalc_report_start OK

(JCX0240I) SYSPRINT DD in STEP02/PS010 open

제4장 SPOOL




(JCX0058I) pgm pid=1643

(JCX0060I) Entering exec_pipe_loop() ...

(JCX0301I) SYSIN DD to PGM done

(JCX0245I) PGM closed stdout pipe

(JCX0061I) Leaving exec_pipe_loop() ...

(JCX0063I) pipe work done with coprocess child (PGM)

(JCX0080I) PGM pid[1643] EXITED

(JCX0065I) PS010 EXEC PGM step done with RC=0

(JCX0073I) dsalc_report_info OK

(JCX0069I) step res usage: real[ 0.05] user[ 0.01] system[ 0.00] cuser[ 0.00] csystem[ 0.01]

(JCX0070I) res usage: cpu_time[ 0.02] proc_time=[ 0.05] memory_size=[-1Kb]



(JCX0345I) STEPLIB DD DISPOSE COND=NORMAL

(JCX0345I) CONCATED DD DISPOSE COND=NORMAL

(JCX0345I) SYSPRINT DD DISPOSE COND=NORMAL

--------------------------- DATA SET UNALLOCATION ------------------------

(JCX0346I) SYSUT1 DD UNALLOC COND=NORMAL


(JCX0346I) STEPLIB DD UNALLOC COND=NORMAL

(JCX0346I) SYSPRINT DD UNALLOC COND=NORMAL



(JCX0346I) STEPLIB DD UNALLOC COND=NORMAL

(JCX0346I) SYSPRINT DD UNALLOC COND=NORMAL

(JCX0333I) JOB is enqueued for output processing - JOBID=JOB00012, ABEND=

<SYSMSG>

5. CATPROC – JOB 실행에서 CATALOGED PROCEDURE를 사용할 때

PROCEDURE의 내용을 저장한다.

제4장 SPOOL


+--------------------------------------------------------------------+

| |

| |

| PROC for STEP01: SYS1.PROCLIB(IBGPROC) |

| |

| |

+--------------------------------------------------------------------+





//SYSUT1 DD DUMMY

//SYSUT2 DD DUMMY

+--------------------------------------------------------------------+

| |

| |

| PROC for STEP02: SYS1.PROCLIB(IBGPROC) |

| |

| |

+--------------------------------------------------------------------+





//SYSUT1 DD DUMMY

//SYSUT2 DD DUMMY

<CATPROC>

6. JCL에서 SYSOUT으로 정의된 SPOOL 데이터 셋 – 이들은 주로 JCL에 기

술된 유틸리티나 응용프로그램에서 OUTPUT으로 사용된다.

현재 이 예제에서는 STEP01, STEP02에서 각각 IEBGENER의 메시지를 저

장하는 SYSPRINT문에 대하여 SPOOL 데이터 셋이 생성되었다.

제4장 SPOOL


<STEP01/PS010 SYSPRINT saza.TESTPROC.JOB00012.D000004>

+0000.001.788: exec child pgm

>> M 2007-02-01 00:46:39 [001642:iebgener_main.c:648] (IBG0001M)

>> M 2007-02-01 00:46:39 [001642:iebgener_main.c:323] (IBG0005M) RECORD COUNT = 2742

>> M 2007-02-01 00:46:39 [001642:iebgener_main.c:696] (IBG0006M) TOTAL RECORD COUNT = 2742


<STEP02/PS010 SYSPRINT saza.TESTPROC.JOB00012.D000009>

+0000.002.685: exec child pgm


>> M 2007-02-01 00:46:39 [001643:iebgener_main.c:323] (IBG0005M) RECORD COUNT = 2742

>> M 2007-02-01 00:46:39 [001643:iebgener_main.c:696] (IBG0006M) TOTAL RECORD COUNT = 2742


4.2 SPOOL BACKUP

JOBQ에서 필요 없게 된 JOB을 삭제하게 되면, 해당 SPOOL도 삭제하게 된다.

만약 이 때, SPOOL을 보존해야 할 필요가 있으면 SPOOL BACKUP 기능을 사용

하여 SPOOL을 백업할 수 있다.

SPOOL BACKUP 명령이 내려지면 tjes.conf [SPOOL] BACKUP에 설정된 백

업 디렉터리에 현재 날짜로 디렉터리가 생성된다.

그리고 이 디렉터리에 백업된 JOB에 대해서 해당 SPOOL을 압축하여

JOBID_JOBNAME_submitDATE_submitTIME.tar.gz 형식의 파일을 생성한 후

백업된 JOB을 JOBQ와 SPOOL에서 삭제한다. 백업된 SPOOL에 대해서 조회를

하게 되면, tjes.conf [SPOOL] TEMP_DIR에 설정된 디렉터리에 압축된

JOBID_JOBNAME_submitDATE_submitTIME.tar.gz 형식의 파일을 풀어 놓고,

이후 해당 JOB에 대한 SPOOL을 조회할 수 있다.

제5장 OUTPUT Processing



OUTPUT Processing은 JOB 수행 도중에 생성된 SYSOUT들을 JOB이 종료된 후

에 처리하는 단계이다.

SYSOUT은 OUTPUT이라는 단위로 나뉘어져 처리된다. OUTPUT Processing은

SYSOUT의 내용을 프린터로 출력하는 작업과 인터널 리더를 통하여 SYSOUT을

JOBQ로 submit하는 두 가지의 작업을 한다.

두 작업 중 어떤 작업을 수행할 지는 SYSOUT의 속성에 따라 달라진다.

첫째, OpenFrame에서 프린터로 출력하는 작업은 엄밀히 말하면 물리적인 프린터

를 직접 가동시키는 것은 아니고, 외부 프린터 솔루션에 프린트할 데이터와 프린

트에 사용될 리소스 정보(FORMS, FORMDEF, PAGEDEF 등)를 전달하는 것이다.

외부 프린터 솔루션에 데이터와 정보를 전달하기 위해 print.conf [PRINTn]

섹션에 있는 COMMAND와 DRIVER_PATH에 필요한 명령어와 공유 라이브러리의

경로를 설정해야 한다.

둘째, 인터널 리더를 통한 submit에서는 print.conf [INTRDR] DRIVER_PATH

에 필요한 공유 라이브러리 경로를 설정해야 한다.

5.1 OUTPUT

OUTPUT이란 OUTPUT Processing에서 처리되는 단위로, JOB 수행이 끝나면 생

성된 SPOOL 데이터 셋은 OUTPUT Processing 단계를 거치게 된다.

OUTPUT은 JCL의 SYSOUT과 OUTPUT문에 의해 결정된다. 보통은 하나의

SPOOL 데이터 셋이 한 개의 OUTPUT으로 처리되며, 다음의 예처럼 하나 이상

의 OUTPUT으로도 처리될 수 있다.

다음 예와 같이 JCL이 구성되면 한 개의 SPOOL 데이터 셋이 여러 개의

OUTPUT 처리에 사용된다.

//OUT01 OUTPUT FORMDEF=FORM1

//OUT02 OUTPUT FROMS=LETTER01,FROMDEF=LTR1,PAGEDEF=LTR4

//PRT DD SYSOUT=A, OUTPUT=(*.OUT01,*.OUT02)



위의 JCL에서 PRT DD는 OUT01, OUT02 두 개의 OUTPUT DD를 참조하고 있다.

따라서 JOB이 끝나면 OUT01의 OUTPUT 문을 참조하는 OUTPUT과 OUT02의

OUTPUT 문을 참조하는 OUTPUT이 OUTPUT Processing에 따라 처리된다.

OUT01을 참조하는 OUTPUT이 처리되면 FORM1의 FORMDEF의 포맷으로 PRT

DD에 정의된 SPOOL 데이터 셋의 내용이 기본 용지에 출력된다.

OUT02를 참조하는 OUTPUT이 처리되면 LTR1이라는 FORMDEF와 LTR4라는

PAGEDEF의 포맷으로 LETTER01이라는 용지에 SPOOL 데이터 셋의 내용이 출

력된다.

5.2 OUTPUT 처리

JOB 수행이 끝나면 SPOOL 데이터 셋은 OUTPUT 단위로 OUTPUTQ에 등록된

다. 등록된 OUTPUT은 ofrpmsvr에 의해 스케줄링되어 프린트되거나 인터널 리

더에 의해 다시 submit 된다. 그리고 ofrpmsvr은 print.conf [PRINTERn]

섹션의 CLASS 설정과 OUTPUT CLASS와 비교하여 스케줄링하고, OUTPUT

DISPOSITION에 따라 OUTPUT을 처리한다.

OUTPUT CLASS

OUTPUT에 부여된 1 바이트 문자로 A-Z, 0-9가 사용된다. OUTPUT CLASS는

JCL에서 지정한다.

OUTPUT문에서 OUTPUT CLASS를 지정한 경우, OUTPUT문을 참고하는

SYSOUT문에 CLASS가 또 지정되면, SYSOUT문에서 지정된 값이 오버라이드

되므로 SYSOUT문에서는 CLASS를 지정하지 않도록 한다.

다음에서는 PRINT DD의 OUTPUT CLASS가 Y로 지정된다.

//OUT1 OUTPUT CLASS=Y,FORM=TEST

//PRINT DD SYSOUT=(,),OUTPUT=*.OUT1

SYSOUT문에서 OUTPUT CLASS를 지정하는 경우 다음은 PRINT DD의

OUTPUT CLASS가 A로 지정된다.

//PRINT DD SYSOUT=A



OUTPUT CLASS를 *로 지정하는 경우 *로 지정하면 JOB문에서 MSGCLASS로

지정된 CLASS가 OUTPUT CLASS로 지정된다.

다음 예에서는 PRINT DD의 OUTPUT class가 X로 지정된다.

//COPY02 JOB CLASS=I,MSGCLASS=X,MSGLEVEL=(1,1)

...

//PRINT DD SYSOUT=*

OUTPUT DISPOSITION

OUTPUT에 부여된 조치사항이다. JOB이 성공적으로 종료되었는지 여부에 따라

정상 처리(normal disposition)와 비정상 처리(abnormal disposition)로 나뉜다.

다음은 OUTPUT DISPOSTION에 따른 JOB 처리 과정을 나타낸 그림이다.

[그림 5-1] OUTPUT DISP에 따른 처리과정

DISP의 종류와 성격은 다음과 같다.

1. WRITE

OUTPUT이 스케줄링되어 프린트 되어야 함을 의미한다. 정상 처리되면

OUTPUT이 삭제된다.



2. HOLD

사용자가 해제할 때까지 스케줄링 되지 않고 OUTPUTQ에 대기한다. 사용자

가 해제하면 DISP는 WRITE로 변경된다.

3. KEEP

WRITE와 마찬가지로 OUTPUT이 스케줄링되어 프린트 되어야 함을 의미한

다. 다만 정상 처리된 후 DISP는 LEAVE로 변경된다.

4. LEAVE

사용자가 해제할 때까지 스케줄링 받지 않고 OUTPUTQ에 대기한다. 사용자

가 해제하면 DISP는 KEEP으로 변경된다.

5. PURGE

OUTPUTQ에서 삭제한다.

OUTPUT DISPOSITION은 다음과 같은 방법으로 지정한다.

1. JCL의 OUTPUT문으로 지정한다.

다음 예에서는 PRINT DD의 OUTPUT DISPOSITION에 정상 처리로 WRITE, 비정

상 처리로 PURGE가 지정된다. 즉, JCL이 수행되어 JOB이 정상 종료되면

OUTPUT을 처리하고, JOB이 비정상 종료되면 OUTPUT을 처리하지 않는다.

//OUT1 OUTPUT OUTDISP=(WRITE,PURGE)

//PRINT DD SYSOUT=(A,),OUTPUT=*.OUT1

2. SYSOUT문에 INTRDR 속성을 주면 사용자가 명시적으로 기술하지 않는 한

(WRITE,WRITE)로 지정된다.

다음 예에서 SUBM DD는 INTRDR 속성을 가진다.

JOB이 끝난 후 SUBM DD에 정의된 SYSOUT 데이터는 인터널 리더를 통하여

submit된다.

//SUBM DD SYSOUT=(A,INTRDR)

3. JCL의 OUTPUT문에서 지정하지 않으면, OUTPUT class에 따라 환경파일에

설정된 값으로 지정된다.



환경파일은 tjes.conf [OUTclass] 섹션에서 OUTPUT DISPOSITION이 class

에 따라 다음과 같은 예처럼 정의된다.

OUTPUT class가 A인 OUTPUT은 (WRITE,WRITE)로 지정되고, OUTPUT class가

B이면 (HOLD,PURGE)로 지정된다.

만약 OUTPUT class에 해당하는 DISP가 [OUTclass] 섹션에 정의되어 있지 않

으면 디폴트 값으로 (PURGE,PURGE)가 사용된다.

[OUTclass]

A=WRITE,WRITE

B=HOLD,PURGE

OUTPUTQ에 들어있는 OUTPUT들은 프린트되어야 할 것들과 인터널 리더를 통

해 처리되어 JOB으로 다시 submit 되어야 할 것들이 있다.

인터널 리더를 통해 처리되는 OUTPUT들은 OUTPUT DISPOSITION이 WRITE

또는 KEEP이고, print.conf [INTRDR] 섹션에 등록되어 있으면 OUTPUT

CLASS에 상관없이 무조건 인터널 리더에 의해 submit 된다.

프린트되어야 할 OUTPUT들은 OUTPUT DISPOSITION이 WRITE 또는 KEEP일

때 OUTPUT class 정보를 print.conf [PRINTERn]섹션에 등록된 class 정보와

비교하여 정보가 맞으면 프린트된다.

[PRINTERn] 섹션에 등록된 CLASS 정보가 SYSOUT의 OUTPUT CLASS를 포

함하고 있으면, ofrpmsvr은 [PRINTERn]에 설정된 명령어와 공유 라이브러리를

사용하여 외부 프린터 솔루션에 데이터와 프린트 리소스 정보를 전달한다.

Internal Reader

인터널 리더는 Online CICS 또는 배치 프로그램이 JOB을 TJES로 submit 할 수

있도록 하는 모듈이다. OpenFrame 상에서 동작하는 모든 JOB은 인터널 리더를

통해 submit 할 수 있다.

인터널 리더를 사용하기 위해서는 DD 문에 SYSOUT=(out_class,INTRDR)와 같

이 기술하여, DD에 저장된 내용이 인터널 리더로 출력하도록 한다.



다음 예제는 인터널 리더 사용법을 보여준다.

###########################################################################

## IEBEDT05 - iebedit SYSUT1 JCL and extract RMSTEP1 only. ##

## then submit it to intrdr ##

###########################################################################

//IEBEDT05 JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1)

//IEBEDT EXEC PGM=IEBEDIT

//SYSIN DD *

EDIT START=,TYPE=INCLUDE

/*

//SYSUT2 DD SYSOUT=(A,INTRDR)

//SYSUT1 DD DATA

INTERNAL READER로 submit 하고자 하는 JCL 내용

/*

//

위 JCL은 SYSUT1 DD로 주어진 JCL을 SYSUT2로 복사하여 SYSUT2를 CLASS

A의 인터널 리더로 출력하는 JOB이다.

위와 같이 JCL에 USER와 PASSWD가 기술되지 않은 경우, 인터널 리더는

tjes.conf [INTRDR] 섹션에 설정된 계정을 이용하여 JCL을 submit 한다.

제6장 TJESMGR 명령어



tjesmgr는 JOB과 TJES를 관리하는 기능뿐만 아니라 데이터 셋과 관련한 작업과

SPOOL 백업 기능 등을 수행한다.

tjesmgr는 TACF 또는 OS 사용자로 로그인을 해야 하며, submit할 JCL에 따로

사용자가 파라미터로 등록되어 있지 않다면, 로그인된 사용자는 JOB을 submit하

는 사용자가 된다.

tjesmgr는 tjesmgr에 접속한 후 tjesmgr 실행창에서 명령어를 수행하는 것이 일반

적이지만, UNIX 시스템의 명령어 라인에서 하나의 명령어씩 실행하는 것도 가능

하며, 실행 방법은 tjesmgr –h를 통해서 확인을 할 수 있다.

tjesmgr 실행방법

$ tjesmgr -i[ USERID[ [GROUPNAME] ]][/PASSWORD] [command]

tjesmgr 사용방법 조회

$ tjesmgr -h

tjesmgr 버전 정보 조회

$ tjesmgr -v

다음은 UNIX 명령어 라인에서 PS(Print Screen)를 실행하는 예이다.

$ tjesmgr –iUSERNAME/PASSWORD ps n=TEST

다음의 예는 선행 명령어가 필요한 경우로써 명령어 처리를 할 수 없다.

$ tjesmgr –iUSERNAME/PASSWORD

$ PODD JOB00001 di=1

PSJOB 또는 POSPOOL이 먼저 실행되어야 PODD 명령을 실행할 수 있다. 따라

서 명령어 라인에서 위의 예제는 실행할 수 없다.

참고: 자세한 내용은 “PODD (Print Output DD Information)” 명령어를 참고한다.



6.1 JOB 실행 명령어

JOB을 submit하고 JOB의 상태를 변경할 수 있는 명령어들이다.

RUN

RUN(R) {JCLFILE}

[node=NODENAME]

[step=restart STEP]

[cat=USERCATALOG]

입력 파라미터에 따라서 JOB을 submit한다.

- {JCLFILE}

JCL 이름 또는 UNIX 파일경로를 지정해 주거나 DATASET(member) 형식으

로 지정할 수 있다. JCLFILE을 DATASET(member) 형식으로 설정할 때 데이

터 셋이 사용자 카탈로그에 등록되어 있다면 cat=USERCATALOG를 지정한다.

- [node=NODENAME]

NODENAME을 지정한 경우 원하는 노드에서 JOB을 수행하도록 submit 할

수 있다.

NODENAME을 지정하지 않은 경우 tjesmgr.conf [DEFAULT_OPTION]

섹션의 DEFAULT_RUNNING_NODE에 설정된 값에 따라서 현재 노드에서만

JOB을 수행할 수 있도록 할지 아니면, 전체 노드 중 아무 노드에서나 JOB

을 수행할 수 있도록 할지를 결정한다.

- [step=restart STEP]

restart STEP을 지정하게 되면 JCL에 지정된 STEP부터 JOB이 실행된다.

submit을 하게 되면 JOB은 START 상태로 JOBQ에 쌓이고 PS 명령어를 통

해서 JOBQ에 쌓인 JOB을 확인할 수 있다.



START

START JOBID[|n=JOBNAME]

입력된 JOBID 또는 JOBNAME에 해당하는 JOB들의 상태를 HOLD 상태에서

START 상태로 바꾼다.

HOLD 상태의 JOB들에 대해서만 START 명령어가 유효하다.

HOLD

HOLD JOBID[|n=JOBNAME]

입력된 JOBID 또는 JOBNAME에 해당하는 JOB들의 상태를 START 상태에서

HOLD 상태로 바꾼다. HOLD 상태의 JOB은 스케줄링이 되지 않는다.

START 상태의 JOB들에 대해서만 유효하다.

CANCEL

CANCEL JOBID[|n=JOBNAME]

입력된 JOBID 또는 JOBNAME에 해당하는 JOB들을 제거(purge)한다.

HOLD 상태이거나 START 상태의 JOB들에 대해서만 유효하다.

SUSPEND

SUSPEND JOBID[|n=JOBNAME]

입력된 JOBID 또는 JOBNAME에 해당하는 JOB들의 상태를 WORKING 상태에

서 SUSPEND 상태로 바꾼다. 즉, 실행중인 JOB을 일시 정지시킨다.

WORKING 상태의 JOB들에 대해서만 유효하다.



RESUME

RESUME JOBID[|n=JOBNAME]

입력된 JOBID 또는 JOBNAME에 해당하는 JOB들의 상태를 SUSPEND 상태에

서 RESUME 상태로 바꾼다. 즉, 일시 정지된 JOB을 다시 실행시킨다.

SUSPEND 상태의 JOB들에 대해서만 유효하다.

STOP

STOP JOBID[|n=JOBNAME]

입력된 JOBID 또는 JOBNAME에 해당하는 JOB들의 상태를 WORKING 상태에

서 STOP 상태로 바꾼다. 즉, 실행중인 JOB을 중지시킨다.

RESUME 상태이거나 WORKING 상태의 JOB들에 대해서만 유효하다.

REMOVE

REMOVE JOBID[|n=JOBNAME]

입력된 JOBID 또는 JOBNAME에 해당하는 JOB들을 제거한다.

DONE, ERROR, STOP, FLUSH 상태의 JOB들에 대해서만 유효하다.

OUTQUEUEPURGE

OUTQUEUEPURGE(OR) JOBID[|on=OUTNO]

입력된 JOBID 또는 OUTNO에 해당하는 JOB들의 OUTPUT들을 OUTPUTQ에서

제거한다. OUTNO는 POLIST나 POJOB 명령어로 출력되는 OUTPUTID의 숫자를

말한다.

참고: OUTPUT에 대한 자세한 내용은 “5.1 OUTPUT”을 참고한다.



INQUEUEclass

INQUQUEclass(IC) JOBID[|n=JOBNAME] c=class

입력된 JOBID 또는 JOBNAME에 해당하는 JOB들의 class을 변경한다.

HOLD 상태이거나 START 상태인 JOB들에 대해서만 유효하다.

주로 해당 class의 runner가 전부 할당되어 있어서 대상 JOB을 바로 실행하지

못하는 경우에 사용하게 된다.

6.2 JOB/OUTPUT 명령어

JOB을 submit한 후의 JOB 진행 상태와 결과 그리고 OUTPUT 관련 정보를 볼

수 있는 명령어들이다.

PS (Print Screen)

PS [n=JOBNAME]

PS [c=class] [s=STATUS] [rc=retcode] [node=NODENAME]

PS [from JOBID] [[c=class] [s=STATUS] [rc=retcode] [node=NODENAME]]

PS JOBstatus

입력 파라미터의 조건에 해당하는 JOBQ에 있는 JOB들에 대한 JOBNAME,

JOBID, CLASS, STATUS, RC, NODE, JCL 리스트를 보여준다.

JOBQ상의 JOB에 대한 디스플레이 정보는 다음과 같다.

정보 설명

JOBNAME 디스플레이 대상 JOB의 JOBNAME이다.

JOBID 디스플레이 대상 JOB의 JOBID이다.

CLASS 디스플레이 대상 JOB의 CLASS이다.

STATUS 디스플레이 대상 JOB의 현재 STATUS이다.

RC 디스플레이 대상 JOB의 리턴코드이다.

NODE JOB이 실행된 노드명이다.

JCL JOB이 기술되어있는 JCL 이름이다.

[표 6-1] PS 디스플레이 정보



참고: CLASS, STATUS, RETCODE, NODENAME과 같은 순서로 조건을 주어야 한다.

올바른 예) PS c=A, s=W, rc=0

틀린 예) PS s=W, c=A → 파싱 에러 발생

PSJOB (Print Screen JOB detail information)

PSJOB(PSJ) JOBID

입력된 JOBID에 해당하는 JOB에 대한 상세 정보를 출력한다. 만약, 대상 JOB의

상태가 WORKING인 경우에는 상세 정보를 주기적으로 업데이트해서 출력한다.

JOB에 대한 디스플레이 정보는 다음과 같다.

정보 설명

JOBID 디스플레이 대상 JOB의 JOBID이다.

NODE NAME JOB이 실행된 노드명이다.

JOB NAME 디스플레이 대상 JOB의 JOBNAME이다.

JOB CLASS 디스플레이 대상 JOB의 CLASS이다.

JOB STATUS 디스플레이 대상 JOB의 현재 STATUS이다.

DONE, ERROR, FLUSH인 경우 괄호( )안에 JOB의 리

턴 값이 들어간다.

JOB PRTY 디스플레이 대상 JOB의 우선순위이다.

JCLRUNNER INDEX JOB이 실행된 runner index이다. Runner slot에 대한

정보는 PSJCLRUN에서 확인할 수 있다.

JOB WAIT 디스플레이 대상 JOB 상태가 WORKING 중에 WAIT

하고 있는 이유이다.

JOB USER 디스플레이 대상 JOB을 submit한 USER이다.

JCL PATH 디스플레이 대상 JOB의 JCL 경로를 나타낸다.

TIME STAMP JOB의 submit, start, end 시간을 나타낸다.

RES USAGE 해당 JOB의 리소스 사용량을 나타낸다.

PROCESS - 프로세스 총 사용시간

CPU - CPU 총 실행시간

CPU ?% - working중인 프로세스의 CPU 점유율로, 해

당 JOB 상태가 WORKING 중인 경우만 나타난다.

MEM ?Kb - working중이 프로세스의 메모리 크기로,



정보 설명

해당 JOB 상태가 WORKING인 경우만 나타난다.

STEP LIST 디스플레이 대상 JOB의 STEP별 정보를 보여준다.

[???]: STEP name

START : STEP 시작시간

RC - STEP의 리턴코드

CPU - STEP에서 CPU 이용시간

/ ??s - STEP의 총 소요시간

SPOOL LIST 디스플레이 대상 JOB의 SPOOL LIST를 보여준다.

POSPOOL의 디스플레이 정보와 동일하다.

OUTPUT

PROCESSING STATUS

대상 JOB의 OUTPUT 처리에 대한 내용을 나타낸다.

[표 6-2] PSJOB 디스플레이 정보

WORKING중인 JOB의 경우의 디스플레이 정보는 다음과 같다.

정보 설명

[STEPNAME] CURRENT

PROCESSING

현재 처리하고 있는 STEP을 나타낸다.

DDNAME JOBID(DSNAME)

R:? W:?

R: 해당 데이터 셋의 읽기 시도 횟수이다.

W: 해당 데이터 셋의 쓰기 시도 이다.

[표 6-3] PSJOB – 모니터링 디스플레이 정보

PSIO (Print Screen Input/Output information)

PSIO JOBID

입력된 JOBID에 해당하는 JOB의 데이터 셋 I/O 횟수를 보여준다.

데이터 셋 I/O 디스플레이 정보는 다음과 같다.

정보 설명

DDNAME JCL에 기술된 DD 이름이다.

DSNAME 데이터 셋 이름이다.

RTV (Retrieved count) STEP별 데이터 셋들의 검색된 횟수이다.



정보 설명

INS (Inserted count) STEP별 데이터 셋들의 추가된 횟수이다.

UPD (Updated count) STEP별 데이터 셋들의 업데이트된 횟수이다.

DEL (Deleted count) STEP별 데이터 셋들의 삭제된 횟수이다.

[표 6-4] PSIO – 데이터 셋 I/O 디스플레이 정보

PO (Print Output status)

PO

JOBID별 OUTPUT 상태를 보여준다.

JOBID별 OUTPUT 상태에 대한 디스플레이 정보는 다음과 같다.

정보 설명

JOBID 디스플레이 대상 JOBID이다.

OUTPUT STATUS 디스플레이 대상 OUTPUT 상태이다.

[표 6-5] PO – OUTPUT 상태 디스플레이 정보

POLIST (Print Output detail LIST)

POLIST

OUTPUT 리스트들의 상세 정보를 보여준다.

OUTPUT 리스트에 대한 디스플레이 정보는 다음과 같다.

정보 설명

OUTPUTID 디스플레이 대상 OUTPUT ID이다.

JOBID 디스플레이 대상 JOBID이다.

JOBNAME 디스플레이 대상 JOB 이름이다.

DDID 디스플레이 대상 DD에 부여된 ID이다.

DDNAME JCL에 기술되었던 DD 이름이다.

CLS 디스플레이 대상 OUTPUT의 CLASS이다.



정보 설명

(OUTPUT class)

ST

(OUTPUT STATUS)

OUTPUT 상태이다.

FORMS 디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.

CHARS 디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.

FORMDEF 디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.

PAGEDEF 디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.

WRITER 디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.

[표 6-6] POLIST – OUTPUT 리스트 디스플레이 정보

참고: DDID, FORMS, CHARS, FORMDEF, PAGEDEF, WRITER들은 PRINT 관련 정보들이

다. 이에 대한 자세한 내용은 “제4장 SPOOL과 OUTPUT Processing”을 참고한다.

POJOB (Print Output of JOB)

POJOB(POJ) JOBID

입력된 JOBID에 해당하는 JOB의 OUTPUT 정보를 보여준다.

JOB의 OUTPUT에 대한 디스플레이 정보는 다음과 같다.

정보 설명

OUTPUTID 디스플레이 대상 OUTPUT ID이다.

DDID 디스플레이 대상 DD에 부여된 ID이다.

DDNAME JCL에 기술되었던 DD 이름이다.

CLS 디스플레이 대상 OUTPUT CLASS이다.

ST OUTPUT 상태이다.

FORMS 디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.

CHARS 디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.

FORMDEF 디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.

PAGEDER 디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.

WRITER 디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.

[표 6-7] POJOB – OUTPUT 디스플레이 정보



참고: POJOB의 디스플레이 정보는 POLIST의 디스플레이 정보와 동일하다.

POSPOOL (Print Output SPOOL of JOB)

POSPOOL JOBID

입력된 JOBID에 해당하는 JOB의 SPOOL 정보를 보여준다.

SPOOL에 대한 디스플레이 정보는 다음과 같다.

정보 설명

NO DDINDEX로 PODD 명령 시에 입력 파라미터로 사용된다.

STEP 해당 SPOOL이 생성된 STEP 이름이다.

DDNAME 해당 SPOOL의 DDNAME이다.

SIZE 해당 SPOOL의 크기이다.

DSNAME 해당 SPOOL의 데이터 셋 이름이다.

[표 6-8] POSPOOL – SPOOL 디스플레이 정보

관련 환경설정 tjesmgr.conf [DEFAULT_OPTION] SPOOL_LIST={ALL|EXIST|GTZERO}

SPOOL_LIST는 SPOOL을 보여줄 조건을 설정한다..

PODD (Print Output DD Information)

PODD JOBID di=DDINDEX[|dn=DDNAME]

입력된 JOBID와 DDINDEX 또는 DDNAME에 해당하는 SPOOL을

tjesmgr.conf [DEFAULT_OPTION] VIEWER에서 설정한 뷰어로 열어준다.

JOBID만 준 경우 대상 JOB의 SPOOL을 모두 열어준다.

PODD 명령어를 사용하기 위해서는 PSJOB이나 POSPOOL 명령이 선행되어야

한다.

관련 환경설정 tjesmgr.conf [DEFAULT_OPTION] VIEWER

SPOOL을 열수 있는 뷰어를 지정한다.



PSHISTORY (Print Screen of JOB History)

PSHISTORY(PSH)

PSHISTORY 명령을 실행하면 입력 창이 뜨고, 사용자로부터 입력 받은 조건에

해당하는 내용을 찾아 뷰어로 보여준다. 아무런 조건도 주지 않은 경우 전체 로

그를 보여준다.

사용자에게 다음의 파라미터에 대한 입력을 요구한다.

파라미터 설명

USERID JOB을 submit한 userid를 설정한다.

DATE 날짜의 범위를 지정한다.

OPERATION SUBMIT, EXECUTE, SUSPEND, RESUME, FINISH,

REMOVE 중에서 조건을 설정한다.

JOBID JOBID를 설정한다.

[표 6-9] PSHISTORY – 입력 파라미터

참고: 자세한 내용은 “JOB Logging”를 참고한다.

관련 환경설정 tjesmgr.conf [DEFAULT_OPTION] VIEWER

PODD 관련 환경 설정을 참고한다.

tjes.conf [LOG] JOBLOG

해당 환경파일에 설정되어 있는 로그 파일에서 검색한다.

ofsys.conf [DIRECTORY] TEMP_DIR

검색한 내용을 임시로 기록할 위치이다.



6.3 INITIATOR 명령어

JOB의 실행을 위한 TJES 환경에 관련된 명령어들이다.

BOOT

BOOT [node=NODENAME]

전체 노드의 TJES를 부트한다.

NODENAME을 준 경우 대상 노드만을 부트한다.

부트가 된 노드에서는 JOB을 실행할 수 있다. 즉, runner slot에 JOB을 할당할 수

있게 된다.

SHUTDOWN

SHUTDOWN [node=NODENAME]

전체 노드의 TJES를 다운시킨다.

NODENAME을 준 경우 대상 노드만을 다운시킨다.

다운을 하게 되면 비어있는 runner slot들을 모두 down 상태로 변경하여 추가적

인 JOB의 스케줄링을 제한하고 WORKING 중인 runner slot들은 JOB이 끝나는

대로 down 상태로 변경한다.

참고: 자세한 사항은 “PSJCLRUN(PSR)”을 참고한다.

NODESTATUS(NODEST)

NODESTATUS(NODEST)

전체 노드의 상태를 보여준다.



전체 노드에 대한 상태 디스플레이 정보는 다음과 같다.

정보 설명

NODENAME 노드명이다.

OBMJINIT_STATUS obmjinit 서버의 상태이다. (Active, Downed)

BOOT_STATUS TJES의 부트상태이다. (Booted, Not booted)

[표 6-10] NODESTATUS – 노드 정보

PSJCLRUN(PSR)

PSJCLRUN(PSR) [node=NODENAME]

해당 노드의 runner slot 상태를 보여준다.

NODENAME을 주지 않은 경우 자기 노드의 runner slot 상태를 보여준다.

Runner slot에 대한 디스플레이 정보는 다음과 같다.

정보 설명

IDX Runner 인덱스이다.

JCLRUNACTIVE(RA), JCLRUNINACTIVE(RI),

JCLRUNclass(RC)에서 사용된다

SLOTNAME tjes.conf [INITDEF] 환경설정에 정의된 runner slot 이

름이다.

STATUS Runner slot의 상태이다. (Active, Inactive, Downed)

class 이 runner slot에 할당되어있는 class들이다.

JOBID,

JOBNAME,

JOBclass, PID

Runner slot에 할당된 JOB에 대한 정보들이다.

해당 runner slot의 class나 STATUS를 RA, RI, RC나

SHUTDOWN 등의 명령으로 바꾸는 경우, 대상 runner slot

에 JOB이 할당되어있으면 나중에 바뀔 것이라는 메시지가

나타난다.

예) STATUS will be [DOWNED] after JOB finished

[표 6-11] PSJCLRUN – runner 상태 정보



관련 환경설정 tjes.conf [NODEINFO] NODENAME

자기 노드를 찾을 때 사용된다.

tjes.conf [INITDEF]

Runner slot들의 기초설정을 한다.

JCLRUNACTIVE(RA)/JCLRUNINACTIVE(RI)

JCLRUNACTIVE(RA)/JCLRUNACTIVE(RI) i=INDEX,,, [node=NODENAME]

명령어 라인에서 입력 받은 runner slot의 상태를 Active에서 Inactive로 또는

Inactive에서 Active로 변경한다. 바뀐 정보는 PSJCLRUN을 통해 확인할 수 있다.

인덱스는 여러 개를 지정하거나 또는 범위를 지정할 수도 있다.

형식: i=INDEX,,,

NODENAME을 지정하지 않은 경우 자기 노드의 runner slot 상태를 변경한다.

다음은 JCLRUNACTIVE, JCLRUNINACTIVE 명령 사용시 범위 값을 지정하는 방

법에 대한 예를 보여준다.

$ RA i=0,1,2,3

$ RI i=0-9


현재 노드를 찾을 때 사용된다.

JCLRUNclass(RC)

JCLRUNclass(RC) i=INDEX,,, cs=classes [node=NODENAME]

해당 runner slot의 class를 입력으로 받은 class로 변경한다.



인덱스는 여러 개를 지정하거나 또는 범위를 줄 수도 있다.

형식: i=INDEX,,,

NODENAME을 지정하지 않은 경우 자기 노드의 class 설정을 변경한다.

다음은 JCLRUNclass 명령을 사용하여 범위 값과 class를 지정하는 방법에 대한

예를 보여준다.

$ JCLRUNclass i=0,1,2,3 cs=A

$ RC i=0-9 cs=AB


자기 노드를 찾을 때 사용된다.

PSclass(PSC)

PSclass(PSC)

Class별로 JOB들의 상태 카운트를 보여준다.

Class별로 JOB들의 NODE, CLASS, HOLD, START, WORIKING, SUSPEND,

DONE, STOP, ERROR, FLUSH 카운트를 보여준다.

6.4 데이터 셋 명령어

데이터 셋을 조회하거나 생성, 삭제 또는 복사하기 위한 명령어들이다.

참고: USERCATALOG와 관련해서는 tjesmgr의 “SETCAT 명령어” 및 “데이터 셋 안내서”

의 “USERCATALOG ALIAS”를 참고한다.



PSCATALOG(PSCAT)

PSCATALOG(PSCAT) [DSN] [CAT=USERCATALOG]

입력 조건에 해당하는 카탈로그에 등록되어있는 데이터 셋 리스트를 보여준다.

- [DSN]

데이터 셋의 전체 이름이 아닌 prefix를 입력한다. prefix로 시작하는 모든 데

이터 셋이 디스플레이 대상이 된다.

- [CAT=USERCATALOG]

사용자 카탈로그에 등록되어 있는 데이터 셋을 찾아서 보여준다.

카탈로그에 등록되어 있는 데이터 셋 디스플레이 정보는 다음과 같다.

정보 설명

CATALOG NAME 검색한 데이터 셋이다.

VOLUME 디스플레이 대상 데이터 셋이 들어있는 볼륨이다.

ENTRY 디스플레이 대상 데이터 셋의 타입이다.

데이터 셋의 타입에는 Non-VSAM, CLUSTER, AIX, PATH,

GDG, UCAT, ALIAS 등이 있다.

DSORG 디스플레이 대상 데이터 셋의 DSORG이다.

Non-VSAM 데이터 셋인 경우만 PO, PS, DA 등의

organization을 나타낸다.

NVSM 디스플레이 대상 데이터 셋의 종류이다.

Non-VSAM 데이터 셋인 경우만 PDS, SDS, GDS 등의 데

이터 셋 종류를 나타낸다.

VSAM 디스플레이 대상 데이터 셋의 종류이다.

VSAM 데이터 셋인 경우만 KSDS, RRDS 등의 데이터 셋

종류를 나타낸다.

[표 6-12] PSCATALOG - 데이터 셋 디스플레이 정보



SETCATALOG(SETCAT)

SETCATALOG(SETCAT) [USERCATALOG]

입력으로 받은 USERCATALOG를 기본 카탈로그로 하여 데이터 셋 관련 명령어

에서 사용한다. USERCATALOG를 주지 않은 경우 마스터 카탈로그를 기본 카탈

로그로 한다.

다음과 같이 지정하고 PSCAT, PSDS 등을 실행했을 때 USERCATALOG를 지정

하지 않은 경우 TAPECAT을 기본 카탈로그로 해서 정보를 보여준다.

$ SETCAT TAPECAT

카탈로그의 지정 순위

1. parameter user catalog

2. SETCAT으로 지정된 user catalog

3. Dataset alias에 따른 user catalog

4. master catalog

PSDS

PSDS DSN [CAT=USERCATALOG] [MEM=member_name_prefix]

입력에 해당하는 데이터 셋의 상세정보를 보여준다.

- DSN

상세정보를 조회하고자 하는 데이터 셋 이름을 입력한다.

- [CAT=USERCATALOG]

USERCATALOG에 등록되어있는 데이터 셋을 찾아서 보여준다.

- [MEM=member_name_prefix]

멤버가 있는 데이터 셋의 경우 MEM을 지정한 경우 해당 멤버를 검색해서

보여준다.



데이터 셋에 대한 상세한 디스플레이 정보는 다음과 같다.

정보 설명

DSN 디스플레이 대상 데이터 셋 이름이다.

VOLUME 디스플레이 대상 데이터 셋이 들어있는 볼륨이다.

TYPE 디스플레이 대상 데이터 셋의 타입이다.


RECFM 디스플레이 대상 데이터 셋의 RECFM이다.

LRECL(A) 디스플레이 대상 데이터 셋의 평균 레코드 길이이다.

LRECL(M) 디스플레이 대상 데이터 셋의 최대 레코드 길이이다.

BLKSIZE 디스플레이 대상 데이터 셋의 블록 크기이다.

DATASIZE 디스플레이 대상 데이터 셋의 실제 크기이다.

테이프 데이터 셋의 경우 압축 상태로 되어있는데,

DATASIZE 크기는 압축이 되지 않았을 때의 크기이다.

OWNERID 디스플레이 대상 데이터 셋의 실제 파일의 소유자이다.

DEVTYPE 디스플레이 대상 데이터 셋의 디바이스 타입이다.

테이프 데이터 셋인 경우 ‘TAPE Device’라고 나타난다.

CREATION 디스플레이 대상 데이터 셋의 생성일자이다.

EXPIRATION 디스플레이 대상 데이터 셋의 만료일자이다.

LAST REFERENCE

DATE(TIME)

디스플레이 대상 데이터 셋을 마지막으로 조회하거나 수

정한 날짜와 시간이다.

SMS STRORAGE

class

디스플레이 대상 데이터 셋 생성시 참고한 SMS 스토리

지 클래스이다.

SMS

MANAGEMENT

class

디스플레이 대상 데이터 셋 생성시 참고한 SMS 관리 클

래스이다.

SMS DATA class 디스플레이 대상 데이터 셋 생성시 참고한 SMS 데이터

클래스이다.

[표 6-13] PSDS – 데이터 셋 디스플레이 정보



멤버가 있는 데이터 셋의 경우 해당 멤버에 대한 디스플레이 정보이다.

정보 설명

Name 디스플레이 대상 멤버의 이름이다.

Owner 디스플레이 대상 멤버의 실제 파일의 소유자이다.

Size 디스플레이 대상 멤버의 실제 파일크기이다.

ExpireDT 디스플레이 대상 멤버의 만기일이다.

LastAccessed 디스플레이 대상 멤버를 마지막으로 접근한 시간이다.

[표 6-14] PSDS – 멤버 디스플레이 정보

PSENTRY

PSENTRY DSN [CAT=USERCATALOG] [MEM=member_name_prefix]

입력에 해당하는 데이터 셋의 상세정보를 보여준다.

PSDS와 다른 점은 GDG, PATH, ALIAS와 같이 볼륨이 없고 카탈로그에만 등록되

어있는 데이터 셋들에 대한 정보도 보여준다.

- DSN

상세정보를 조회하고자 하는 데이터 셋 이름을 입력한다.

- [CAT=USERCATALOG]

USERCATALOG에 등록되어있는 데이터 셋을 찾아서 보여준다.

- [MEM=member_name_prefix]

멤버가 있는 데이터 셋의 경우 MEM을 지정한 경우 해당 멤버를 검색해서

보여준다.

데이터 셋에 대한 상세한 디스플레이 정보는 다음과 같다.

정보 설명

DSN 디스플레이 대상 데이터 셋 이름이다.

VOLUME 디스플레이 대상 데이터 셋의 볼륨이다.

TYPE 디스플레이 대상 데이터 셋의 타입이다.


RECFM 디스플레이 대상 데이터 셋의 RECFM이다.



정보 설명

NONVSAM 디스플레이 대상 데이터 셋의 종류이다.

Non-VSAM 데이터 셋인 경우만 PDS, SDS, GDS 등의 데이

터 셋 종류를 나타낸다.

VSAM 디스플레이 대상 데이터 셋의 종류이다.

VSAM 데이터 셋인 경우만 KSDS, RRDS 등의 데이터 셋

종류를 나타낸다.

OWNERID 디스플레이 대상 데이터 셋의 실제 파일의 소유자이다.

GDG LIMIT 디스플레이 대상 데이터 셋이 GDG 데이터 셋인 경우에 나

타나는 것으로 생성 한계 개수이다.

CREATION 디스플레이 대상 데이터 셋의 생성일자이다.

EXPIRATION 디스플레이 대상 데이터 셋의 만료일자이다.

[표 6-15] PSENTRY – 데이터 셋 디스플레이 정보

멤버가 있는 데이터 셋의 경우 해당 멤버에 대한 디스플레이 정보이다.

정보 설명

Name 디스플레이 대상 멤버의 이름이다.

Owner 디스플레이 대상 멤버의 실제 파일의 소유자이다.

Size 디스플레이 대상 멤버의 실제 파일크기이다.

ExpireDT 디스플레이 대상 멤버의 만기일이다.

LastAccessed 디스플레이 대상 멤버를 마지막으로 접근한 시간이다.

[표 6-16] PSENTRY - 멤버 디스플레이 정보

DATASETCREATE(DSCREATE)

DATASETCREATE(DSCREATE)

명령을 실행을 하면 사용자 입력 창이 나타나고 사용자로부터 입력 받은 조건에

해당하는 Non-VSAM 데이터 셋을 생성한다.

참고: VSAM 데이터 셋을 생성하기 위해서는 IDCAMS 유틸리티를 사용해야 하며, 이에 대

한 자세한 내용은 “유틸리티 참고 안내서”의 “IDCAMS”를 참고한다.



입력 파라미터

파라미터 설명

NAME 생성할 Non-VSAM 데이터 셋의 이름으로 반드시 입력해

야 하는 필수항목이다.

MEMBER GDG 에 대해서만 member를 줄 수 있다.

값은 -1, 1, 2와 같이 숫자로 준다.

VOLUME Non-VSAM 데이터 셋이 저장될 볼륨의 위치이다.

디폴트 값은 UNIT에 따르거나 SMS 규칙을 따른다.

아무런 값도 지정되지 않은 경우 디폴트 값으로 설정된

볼륨에 따른다.

DSORG 데이터 셋의 DSORG를 지정한다. 디폴트 값은 PS이다.

RECFM 데이터 셋의 레코드 포맷을 지정한다. 디폴트 값은 FB이

다.

UNIT 데이터 셋의 UNIT을 지정한다. 디폴트 값은 VOLUME에

따른다.

입력을 받은 UNIT과 VOLUME이 서로 일치하지 않는 경

우 에러가 발생한다.

참고: “데이터 셋 안내서”의 “UNIT”과 “VOLUME”을 참고한다.

LRECL 데이터 셋의 최대 레코드 길이를 지정한다. 디폴트 값은

80이다.

BLKSIZE 데이터 셋의 블록 크기를 지정한다. 디폴트 값은 4096이

다

EXPIRATION DATE 데이터 셋의 만기일을 지정한다. 디폴트 값은 99991231

이다.

USER CATALOG 사용자 카탈로그를 지정한다.

사용자 카탈로그를 지정하지 않는 경우 마스터 카탈로그

또는 ALIAS에 따른 카탈로그로 한다.

주의: 생성 관련 명령은 tjesmgr의 SETCATALOG 명령어의 옵션

을 따르지 않는다.

[표 6-17] DATASETCREATE – 입력 파라미터



DATASETDELETE(DSDELETE)

DATASETDELETE(DSDELETE) [FORCE] DSN [CAT=USERCATALOG]

입력에 해당하는 Non-VSAM 데이터 셋들을 삭제한다.

- [FORCE]

삭제하고자 하는 Non-VSAM 데이터 셋의 실제 파일이 존재하지 않는 경우에

도 에러를 발생시키지 않고 카탈로그에 있는 정보만을 삭제한다.

- DSN

삭제 대상 데이터 셋 이름 또는 삭제 대상 데이터 셋의 prefix + ***을 입력

한다.

예) AAA.BBB, AAA,BCC, AAA.BBB.CCC

위와 같이 세 개의 데이터 셋이 있는 경우,

DSDELETE AAA.BBB를 하면 AAA.BBB만이 삭제가 된다.

DSDELETE AAA.BBB***을 하면 AAA.BBB와 AAA.BBB.CCC가 삭제가 된다.

DSDELETE AAA.B***을 하면 AAA.BBB, AAA.BCC, AAA.BBB.CCC가 삭제가

된다.

- [CAT=USERCATALOG]

USERCATALOG에 등록되어있는 Non-VSAM 데이터 셋을 찾아서 삭제한다.

DATASETCOPY(DSCOPY)

DATASETCOPY(DSCOPY) DSN(from) [CAT=FROM_USERCATALOG]

DSN(to) [CAT=TO_USERCATALOG]

[VOLUME [UNIT]]

입력에 해당하는 from 데이터 셋을 to 데이터 셋으로 복사한다.

from 데이터 셋을 지정할 때 기본 카탈로그가 맞지 않은 경우

FROM_USERCATALOG를 지정해줘야 해당 데이터 셋을 찾을 수 있다.

VOLUME과 UNIT은 to 데이터 셋에 대한 정보이다.



참고: 기본 카탈로그에 대한 내용은 “SETCATALOG(SETCAT)” 명령어를 참고한다.

DATASETEXPORT(DSEXPORT)

DATASETEXPORT(DSEXPORT) DSN(from) FILEPATH(to) [CAT=USERCATALOG]

입력에 해당하는 Non-VSAM 데이터 셋을 외부로 반출한다.

- DSN(from)

외부로 반출한 Non-VSAM 데이터 셋을 입력한다.

- FILEPATH(to)

Non-VSAM 데이터 셋을 반출할 UNIX 절대 파일경로를 입력한다.

- [CAT=USERCATALOG]

CAT을 지정한 경우 USERCATALOG에 있는 Non-VSAM 데이터 셋들을 찾아

서 처리한다.

DATASETIMPORT(DSIMPORT)

DATASETIMPORT(DSIMPORT) FILEPATH(from)

외부로 반출한 파일을 읽어서 데이터 셋으로 복원한다.

명령을 실행을 하면 사용자 입력 창이 나타나고 사용자로부터 입력 받은 조건에

해당하는 Non-VSAM 데이터 셋으로 복원한다

- FILEPATH(from)

Non-VSAM 데이터 셋이 저장되어 있는 UNIX 절대 파일경로를 입력한다.

입력 파라미터

입력 파라미터들로 외부로 반출할 때의 데이터 셋 이름과 형식을 바꿀 수 있다.

이미 등록이 되어있으면 기존의 데이터 셋을 오버라이드한다.

참고: 입력 파라미터에 대한 설명은 “DATASETCREATE(DSCREATE)”를 참고한다.



GDGCREATE

GDGCREATE

명령을 실행하면 입력을 받을 창이 뜨고 입력 조건에 맞게 GDG 데이터 셋을 생

성한다.

입력 파라미터

파라미터 설명

NAME 생성할 GDG 데이터 셋의 이름으로 반드시 입력해야

하는 필수항목이다.

GENERATION LIMIT GDS 데이터 셋의 limit로 반드시 입력해야 하는 필수항

목이다.

EXPIRATION 생성할 GDG 데이터 셋의 만기일을 지정한다.

USER CATALOG GDG 데이터 셋이 등록될 사용자 카탈로그를 지정한다.

사용자 카탈로그를 지정을 하지 않는 경우 마스터 카탈

로그 또는 ALIAS에 따른 카탈로그에 등록된다.

주의: 생성 관련 명령은 tjesmgr의 SETCATALOG 명령어의 옵션을 따르지 않는다.

[표 6-18] GDGCREATE – 입력 파라미터

GDGDELETE

GDGDELETE DSN [CAT=USERCATALOG]

입력에 해당하는 GDG 데이터 셋을 삭제한다.

- DSN

삭제할 GDG 데이터 셋을 입력한다.

- [CAT=USERCATALOG]

USERCATALOG에 등록되어 있는 GDG 데이터 셋을 찾아서 삭제한다.

GDG 멤버가 있는 경우에는 4031 에러가 발생한다. 이런 경우 GDG 멤버를 먼

저 삭제해야 한다.



RECATALOG(RECAT)

RECATALOG(RECAT)

명령을 실행하면 사용자 입력 창이 나타나고 입력조건에 해당하는 Non-VSAM 데

이터 셋을 리카탈로그한다.

실제 파일만 존재하고 카탈로그에 등록되어있지 않은 Non-VSAM 데이터 셋을 카

탈로그에 등록할 때, 또는 이미 카탈로그에 등록되어있는 Non-VSAM 데이터 셋

의 카탈로그 내용을 바꾸고 싶을 때 사용한다.

입력 파라미터

파라미터 설명

NAME 생성할 Non-VSAM 데이터 셋의 이름으로 반드시 입력

해야 하는 필수항목이다.

MEMBER GDG 에 대해서만 member를 줄 수 있다.

값은 -1, 1, 2와 같이 숫자로 준다.

VOLUME Non-VSAM 데이터 셋이 저장될 볼륨의 위치이다.

디폴트 값은 UNIT에 따르거나 SMS 규칙을 따른다.

아무런 값도 지정되지 않은 경우 디폴트 값으로 설정

된 볼륨에 따른다.

DSORG 데이터 셋의 DSORG를 지정한다. 디폴트 값은 PS이

다.

RECFM 데이터 셋의 레코드 포맷을 지정한다. 디폴트 값은 FB

이다.

UNIT 데이터 셋의 UNIT을 지정한다. 디폴트 값은 VOLUME

에 따른다.

입력을 받은 UNIT과 VOLUME이 서로 일치하지 않는

경우 에러가 발생한다.

참고: “데이터 셋 안내서”의 “UNIT”과 “VOLUME”을 참고한다.

LRECL 데이터 셋의 최대 레코드 길이를 지정한다. 디폴트 값

은 80이다.

BLKSIZE 데이터 셋의 블록 크기를 지정한다. 디폴트 값은 4096

이다

EXPIRATION DATE 데이터 셋의 만기일을 지정한다. 디폴트 값은



파라미터 설명

99991231이다.

USER CATALOG 사용자 카탈로그를 지정한다.

사용자 카탈로그를 지정하지 않는 경우 마스터 카탈로

그 또는 ALIAS에 따른 카탈로그로 한다.

주의: 생성 관련 명령은 tjesmgr의 SETCATALOG 명령어의 옵션을 따르지 않는다.

CURRENT CATALOG 디스플레이 대상 데이터 셋이 현재 등록되어있는 카탈

로그를 지정한다.

[표 6-19] RECATALOG – 입력 파라미터

UNCATALOG(UNCAT)

UNCATALOG(UNCAT) DSN [CAT=USERCATALOG]

입력에 해당하는 데이터 셋들을 언카탈로그한다.

- DSN

Non-VSAM 데이터 셋의 전체 이름이 아닌 prefix를 입력한다. prefix로 시작

하는 모든 Non-VSAM 데이터 셋이 언카탈로그의 대상이 된다.

- [CAT=USERCATALOG]

USERCATALOG에 등록되어있는 Non-VSAM 데이터 셋을 찾아서 언카탈로그

한다.

PSLOCK(PSL)

PSLOCK(PSL) {JOBID|DSN=[datasetname|prefix]} [CAT=USERCATALOG]

입력에 해당하는 데이터 셋의 lock 정보를 보여준다.

- {JOBID|DSN=[datasetname|prefix]}

DSN에는 데이터 셋의 전체 이름 또는 prefix를 입력한다. 해당 데이터 셋이

나 prefix로 시작하는 모든 데이터 셋의 lock 정보를 보여준다.



- [CAT=USERCATALOG]

USERCATALOG_NAME:DATASET_NAME을 찾아서 보여준다.

디스플레이 정보:

정보 설명

옵션(1,2 컬럼) 1: Lock을 요청하고 있는 상태이면 R이 보여진다.

2: Lock을 건/요청한 프로세스가 실행 중이면 * 이 보여진

다. 프로세스의 NODE가 다른 경우는 보여지지 않는다.

PID Lock을 건/요청한 프로세스 아이디이다.

JOBID Lock을 건/요청한 JOBID이다.

NODEID Lock을 건/요청한 노드이다.

LOCKTYPE 요청한 lock의 타입이다.

Exclusive: 대상 데이터 셋을 수정하기 위해서 사용하는 타

입으로 다른 JOB에서 Lock을 공유할 수 없다.

Shared: 대상 데이터 셋을 조회하기 위해서 사용하는 타입

으로 다른 곳과 lock을 공유할 수 있다.

CATALOG_DSN 요청한 Lock의 이름이다.

Lock 이름은 “USERCATALOG_NAME:DATASET_NAME”으로

구성되어 있다.

[표 6-20] PSLOCK – 디스플레이 정보

LOCKCLEAR

LOCKCLEAR JOBID

| p=PID,,,[node=NODENAME]

| node=NODENAME ALL

| ALL

입력에 해당하는 데이터 셋의 lock을 제거한다.

비정상적으로 JOB이 종료되어 lock이 풀리지 않은 경우에 사용한다.

PID는 여러 개를 줄 수 있다.

node=NODENAME ALL인 경우 이 노드의 전체 lock을 제거한다.

ALL만을 준 경우 모든 lock을 제거한다



다음은 A 노드의 프로세스 1000, 1001, 1002, 1003번에 걸린 모든 lock을 제거하

는 예를 보여준다.

$ LOCKCLEAR p=1000,1001,1002,1003 node=A

PSVOLUME(PSV)

PSVOLUME(PSV)

명령을 실행하면 볼륨에 대한 정보를 보여준다.

볼륨에 대한 디스플레이 정보는 다음과 같다.

정보 설명

SER 볼륨 시리얼이다.

TOTAL(MB) 전체 볼륨 크기이다

USAGE(%) 현재 볼륨 사용율이다.

FREE(MB) 사용할 수 있는 볼륨 크기이다.

PATH 볼륨의 UNIX 파일경로이다.

[표 6-21] PSVOLUME – 볼륨 디스플레이 정보

관련 환경설정: volume.conf

volume에 대한 설정이다.

참고: volume.conf 환경설정에 관한 자세한 내용은 “데이터 셋 안내서”를 참고한다.



6.5 SPOOL 백업 명령어

SPOOL을 백업하기 위해 사용하는 명령어들이다.

SPOOLBACKUP(SPBK)

SPOOLBACKUP(SPBA) dt=YYYYMMDDHHMISS [START_JOBID,END_JOBID]

입력에 해당하는 SPOOL들을 백업한다.

- dt=YYYYMMDDHHMISS

dt는 JOB을 submit한 시간을 입력한다. 주어진 시간 이전에 submit된 JOB의

SPOOL에 대해서 백업한다.

- [START_JOBID,END_JOBID]

백업하려는 JOBID의 범위를 입력한다.

BACKUP을 하고 나면 SPOOL들은 tjes.conf [SPOOL] BACKUP에 정의된 디

렉터리에 압축 파일로 저장된다.

관련 환경설정 tjes.conf [SPOOL] BACKUP

백업한 SPOOL들을 저장할 디렉터리이다.

tjes.conf [SPOOL] TEMP_DIR

백업한 SPOOL의 내용을 보고 싶을 때 복원할 디렉터리이다.

SPOOLBACKUPLIST(SPBL)

SPOOLBACKUPLIST date=YYYYMM[|YYYY]

입력 조건에 해당하는 년/월에 백업된 날짜들을 보여준다.

- date=YYYYMM[YYYY]

date는 검색할 년/월이다.



디스플레이 정보

BACKUP_DATE: SPOOL이 백업된 날짜를 보여준다.

SPOOLPS(SPPS)

SPOOLPS(SPPS) date=YYYYMMDD [n=JOBNAME]

| n=JOBNAME

입력 조건에 해당하는 날짜에 백업된 SPOOL 리스트를 보여준다.

- date=YYYYMMDD

date는 백업된 날짜이다.

- n=JOBNAME

찾고자 하는 JOBNAME의 prefix이다.


정보 설명

NO 디스플레이 대상 SPOOL 리스트 번호이다.

이 SPOOL 리스트 번호는 SPOOLRESTORE,

SPOOLPSJOB, SPOOLPSIO 등에서 사용된다.

JOBNAME 디스플레이 대상 JOB NAME이다.

JOBID 디스플레이 대상 JOB ID이다.

submit_TIME 디스플레이 대상 JOB이 submit 되었던 날짜이다.

BACKUP_DATE 디스플레이 대상 JOB이 백업되었던 날짜이다.

[표 6-22] SPOOLPS – 백업된 SPOOL 리스트 디스플레이 정보

SPOOLRESTORE(SPRE)

SPOOLRESTORE(SPRE) i=INDEX

입력 조건에 해당하는 백업된 SPOOL의 내용을 조회할 수 있게 임시 디렉터리에

복원한다.

SPOOLPS를 먼저 실행한 후에 실행을 해야 한다.



관련 환경설정 tjes.conf [SPOOL] BACKUP

SPOOL이 백업될 디렉터리이다.

tjes.conf [SPOOL] TEMP_DIR

SPOOL의 내용을 보기 위해 임시로 복원하게 될 디렉터리이다.

SPOOLCLEAR(SPCL)

SPOOLCLEAR(SPCL) i=INDEX

입력조건에 해당하는 임시 디렉터리에 복원된 SPOOL을 제거한다.

즉, SPOOLRESTORE을 통해서 복원되었던 SPOOL들을 제거한다.

SPOOLPSIO(SPPSIO)

SPOOLPSIO(SPPSIO) i=INDEX

입력조건에 해당하는 복원된 JOB의 I/O 정보를 보여준다.

SPOOLPS과 SPOOLRESTORE 명령어를 우선 실행해야 SPOOLPSIO 명령어의

결과를 볼 수 있다.

디스플레이 정보:

STEP별 데이터 셋들의 읽기/쓰기 횟수를 보여준다.

SPOOLPSJOB(SPPSJ)

SPOOLPSJOB(SPPSJ) i=INDEX

입력조건에 해당하는 복원된 JOB의 상세 정보를 보여준다.

SPOOLPS과 SPOOLRESTORE 명령어를 우선 실행해야 SPOOLPSJOB 명령어

의 결과를 볼 수 있다.




PSJOB의 JOB이 끝났을 때의 정보와 동일하다. 단, OUTPUT에 대한 정보는 출

력되지 않는다.

SPOOLPOSPOOL(SPPOSPOOL)

SPOOLPOSPOOL(SPPOSPOOL) i=INDEX

입력조건에 해당하는 복원된 JOB의 SPOOL 정보를 보여준다.

SPOOLPS과 SPOOLRESTORE 명령어를 우선 실행해야 SPOOLPOSPOOL 명령

어의 결과를 볼 수 있다.


POSPOOL의 정보와 동일하다.

SPOOLPODD(SPPODD)

SPOOLPODD(SPPODD) i=INDEX [spdi=DDINDEX]

입력조건에 해당하는 복원된 JOB의 SPOOL을 설정한 뷰어로 열어준다.

- i=INDEX

INDEX만 준 경우 대상 SPOOL을 설정한 뷰어로 모두 열어준다.

- [spdi=DDINDEX]

DDINDEX에 해당하는 SPOOL을 설정한 뷰어로 모두 열어준다.

참고: SPOOLPODD 명령은 PODD 명령과 동일하므로 자세한 내용은 “PODD (Print Output DD Information)" 명령을 참고한다.



6.6 기타 명령어

HELP

HELP [command]

입력 명령어에 해당하는 명령어 사용법을 보여준다.

명령어를 주지 않은 경우 모든 명령어의 사용법을 보여준다.

CLS

CLS

명령을 실행하면 tjesmgr의 화면을 제거한다.

VERSION

VERSION

명령을 실행하면 TJES의 버전정보를 보여준다.

LICENSE

LICENSE PRODUCT[|FILEPATH]

입력에 해당하는 라이선스 파일의 정보를 보여준다.

- PRODUCT

PRODUCT로는 현재 TJES, TSAM, TACF, HIDB, OSC, OSI가 있다.

- [FILEPATH]

라이선스 파일의 이름만을 입력한 경우 환경파일에 등록되어 있는 라이선스

디렉터리에서 해당 라이선스 파일을 찾아서 정보를 보여준다.



관련 환경설정 ofsys.conf [DIRECTORY] LICENSE_DIR

라이선스 디렉터리이다.

EDIT

EDIT FILENAME

입력한 FILENAME을 지정한 에디터로 열어준다.

FILENAME은 절대경로를 주어야 한다.

관련 환경설정 tjesmgr.conf [DEFAULT_OPTION] EDITOR

파일을 열수 있는 에디터를 지정한다.

PSPRINT(PSP)

PSPRINT(PSP)

명령을 실행하면 환경파일에 등록되어 있는 프린터의 정보를 보여준다.

환경파일에 등록되어 있는 프린터에 대한 디스플레이 정보는 다음과 같다.

정보 설명

PRINTER_NAME 프린터 이름이다.

class OUTPUT class들이다.

PRINTER_COMMAND 프린터를 실행할 명령어이다.

DRIVER_PATH 프린터 라이브러리가 있는 경로이다.

[표 6-23] PSPRINT – 프린터 디스플레이 정보

관련 환경설정 print.conf [PRINTERn]

프린터 설정을 한다.

제7장 환경설정



TJES를 실행시키기 위해서는 TMAX 환경과 TJES 환경을 사전에 설정해야 한다.

7.1 TMAX 설정

TMAX 서버들로 운영되는 OpenFrame에서 TJES를 실행하기 위해서는 TMAX의

설치 및 환경설정은 필수적이다.

OpenFrame 최초 설치 시 TMAX 환경은 자동으로 디폴트 값으로 등록되며, 디폴

트 값을 변경하고자 할 경우 다음의 단계로 다시 설정할 수 있다.

1. TMAX 서버의 구동을 중지한다.

$ tmdown

2. $TMAXDIR/config/XXX.m 의 파일을 열어서 환경을 재설정한다.

3. 변경한 환경을 적용한다.

$ cfl -i $TMAXDIR/config/XXX.m

4. TMAX 서버를 재구동한다.

$ tmboot

참고: 상기 예제에서 XXX.m 환경파일의 변경 방법에 대해서는 “TMAX 설치 안내서”를 참

고하기 바란다.



TMAX server

TJES의 운영을 위해서 다음의 서버들이 구동되어있어야 한다.

서버명 역할

obmjschd JOB 스케줄러

obmjinit JOB Initiator

obmjmsvr JOB 매니져

obmjhist JOB 히스토리

obmjspbk JOB SPOOL 백업

ofrpmsvr 프린터 매니저

[표 7-1] TJES 서버

서버명 역할

ofrsasvr 보안 관리

ofrlmsvr,ofrlmwrk Lock 관리

ofruisvr 사용자 인터페이스 담당 서버

ofrcmsvr 콘솔 관리

[표 7-2] TJES 관련 서버

OpenFrame 설치시 TJES 서버와 TJES 관련 서버들은 자동으로 등록된다.

다음은 tmax 환경에 등록된 내용들이다.

obmjschd SVGNAME = svg_domain,MIN = 1, MAX = 1, SVRTYPE=UCS,

CLOPT="-o $(SVR)$(DATE).out -e $(SVR)$(DATE).err"

obmjinit SVGNAME = svg_node1,MIN = 1, MAX = 1, SVRTYPE=UCS,


obmjmsvr SVGNAME = svg_node1,




obmjhist SVGNAME = svg_node1,


obmjspbk SVGNAME = svg_domain, MIN = 1, MAX = 1,


ofrpmsvr SVGNAME = svg_domain, MIN = 1, MAX = 1, SVRTYPE=UCS,


ofrsasvr SVGNAME = svg_domain, MIN = 1, MAX = 1, SVRTYPE=UCS,


ofrlmsvr SVGNAME = svg_domain, MIN = 1, MAX = 1, SVRTYPE=UCS,


ofrlmwrk SVGNAME = svg_domain, MIN = 1, MAX = 1,


ofruisvr SVGNAME = svg_node1,


ofrcmsvr SVGNAME = svg_domain, MIN = 1, MAX = 1, SVRTYPE=UCS,


위의 내용 중에 SVGNAME=svg_domain은 전체 노드 중에 한곳에서만 구동되어

야 한다는 것을 의미하고, MIN=1,MAX=1로 되어있는 설정은 하나의 서버만이 구

동되어야 함을 의미한다.

따라서 obmjschd의 경우는 전체 노드 중에 한곳에서만, 하나의 서버만으로 구

동이 되고, obmjinit의 경우는 노드마다, 하나의 서버만으로 구동이 된다.

또한, obmjmsvr의 경우는 노드마다, 여러 개의 서버들이 구동이 될 수 있다.



상기 서버들을 구동시키고 정상적으로 서버가 구동되고 있는지 확인하는 방법은

다음과 같다.

TMAX 서버 구동

$ tmboot

TMAX 서버들의 상태 조회

$ tmadmin

$$1 node (tmadm): si

다음은 TMAX 서버가 정상적으로 동작하고 있는지 결과를 보여주는 화면으로

status가 RDY이면 서버가 구동중인 상태이고, NRDY이면 서버가 다운된 상태를

나타낸다.

------------------------------------------------------------------------

clh svrname (svri) status count qcount qpcount emcount

------------------------------------------------------------------------

0 ofrsasvr ( 4) RDY 0 0 0 0

0 ofrlmsvr ( 5) RDY 0 0 0 0

0 ofrlmwrk ( 6) RDY 0 0 0 0

0 ofrdmsvr ( 7) RDY 0 0 0 0

0 ofrdsedt ( 8) RDY 0 0 0 0

0 ofrcmsvr ( 9) RDY 0 0 0 0

0 ofruisvr ( 10) RDY 0 0 0 0

0 obmjmsvr ( 11) RDY 0 0 0 0

0 obmjschd ( 12) RDY 0 0 0 0

0 obmjinit ( 13) RDY 1 0 0 0

0 obmjhist ( 14) RDY 0 0 0 0

0 obmjspbk ( 15) RDY 0 0 0 0

0 ofrpmsvr ( 16) RDY 0 0 0 0

TMAX 서버 구동 중지

$ tmdown



tmadmin을 통해 TMAX 서버를 조회한 경우, 서버가 NRDY 상태인 경우에는 서

버 로그를 통해서 원인을 파악할 수 있다. 서버 로그는 TMAX에서 생성되는 파

일로 $TMAXDIR/log/ulog 디렉터리에서 찾아볼 수 있다.

참고: TMAX 관련 내용은 “TMAX 안내서”를 참고하기 바란다.

7.2 TJES 설정

OpenFrame TJES의 환경 파일은 설치 시 디폴트 값으로 또는 설치 중의 사용자

입력 값으로 자동 설정되므로 별도의 설정을 필요로 하지 않는다.

OpenFrame 환경 파일 형식

OpenFrame에서 사용하는 환경 파일들은 OpenFrame 설치 시 지정한

$OPENFRAME_HOME/config 디렉터리에 있다.

환경파일의 형식은 다음과 같다.

xxx.conf

[SECTION NAME]

FIELD NAME=value

TJES 환경 파일

tjes.conf 환경파일은 다음으로 구성되어 있다

아래의 환경을 변경하고 이를 시스템에 적용하려면 기본적으로 TMAX 서버를 다

운시켰다가 재기동해야 한다.

[NODEINFO]

NODENAME = value

NODELIST = value1;value2...



노드에 대한 정보를 설정하는 섹션이다

- NODENAME

현재 노드의 이름을 설정한다

- NODELIST

전체 노드의 이름들을 설정한다. 각 노드 간의 구분은 세미콜론(;)으로 한다

참고: [NODEINFO] 섹션에서 설정되는 노드명은 TMAX 환경파일의 *NODE에 지정된 노드

명과 동일해야 한다.

OpenFrame 최초 설치 시 NODELIST에는 하나의 이름만 설정되어 있으며,

OpenFrame에서 멀티 노드를 사용하려는 경우 추가된 노드의 이름을 NODELIST

에 설정해 주어야 한다.

예) A 노드 만을 사용하는 경우 - A 노드의 환경

[NODEINFO]

NODENAME=nodeA

NODELIST=nodeA

예) A, B 노드를 사용하는 경우 - A 노드의 환경

[NODEINFO]

NODENAME=nodeA

NODELIST=nodeA;nodeB

예) A, B 노드를 사용하는 경우 - B 노드의 환경

[NODEINFO]

NODENAME=nodeB

NODELIST=nodeA;nodeB

[SYSTEM_DS]

JOBQ=SYS1.JOBQ

TJES_STAT=SYS1.JESST

OUTPUTQ_BASE=SYS1.OUTPUTQ

OUTPUTQ_PJOBID=SYS1.OUTPUTQ.PJOBID



OUTPUTQ_PJOBNAME=SYS1.OUTPUTQ.PJOBNAME

TJES에서 사용하는 시스템 데이터 셋을 설정하는 섹션이다

시스템 데이터 셋들은 OpenFrame 최초 설치 시에 자동으로 생성된다.

- JOBQ

JOBQ로 사용될 데이터 셋의 이름을 설정한다.

- TJES_STAT

JESST로 사용될 데이터 셋의 이름을 설정한다.

- OUTPUTQ_BASE

OUTQ로 사용될 데이터 셋의 이름을 설정한다.

- OUTPUTQ_PJOBID

OUTQ로 사용될 데이터 셋에 대해 JOBID로 Alternative Indexing을 한 데이

터 셋에 부여할 이름을 설정한다.

- OUTPUTQ_PJOBNAME

OUTQ로 사용될 데이터 셋에 대해 JOBNAME으로 Alternative Indexing을 한

데이터 셋에 부여할 이름을 설정한다.

참고: 위의 데이터 셋 이름들은 초기 설정 값 그대로 사용할 것을 권장하지만, 변경하기를 원할 경우 IDCAMS 유틸리티를 통해서 바꿀 데이터 셋을 생성해주어야 한다.

[JOBDEF]

STARTNUM=1

ENDNUM=9999

FULL_WARNING=value

TJES에서 JOB을 관리하기 위한 섹션이다.

- STARTNUM,ENDNUM

JOBID의 시작과 끝을 설정함과 동시에 JOBQ의 크기가 설정된다.

기본 설정이 STARTNUM=1, ENDNUM=9999로 설정되어있기 때문에 JOBID

는 JOB00001부터 JOB09999까지 생성이 되고 JOBQ에는 9999개까지의

JOB 정보가 들어갈 수 있다.



- FULL_WARNING

JOBQ가 몇 퍼센트까지 사용될 경우 JOBQ가 꽉 찬다는 경고 메시지를 보여

줄 지를 설정한다.

STARTNUM과 ENDNUM의 변경 값을 시스템에 적용하려면 tjesinit 툴을 사용하

여 초기화 작업을 다시 해주어야 한다.

초기화 작업을 할 경우 JOBQ의 모든 정보가 삭제되므로 현재 JOBQ의 정보를

보관하고자 하는 경우 SPOOL BACKUP 명령을 통해 SPOOL을 백업해놓기를 권

장한다. (SPOOL 백업에 대한 내용은 2.6 JOB의 BACKUP을 참고한다.)

참고: 초기화에 관한 내용은 “툴 참고 안내서”의 “tjesinit”을 참고한다.

[SCHEDULING]

DUPL_JOBNAME=YES|NO

PRTYJECL=YES|NO

PRTYJCL=YES|NO

PRTYHIGH=value

PRTYLOW=value

PRTYRATE=1440

INTERVAL=10

TJES에서 JOB 스케줄링에 관한 섹션이다.

- DUPL_JOBNAME

동일한 JOBNAME을 갖는 JOB을 동시에 실행할지 여부를 결정한다.

디폴트 값은 YES이다.

- PRTYJECL

submit한 JCL에서 JECL의 PRTY을 사용할지 여부를 결정한다.


- PRTYJCL

submit한 JCL에서 JCL의 PRTY을 사용할지 여부를 결정한다.




- PRTYHIGH,PRTYLOW

스케줄러에서 우선순위를 변경할 최대값을 결정한다.

최대값 보다 큰 우선순위는 에이징 처리를 하지 않는다.

- PRTYLOW

스케줄러에서 우선순위를 변경할 최소값을 결정한다.

최소값 보다 작은 우선순위는 에이징 처리를 하지 않는다.

- PRTYRATE

하루에 에이징을 몇번할지 rate를 설정한다.

86400(24시간)/prtyrate 초 후에 JOB의 우선순위를 1 증가시킨다.

이로서 일정 시간 동안 작업이 실행되지 못하는 JOB들의 우선순위를 높여서

오래 기다린 JOB 일수록 빨리 실행될 수 있다.

- INTERVAL

스케줄러가 스케줄링하는 간격을 초단위로 설정한다. 디폴트 값은 10이다.

간격이 너무 길면 START된 JOB들이 빨리 실행되지 않고, 너무 짧게 설정되

면 스케줄링 처리를 자주 함으로써 부하가 생길 수 있다.

[RESOURCE]

SHMKEY=values

TJES에서 사용할 UNIX 자원에 대한 섹션이다.

- SHMKEY

TJES에서 obmjinit와 tjclrun간 통신을 위한 공유 메모리 키를 설정한다.

[PROCLIB]

JCLLIB=datasetname[:datasetname...]

PROCnn=datasetname[:datasetname...]

JOB을 실행하기 위해 필요한 데이터 셋에 대한 섹션이다.

- JCLLIB

JCL들을 찾을 기본 PDS 데이터 셋들이다.

사용자들이 사용할 JCL들을 JCLLIB에 저장해 놓으면 JCL의 이름만으로



JOB을 submit할 수 있다.

만약 데이터 셋들에 동일한 JCL이 있는 경우 기술한 순서에 따라 우선순위

가 부여된다. 데이터 셋을 구분하기 위해 콜론(:)을 사용한다

- PROCnn

JCL 내에서 PROC나 INCLUDE들을 찾을 때 기본으로 찾게 될 PDS 데이터

셋으로 00부터 99까지 설정할 수 있다. 데이터 셋을 구분하기 위해 콜론(:)을

사용한다.

[DYNAMIC_LIBRARY]

TEMPLIB=datasetname

- TEMPLIB

사용자 라이브러리의 변경이 있을 때 기존 라이브러리를 임시로 저장할

PDS 데이터 셋 이름이다.

참고: 상세한 내용은 “툴 참조 안내서”의 “dlupdate”와 “dlclean"을 참고한다.

[LOG]

JOBLOG = $(OPENFRAME_HOME)/log/job.log

TJES에 관한 로그파일에 대한 섹션이다.

- JOBLOG

JOB의 상태변화를 기록하는 JOBLOG의 filepath를 지정한다.

로그에 대한 분석은 TJESMGR의 JOBHISTORY를 통해서 할 수 있다.

(TJESMGR 명령어 중 “PSHISTORY (Print Screen of JOB History)”를 참고한다.)

[SPOOL]

SPOOL_VOLUME_SER=VSPOOL

BACKUP=$OPENFRAME_HOME/spbackup

TEMP_DIR=$OPENFRAME_HOME/sptemp

TJES의 SPOOL에 대한 섹션이다.

- SPOOL_VOLUME_SER

volume.conf에 지정된 SPOOL VOLUME SERIAL을 설정한다.



- BACKUP

BACKUP 기능 사용시 SPOOL 백업 데이터가 저장될 디렉터리를 설정한다.

- TEMP_DIR

백업된 SPOOL 데이터를 조회하고자 할 때 임시로 사용할 디렉터리를 설정

한다.

참고: 자세한 내용은 “2.6 JOB의 BACKUP”과 TJESMGR 명령어의 “SPOOLBACKUP(SPBK)”을 참고한다.

[OUTDEF]

USE_OUTPUTQ=YES

OUTNUM=8000

DATA_DIR=$OPENFRAME_HOME/outputq

- USE_OUTPUTQ

OUTPUT Processing을 수행할지 여부를 지정한다.

- OUTNUM

OUTPUTQ의 크기를 설정한다.

- DATA_DIR

SPOOL에서 해당 OUTPUT의 데이터를 복사할 디렉터리 지정한다.

[OUTclass]

#class=[normal disp][,abnormal disp] [: default lrecl]

[OUTclass]

SYSOUT의 OUTPUT class에 따라 디폴트 OUTPUT DISPOSITION과 디폴트 lrecl

을 설정할 수 있다.

- #class

OUTPUT class가 A인 SPOOL 데이터 셋은 JCL에서 OUTPUT DISPOSITION

을 기술하지 않았을 때, 디폴트 OUTPUT DISPOSITION으로 (WRITE,WRITE)

을 사용한다. 그리고, LRECL을 기술하지 않았으면 120으로 사용한다.



OUTclass를 지정하는 예는 다음과 같다.

A=WRITE,WRITE:120

[INTRDR]

HOLD=[YES|NO]

NODENAME=nodename

USERNAME=username

GROUPNAME=groupname

PASSWORD=password

ENPASSWD=encrypted password

TJES의 인터널 리더에 대한 섹션이다.

- HOLD

인터널 리더로 JOB을 submit할 때 JOB의 상태를 HOLD로 할지 여부를 설

정한다.

- NODENAME

인터널 리더로 JOB을 submit할 때 JOB을 실행할 노드를 설정한다.

- USERNAME

인터널 리더로 JOB을 submit할 때 TACF인증을 받을 사용자를 설정한다.

- GROUPNAME

인터널 리더로 JOB을 submit할 때 TACF인증을 받을 사용자 그룹을 설정한

다.

- PASSWORD

인터널 리더로 JOB을 submit할 때 TACF인증을 받을 사용자 비밀번호를 설

정한다.

- ENPASSWD

인터널 리더로 JOB을 submit할 때 TACF인증을 받을 사용자 비밀번호를 암

호화해서 설정한다.

PASSWORD나 ENPASSWD는 하나만 설정해야 한다.



[INITDEF]

INITNUM=values

INITxxxx=name,classes,ACTIVE/INACTIVE

TJES의 runner의 초기 설정 값에 대한 섹션이다.

- INITNUM

전체 슬롯의 개수를 지정한 것이다.

- INITxxxx

슬롯의 번호에 따라서 슬롯의 이름, 슬롯이 사용할 JOB의 class들, 슬롯의

STATUS를 설정한다.

7.3 TJESMGR 설정

본 장에서는 tjesmgr에서 사용하는 tjesmgr.conf 환경파일에 대한 설명을 한다.

[DEFAULT_OPTION]

SPOOL_LIST=[ALL|EXIST|GTZERO]

EDITOR=value

VIEWER=value

DEFAULT_RUNNING_NODE=[MY|ANY]

tjesmgr의 명령어를 실행 시 참고하는 정보를 설정하는 섹션이다.

- SPOOL_LIST

ALL: 모든 SPOOL을 보여준다.

EXIST: SPOOL 파일이 존재하는 것만 보여준다.

GTZERO: SPOOL 파일 크기가 0보다 큰 것만 보여준다.

- EDITOR

파일을 열수 있는 에디터를 지정한다.

에디터를 지정하는 예는 다음과 같다.

EDITOR=vi &FILEPATH



- VIEWER

SPOOL을 열수 있는 뷰어를 지정한다.

뷰어를 지정하는 예는 다음과 같다.

VIEWER=vi –R &FILEPATH

참고: HP 또는 AIX 장비에서는 vi 만을 주는 경우 화면의 일부분부터 나오는 경우가 있다. 이런 경우 vi –w &ROWCOUNT –R &FILEPATH로 설정하면 모든 내용이 깨지지 않고 출력된다.

- DEFAULT_RUNNING_NODE

MY : JOB이 submit될 때 노드가 지정되지 않았을 경우 자기노드에서만 JOB

이 실행될 수 있도록 한다.

ANY : JOB이 submit될 때 노드가 지정되지 않았을 경우 어느노드에서나

JOB이 실행될 수 있도록 한다.

[DEFAULT_USER]

USERNAME=username

GROUPNAME=groupname

PASSWORD=password

tjesmgr를 실행 시 자동으로 로그인할 수 있는 정보를 설정하는 섹션이다.

[DEFAULT_USER] 섹션을 설정하면 tjesmgr를 실행할 때 이 섹션에 설정된 사용

자 정보로 로그인 한다.

- USERNAME

tjesmgr에 접속할 user를 설정한다.

- GROUPNAME

tjesmgr에 접속할 user가 속한 groupname을 설정한다.

- PASSWORD

tjesmgr에 접속할 user의 비밀번호를 설정한다.



[TACF]

ASKGRPNM=YES|NO

ALLOWED_USER=

CHECK_CMDAUTH=YES|NO

tjesmgr에서 TACF의 환경을 설정하는 섹션이다.

- ASKGRPNM

NO로 설정하면 tjesmgr 실행 시에 groupname은 묻지 않는다.

- ALLOWED_USER

ALLOWED_USER에 설정된 USER만이 tjesmgr에 로그인 할 수 있다.

- CHECK_CMDAUTH

YES로 설정하면 tjesmgr의 명령어에 대한 권한을 확인한다.

참고: TACF에 관한 자세한 내용은 “TACF 안내서”를 참고한다.

7.4 OUTPUT 설정

print.conf 환경파일 중에서 OUTPUT을 위한 설정에 대하여 설명한다

[PRINTER1]

CLASS=AB38

COMMAND=lpr

DRIVER_PATH=$OPENFRAME_HOME/lib/dfltprt.so

[PRINTER1]

PRINTER1 - PRINT9까지 설정할 수 있다.

- CLASS

PRINTER1에서 처리할 수 있는 OUTPUT의 OUTPUT class를 지정한다.

- COMMAND

외부 프린터 솔루션에 데이터와 정보 전달을 위한 명령어를 설정한다.



- DRIVER_PATH

외부 프린터 솔루션의 인터페이스를 위해 만들어진 공유 라이브러리의 경로

로써 프린터 솔루션마다 달라지므로 정확한 설정이 필요하다.

[INTRDR]

DRIVER_PATH=$OPENFRAME_HOME/lib/intrdr.so

- DRIVER_PATH: 인터널 리더 구동을 위해 만들어진 공유 라이브러리의 경로

를 기술한다.

7.5 TJCLRUN 설정

tjclrun이 동작하는 방식에 대한 설정파일인 tjclrun.conf를 설명한다.

[JOB]

CLASS=A

MSGCLASS=A

MSGLEVEL[1]=1

MSGLEVEL[2]=1

TJES에서 JOB을 처리하기 위해서 요구되는 최소한의 JCL JOB문의 파라미터가

생략된 경우 사용할 디폴트 값을 설정한다.

- CLASS={jobclass}

필수 설정항목이며 JOB문의 CLASS 파라미터가 생략된 경우 사용할 디폴트

JOB CLASS 값을 설정한다.

{jobclass}는 알파벳 A-Z, 숫자 0-9 중의 한 글자로 설정한다.

- MSGCLASS={msgclass}

필수 설정항목이며 JOB문의 MSGCLASS 파라미터가 생략된 경우 사용할 디

폴트 JOB MSGCLASS 값을 설정한다.

{msgclass}는 알파벳 A-Z, 숫자 0-9 중의 한 글자로 설정한다.



- MSGLEVEL[1]={msglevel_statement}

필수 설정항목이며 JOB문의 MSGLEVEL의 첫번째 서브 파라미터가 생략된

경우 사용할 디폴트 MSGLEVEL 값을 설정한다. {msglevel_statement}는 0 또

는 1 중 하나로 설정해야 한다. 0으로 설정하면 JCL 파싱 결과인 JCL parse

tree가 JOB SPOOL의 JESJCL에 출력되지 않는다. 1로 설정하면 JESJCL에

parse tree가 출력된다. 지정된 msglevel_statement에 따라 출력되는 정보의

구체적인 내용은 추후 변경될 수 있다.

- MSGLEVEL[2]={msglevel_message}

필수 설정항목이며 JCL JOB문에 MSGLEVEL의 두번째 서브 파라미터가 생

략된 경우 사용할 디폴트 MSGLEVEL 값을 설정한다. {msglevel_message}는

0 또는 1중 하나로 설정해야 한다. 0으로 설정하면 JOB SPOOL의 SYSMSG

에 데이터 셋 할당 등의 결과나 JOB 처리에 따른 로그 메시지가 출력되지

않는다. 1로 설정하면 데이터 셋 할당 등의 처리 결과 및 JOB 처리에 따른

로그 메시지가 출력된다. 어느 경우나 JOB의 비정상 종료를 나타내는 에러

메시지는 항상 출력된다. 지정된 msglevel_message에 따라 출력되는 로그

메시지의 구체적인 내용은 추후 변경될 수 있다.

[DDTAB]

DDTAB_MAX=1024

- DDTAB_MAX={number}

옵션 설정항목이며 tjclrun이 JOB을 실행함에 있어서 사용되는 JCL에서 (JCL

프로시저 포함) 처리 가능한 최대 JCL DD문의 개수를 설정한다.

예를 들어 DDTAB_MAX=1024라고 설정하면 INPJCL 및 해당 JOB에서 호출

되는 JCL 프로시저를 포함하여 1024개까지의 DD문만 하나의 JOB에서 사용

할 수 있다. 그 이상의 DD문이 존재하면 에러로 처리되고 JOB은 비정상 종

료 처리되며, SYSMSG 상에 에러 메시지 'No free DD entry in

ddtab'이 출력된다. 이 경우 DDTAB_MAX 값을 상향 조정하는 것을 고려해

야 한다. 디폴트 값은 512이다.



[SYSLIB]

BIN_PATH=${OPENFRAME_HOME}/bin:${OPENFRAME_HOME}/util:${COBDIR}/bin:/usr/local/bin:/bin

LIB_PATH=${OPENFRAME_HOME}/lib:${TB_HOME}/client/lib:${TMAXDIR}/lib:${COBDIR}/lib:${ORACLE_HOME}/lib:/usr/lib:/lib:/lib/i686:/usr/local/lib

COB_PATH=${COBPATH}

tjclrun이 실행하는 프로그램의 하위 배치 실행 프로그램이나 공유 라이브러리 등

을 찾는데 사용되는 디폴트 디렉터리들을 설정한다.

[SYSLIB] 섹션에는 가급적 고객사에서 공용으로 사용되는 디렉터리만 포함하고

특정 JOB이나 job step에서만 제한적으로 사용되는 프로그램을 포함하는 디렉터

리는 JCL에 JOBLIB이나 STEPLIB DD를 사용해서 지정하도록 하는 것이 좋다.

그렇게 하지 않은 경우 배치 프로그램의 로딩 작업 시 성능이 저하될 수 있다.

BIN_PATH, LIB_PATH, COB_PATH에 대한 설정을 하지 않으면 해당 사용자의 환

경변수가 내부적으로 대신 사용된다. 즉, BIN_PATH를 설정하지 않은 경우 환경

변수 PATH의 값이 BIN_PATH 값으로 설정된 것처럼 동작한다.

설정 값을 나타내는 {pathlist}는 절대 경로명으로 지정해야 한다. 여러 경로명의

리스트로 값을 설정하는 경우에는 각 경로명을 콜론(:)으로 구분한다. {pathlist}의

값이 길어지더라도 한 라인에 입력해야 한다. {pathlist}의 최대 길이는 4096 바이

트이다.

- BIN_PATH={pathlist}

옵션 설정항목이며, 환경변수 PATH에 해당하는 값으로, tjclrun이 실행하는 배

치 프로그램을 찾는 디폴트 디렉터리 경로명의 리스트를 설정한다. JCL에

JOBLIB이나 STEPLIB DD가 지정된 경우에는 먼저 JOBLIB이나 STEPLIB에

서 실행 파일을 찾아보고 JOBLIB이나 STEPLIB에 해당하는 위치에 실행 파

일이 존재하지 않는 경우에 BIN_PATH에 설정된 디렉터리들에서 실행 파일

을 찾는다.

- LIB_PATH={pathlist}

옵션 설정항목이며, 환경변수 LIBPATH(IBM AIX의 경우), SHLIB_PATH(HPUX

의 경우), LD_LIBRARY_PATH(SUNOS나 Linux의 경우)에 해당하는 값으로,

tjclrun이 실행하는 배치 프로그램에서 사용되는 공유 라이브러리를 찾는 기



본 디렉터리 경로명의 리스트를 설정한다. JCL에 JOBLIB이나 STEPLIB DD

가 지정된 경우에는 지정된 JOBLIB이나 STEPLIB에 해당하는 위치에서 필

요로 하는 공유 라이브러리가 있는지 먼저 찾아보고, 없으면 LIB_PATH에 설

정된 디렉터리들에서 공유 라이브러리를 찾는다.

- COB_PATH={pathlist}

옵션 설정항목이며, MFCOBOL에서 사용하는 환경변수 COBPATH에 해당하

는 값으로, tjclrun이 실행하는 코볼 프로그램에서 사용하는 코볼 프로그램용

공유 라이브러리나 서브 프로그램을 찾는 기본 디렉터리 경로명의 리스트를

설정한다. JCL에 JOBLIB이나 STEPLIB DD가 지정된 경우에는 지정된

JOBLIB 이나 STEPLIB에 해당하는 위치에서 필요로 하는 코볼 프로그램용

공유 라이브러리나 서브 프로그램을 먼저 찾아보고, 없으면 COB_PATH에 설

정된 디렉터리들에서 찾는다.

참고: Mainframe에서는 오브젝트에 대한 배치 프로그램이나 공유 라이브러리 등의 구분이 없는 반면 OpenFrame(UNIX)에서는 각각의 경우가 구분되어 있기 때문에 JCL에 사

용자가 지정한 JOBLIB이나 STEPLIB DD는 BIN_PATH, LIB_PATH, COB_PATH 모두

에 영향을 준다. 반면 tjclrun.conf에 BIN_PATH, LIB_PATH, COB_PATH를 별도로 나누어 지정할 수 있게 한 이유는 각 OpenFrame(UNIX)에서 배치 프로그램이나 공유 라이브러리 등의 오브젝트 타입 별로 찾아볼 디렉터리 공간을 별도로 설정하여 오브젝트를 좀

더 효율적으로 찾게끔 하기 위해서이다.

참고: 특정 UNIX 환경에서 (현재까지 알려진 바로는 IBM AIX 시스템) tjclrun에 setuid root 권한을 부여하고 설치하여 운영하는 경우 보안상의 이유로 운영 시스템 차원에서 tjclrun을 실행할 때 환경변수 LIBPATH를 클리어하는 문제가 있다. 이 경우에는 고

객사에 설치된 OpenFrame 환경 하에서 tjclrun을 직접 재링크(relink) 해주어야 한다. 또한 BIN_PATH, LIB_PATH, COB_PATH 설정들도 생략하지 말고 명시적으로 설정해

주어야 한다. 이와 관련된 좀 더 자세한 내용은 “보안”의 “setuid root tjclrun”를 참고

한다.

[PGM]

USE_PGMRTS00=NO

- USE_PGMRTS00={YES|NO}

옵션 설정항목이며, tjclrun이 유틸리티 프로그램 PGMRTS00을 이용하여 공

유 라이브러리로 컴파일된 배치 응용프로그램을 호출할지 여부를 설정한다.

NO로 설정하면 tjclrun은 실행파일로 컴파일된 프로그램만 호출할 수 있다.



YES로 설정하면 tjclrun은 지정된 프로그램이 실행파일이 아닌 경우

PGMRTS00 유틸리티를 호출하고 PGMRTS00이 공유 라이브러리로 컴파일

된 배치 프로그램을 동적으로 로딩하여 실행할 수 있도록 한다. 결과적으로

사용자 관점에서는 공유 라이브러리 형태로 컴파일된 배치 프로그램도 JCL

에서 호출할 수 있게 된다. 디폴트 값은 NO이다.

[ACCOUNT]

SETUID=NO

- SETUID={YES|NO}

옵션 설정항목이며, tjclrun 프로세스 및 tjclrun이 JOB을 위해서 호출하는 배

치 프로그램의 프로세스 소유자(owner userid)가 JCL JOB에 기술된 USER

파라미터의 값으로 수행되도록 할지 여부를 설정한다.

YES로 설정하는 경우 tjclrun 프로그램을 setuid root 권한을 부여하여 설치해

야 하며, JOB의 실행 중에 호출되는 프로그램은 JCL JOB문의 USER에 지정

된 사용자가 실행한 것으로 프로세스 어카운팅되며, JOB 실행 중에 생성되는

파일이나 기타 리소스에 대한 권한 검사(TACF 권한 검사와 별도로 OS에서

기본적으로 수행되는 권한 검사) 역시 JCL에 기술된 JOB USER에 대해서

행해진다.

NO로 설정한 경우 TJES 시스템을 부팅한 운영자, 특히 runner slot 프로세스

의 소유자가 tjclrun 및 job step에서 실행되는 배치 프로그램의 프로세스 소

유자로 사용된다. 이 경우 JCL JOB문의 USER 파라미터를 이용하여 JOB 별

로 다른 사용자가 수행하는 것으로 처리하는 방식은 지원되지 않는다. 모든

OS 레벨의 권한 체크는 운영자의 권한으로 수행되며 해당 JOB을 수행하는

프로세스의 소유자 역시 동일한 운영자의 OS userid로 어카운팅된다. 디폴트

값은 NO이다.

- USERID={userid}

옵션 설정항목이며, 위의 SETUID 설정을 YES로 설정한 경우에만 추가적으

로 사용되는 설정 값이다. {userid}를 지정하는 경우는 SETUID에서 YES로

설정한 경우의 동작을 수행하기는 하지만 JCL JOB문의 USER 파라미터에

지정된 사용자 대신에 항상 설정파일에 USERID={userid}에 지정된 사용자가

사용된다. 이 설정은 SETUID를 YES로 하면서 항상 특정 사용자로만 JOB을

실행하게 하려는 경우에 활용할 수 있다. USERID를 설정하지 않으면 사용되

지 않으며 디폴트 값은 없다.



[TACF]

CHECK_DSAUTH=NO

CHECK_UTAUTH=NO

- CHECK_DSAUTH={YES|NO}

옵션 설정항목이며, tjclrun의 TACF 지원 기능 중에서 데이터 셋에 대한

TACF 접근 권한 검사를 수행할지 여부를 설정한다. 디폴트 값은 NO이다.

- CHECK_UTAUTH={YES|NO}

옵션 설정항목이며, tjclrun의 TACF 지원 기능 중에서 주요 유틸리티 프로그

램에 대한 TACF 실행 권한 검사를 수행할지 여부를 설정한다. 디폴트 값은

NO이다.

[JCL]

IGNORE_TRAIL=YES

- IGNORE_TRAIL={YES|NO}

옵션 설정항목이며, JCL 파일의 마지막 부분이 JCL 문장이 아닌 경우는

Mainframe에서는 //SYSIN DD * 가 생략된 입력 스트림 데이터 셋으로 처리

된다.

그러나 OpenFrame 상에서는 마이그레이션 과정 중에 공백라인이나 불필요

한 라인들이 추가되는 경우가 빈번히 발생된다. 이러한 경우에 JCL 파일의

TRAIL(마지막 부분)을 //SYSIN DD *가 생략된 입력 스트림 데이터 셋으로 간

주할지 아니면 무시할지를 설정한다.

YES로 설정하면 TRAIL은 무시되어 버려지고, NO로 설정하면 TRAIL은

SYSIN DD *가 생략된 입력 스트림 데이터 셋으로 처리된다. 디폴트 값은

YES이다.

참고: 특별한 내용 없이 공백으로만 이루어진 TRAIL은 이 설정과 상관없이 항상 무

시된다.



[DEBUG]

PROFILE=NO

- PROFILE={YES|NO}

옵션 설정항목이며, tjclrun 자체의 성능을 조사하기 위한 실행 프로파일 정보

를 출력할지 여부를 지정한다. YES를 지정하면 tjclrun 인터널 로그에 주요

실행 단계별 시간정보를 포함하는 성능 분석을 위한 로그 메시지가 추가적으

로 출력된다. NO를 지정하면 해당 메시지가 출력되지 않는다. tjclrun 자체의

성능 문제를 분석하는 경우가 아니라면 YES로 설정하지 않을 것을 권장한다.

디폴트 값은 NO이다.

7.6 Return Code 설정

배치 프로그램의 종료코드 별로 JOB COND나 EXEC COND를 일으키는 예외상

황으로 볼지 여부를 설정하기 위한 환경 설정이다.

[PGM_NAME]

IKJEFT01=8-255

MYPGM1=8-255

MYPGM2=8,16-4096

...

다음과 같이 프로그램 이름별로 여러 개의 예외상황을 설정한다.

{pgmname}={rc_spec}

{pgmname}에 특정 프로그램 이름을 지정한다. {rc_spec}에는 해당 프로그램의 종

료코드 중에서 예외상황으로 간주해야 하는 종료코드를 나열한다.

종료 코드를 나열하는 방법은 다음과 같다.

rc_spec={[(RC|RC-RC),]...}

RC는 종료코드를 나타내는 0-4096 사이의 숫자이다.

예를 들면 "8,12,16-24"와 같은 형태로 {rc_spec}을 지정할 수 있다. 여러 개의 종

료코드를 콤마(,)로 구분하여 입력한다.



종료코드의 범위를 지정할 때는 하이픈(-)을 이용해서 나타낸다. 예를 들어

8,12,16-24라고 설정하면 8, 12 그리고 16부터 24 사이의 종료코드는 예외상황이

발생한 것으로 간주된다.

[PGM_TYPE]

COBOL=16-4096

PLI=1000,2000,3000

OTHER=16-255

ALL=8-255

다음과 같이 프로그램 종류별로 여러 개의 예외상황을 설정한다.

{pgmtype}={rc_spec}

{pgmtype}에 COBOL, PLI, OTHER, ALL을 지정할 수 있다. {rc_spec}을 지정하는

방법은 [PGM_NAME] 섹션에서 설명한 내용과 동일하다. [PGM_TYPE] 섹션에서

는 프로그램 종류별로 예외상황에 해당하는 종료코드를 지정한다.

{pgmtype} COBOL은 COBOL 컴파일러로 작성된 프로그램에 대해서 수행되는 종

료코드 검사를 나타낸다. {pgmtype} PLI은 PLI 컴파일러로 작성된 프로그램에 대

해서 수행되는 종료코드 검사를 나타낸다. {pgmtype} OTHER는 프로그램 종류가

알려지지 않은 기타 프로그램에 대한 종료코드 검사를 나타낸다. 일반적인 C언어

로 작성된 프로그램은 여기에 해당된다. {pgmtype} ALL에 지정한 조건은

rc.conf의 다른 설정에 의해서 예외상황이 만족되지 않는 경우에 항상 검사된

다.

예를 들어 COBOL 프로그램이 종료코드 8로 종료한 경우 위에 예시된

COBOL=16-4096에 의해서 예외상황이 만족되지 않는다. 이때 ALL이 설정되어

있는 경우는 추가적으로 ALL=8-255에 대해서 예외상황 검사가 수행되고 해당

STEP은 예외상황이 만족되는 것으로 처리된다. ALL 설정이 없는 경우는 예외상

황이 만족되지 않는 것으로 처리된다.

참고: {pgmtype} ALL에 의한 다른 예외상황(JOB CONDITION)이 만족되지 않는 경우에 추

가적으로 행해지는 예외상황 검사를 원하지 않는 경우는 ALL 설정을 하지 않도록 한다.

openframe tjes 안내서 - kr.tmaxsoft.com · resume.....96 stop ... compiler mf-cobol

Documents