openframe tjes 안내서 - tmaxsoft · 2019. 4. 9. · openframe 시스템의 vos3 jcl의 문법...

OpenFrame

TJES 안내서

OpenFrame/Batch for VOS3 2.0

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

Copyright Notice

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

대한민국 경기도 성남시 분당구 서현동 263 분당스퀘어(AK프라자) 12층 우)463-824

Restricted Rights Legend

All TmaxSoft Software (Tmax OpenFrame®) and documents are protected by copyright laws and the Protection

Act of Computer Programs, and international convention. TmaxSoft 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 transmitted, copied, deployed, or reproduced in any form or

by any means, electronic, mechanical, or optical, without the prior written consent of TmaxSoft Co., Ltd.

이 소프트웨어(Tmax OpenFrame®) 사용설명서의 내용과 프로그램은 저작권법, 컴퓨터프로그램보호법 및 국제

조약에 의해서 보호받고 있습니다. 사용설명서의 내용과 여기에 설명된 프로그램은 TmaxSoft Co., Ltd.와의 사용

권 계약 하에서만 사용이 가능하며, 사용권 계약을 준수하는 경우에만 사용 또는 복제할 수 있습니다. 이 사용설명

서의 전부 또는 일부분을 Tmaxsoft의 사전 서면 동의 없이 전자, 기계, 녹음 등의 수단을 사용하여 전송, 복제, 배

포, 2차적 저작물작성 등의 행위를 하여서는 안 됩니다.

Trademarks

Tmax® and Tmax OpenFrame®are registered trademarks of TmaxSoft Co., Ltd. Other products, titles or services

may be registered trademarks of their respective companies.

Tmax®와 Tmax OpenFrame®은 TmaxSoft Co., Ltd.의 등록 상표입니다. 기타 모든 제품들과 회사 이름은 각각 해

당 소유주의 상표로서 참조용으로만 사용됩니다.

Open Source Software Notice

This product includes open source software developed and/or licensed by "OpenSSL", "RSA Data Security, Inc.",

"Apache Foundation", and "Jean-loup Gailly and Mark Adler". Information about the aforementioned and the related

open source software can be found in the "${INSTALL_PATH}/license/oss_licenses" directory.

본 제품은 “OpenSSL”, “RSA Data Security, Inc.”, “Apache Foundation” 및 “Jean-loup Gailly와 Mark Adler”에 의

해 개발 또는 라이선스된 오픈 소스 소프트웨어를 포함합니다. 관련 상세 정보는 제품의 디렉터리 “${IN

STALL_PATH}/license/oss_licenses”에 기재된 사항을 참고해 주십시오.

안내서 정보

안내서 제목: OpenFrame TJES 안내서

발행일: 2009-10-30

소프트웨어 버전: OpenFrame/Batch for VOS3 2.0

안내서 버전: v2.1.1

내용 목차

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

제1장 TJES 개요 ........................................................................................................................ 1

1.1. 특징 ........................................................................................................................... 16

1.2. 구성요소 ...................................................................................................................... 3

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

1.4. TJES 부트와 다운 ........................................................................................................ 7

1.4.1. 부트 .................................................................................................................. 7

1.4.2. WarmBoot와 ColdBoot ....................................................................................... 7

1.4.3. Shutdown .......................................................................................................... 8

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

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

2.1. JOB 상태 ................................................................................................................... 16

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

2.2. JCL의 관리 ................................................................................................................ 16

2.3. JOB의 처리단계 ......................................................................................................... 17

2.3.1. Submit 단계 .................................................................................................... 17

2.3.2. Schedule 단계 ................................................................................................. 19

2.3.3. Execution 단계 ................................................................................................ 21

2.3.4. Output 단계 ..................................................................................................... 22

2.3.5. Remove 단계 ................................................................................................... 22

2.4. JOB의 조회 ................................................................................................................ 22

2.5. 로그 ........................................................................................................................... 23

2.5.1. Submit 로그 .................................................................................................... 23

2.5.2. JOB 로그 ........................................................................................................ 23

2.6. JOB의 백업 ................................................................................................................ 26

2.7. JOB EXIT CODE ........................................................................................................ 26

2.7.1. STEP EXIT CODE ........................................................................................... 26

2.7.2. JOB EXIT CODE ............................................................................................. 27

제3장 JOB Execution ............................................................................................................... 29

3.1. JOB 실행 ................................................................................................................... 29

3.1.1. 실행 초기화 ..................................................................................................... 30

3.1.2. 입력 JCL 파싱 ................................................................................................. 32

3.1.3. 실행 과정 ........................................................................................................ 33

3.1.4. 프로그램 실행 .................................................................................................. 34

3.1.5. 프로시저 실행 .................................................................................................. 37

3.1.6. DD 처리 .......................................................................................................... 37

3.1.7. 스페셜 DD ....................................................................................................... 38

3.1.8. JOB SPOOL .................................................................................................... 40

3.1.9. JOB Control .................................................................................................... 43

OpenFrame iii

3.1.10. JOB Level Report .......................................................................................... 44

3.1.11. STEP Level Report ........................................................................................ 44

3.1.12. 보안 .............................................................................................................. 45

3.1.13. tjclrun 호출 .................................................................................................... 48

3.1.14. NICE를 통한 PERFORM 처리 ......................................................................... 49

제4장 SPOOL ........................................................................................................................... 51

4.1. SPOOL BACKUP ....................................................................................................... 51

4.2. SPOOL 데이터 셋 ....................................................................................................... 51

제5장 OUTPUT Processing ...................................................................................................... 61

5.1. OUTPUT .................................................................................................................... 61

5.2. OUTPUT 처리 ............................................................................................................ 61

5.2.1. OUTPUT CLASS ............................................................................................. 61

5.2.2. OUTPUT DISPOSITION .................................................................................. 62

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

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

6.1.1. RUN ............................................................................................................... 66

6.1.2. START ............................................................................................................ 66

6.1.3. HOLD ............................................................................................................. 67

6.1.4. SUSPEND ...................................................................................................... 67

6.1.5. RESUME ........................................................................................................ 67

6.1.6. STOP ............................................................................................................. 67

6.1.7. REMOVE ........................................................................................................ 67

6.1.8. CANCEL ......................................................................................................... 68

6.1.9. NICE .............................................................................................................. 68

6.1.10. OUTQUEUEPURGE ...................................................................................... 68

6.1.11. INQUEUECLASS .......................................................................................... 68

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

6.2.1. PS (Print Screen) ............................................................................................ 69

6.2.2. PSJOB (Print Screen JOB detail information) .................................................... 69

6.2.3. PSIO (Print Screen Input/Output information) .................................................... 71

6.2.4. PO (Print Output status) ................................................................................... 72

6.2.5. POLIST (Print Output detail LIST) ..................................................................... 72

6.2.6. POJOB (Print Output of JOB) ........................................................................... 73

6.2.7. POSPOOL (Print Output SPOOL of JOB) .......................................................... 74

6.2.8. PODD (Print Output DD Information) ................................................................ 75

6.2.9. PSHISTORY (Print Screen of JOB History) ....................................................... 75

6.3. INITIATOR 명령어 ...................................................................................................... 76

6.3.1. BOOT ............................................................................................................. 76

6.3.2. SHUTDOWN ................................................................................................... 76

6.3.3. NODECLEAR .................................................................................................. 77

6.3.4. NODESTATUS (NODEST) ............................................................................... 77

6.3.5. JCLRUNACTIVE (RA) / JCLRUNINACTIVE (RI) ................................................ 77

iv OpenFrame TJES 안내서

6.3.6. JCLRUNCLASS(RC) ....................................................................................... 78

6.3.7. PSCLASS(PSC) .............................................................................................. 79

6.3.8. SHOWCLASS(SC) .......................................................................................... 79

6.3.9. CHANGECLASS(CC) ...................................................................................... 79

6.3.10. PSJCLRUN (PSR) ......................................................................................... 80

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

6.4.1. PSCATALOG (PSCAT) ..................................................................................... 81

6.4.2. SETCATALOG (SETCAT) ................................................................................. 82

6.4.3. PSDATASET(PSDS) ........................................................................................ 83

6.4.4. PSENTRY(PSENT) .......................................................................................... 85

6.4.5. DATASETLIST (DSLIST) .................................................................................. 85

6.4.6. DATASETCREATE (DSCREATE) ...................................................................... 86

6.4.7. DATASETCOPY (DSCOPY) ............................................................................. 87

6.4.8. DATASETMOVE (DSMOVE) ............................................................................. 88

6.4.9. DATASETDELETE (DSDELETE) ...................................................................... 88

6.4.10. DATASETRECATALOG (DSRECAT) ................................................................ 89

6.4.11. DATASETUNCATALOG (DSUNCAT) ............................................................... 90

6.4.12. DATASETIMPORT (DSIMPORT) ..................................................................... 90

6.4.13. DATASETEXPORT (DSEXPORT) ................................................................... 91

6.4.14. DATATOUCH (DSTOUCH) .............................................................................. 91

6.4.15. GDGCREATE ................................................................................................ 92

6.4.16. GDGDELETE ................................................................................................ 92

6.4.17. PSLOCK (PSL) .............................................................................................. 93

6.4.18. LOCKCLEAR ................................................................................................ 94

6.4.19. PSVOLUME (PSV) ........................................................................................ 94

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

6.5.1. SPOOLBACKUP (SPBA) ................................................................................. 95

6.5.2. SPOOLBACKUPLIST (SPBL) ........................................................................... 96

6.5.3. SPOOLPS (SPPS) .......................................................................................... 96

6.5.4. SPOOLRESTORE (SPRE) ............................................................................... 97

6.5.5. SPOOLCLEAR (SPCL) .................................................................................... 97

6.5.6. SPOOLPSJOB (SPPSJ) .................................................................................. 98

6.5.7. SPOOLPSIO (SPPSIO) ................................................................................... 98

6.5.8. SPOOLPODD (SPPODD) ................................................................................ 98

6.5.9. SPOOLPOSPOOL (SPPOSPOOL) ................................................................... 99

6.6. 기타 명령어 ................................................................................................................ 99

6.6.1. PSPRINT (PSP) .............................................................................................. 99

6.6.2. CLS .............................................................................................................. 100

6.6.3. EDIT ............................................................................................................. 100

6.6.4. VERSION ...................................................................................................... 100

6.6.5. HELP ............................................................................................................ 101

6.6.6. LICENSE ...................................................................................................... 101

6.6.7. ERROR ......................................................................................................... 101

OpenFrame v

6.6.8. CURRENTUSER ........................................................................................... 101

6.6.9. SWITCHUSER .............................................................................................. 102

6.7. JSS3 관련 명령어 ..................................................................................................... 102

6.7.1. SETNET (SN) ................................................................................................ 102

6.7.2. DISPLAYNETLIST (DNL) ............................................................................... 104

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

7.1. Tmax 설정 ............................................................................................................... 126

7.1.1. Tmax 서버 ..................................................................................................... 107

7.1.2. 멀티 노드 설정 ............................................................................................... 110

7.2. TJES 설정 ................................................................................................................ 112

7.2.1. OpenFrame 환경 파일 형식 ............................................................................ 112

7.2.2. TJES 환경 파일 ............................................................................................. 112

7.3. TJESMGR 설정 ........................................................................................................ 126

7.4. OUTPUT 설정 .......................................................................................................... 126

7.5. TJCLRUN 설정 ......................................................................................................... 127

7.6. Return Code 설정 ..................................................................................................... 135

색인 .......................................................................................................................................... 137

vi OpenFrame TJES 안내서

그림 목차

[그림 1.1] TJES 구성요소 ............................................................................................................ 3

[그림 1.2] 멀티 노드 환경 ............................................................................................................. 6

[그림 2.1] JOB 상태 흐름도 ........................................................................................................ 13

OpenFrame vii

안내서에 대하여

안내서의 대상

본 안내서는 리호스팅 솔루션인 Tmax OpenFrame®(이하 OpenFrame)/Batch 시스템의 엔진 역할을 수행

하는 TJES를 통해 JOB을 실행하고 관리하는 사용자를 대상으로 기술한다. 본 안내서에서는 JOB을 관리

하고 실행하는 단계, SPOOL 관리, OUTPUT 처리단계 등에 대하여 기술하고 TJES를 운영할 때 유용한

명령어와 로그 및 에러 처리방법, TJES 관련 환경설정에 대하여 기술한다.

안내서의 전제 조건본 안내서를 정확히 사용하려면 OpenFrame/Batch의 개념을 이해하고 있어야 한다. OpenFrame/Batch에

대한 이해를 돕기 위해 “OpenFrame Batch 안내서”를 먼저 숙지할 것을 권장한다.

안내서에 대하여 ix

안내서 구성

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

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

● 제1장: TJES 개요

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

이터 셋에 대해 기술한다.

● 제2장: JOB의 관리

JOB 상태와 상태 변경, Class 개요, JCL 관리, JOB 처리단계, JOB 조회 방법, JOB 로그, JOB 백업방법

및 JOB의 EXIT CODE에 대해 기술한다.

● 제3장: JOB Execution

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

실행과 JOB 실행의 산출물 등에 대한 설명을 포함한다.

● 제4장: SPOOL

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

● 제5장: OUTPUT Processing

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

● 제6장: TJESMGR 명령어

JOB 실행 명령어, JOB/OUTPUT 명령어, INITIATOR 명령어, 데이터 셋 명령어, SPOOL 백업 명령어와

기타 TJESMGR 명령어에 대해 기술한다.

● 제7장: 환경설정

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

x OpenFrame TJES 안내서

안내서 규약

내용표기

명령어,명령어 수행 후 화면에 출력된 결과물, 예제코드AaBbCc123

참조 또는 주의사항참고

필수 인수 값{ }

옵션 인수 값[ ]

선택 인수 값|

다른 관련 안내서 언급 또는 안내서 내의 다른 장 및 절 언급" "(따옴표)

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

강조진하게

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

명령어 프롬프트$

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

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

그림 이름[그림 1.1]

표 이름[표 1.1]

안내서에 대하여 xi

시스템 사용 환경

요구 사항

IBM AIX 5.xPlatform

HP-UX 11.xx

Solaris 9 (SunOS 5.9)

Linux IA64 2.6.x

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

256MB 이상 메모리 공간

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

Tibero 3.0Database

Oracle 9i 또는 10g

COBOL2002Compiler

OpenFrame/BatchOpenFrame 제품군

xii OpenFrame TJES 안내서

관련 안내서

설명안내서

제품의 설치와 환경 설정에 대한 부분을 기술한 안내서이다.OpenFrame

Batch 설치 안내서

OpenFrame/Batch를 구성하는 전반적인 기능에 대해 기술한 안내서이

다.

OpenFrame

Batch 안내서

OpenFrame 시스템의 VOS3 JCL의 문법 지원 사항과 상세 내용에 대해

서 기술한 안내서이다.

OpenFrame

JCL 문법 안내서

OpenFrame/Base를 구성하는 전반적인 기능에 대해 기술한 안내서이

다.

OpenFrame

Base 안내서

TACF에 대한 기능과 구조, 사용자와 그룹 연결, 리소스와 데이터 셋에

대한 인증과 권한 및 다양한 TACF의 명령어에 대해 기술한 안내서이다.

OpenFrame

TACF 운영자 안내서

OpenFrame 데이터 셋에 대한 소개와 데이터 셋 종류 및 카탈로그 방법

등에 대해 기술한 안내서이다.

OpenFrame

데이터 셋 안내서

OpenFrame 엔진과 함께 제공되는 다양한 유틸리티 프로그램에 대해

기술된 안내서이다.

OpenFrame

유틸리티 참조 안내서

OpenFrame 제품을 사용 중에 발생할 수 있는 에러에 대한 정보 및 에

러 대응방법이 기술된 안내서이다.

OpenFrame

에러 메시지 참조 안내서

OpenFrame 시스템을 운용하는데 사용하는 다양한 툴 프로그램에 대해

기술된 안내서이다.

OpenFrame

툴 참조 안내서

참고 문헌

안내서제품

VOS3 JOB제어언어 문법서 6190-3-144-E0Mainframe

VOS3 JOB관리 해설서 6190-3-140-A0

VOS3 시스템조작 - JSS3편 6190-3-101-F0

안내서에 대하여 xiii

안내서제품

Tmax 관리자 안내서Tmax

Tmax 설치 안내서

xiv OpenFrame TJES 안내서

연락처

Korea

TmaxSoft Co., Ltd

263 BundangSquare (AK Plaza) 12th floor, Seohyeon-dong, Bundang-gu,

Seongnam-si, Gyeonggi-do, 463-824

South Korea

Tel: +82-31-8018-1000

Fax: +82-31-8018-1115

Email: [email protected]

Web (Korean): http://www.tmax.co.kr

기술지원: http://technet.tmaxsoft.com

USA

TmaxSoft, Inc.

560 Sylvan Avenue Englewood Cliffs, NJ 07632

U.S.A

Tel: +1-201-567-8266

Fax: +1-201-567-7339


Web (English): 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


Web (Japanese): http://www.tmaxsoft.co.jp

안내서에 대하여 xv

http://www.tmax.co.kr

http://technet.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,

Chaoyang District, Beijing, China, 100027

China

Tel: +86-10-6410-6145~8

Fax: +86-10-6410-6144


Web (Chinese): http://www.tmaxsoft.com.cn

xvi OpenFrame TJES 안내서

http://www.tmaxchina.com.cn

제1장 TJES 개요

OpenFrame TJES(이하 TJES)는 Tmax Job Entry Subsystem의 약자로, Mainframe의 JES에 대응하는

OpenFrame 시스템의 Batch JOB 관리 모듈이다. TJES는 멀티 노드 구성과 자동화된 에러 복구 지원을

위해 TmaxSoft의 TP-Monitor 제품인 Tmax에 구현되었다.

TJES는 JCL과 JOB 실행 및 관리를 UNIX에서 Mainframe과 가장 유사하게 지원하는 Batch 처리 솔루션

이다. 또한 검증된 미들웨어를 이용한 멀티노드 클러스터링을 통해 UNIX 시스템의 성능 한계를 뛰어넘어,

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

TJES는 JCL을 통해 사용자로부터 JOB을 받아들이고, 이를 시스템의 자원 상황에 맞춰 스케줄링하여

Runner를 통해 수행하고, JOB의 수행 결과를 프린트하며, JOB의 수행상황을 조회하는 등 OpenFrame에

서 일어나는 JOB에 관한 모든 수행을 관장한다.

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

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

– Mainframe 과 동일한 JCL 문법 지원

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

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

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

– Mainframe JES 의 스케줄링 원칙과 동일하게 스케줄링

– 멀티노드 스케줄링 지원

● JOB의 OUTPUT을 처리한다.

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

본 안내서에서는 JOB을 관리하고 실행하는 단계, SPOOL 관리, OUTPUT 처리단계 등에 대하여 기술하

고 TJES를 운영할 때 유용한 명령어와 로그 및 에러 처리방법, TJES 관련 환경설정에 대하여 기술한다.

제1장 TJES 개요 1

1.1. 특징TJES는 Mainframe의 Batch 프로그램(유틸리티, COBOL 프로그램, PL/I 프로그램)을 구동할 수 있는 것

이외에도, 기본적으로 UNIX 셸 스크립트, C 프로그램 등 UNIX에서 실행 가능한 모든 프로그램을 구동할

수 있다.

UNIX에서 셸 스크립트와 cron을 통해 Batch 처리할 경우에는 체계화된 JOB 스케줄링 및 관리의 부재 그

리고 리소스 통제 미비로 인해 어려움을 겪기 쉽다.

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

● JOB 속성과 Runner 등 시스템 자원 상황에 따른 스케줄링

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

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

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

● OUTPUT 관리

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

● TACF를 통한 보안성 향상

2 OpenFrame TJES 안내서

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

[그림 1.1] TJES 구성요소

TJES 컴포넌트

● obmjmsvr

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

● obmjschd

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

링을 주로 담당하고 이외에 JOBID 발급과 각 노드의 부트상태를 관리한다.

● obmjinit

Runner와 Runner Slot을 관리하는 서버이다. obmjinit는 TJES의 각 노드마다 1개씩 기동되는 서버로,

자기 노드에 할당된 Runner와 Runner Slot를 관리하고 JOB을 Runner에 할당하는 역할을 담당한다.

● obmjhist

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

액션에 대한 정보를 저장하는 서버이다.


● obmjspbk

SPOOL 백업 서버이다. TJES 전체 도메인에서 1개의 노드에서만 기동되어야 하는 서버로 실행이 종료

된 JOB을 TJES에서 제거하면서 해당 JOB의 SPOOL을 별도의 저장소로 백업하고 이후 조회하는 기능

을 제공한다. 백업된 SPOOL은 TJES 상에서와 동일한 형태로 조회가 가능하다.

● tjclrun

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

● ofrpmsvr

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

을 조건에 맞는 프린터로 출력한다.

OpenFrame 기타 제품

● Base

OpenFrame이 구동되기 위해 필수적으로 필요한 제품이다. OpenFrame/Base는 NVSM, TSAM 등의 데

이터 셋 지원, 카탈로그 관리, 데이터 셋 Lock 관리 등을 지원한다.

참고

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

● TACF

OpenFrame의 보안을 담당하는 제품이다. OpenFrame TJES는 OpenFrame/TACF와 연동되어야 사용

자 인증이나 데이터 셋, JOB 이름 등의 자원에 대한 권한 체크등의 강력한 보안 기능을 사용할 수 있다.

참고

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

TJES 사용 자원

– Runner Slot

Runner Slot은 Runner의 운용 정보를 저장하고 있는 영역으로 Runner 1개당 1 개의 Runner Slot 이 할

당된다. Runner와 obmjinit 사이의 데이터 교환 창구로 사용된다. Runner Slot은 obmjinit 이 정상적으로

기동될 때 생성되며 obmjinit이 정상적으로 종료될 때 제거된다. UNIX의 Shared Memory로 구현하였으

므로 필요할 때 기타 UNIX Shared Memory와 동일한 방식으로 관리할 수 있다.


– SPOOL

TJES가 사용하는 특별한 데이터 셋이다. JOB 구동에 필요한 자원이나 JOB의 진행상황과 결과를 저장

하기 위해 사용한다. JOB을 submit할 때 JOBID와 동일한 이름으로 디렉터리를 생성하여 이 디렉터리

의 하위 공간을 사용한다.

JOB SPOOL은 REMOVE나 CANCEL 명령이 실행되면 삭제된다.

– TJES 시스템 데이터 셋

TJES가 내부 정보 저장을 위해 사용하는 시스템 데이터 셋이다. JOBQ, JESST, OUTPUTQ가 있다.

참고

자세한 내용은 “1.5. TJES 시스템 데이터 셋”을 참조한다.

Interface

● textrun

OpenFrame 제품이 아닌, 3rd party 스케줄러에서 TJES에 JOB을 submit하고, 진행 상황과 결과를 모니

터링할 수 있는 모듈이다. UNIX 상의 3rd party 스케줄러들은 JOB의 시작과 끝을 프로세스의 시작과 종

료로 구분한다. 따라서 textrun은 자신이 submit한 JOB이 끝날 때까지 종료되지 않고 계속 실행 중에 있

다가 JOB이 종료되면 그 결과를 반환하고 종료한다.

● tjesmgr

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

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

● OpenStudio

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

는 등의 TJES 관리기능을 제외한, JOB을 submit하고 조회 및 관리하는 기능을 제공한다.

외부 제품

● External Scheduler

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

등 JOB간의 상관관계에 따른 스케줄링을 지원하지 않는다. 이런 상관관계에 따른 스케줄링이나 일간,

주간, 월간 배치 등 자동화된 JOB submit을 위해서 External Scheduler가 사용된다. Control-m, A-Auto

등이 있다.


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 서버이다.

만약 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 부트와 다운

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

없는 상태이다.

시스템 관리자는 tjesmgr의 노드 명령어 중 BOOT와 SHUTDOWN 명령어를 통해 이를 제어할 수 있다.

참고

자세한 사용방법은 “6.3. INITIATOR 명령어”에서 “6.3.1. BOOT”와 “6.3.2. SHUTDOWN”을 참고한

다.

1.4.1. 부트

부트는 TJES가 다운되어 있는 상태에서만 동작하며, 이미 부트되어 있는 상태라면 BOOT 명령은 무시된

다. 부트는 TJES의 각 노드에서 자신의 Runner Slot 상태를 사용할 수 있는 상태로 초기화한 후, TJES의

obmjschd에게 Runner Slot의 현재 상태를 보고하여 JOB이 스케줄링될 수 있도록 한다.

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

다. 이후 DB 연결 실패 등과 같은 장애(disaster) 발생으로 인한 TJES 자동복구절차에서 부트상태를 유지

할 수 있도록 한다.

멀티 노드 TJES 환경에서는 TJES가 부트될 때, TJES 전체 도메인에 속한 모든 노드에 BOOT 명령을 전

달하게 된다. 그리고 멀티 노드 환경에서도 개별 노드 별로 부트하는 방법을 제공한다.

부트될 때 해당 노드의 Runner Slot 상태는 Downed에서 다운되기 전의 Active 또는 Inactive 상태로 복구

되고, 부트된 적이 없다면 tjes.conf 설정파일의 [INITDEF]섹션에 설정된 기본상태로 복구된다.

1.4.2. WarmBoot와 ColdBoot

● WarmBoot

시스템을 초기화한 후 운영 중에 사용하는 일반적인 부트이다. TJES Shared Memory를 초기화하고, 스

케줄러에게 Runner Slot의 현재 상태 정보를 보고하여 JOB 스케줄링이 일어날 수 있도록 한다. tjesmgr

의 BOOT명령을 통해 WarmBoot를 한다.

참고

ColdBoot에 대한 자세한 내용은 OpenFrame 안내서 중 “툴 참조 안내서”의 “tjesinit”을 참고한다.


● ColdBoot

OpenFrame TJES를 초기화하는 역할을 하는 특수목적의 부트로 tjesinit 툴을 사용하여 시스템 데이터

셋을 초기화한다. ColdBoot 이후에도 실제 JOB을 수행하기 위해서는 WarmBoot를 해야 한다.

다음의 경우에 ColdBoot를 한다.

– OpenFrame TJES 설치 후

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

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

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

• OUTPUTQ 사이즈 변경 후

• [JOBCLASS] 섹션 변경 후 ( MVS, VOS 시스템의 경우 )

• JOB GROUP 설정 변경 후 ( XSP 시스템의 경우 )

1.4.3. 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.5. TJES 시스템 데이터 셋

TJES는 시스템 설정과 각종 자원에 대한 정보를 노드간에 공유하기 위해 다음과 같은 VSAM 데이터 셋에

저장한다.

JESST

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

설명시스템 레벨 정보

시스템 상에 존재하는 노드들의 정보와 각각의 노드들의 부트 상태를 저장한다.노드 정보

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

OUTPUTQ 크기 등 OUTPUTQ에 대한 개괄적인 정보를 저장한다.OUTPUTQ 정보

JOB CLASS별 기본 속성 정보를 저장한다.JOB CLASS 정보

참고

JESST의 실제 데이터 셋 이름은 tjes.conf 설정파일에 [SYSTEM_DS] 섹션에 TJES_STAT의 항목에

지정된다. 해당 항목의 정보를 TJES_STAT=SYS1.JESST으로 설정할 것을 권장한다.

JOBQTJES에서 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로 설정할 것을 권장한다.


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

셋이다.

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

용 UNIX 툴인 tjesinit을 통해 시스템 데이터 셋을 초기화해야 한다.

참고

ColdBoot 단계 중에 기록해야 하는 SYS1.JESST의 JOBQ 정보, OUTPUTQ 정보 등은 tjesinit을 통

해서만 갱신된다. 이후에 tjes.conf의 설정을 변경한다면, tjesinit을 통해 SYS1.JESST에 변경 사항을

반영해야 한다.

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

모두 SYS1.XXXX로 설정한다고 가정한다. 다른 이름의 시스템 데이터 셋을 사용하려면 스크립트를 변경

하고, IDCAMS(또는 JSCVSUT)를 통해 새로 시스템 데이터 셋을 생성하여야 하며, 스크립트를 변경할 때

에는 진하게 표시된 데이터 셋 이름만을 고치는 것을 권장한다. 진하게 표시된 데이터 셋 이름은 한 스크

립트 내에서는 모두 동일해야 한다.

스크립트 상에 100000의 기본값으로 지정된 볼륨은 시스템 설정에 따라 수정한다.

<SYS1.JESST>

#!/bin/sh

# JESST Creating Script ( TJES 5.0 )

# 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.JOBQ>

#!/bin/sh

# JOBQ Creating Script ( TJES 5.0 )

# 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 -


VOLUMES(100000) -

KEYS(24 0) )

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

UPGRADE -


VOLUMES(100000) -

KEYS(16 8) )

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.OUTPUTQ>

#!/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 -

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


제2장 JOB의 관리

본 장에서는 JOB이 가질 수 있는 상태와 JOB이 실행되는 단계 및 결과 조회 그리고 JOB을 관리하는 방

법에 대해서 설명한다.

OpenFrame에서 JOB을 관리하는 방법은 tjesmgr와 OpenStudio 2가지가 있는데 본 안내서에서는 tjesmgr

를 사용하여 JOB을 관리하는 방법에 대해서만 다루도록 한다.

참고

OpenStudio를 사용하여 JOB을 관리하는 방법에 대해서는 OpenFrame 안내서 중 ”OpenStudio BM

안내서”를 참고한다.

2.1. JOB 상태

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

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

[그림 2.1] JOB 상태 흐름도

제2장 JOB의 관리 13

참고

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

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

● START

JCL을 통해 JOB이 submit되어 실행되기 전까지의 상태로서, JOB 스케줄링의 대상이고 아직 Runner

Slot에게 할당되지 않은 상태이다. JOB CLASS를 변경할 수 있고, HOLD 명령을 통해 JOB을 HOLD 상

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

● HOLD

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

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

– 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

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

STOP 명령을 통해 JOB 수행을 끝내고 STOP 상태로 바꿀 수 있다.

주의

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

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

● DONE

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


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

반환 코드(PSJOB) 등을 조회하여 별도로 확인해야 한다. REMOVE 명령을 통해 JOBQ에서 제거할 수

있다.

참고

DONE 상태는 JCL에서 요청된 대로 JOB의 모든 STEP이 수행되었고 반환 코드가 COND문이나

rc.conf 등을 통해 지정한 허용 범위이내라는 것을 의미하는 것이지, 각 STEP에 지정된 프로시저나

프로그램이 업무적으로 정상 실행되었다는 것을 의미하는 것은 아니다.

● 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에서 제거할

수 있다.

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

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

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

첫번째 칼럼의 현재 상태에서 두번째 칼럼의 명령어를 사용하면 세번째 칼럼의 상태로 변경된다.

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

START, HOLDRUN-

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

HOLDHOLD

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

STARTSTART

SUSPENDSUSPENDWORKING


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

STOPSTOP

STOPSTOPSUSPEND

WORKINGRESUME

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

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

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

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

JOBQ는 tjes.conf의 [JOBDEF] 섹션에 설정된 크기만큼만 저장을 할 수 있기 때문에 필요하지 않는 JOB

들은 JOBQ에서 삭제할 필요가 있다.

CANCEL이나 REMOVE는 모두 JOBQ에서 JOB을 삭제하는 명령이지만 CANCEL은 JOB이 실행되기 전

에, REMOVE는 JOB이 실행된 후에 삭제된다는 점이 다르다.

HOLD 상태에 있는 JOB들은 스케줄링이 되지 않기 때문에 HOLD 상태인 JOB을 실행하고자 하면 START

상태로 상태를 바꾸어야 한다. 이때 START 명령어를 사용하여 상태를 변경할 수 있다.

참고

1. JOBQ에서 JOB 삭제와 관련된 내용은 “7.2. TJES 설정”을 참고한다.

2. 각 명령어 사용법은 “제6장 TJESMGR 명령어”를 참고한다.

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을 찾을 수 있다.

참고

JCLLIB에 지정한 PDS순서대로 해당 데이터 셋의 멤버를 검색한다.


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

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

2. Schedule: 조건을 충족하는 Runner Slot에게 JOB을 할당하는 단계

3. Execution: 실제로 Runner가 JOB을 수행하는 단계

4. Output: JOB의 수행이 끝나고 그 Output이 처리되는 단계

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

2.3.1. Submit 단계

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

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

에 필요한 리소스를 할당한 후 JOBQ에 저장한다. submit된 JOB의 정보는 스케줄러에 통보되어, 스케줄

러에 의해 JOB이 Runner Slot에 할당될 수 있도록 한다.

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

● JOBID

TJES가 JOB을 구분하여 관리하기 위해서는 각각의 JOB에 유일한 ID를 부여해야 한다. 이를 JOBID라

하며, TJES에서 관리하는 JOBID는 'JOBnnnnn'의 형식을 갖는다. JOB에 부여할 수 있는 JOBID 범위

는 00001부터 99999이다. JOBID는 Submit할 때 발급되어 JOB이 CANCEL이나 REMOVE를 통해 제

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

이외에 CICS에서 생성하는 'STCnnnnn', TSO에서 생성하는 'TSOnnnnn' 형식의 JOBID가 있으나, 이는

TJES가 관리하지 않는다.

● SPOOL

TJES는 1개의 JOB마다 독립적인 SPOOL 공간을 할당하는데 UNIX 디렉터리로 구현되어 있다. SPOOL

볼륨에 위치하며 JOBID를 디렉터리명으로 한다. SPOOL에는 Submit받은 시점의 JCL을 보존하기 위

하여 복사한 INPJCL, 카탈로그를 복사한 CATPROC, JOB의 수행 결과인 SYSOUT과 TJES가 JOB의

수행상태를 보고하기 위해 내부적으로 사용하는 파일 등이 저장된다. SPOOL은 tjesinit 툴을 통해 초기

화한다.

● JOBQ


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

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

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

1. JOBID를 발급하고 SPOOL을 생성한다.

2. Submit된 JCL을 SPOOL에 INPJCL로 복사한다.

3. Submit용으로 TJESSUBM이라는 JOB을 JOBQ에 저장한다. JSS3 command가 존재하지 않으면 이

JOB은 재사용되어 JCL 에 기술된 1번째JOB 으로 대체된다.

4. JCL을 파싱한다.

이 시점에 구문 오류가 발생하면 이를 SPOOL의 SYSMSG에 저장하고, Submit 과정을 종료한다.

5. JSS3 명령어가 존재하면 이를 수행한다.

JSS3 명령어는 명령어 실행 전용 서버인 ofrcmd에서 수행된다.

6. JCL에 기술된 각각의 JOB별로 다음의 내용이 수행된다.

a. JOBID를 발급하고 SPOOL을 생성한다.

b. Submit된 JCL을 SPOOL에 INPJCL로 복사한다.

c. TYPRUN = JCLHOLD가 주어지면 운영자가 명시적으로 명령을 할 때까지 다음 단계의 진행을 일시

중지한다.

d. STEP에 기술된 프로시저를 SPOOL에 CATPROC으로 복사하고, 파싱한다.

e. TYPRUN = SCAN이 주어지면 JOB에 해당하는 JCL이나 CATPROC의 구문 분석을 시행하고, 이 결

과를 SPOOL의 SYSMSG에 저장한다. JOB을 DONE이나 ERROR의 종료상태로 저장하고 현재 JOB

의 Submit을 종료한다.

f. 이외의 경우 JOBQ에 JOB을 저장한다.

- TYPRUN=HOLD나 JOB의 CLASS에 HOLD 설정(tjes.conf 의 [JOBCLASS] 설정 )이 있는 경우

HOLD 상태로 저장된다.

- 이외의 경우 START 상태로 저장된다.

g. TJES의 스케줄링을 담당하는 obmjschd에 JOB의 스케줄링 정보를 전달한다.

7. JCL의 Submit 결과를 요약하여 Submitter에게 보고한다.


Submit 단계 중에 에러가 발생하면 tjes.conf의 [LOG] 섹션의 SUBMITLOG 항목에 지정된 로그 파일에

해당 내용이 저장된다.

tjesmgr의 PS 명령어를 통해서 Submit하여 생성된 JOB들이 JOBQ에 등록되어 있는 것을 확인할 수 있다.

참고

1. Submit 로그의 형식에 대한 자세한 내용은 “2.5.2. JOB 로그”를 참고한다.

2. JOBQ의 Output에 대한 자세한 내용은 “6.2.1. PS (Print Screen)”을 참고한다.

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

● tjesmgr의 RUN 명령어를 통한 방법(“제6장 TJESMGR 명령어”의 “6.1.1. RUN”을 참고한다.)

● textrun 툴을 사용하는 방법(OpenFrame 안내서 중 "툴 참조 안내서"의 "textrun"을 참고한다.)

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

2.3.2. Schedule 단계

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

JOB을 배정한다.

● Runner Slot의 상태가 Active로 활성화되어 있어야 하며, 다른 JOB을 수행하고 있는 중이 아니어야 한

다.

● RUNNER CLASS가 JOB CLASS와 일치해야 한다.

● JOB을 Submit할 때 특정 노드에서 JOB이 실행되도록 명시했을 경우, 그 노드와 Runner Slot이 속한 노

드가 일치해야 한다.

● JSS3의 NET 문을 지원한다. NHOLD 값이 0 이 되어야 하고, OPHOLD 되어있지 않아야 한다.

● JSS3의 MAIN 문을 지원한다. 현재 START 문을 지원하고 있기 때문에, START 문으로 지정한 날짜와

시각이 지나야 스케줄링 받을 수 있다.

다음은 스케줄링 메소드를 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

Check JSS3 JOBNET NHOLD. If not 0, try next Job

Check JSS3 MAIN START. If not passed, try next Job

Assign the Job to the runner and break

}

}

JOB CLASS

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

을 가져야 한다.

JCL에 클래스가 기술되어 있지 않을 때에는 tjclrun.conf의 [JOB] CLASS에 기술된 디폴트 JOB CLASS

를 사용한다.

JOB CLASS는 해당 JOB이 실행될 수 있는 Runner Slot을 제한하는 용도로 JOB 스케줄링에 사용된다. A

라는 JOB CLASS를 가진 JOB은 RUNNER CLASS에 CBA 혹은 ABC와 같은 식으로 A를 포함한 Runner

Slot에만 할당될 수 있다.

이외에도 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개의 값을 가지

며, 1개의 Runner Slot은 최대 8개의 클래스를 가질 수 있다.

복수의 RUNNER CLASS가 설정된 경우에는, 앞에 기술된 클래스에 해당하는 JOB이 없을 때에만 뒤에

기술된 클래스가 사용될 수 있다. 즉, 제일 먼저 설정된 클래스가 최우선이고 맨 마지막에 설정된 클래스

가 제일 낮은 우선순위를 갖는다. 또한 i 번째에 기술된 클래스에 해당하는 JOB을 실행하기 위해서는,

TJES의 모든 Runner Slot이 i 번째 이전에 기술된 클래스로 해당 JOB을 실행할 수 없어야 한다.

예를 들면 TJES 내에 1번 Runner Slot은 RUNNER CLASS가 ABC이고, 2번 Runner Slot은 BCA였을 때,

C의 JOB은 B의 JOB이 없을 때 2번 Runner Slot의 2번째 클래스로 실행될 수 있지만, 1번 Runner Slot의

3번째 클래스로 실행하기 위해서는 A와 B의 JOB이 없으면서, 2번 Runner Slot이 이미 JOB을 실행하고

있거나 Active 상태가 아니어서 , 2번째 클래스로 JOB을 실행할 수 없어야 한다.

JSS3 NET 문

JSS3 NET 문의 VOS3의 JOBNET 속성을 지정하기 위해 사용한다.


JOBNET은 간략히 설명하면 JOB 의 실행 순서를 설정하고 조건에 따라 실행하는 JOB 을 분기하는 등,

기존에는 운영자가 개입했어야 할 업무들을 자동화할 수 있는 VOS3의 특화 기능이다.

기본적으로 다음의 요소를 통해 JOBNET을 구성하게 된다.

● NHOLD: JOB이 실행되기 전에 선행으로 수행되어야 하는 JOB의 수를 지정한다. 0 이 아니면 실행되지

않는다.

● RELEASE: JOB이 종료되었을 때, 그 결과를 전달할 후속 JOB을 지정한다.

● COND: JOB이 종료되었을 때, 정상인지 비정상인지 판별하는 조건을 지정한다.

● NORMAL: 선행 JOB이 정상 종료되었을 때의 처리 방식을 지정한다.

● ABNORMAL: 선행 JOB이 비정상 종료되었을 때의 처리 방식을 지정한다.

참고

NET 문에 대한 자세한 사항은 OpenFrame 안내서 중 "JCL 문법 안내서"를 참고한다.

JSS3 MAIN 문

JSS3 NET 문은 스케줄링 시작 시각을 지정하기 위해 사용한다.

스케줄링 시작 시각을 지정하는 START 기능과, 실행 시작 시각의 deadline을 지정하는 DL 기능이 있다.

현재는 START 기능만을 지원한다.

참고

MAIN 문에 대한 자세한 사항은 OpenFrame 안내서 중 "JCL 문법 안내서"를 참고한다.

2.3.3. Execution 단계

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

Runner는 SPOOL에 복사되어 있는 JCL을 파싱하고, 그 결과에 따라 JOB을 실행한다. 하나의 JOB은 하

나 이상의 JOB STEP으로 구성되는데, Runner는 이 JOB STEP을 JCL에 기술된 순서대로 순차적으로 실

행한다.

JOB을 실행할 때 필요한 데이터 셋을 할당하는 일도 Execution 단계에서 일어난다.


2.3.4. Output 단계

JOB 수행 중 생성된 SYSOUT을 처리하는 단계이다. SYSOUT은 Output이라는 단위로 처리되는데,

OUTPUT CLASS에 따라 처리할 수 있는 프린터와 기본 후처리가 결정된다. Output은 프린터로 출력되거

나 인터널 리더를 통해 TJES로 Submit된다.

참고

자세한 내용은 “제5장 OUTPUT Processing”을 참고한다.

2.3.5. Remove 단계

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

되었던 JOBID, SPOOL, 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의 상세한 정보를 조회할 수 있다.

설명명령어

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

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

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

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

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

참고

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


2.5. 로그

TJES는 운영에 대한 자료로 사용하거나 운영할 때 발생할 수 있는 각종 사건들의 책임 소재를 분명히 하

는 용도로 사용하기 위해서 TJES 에서 일어나는 여러가지 이벤트에 대하여 로그를 남긴다.

OpenFrame/Batch v5.0 이상의 TJES 는 다음의 2가지의 로그를 남긴다.

● JCL의 Submit에 대한 정보를 저장하는 Submit 로그

● JOB의 모든 상태 변화에 대한 JOB 로그

매일 방대한 양의 로그가 기록될 수 있으므로 정리작업 없이 장기간 운영하면 로그 파일의 크기가 상당히

커질 수 있다. 이러한 문제점을 해결하기 위해서 날짜 별로 로그를 생성하는 옵션을 제공한다. tjes.conf

의 [LOG] 섹션에 로그별 파일 경로를 설정할 떄 &SYSDATE 를 파일 이름 중간에 기입하면, &SYSDATE

부분이 YYYYMMDD 형태의 날짜로 치환되어 날짜별로 로그를 생성할 수 있다.

2.5.1. Submit 로그

Submit 로그는 tjes.conf의 [LOG]섹션의 SUBMITLOG항목에 설정한 파일경로에 저장된다.

Submit 로그는 성공과 실패를 구분하지 않고, obmjmsvr에서 인지한 JCL을 submit하려는 모든 시도에 대

해 기록한다.

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

>> timestamp jclpath

submit_result

설명항목

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

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

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

2.5.2. JOB 로그

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

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

각 항목에 대한 설명은 다음과 같다.

설명항목

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

START 상태로 submit될 경우에 S가 설정되고, HOLD 상태로 submit될 경우에는 H

가 설정된다.

submit된 JOB CLASS이다.class

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

JCL에 JOB들이 실행될 execution_node를 지정하지 않았거나 tjesmgr.conf의 [DE

FAULT_OPTION] 섹션의 DEFAULT_RUNNING_NODE=MY를 설정하지 않았다면

모든 노드에서 실행될 수 있도록 애스터리스크(*)가 설정된다.

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

CHANGE

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

status=S|H,class=job_class


설명항목

변경된 후의 JOB Status 이다.status

S 는 START 상태를, H는 HOLD 상태를 의미한다.

변경된 후의 JOB CLASS 이다.class

CANCEL

JOB이 취소된다.

EXECUTE

JOB을 Runner에 할당한다.

index=runner_index;pid=runner_pid;class=working_class



설명항목

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

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

Runner Slot에 할당된 복수의 클래스 중 현재 JOB을 실행하기 위해 사용하고 있는 클래

스이다.

class

SUSPEND

JOB이 일시 정지된다.

index=runner_index;pid=runner_pid


설명항목



RESUME

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

index=runner_index;pid=runner_pid


설명항목



FINISH

JOB의 실행이 종료된다.

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


설명항목



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

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


REMOVED

JOB이 TJES에서 제거된다.

2.6. JOB의 백업

많은 JOB을 실행하게 되면 JOBQ에 JOB이 계속 쌓이게 되어 더이상 JOB을 submit 할 수 없는 상태까지

될 수 있다. 따라서 오래된 JOB에 대해서는 JOBQ에서 삭제해야 하며, 삭제하고자 하는 JOB들의 정보를

남겨놓고 싶을 때는 SPOOL을 백업한다.

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

설명명령어

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

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

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

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

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

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

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

보 출력)

SPOOLPOSPOOL

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

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

2.7. JOB EXIT CODE

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

2.7.1. STEP EXIT CODE

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

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

설명항목

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


설명항목

SYSTEM ABEND로 해당 애플리케이션이 시그널로 종료했음을 의미한다. SIGPIPE, SIGSEGV,

SIGABEND, SIGBUG 등의 시그널 중에 프로세스를 종료시키는 시그널로 인해 프로세스가 이

상 종료한 경우이다.

S

USER ABEND로, 해당 애플리케이션이 애플리케이션에서 정한 ABEND 상황임을 보고하고

WAASABND를 통해 종료했음을 의미한다.

U

Application ABEND로, 해당 애플리케이션은 정상적으로 종료했으나, 그 RC 값을 호출한 프로

그램(IKJEFT01 등)에서 판단했을 때 조건을 만족하지 못해 JOB을 종료해야 함을 의미한다.

A

● NNNN: 0~4096까지의 숫자로 애플리케이션의 반환 값이다. (255 이상은 external rc module을 통해 반

환 코드가 보고된다.)

2.7.2. JOB EXIT CODE

JOB EXIT CODE는 JOB의 종료 상황에 대한 부가 정보로, ANNNNN 형태를 가진다. (A : 문자, N : 0-9)

JOB 상태별로 다음과 같은 형식과 의미를 갖는다.

설명JOB 상태

XNNNNN. 마지막 STEP의 EXIT CODE이다.DONE

( X는 STEP EXIT CODE와 동일하다. )

XNNNNN. ERROR를 발생시킨 STEP의 EXIT CODE이다.ERROR

( X는 STEP EXIT CODE와 동일하다. )

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

[+-]NNNNNFLUSH

+ : Runner에서 비정상적인 상태를 감지하여 종료한 경우이며, 이때 NNNNN은 Runner

가 반환한 값이다. 에러상황이 OpenFrame의 Error Code로 정의된 명확한 상황은 Error

Code를 반환하고 이외에 세분화하여 정의되지 않은 상황은 1이 반환된다.

- : Runner가 UNIX 시그널에 의해 비정상 종료한 경우이며, 이때 NNNNN은 UNIX 시그

널 번호이다


제3장 JOB Execution

TJES가 제공하는 Batch JOB을 관리 및 처리하는 단계 중의 하나인 JOB Execution(이하 JOB 실행)은 사

용자가 submit한 JOB이 스케줄러에 의해서 스케줄링되면 해당 JOB을 실제로 OS에서 실행하는 단계이

다. JOB 실행단계는 tjclrun에 의해서 수행된다.

다음은 tjclrun에 의해 JOB이 실행되는 단계에 대한 설명이다.

1. 스케줄러가 JOB의 스케줄링 파라미터와 현재 시스템에서 사용 가능한 Runner Slot의 상태에 따라서

특정 Runner Slot에서 JOB을 수행하도록 할당(스케줄링)한다.

2. 해당 Runner Slot은 tjclrun을 실행하기 위한 자료를 JOB SPOOL에 기록하고 tjclrun을 호출한다.

3. tjclrun은 JOB SPOOL을 통해 전달된 해당 JOB의 JCL에 적힌 내용에 따라서 JOB을 실행한다.

4. JOB의 실행이 끝나면 tjclrun은 자신을 호출한 Runner Slot에게 JOB의 실행 결과를 보고한다.

JOB 실행 결과는 최종적으로 TJES가 관리하는 JOBQ에 저장된다. 또 실행이 완료된 JOB의 OUTPUT 및

JOBQ에 저장된 JOB에 대한 정보는 이후 TJES에 의해서 관리된다.

사용자는 실행이 완료된 JOB의 실행 결과를 검토하거나 출력할 수 있으며, 해당 JOB에 대한 정보가 더

이상 필요하지 않다면 해당 JOB 정보를 제거하게 된다.

본 장에서는 JOB 실행 단계를 책임지는 tjclrun의 동작과 기능에 대해서 설명한다.

3.1. JOB 실행

TJES의 JOB 처리 단계에 따라서 tjclrun이 호출되면, tjclrun은 실행을 위한 몇 가지 초기화 작업을 수행한

후에 JOB SPOOL을 통해 전달된 JCL을 파싱하고, 파싱된 결과에 따라서 JOB을 실행한다.

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

STEP에서 사용되는 데이터 셋을 할당하고 사용자가 지정한 Batch 애플리케이션을 실행하는 등 많은 세

부 작업으로 이루어져있다.

JOB STEP에 지정된 프로그램을 실행한 후에는 해당 프로그램이 종료하기를 기다리면서 프로그램 실행

에 관한 모니터링 정보를 TJES에 주기적으로 보고한다. 또한 실행한 프로그램에게 SYSIN 데이터 셋의

내용을 전달하고, SYSOUT 데이터 셋을 전달받아 JOB SPOOL에 기록한다. 실행한 프로그램이 종료되면,

그 종료결과를 TJES에 보고하고 JOB STEP의 종료상태에 따라 그 다음 JOB STEP을 실행하거나, 예외

조건이 만족하는 경우에는 JOB 수행을 중단한다.

위와 같은 방식으로 JCL에 기술된 마지막 JOB STEP까지 모두 실행한 후에 tjclrun은 JOB의 실행 결과를

TJES에 보고하고 JOB 실행 단계에서 할당한 데이터 셋 등의 자원을 반환한 후에 종료한다.

제3장 JOB Execution 29

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

단계작업

실행 초기화실행

입력 JOB 스트림 파싱

실행 과정

프로그램 실행

프로시저 실행

DD 처리리소스

스페셜 DD

JOB SPOOL

JOB Control컨트롤/모니터링

Job Level Report

Step Level Report

보안 (TACF support)기타

tjclrun 호출 (tjclrun 명령어 사용)

NICE를 통한 PERFORM처리

3.1.1. 실행 초기화

다음은 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에서 실행되는 배치 프로그램의 사용자 ID도 obm이 된다.

그러나 tjclrun.conf 설정파일의 [ACCOUNT] 섹션의 SETUID=YES로 설정하면 JCL JOB문의 USER에 지

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

참고

자세한 내용은 “3.1.12. 보안” 의 "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에 지정된 프로그램을 실행하

거나 tjclrun을 로딩하는 단계에서 실패하게 된다.

참고

자세한 내용은 “3.1.12. 보안” 의 "setuid root tjclrun"을 참고한다.


SYSMSG DD 열기

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

의 SYSMSG에 저장된다. tjclrun은 실행 초기화 단계에서 내부적인 로그 메시지를 저장하기 위해서 SYSMSG

를 미리 열어둔다.

다음의 경우에 로그가 SYSMSG에 저장된다.

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

tjclrun의 문제 분석용 로그를 출력하기 위해서는 tjclrun.conf의 [DEBUG] 섹션에 PROFILE=YES로 지

정해야 한다.

● OpenFrame 라이브러리에서 출력되는 stderr

OpenFrame 라이브러리에서 출력되는 stderr는 OpenFrame 전체 로그 형식을 따르고 있어서 SYSMSG

와는 출력 형식이 다르다.

JOB 시작 보고

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

JOB SPOOL 열기

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

3.1.2. 입력 JCL 파싱

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

참고

tjclrun이 실행하는 JOB문을 포함한 (JOB SPOOL에 저장된) JCL 파일을 JOB 스트림(JOB Stream)

이라고 부른다.

JCL 프로시저 파싱

tjclrun은 하나의 JOB을 실행하는 동안 여러 번 JCL을 파싱한다.

기본적으로 JOB문을 포함하고 있는 INPJCL을 파싱하여 실행에 들어간다. INPJCL의 내용을 순차적으로

실행하는 중에 JCL 프로시저의 호출이 지정되어 있으면 해당 JCL 프로시저를 파싱하고 그 프로시저를 실

행한다. 해당 프로시저의 실행이 끝나면 다시 이전 INPJCL을 계속 실행한다.


JOBPARM PROCLIB

tjclrun은 JCLLIB 문장에 지정된 JCL 라이브러리(라이브러리, PDS 데이터 셋)에서 해당 JCL 프로시저를

찾는다.

tjclrun은 JOB을 실행하는 중에 파싱이 필요한 JCL 프로시저를 JOBPARM 명령의 PROCLIB 파라미터에

기술된 ddname에 해당하는 JCL 라이브러리에서 찾는다. 파싱이 필요한 대상을 앞에서 설명한 JCL 라이

브러리 상에서 찾을 수 없는 경우에는 마지막으로 SYS1.PROCLIB이라는 기본 위치에서 찾는다. 여기에

서도 찾을 수 없는 경우, JOB은 비정상 종료 처리 즉, JOB은 FLUSH 상태로 종료된다.

참고

INPJCL(JOB 스트림)에 JOBPARM 명령이 지정된 경우 이 명령의 PROCLIB 파라미터에 지정된

ddname은 tjes.conf설정파일의 [PROCLIB] 섹션에 설정되어 있어야 한다.

3.1.3. 실행 과정

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

STEP을 실행한다.

참고

JCL의 JOB 문장에 RESTART 파라미터가 지정된 경우 RESTART 파라미터에 지정된 JOB STEP부

터 실행한다.

실행 단계

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

1. Lock phase

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

2. Exec phase

실제로 JOB STEP을 순서대로 실행하는 단계이다.

tjclrun은 미리 INPJCL 및 JCL 프로시저를 분석하여 해당 JOB에서 사용할 데이터 셋의 리스트를 얻고 실

제 실행 단계에 들어가기 전에 해당 데이터 셋들에 대해 일괄적으로 Lock을 요청함으로써 서로 다른 여러

개의 JOB이 동시에 동일한 데이터 셋을 독점적(exclusive)으로 사용하는 경우 빈번하게 발생되는 Dead

Lock 상황을 방지한다.

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

다.


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

● 프로그램 STEP

처리해야 하는 JOB STEP이 프로그램을 실행하는 경우 지정된 프로그램을 실행한다. tjclrun은 프로그

램을 자신의 자식 프로세스로서 실행하고 그 프로그램의 실행이 종료될 때까지 기다린다. 실행한 프로

그램의 실행이 종료되기를 기다리는 중에 주기적으로 프로그램이 수행한 데이터 셋 I/O 통계 등의 정보

를 TJES에 보고한다.

● 프로시져 STEP

처리해야 하는 JOB STEP이 JCL 프로시저를 호출하는 경우 지정된 JCL 프로시저를 파싱하고 그 결과

를 가지고 해당 프로시저를 실행한다. JCL 프로시저 STEP을 실행하고 나면 해당 JCL 프로시저를 호출

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

조건 실행

다음과 같이 서로 다른 방식으로 JOB을 구성하는 JOB STEP을 조건적으로 실행할 수 있다.

● EXEC COND

실행한 이전 JOB STEP의 종료상태에 따라서 다음에 실행할 JOB STEP을 처리할지 건너뛸지를 결정

한다. 이러한 방식의 조건적인 JOB STEP의 실행은 EXEC문의 COND 파라미터를 이용하여 지정한다.

● JOB COND

실행한 배치 프로그램이 종료하면 프로그램의 종료 상태가 JOB COND(예외상황)를 만족하는지 검사

하고 JOB COND를 만족하면 더 이상의 JOB STEP을 실행하지 않고 JOB을 에러로 종료한다.

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

3.1.4. 프로그램 실행

tjclrun의 가장 중요한 역할이 바로 사용자가 지정한 프로그램을 실행하는 것이며, 다음과 같은 세부 작업

으로 이루어진다.

EXEC COND

EXEC PGM STEP을 실행하기 전에 먼저 해당 EXEC문에 기술된 COND 파라미터를 평가하여 이전 STEP

의 실행 결과가 EXEC COND를 만족하는 경우 (즉, 예외상황인 경우) 해당 EXEC PGM STEP을 실행하지

않고 건너뛴다.

JOB에서 실행되는 첫번째 JOB STEP은 항상 EXEC COND가 만족하지 않는 것으로 평가된다.

EXEC COND가 만족되지 않는 경우는 해당 JOB STEP (프로그램 STEP)을 다음과 같은 절차로 실행한다.

1. STEP 진행 보고


해당 프로그램 STEP의 처리 시작을 TJES에게 보고한다.

2. 프로그램 실행 권한

실행할 프로그램을 JOB USER가 실행할 수 있는 권한이 있는지 검사한다. tjclrun.conf 설정파일의

[TACF] 섹션의 CHECK_UTAUTH=YES가 설정되어 있는 경우에만 권한 검사를 수행한다.

3. STEP DD 할당

프로그램 STEP에서 호출할 배치 프로그램이 사용할 데이터 셋을 지정하는 DD문을 처리하여 데이터

셋을 할당한다. 한 STEP에서 중복 DD가 발견된 경우에는 나중에 지정된 DD는 tjclrun에서 임의의 DD

로 변경하여 프로그램에서 사용되지 않도록 한다. JOB STEP 레벨의 스페셜 DD문에 대한 부가적인 처

리도 이 단계에서 처리된다. JOB STEP 레벨의 스페셜 DD문으로는 STEPCAT DD 및 STEPLIB DD문

이 있다.

4. 프로그램 파라미터

프로그램에 전달될 실행 파라미터를 만든다. 프로그램은 이 파라미터를 일반적인 UNIX 프로그램의

argc 또는 argv를 통해서 얻을 수 있다.

참고

프로시져 STEP에서 지정된 PARM은 호출되는 JCL 프로시저 내부에 포함된 프로그램의 PARM의

값을 덮어쓰도록 전달한다.

5. 호출/실행

실제로 시스템 함수를 이용하여 프로그램을 호출(fork)하는 단계이다. TJES에서 프로그램은 tjclrun 프

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

프로세스를 생성하고 자식 프로세스에서 EXEC를 실행하여 지정된 프로그램을 시작한다.

6. 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 배치에서 별도의 처리 없이 배치 프로그램으로 실행하는 것이 가능하다.


참고

1. UNIX 애플리케이션의 stderr는 SYSOUT DD에 stdout의 내용과 함께 기록된다. stdout 및 stderr

모두 애플리케이션의 기본적인 출력 스트림이고 Mainframe에는 stderr에 해당하는 약속된 DD가 없

기 때문에 stderr를 SYSOUT DD에 함께 저장하고 있다.

2.tjclrun은 JCL에 기술된 SYSOUT DD와 SYSPRINT DD를 동의어로 처리한다. 하나의 JOB STEP

에 둘 다 지정된 경우는 SYSOUT DD만 사용하고 SYSPRINT DD는 무시된다.

7. 모니터링 보고/대기

tjclrun은 프로그램을 실행하고 해당 프로그램이 종료할 때까지 기다리면서 주기적으로 애플리케이션

에서 수행한 데이터 셋 I/O 카운트를 TJES에 보고한다.

8. STEP DD 후처리

STEP에서 할당받은 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을 계속하여 실행한다.

Return Code check

JOB COND를 통과했다면 tjclrun은 실행한 프로그램이 종료되면서 반환한 Return Code를 가지고 해당

STEP을 정상으로 할지 에러로 할지를 결정한다. 정상으로 판단되면 뒤따르는 다음 STEP을 계속하여 실

행한다. 그리고 에러로 판단되면 해당 STEP을 비정상 종료하고 뒤따르는 STEP들 중에 EXEC COND의

비정상시에 실행하도록 지정된 STEP 만을 실행한다. 비정상시에 실행되도록하는 조건에는 EVEN과

ONLY 파라미터가 있다.

참고

Return Code에 대한 자세한 내용은 “제7장 환경설정”의 “7.6. Return Code 설정”을 참고한다.


3.1.5. 프로시저 실행

JOB 실행과정에서 설명했듯이 처리해야 하는 JOB STEP이 JCL 프로시저를 호출하는 STEP인 경우, tjclrun

은 지정된 JCL 프로시저를 파싱하고 해당 프로시저의 내용을 실행한다.

해당 프로시저의 마지막 STEP까지 실행을 한 후에는 해당 프로시저를 호출한 JOB STEP의 다음 JOB

STEP들을 이어서 실행한다.

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

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

입력 스트림 프로시저는 해당 프로시저를 호출하는 INPJCL에 프로시저의 내용이 정의되어 있다. 입력

스트림 프로시저는 해당 프로시저가 정의되어 있는 INPJCL에서만 호출할 수 있다.

● 카탈로그 프로시저 (CATPROC)

카탈로그 프로시저는 JCL 프로시저들을 멤버로 갖는 JCL 라이브러리에 등록되어 있는 JCL 프로시저

이다. 카탈로그 프로시저를 호출할 때는 JCL 라이브러리에 등록되어 있는 멤버이름을 프로시져로 지정

해야 한다. 자주 사용되는 JCL 프로시저들을 모아놓은 JCL 라이브러리를 PROCLIB이라고 부르며, 카

탈로그 프로시저는 여러 다른 JCL에서 호출할 수 있다.

tjclrun은 STEP에 지정된 프로시저를 INPJCL에서 먼저 찾아보고, 없는 경우에 카탈로그 프로시저로 간주

하고 CATPROC에서 찾는다.

3.1.6. DD 처리

tjclrun은 JCL의 DD문에 기술된 프로그램이 사용할 데이터 셋을 할당하여 프로그램에서 사용할 수 있도록

해준다.

일반적인 프로그램은 자신이 사용할 데이터 셋을 스스로 할당하지 않고 JCL에 DD문을 기술함으로써 tjclrun

이 할당하게 하고 그 결과를 상속받아서 사용한다.

데이터 셋 할당 작업은 프로그램 STEP에서 프로그램을 실행하기 전에 수행된다. 프로그램이 종료된 이후

에는 할당한 데이터 셋에 대한 후처리 작업을 tjclrun이 해준다. 할당된 데이터 셋은 JOB이 종료될 때 즉,

tjclrun이 종료될 때에 할당 해제된다.

데이터 셋의 할당 작업은 DD문에 기술된 데이터 셋의 특성에 따라서 서로 다르게 처리되는데 크게 다음

과 같이 구분할 수 있다.

Normal 데이터 셋

가장 일반적인 경우로 DSNAME 파라미터에 할당할 데이터 셋의 이름이 주어진 경우이다. OpenFrame의

데이터 셋 할당 모듈을 호출하여 데이터 셋을 할당하고 프로그램이 데이터 셋을 사용할 수 있도록 그 결과

를 프로그램 환경으로 전달한다.


SYSOUT 데이터 셋

DD문에 SYSOUT 파라미터가 지정된 데이터 셋이다. SYSOUT 데이터 셋은 JOB SPOOL에 JOB의 실행

결과로 생성되는 출력 데이터를 저장하기 위해서 생성된다.

임시 데이터 셋

DD문의 DSNAME 파라미터에 지정된 데이터 셋 이름이 '&&' 로 시작되거나 DSNAME 파라미터가 지정되

지 않은 SYSOUT 데이터 셋 외의 데이터 셋 역시 임시 데이터 셋이다. 이 경우 tjclrun은 내부적으로 임시

데이터 셋에 유일한 이름을 부여한다. 임시 데이터 셋은 JOB의 실행 과정에서 생성되고 JOB이 종료될 때

삭제되는 임시 데이터 셋이다.

tjclrun은 사용자가 지정한 임시 데이터 셋 이외에도 내부적인 용도로 몇 개의 임시 데이터 셋을 사용한다.

다음에 설명한 입력 스트림 데이터 셋의 처리도 그 한가지 예이다.

● 입력 스트림 데이터 셋

INPJCL(JOB 스트림)에 DD * 또는 DD DATA의 형태로 기술된 데이터 셋을 말한다.

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

여한다. 그 이후는 일반적인 데이터 셋과 동일한 OpenFrame 데이터 셋 처리 모듈을 이용해서 할당하고

배치 프로그램에서 이 데이터 셋을 사용할 수 있게 된다. tjclrun은 JOB SPOOL에 임시로 저장한 입력

스트림 데이터 셋이 JOB 종료할 때 제거될 수 있도록 임시 데이터 셋으로 생성한다.

3.1.7. 스페셜 DD

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

//ddname DD [parameters,...]

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

른다.

주의

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

할 수 없다.

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

● SYSIN

● SYSOUT 및 SYSPRINT


● JOBLIB 및 STEPLIB

● JOBCAT 및 STEPCAT

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는 동일한 의미로 취급한다. 2개의 DD가 둘 다 존재하는 경우에는 항상

SYSOUT DD를 사용하고 SYSPRINT DD는 사용하지 않는다.

JOBLIB DD/STEPLIB DD

JOBLIB DD와 STEPLIB DD는 tjclrun이 프로그램 STEP에서 프로그램을 찾는 PDS 데이터 셋(라이브러리

경로)을 지정한다.

● JOBLIB DD

JOBLIB DD는 INPJCL의 JOB 문장과 첫번째 EXEC 문장 사이에 지정될 수 있고, 해당 JOB에서 호출되

는 프로그램을 찾는 PDS (라이브러리)를 지정한다. DD문의 concatenation 기능을 이용하여 여러 PDS

에서 프로그램을 찾아보도록 지정할 수 있다.

● 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에서 사용할 데이터 셋 카탈로그를 지정한다. 2가지

경우 모두 DD문의 concatenation을 이용해서 여러 데이터 셋 카탈로그를 지정할 수 있다.

● JOBCAT DD

JOB 스트림의 JOB 문장과 첫 번째 EXEC 문장 사이에만 지정될 수 있고, 그 JOB에서 기본적으로 사용

할 데이터 셋 카탈로그들을 지정한다.

● STEPCAT DD

JOB STEP의 EXEC문 다음에 위치하며, 그 JOB STEP에서 사용할 데이터 셋 카탈로그를 지정한다.

JOBCAT과 STEPCAT이 모두 지정된 경우는 STEPCAT이 사용된다. JOBCAT이 지정되어 있고 STEPCAT

이 지정되어 있지 않은 JOB STEP에서는 JOBCAT이 사용된다. JOBCAT 및 STEPCAT이 전혀 지정되지

않은 JOB에서는 OpenFrame 시스템의 마스터 카탈로그가 사용된다.

JOBCAT이나 STEPCAT이 지정된 경우도 지정된 카탈로그에 데이터 셋이 카탈로깅되어 있지 않은 경우

는 마스터 카탈로그에서 데이터 셋에 대한 카탈로그 정보검색을 시도한다.

3.1.8. JOB SPOOL

tjclrun은 JOB을 수행하는 여러 단계에서 다양한 목적으로 JOB SPOOL을 사용한다. tjclrun이 JOB SPOOL

에 생성하는 데이터 셋과 각각의 용도는 다음과 같다.

INPJCL

tjclrun이 실행하는 JOB 스트림을 담고 있는 JCL 파일이다.

JOB SPOOL의 다른 대부분의 파일은 tjclrun에 의해 생성되는 것에 반하여 INPJCL은 TJES의 SUBMI

TOR(obmjmsvr)가 JOB의 submit 처리를 하는 경우 추후에 tjclrun이 사용할 수 있도록 JOB SPOOL에 미

리 만들어둔다. 그 내용은 사용자가 submit한 JCL 파일과 동일하다.

CATPROC

tjclrun이 JOB을 실행하는 과정에서 카탈로그 프로시저를 처리할 때 사용한 카탈로그 프로시저의 내용을

저장하는 SPOOL 데이터 셋이다.

하나의 JOB에서 여러 개의 카탈로그 프로시저를 호출할 수 있기 때문에 CATPROC에는 JOB에서 사용할

여러 카탈로그 프로시저의 내용이 저장된다.

CATPROC도 INPJCL과 동일하게 TJES의 SUBMITOR(obmjmsvr)가 JOB의 submit처리를 하는 중에

conversion처리를 하게 되면 추후에 tjclrun이 사용하도록 JOB SPOOl에 미리 만들어둔다.


INSDSET

INPJCL에 다음과 같은 형태로 기술되어 있는 입력 스트림 데이터 셋을 tjclrun이 내부적으로 사용하기 위

해서 JOB SPOOL에 생성하는 임시 데이터 셋이다.

다음은 입력 스트림 데이터 셋을 설정하는 예이다.

//ddname DD *

line1

line2

...

lineN

/*

위의 예제의 경우 INSDSET은 line1, line2, ..., lineN을 내용으로 하는 임시 데이터 셋으로 해당 DD를 사용

하는 JOB STEP에서 생성되며, 해당 JOB STEP이 종료될 때 삭제되는 임시 데이터 셋이다. 이러한 동작

을 INSDSET SHUNT라고 부른다.

임시 데이터 셋 생성시에 레코드 길이는 tjclrun.conf의 [DD] 섹션의 INSDSET_LRECL의 지정에 따른다.

지정하지 않는 경우 기본 길이는 80이고 입력 스트림이 레코드 길이 보다 작을 경우 부족한 부분은 스페

이스로 채운다. 기본 길이보다 큰 경우에는 뒤 부분은 버려진다.

참고

1. tjclrun이 INSDSET SHUNT를 하는 이유는 입력 스트림 데이터 셋은 일반 Non-VSAM 데이터 셋과

함께 concatenation될 수 있기 때문에 입력 스트림 데이터 셋을 INPJCL에서 축출하여 데이터 셋으

로 SHUNT해둠으로써 Non-VSAM SDS의 concatenation 로직을 이용하여 일관된 방식으로 concate

nation 처리를 지원하기 위함이다.

2. INSDSET_LRECL의 설정에 대한 것은 “제7장 환경설정”의 “7.6. Return Code 설정”을 참조한다.

JESJCL

tjclrun이 파싱한 INPJCL, INSPROC 및 카탈로그 프로시저를 파싱한 결과인 parse tree를 텍스트 형태로

출력한 내용을 갖는 파일이다. 주로 문제 분석할 때 참고 자료로 사용된다.

JESMSG

tjclrun이 종료하는 경우 그 tjclrun을 실행한 Runner Slot가 해당 JOB SPOOL에 기록하는 데이터 셋이다.

그 내용은 실행된 JOB에 관련된 기본적인 정보와 JOB의 실행 과정에서 보고된 여러 가지 통계정보 그리

고 JOB STEP에 관련된 정보를 포함한다. JOB의 실행에 관련하여 TJES 시스템에서 관심이 되는 사항에

대한 요약적인 정보를 담고 있다.

SYSMSG

SYSMSG는 tjclrun의 주요 메시지 로그이다. 즉, JOB을 실행하는 과정에서 필요한 여러 하위단계의 진행

상태 및 중요 결과 메시지뿐만 아니라 작업 처리할 때 발생한 에러 메시지도 SYSMSG에 저장된다.


JOB의 실행이 비정상적으로 종료된 경우 원인분석을 위해서 우선 SYSMSG의 내용을 검토해야 한다.

SYSMSG의 내용은 tjclrun이 JOB의 JOB STEP을 실행한 순서에 따라서 세부 작업이나 동작이 발생한 시

간순서대로 기록된다.

SYSMSG에 출력되는 내용은 다음과 같다.

● 수행 중인 JOB STEP 이름

● JOB 수행 중에 할당한 데이터 셋 정보

● tjclrun이 호출한 프로그램 이름과 프로세스 ID(pid)

● tjclrun이 호출한 프로그램의 종료 상태

● tjclrun이 현재 수행 중인 동작

● tjclrun의 주요 동작의 성공 여부

● tjclrun 내부 OpenFrame 라이브러리의 stderr 메시지

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에 따라서 사용자가 출력한 내용을

추후에 프린터나 화면으로 출력하는 과정을 관리할 뿐이다.


3.1.9. JOB Control

TJES에서는 스케줄링 단계 이후의 실행 중인 JOB을 SUSPEND(일시정지)/RESUME(실행재개)/STOP(강

제종료)시킬 수 있다.

JOB의 실행을 위해서 실행 중인 여러 하위 프로세스에 대한 위와 같은 세가지 제어를 TJES에서는 JOB

CONTROL이라고 부른다. tjesmgr 혹은 OpenStudio와 같은 사용자 인터페이스를 이용하여 실행 중인

JOB에 대해서 JOB CONTROL을 할 수 있다.

참고

JOB CONTROL에 대한 자세한 명령 사용법은 “제6장 TJESMGR 명령어” 및 “OpenStudio BM 안내

서”를 참고한다.

사용자가 실행 중인 JOB에 대해서 JOB CONTROL 명령을 입력하면 다음과 같은 순서로 처리된다.

1. TJES는 tjclrun에게 JOB CONTROL을 위해 약속된 시그널(SIGUSR1)을 보낸다.

2. jclrun은 SIGUSR1을 받으면 부가적으로 전달되는 정보를 참조하여 SUSPEND/RESUME/STOP 중에

서 어떤 동작이 요청되었는지를 알아낸다.

3. 각각에 해당하는 UNIX 시스템의 JOB CONTROL 시그널(SIGSTOP/SIGCONT/SIGKILL)을 tjclrun이

JOB STEP에서 실행한 하위 프로세스에 보낸다.

4. 시그널을 받은 하위 프로세스는 시그널 종류에 따라서 실행이 일시 정지되거나 실행재개 또는 강제종

료된다.

5. 하위 프로그램에 대한 JOB CONTROL을 수행한 후 tjclrun은 그 결과를 TJES에게 보고한다.

6. tjclrun 프로세스 자체는 SUSPEND인 경우 스스로 자신에게 SIGSTOP을 보내서 실행을 일시 정지한

다. STOP인 경우는 tjclrun은 실행을 종료(exit)한다. RESUME의 경우에는 TJES에서 tjclrun에 SIGCONT

를 보내서 tjclrun을 실행 재개한다. 실행이 재개된 경우 tjclrun은 위에 설명한 것과 같이 자신이 실행한

하위 프로세스에 SIGCONT를 보낸다.

참고

tjclrun의 JOB CONTROL 구현은 UNIX 시스템의 JOB CONTROL 시그널 (SIGSTOP/SIG

CONT/SIGKILL)을 이용하여 구현되었기 때문에 프로세스의 유효사용자(effective userid)가 상이한

경우 시그널을 하위 프로세스에 전달하는 과정에서 권한 부족에 의한 에러가 발생할 수 있고, 이러한

경우 JOB CONTROL은 완벽하게 이루어지지 않을 수 있다. 이러한 상황을 고려하여 항상 완벽한

JOB CONTROL을 수행하기 위해서 시스템 운영자는 tjclrun에 root 권한을 부여해야 한다. 이에 대

한 자세한 내용은 “3.1.12. 보안” 의 "setuid root tjclrun"을 참고한다.


3.1.10. 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의 대기 문제를 쉽게 식별하고 해결할 수

있다.

3.1.11. 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의 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/sys 디렉터리의

dsalc 로그에 기록된다.

● 데이터 셋 I/O 보고

tjclrun이 할당해 준 데이터 셋을 프로그램에서 사용함에 따라 변경되는 해당 데이터 셋에 대한 I/O 카운

트 정보가 반영된다.

tjclrun은 프로그램이 실행되는 동안 수행한 데이터 셋 I/O 통계정보를 주기적으로 TJES에 보고한다. 이

를 통해서 운영자(사용자)는 특정 데이터 셋에 대해서 JOB STEP 별로 몇 건을 READ/ WRITE하고 있

는지를 모니터링 할 수 있다.

3.1.12. 보안

TACF 지원 기능

tjclrun은 다음 2가지의 TACF 보안기능을 지원한다.

1. JOB STEP의 프로그램을 실행할 권한이 있는지 검사하는 기능이다.

2. DD문에 지정된 데이터 셋들에 접근할 권한이 있는지 검사하는 기능이다.

어느 경우나 권한이 없는 경우는 JOB의 실행은 비정상 종료로 처리된다.

참고

TACF를 이용하여 특정 TACF 사용자에 대하여 프로그램 및 데이터 셋에 대한 권한을 제어하는 방법

에 대해서는 OpenFrame 안내서 중 “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 실행을 위한 대리자를 지정하는 방법은 OpenFrame 안내서 중 “TACF 운영자 안내

서”를 참고한다.

setuid root tjclrun

UNIX 시스템에서 실행 프로그램을 실행하는 사용자가 아니라 해당 프로그램 파일의 소유자 권한으로 프

로그램을 실행하기 위해서 실행 프로그램의 소유자와 파일 퍼미션을 적절하게 변경하여 프로그램 실행시

프로세스가 프로그램 파일의 소유자 권한으로 실행되도록 설정하는 작업을 setuid 작업이라고 한다. 물론

setuid된 프로그램인 경우라도 실행하는 사용자에게 해당 프로그램의 실행 권한이 있는 경우에만 실행할

수 있다. 다시 말해, setuid root 작업은 특정 프로그램을 실행시 프로그램을 실행한 사용자가 아닌 root 사

용자 권한으로 프로세스가 실행되게끔 설정하는 작업을 의미한다.

여기서 말하는 프로세스의 사용자는 UNIX 프로세스의 유효 사용자(effective userid)를 말한다. tjclrun은

프로세스가 실행되는 동안 프로세스의 실제 사용자 정보(real userid)를 tjclrun.conf의 설정과 관계없이 전

혀 변경하지 않는다. UNIX 시스템에서 파일 및 시스템 자원에 대한 권한 검사는 프로세스의 유효 사용자

에 대해서 이루어진다.

실제 사용자 정보는 실제적으로 프로세스를 호출한 사용자를 구분하기 위한 용도로 사용된다. 또한 여기

서 말하는 사용자는 TACF 사용자와는 직접적인 관련이 없는 운영 시스템 상의 사용자를 의미한다.

다음의 2가지 사항을 고려하여 필요한 경우 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 u+s 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 라이브러리를 등록

하는 설정을 통해서 OpenFrame 제품에서 제공되는 라이브러리를 공유 라이브러리 search 환경 변

수에 의존하지 않고 찾을 수 있도록 설정할 수 있다.

주의

tjclrun을 setuid root 권한으로 설치하여 운영하는 경우는 tjclrun.conf 설정파일의 [SYSLIB] 섹션을

명시적으로 설정해주어야 한다.

특히 IBM AIX와 같이 필요한 환경변수가 되어버리는 시스템에서는 필수적인 설정이다. 그렇지 않은

경우라도 tjclrun이 [SYSLIB]에 설정된 search path에서만 프로그램이나 공유 라이브러리를 찾게끔

하는 것이 보안 및 시스템 성능상으로 더 유리하다. 물론 OpenFrame 설정파일들에 대한 변경 권한

을 엄격하게 관리해야 한다.

3.1.13. tjclrun 호출

tjclrun은 다음과 같은 실행 인자와 함께 실행되어야 한다.

TJES의 Runner Slot은 JOB의 실행을 할당 받은 당시의 TJES의 상태에 기반하여 적절한 실행인자와 함

께 실행된다.

tjclrun RUNMODE JOBID INITINDEX JOBSTREAM JOBPOS [keyword args ...]

다음은 tjclrun의 인자에 대한 설명이다.


설명인자

JOB (normal run) 또는 JEM (JOB Emulation) 테스트RUNMODE

유일한 JOBID (예, JOBnnnnn)JOBID

Runner Slot 인덱스INITINDEX

JOB (normal run) 또는 JEM (JOB Emulation) 테스트JOBSTREAM

JCL문을 포함하고 있는 JOB 스트림RUNMODE

JOB 스트림에 JOB이 여러 개 있는 것을 고려한 실행할 JOB의 위치JOBPOS

● [keyword args]

RESTART=*|stepname|stepname.procstepname

재시작할 JOB STEP을 지정한다. 애스터리스크(*)는 첫번째 JOB 또는 프로시져 STEP을 의미하고,

stepname은 stepname으로 지정된 JOB STEP을 의미하며, stepname.procstepname은 stepname.proc

stepname의 PROC STEP을 의미한다.

주의

tjclrun을 쉘의 명령어 라인에서 직접 실행하는 것도 가능하기는 하지만 이렇게 실행된 경우는 TJES

의 JOB 관리의 submit 및 스케줄링 단계를 건너뛰고 직접 실행하는 경우이므로 정상적인 JOB의 실

행이 보장되지 않는다.

3.1.14. NICE를 통한 PERFORM 처리

JCL의 문법 중에 JOB문과 STEP문에 PERFORM이라는 파라미터가 있다. MainFrame에서는 이 파라미

터가 JOB이나 JOB STEP에 대한 퍼포먼스 그룹을 지정하여 해당 JOB이나 JOB STEP의 실행 중의 우선

순위를 조절하게 된다.

하지만 UNIX에서는 퍼포먼스 그룹이 존재하지 않고 프로세스 기반으로 NICE라는 기능을 통해 CPU 우선

순위 정도를 사용자들이 조절할 수 있다. OpenFrame에서는 PERFORM 파라미터에 대해서 UNIX의 NICE

와 매핑을 하여 지원을 하고 있다.

PERFORM 파라미터를 이용할지 여부와 PERFORM의 값과 NICE의 값을 매핑하는 것은 OpenFrame 설

정을 통해 할 수 있다. 이에 대한 내용은 “제7장 환경설정”의 “7.5. TJCLRUN 설정”에서 [PERFORM] 섹션

을 참고한다.

주의

UNIX에서 프로세스의 NICE의 값을 변경하기 위해서는 Supper User의 권한이 필요하다. 그러므로

PERFORM을 사용하고자 하는 경우에는 setuid 기능을 함께 사용하여야 한다. NICE의 값을 변경함

으로써 CPU 사용의 우선순위를 높일 수 있다. 이는 CPU 사용시간이 많은 JOB에는 도움이 된다. 하

지만 I/O 처리에 많은 시간을 소비하는 JOB에는 효과가 거의 없다고 볼 수 있다.


제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 BACKUPJOBQ에서 필요없게 된 JOB을 삭제하게 되면, 해당 SPOOL도 삭제하게 된다. 만약 이 때, SPOOL을 보

존해야 할 필요가 있으면 SPOOL BACKUP 기능을 사용하여 SPOOL을 백업할 수 있다.

SPOOL BACKUP 명령이 내려지면 tjes.conf 설정파일에 [SPOOL] 섹션의 SPOOL_BACKUP_DIR항목에

설정된 백업 디렉터리에 현재 날짜로 디렉터리가 생성된다.

그리고 이 디렉터리에 백업된 JOB에 대해서 해당 SPOOL을 압축하여 JOBID_JOBNAME_submitDATE_sub

mitTIME.tar.gz 형식의 파일을 생성한 후 백업된 JOB을 JOBQ와 SPOOL에서 삭제한다. 백업된 SPOOL

에 대해서 조회를 하게 되면, tjes.conf 설정파일에 [SPOOL] 섹션의SPOOL_UNPACK_DIR 항목에 설정된

디렉터리에 압축된 JOBID_JOBNAME_submitDATE_submitTIME.tar.gz 형식의 파일을 풀어 놓고, 이후

해당 JOB에 대한 SPOOL을 조회할 수 있다.

4.2. SPOOL 데이터 셋SPOOL 데이터 셋은 JOB이 수행될 때 기본적으로 생성되는 데이터 셋 (INPJCL, SYSMSG, CAT

PROC,JESMSG, JESJCL)과 JCL에 SYSOUT으로 기술되어 생성되는 데이터 셋이 있다.

다음은 데이터 셋 TEST.DATASET1의 내용을 SYSIN DD의 스크립으에 정해진 키로 TEST.DATASET2,

TEST.DATASET3정렬하는 예이다.

<TESTPROC JCL>

//TESTPROC JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1)

//STEP01 EXEC SORTPROC

//PS010.SORTIN DD DSN=TEST.DATASET1,DISP=(SHR,KEEP)

//PS010.SORTOUT DD DSN=TEST.DATASET2,DISP=(NEW,CATLG),

제4장 SPOOL 51

// DCB=(RECFM=FB,LRECL=10,BLKSIZE=100)

//SYSIN DD *

SORT FIELDS=(1,5,CH,A)

/*


//PS010.SORTIN DD DSN=TEST.DATASET1,DISP=(SHR,DELETE)



//SYSIN DD *


/*

이 JCL은 CATALOGED PROCEDURE인 SORTPROC를 사용하는 두 개의 STEP으로 되어 있다. SORT

PROC의 내용은 다음과 같고 SORT 유틸리티를 수행한다.

<SORTPROC>

//PS010 EXEC PGM=DFSORT

//SORTIN DD DUMMY

//SORTOUT DD DUMMY

//SYSPRINT DD SYSOUT=*

JCL TESTPROC을 submit하여 실행하면 다음과 같은 SPOOL 데이터 셋이 생성된다.

SPOOL LIST :

---------------------------------------------------------------------------

NO STEP DDNAME SIZE DSNAME

---------------------------------------------------------------------------

0 -------- INPJCL 495 INPJCL

1 -------- SYSMSG 4K SYSMSG

2 -------- CATPROC 278 CATPROC

3 -------- JESMSG 1K JESMSG

4 -------- JESJCL 3K JESJCL

5 STEP01/PS010 SYSPRINT 576 obmvos3.TESTPROC.JOB00013.D000003

6 STEP02/PS010 SYSPRINT 576 obmvos3.TESTPROC.JOB00013.D000007

-----------------------------------------------------------------------------

SPOOL LIST의 SPOOL 데이터 셋 내용은 다음과 같다.


INPJCL

submit된 JCL이 복사되어있다. 이후의 JOB 실행에서는 INPJCL의 내용을 사용한다.

<INPJCL>

//TESTPROC JOB CLASS=A,MSGCLASS=X,MSGLEVEL=(1,1)


//PS010.SORTIN DD DSN=TEST.DATASET1,DISP=(SHR,KEEP)



//SYSIN DD *


/*


//PS010.SORTIN DD DSN=TEST.DATASET1,DISP=(SHR,DELETE)



//SYSIN DD *


/*

SYSMSG

JOB이 실행되는 동안 tjclrun이 생성한 메시지를 저장한다.

<SYSMSG>

JOBID=JOB00013 JOBPOS=0 RUNPID=8159

TESTPROC JOB

==============================================================================

--------------------------- STEP01 EXEC PROC step ----------------------------

(JRN0210I) Start parsing Cataloged Procedure ...

---------------------------- PS010 EXEC PGM step -----------------------------

(JRN0258I) SYSIN DD SHUNT - DSNAME=JOB00013(obmvos3.TESTPROC.JOB00013.D000000)

(JRN0320I) SORTIN DD ALLOC - DSNAME=TEST.DATASET1

(JRN0320I) SORTOUT DD ALLOC - DSNAME=TEST.DATASET2

(JRN0321I) SYSIN DD ALLOC - DSNAME=JOB00013(obmvos3.TESTPROC.JOB00013.D000000)

(JRN0321I) SYSPRINT DD ALLOC - DSNAME=JOB00013(obmvos3.TESTPROC.JOB00013.D000003)



---------------------------- PS010 EXEC PGM step -----------------------------





제4장 SPOOL 53


==============================================================================



---------------------------- PS010 EXEC PGM step -----------------------------

EXEC PGM=SORT






(JRN0044I) dsalc_report_start OK

(JRN0240I) SYSPRINT DD in STEP01/PS010 open

(JRN0226I) dsio_open() for SYSIN DD - DDNAME[SYSIN] with DSN, LOCATION[STEP01]

(JRN0335I) SORTIN DD in STEP01/PS010 exported

(JRN0335I) SORTOUT DD in STEP01/PS010 exported

(JRN0335I) SYSIN DD in STEP01 exported

(JRN0335I) SYSPRINT DD in STEP01/PS010 exported

(JRN0058I) pgm pid=8160

(JRN0060I) Entering exec_pipe_loop() ...

(JRN0301I) SYSIN DD to PGM done

(JRN0245I) PGM closed stdout pipe

(JRN0061I) Leaving exec_pipe_loop() ...

(JRN0063I) pipe work done with coprocess child (PGM)

(JRN0080I) PGM pid[8160] EXITED

(JRN0065I) PS010 EXEC PGM step done with RC=0

(JRN0073I) dsalc_report_info OK

(JRN0069I) step res usage: real[ 0.23] user[ 0.00] system[ 0.01] cuser[

0.00] csystem[ 0.00]

(JRN0070I) res usage: cpu_time[ 0.01] proc_time=[ 0.23] memory_size=[-1Kb]

(JRN0345I) SORTIN DD DISPOSE COND=NORMAL

(JRN0345I) SORTOUT DD DISPOSE COND=NORMAL

(JRN0345I) SYSIN DD DISPOSE COND=NORMAL

(JRN0345I) SYSPRINT DD DISPOSE COND=NORMAL



---------------------------- PS010 EXEC PGM step -----------------------------

EXEC PGM=SORT






(JRN0044I) dsalc_report_start OK

(JRN0240I) SYSPRINT DD in STEP02/PS010 open

(JRN0226I) dsio_open() for SYSIN DD - DDNAME[SYSIN] with DSN, LOCATION[STEP02]


(JRN0335I) SORTIN DD in STEP02/PS010 exported

(JRN0335I) SORTOUT DD in STEP02/PS010 exported

(JRN0335I) SYSIN DD in STEP02 exported

(JRN0335I) SYSPRINT DD in STEP02/PS010 exported

(JRN0058I) pgm pid=8163

(JRN0060I) Entering exec_pipe_loop() ...

(JRN0301I) SYSIN DD to PGM done

(JRN0245I) PGM closed stdout pipe

(JRN0061I) Leaving exec_pipe_loop() ...

(JRN0063I) pipe work done with coprocess child (PGM)

(JRN0080I) PGM pid[8163] EXITED

(JRN0065I) PS010 EXEC PGM step done with RC=0

(JRN0073I) dsalc_report_info OK

(JRN0069I) step res usage: real[ 0.04] user[ 0.00] system[ 0.01] cuser[

0.00] csystem[ 0.01]

(JRN0070I) res usage: cpu_time[ 0.02] proc_time=[ 0.04] memory_size=[-1Kb]

(JRN0345I) SORTIN DD DISPOSE COND=NORMAL

(JRN0345I) SORTOUT DD DISPOSE COND=NORMAL

(JRN0345I) SYSIN DD DISPOSE COND=NORMAL

(JRN0345I) SYSPRINT DD DISPOSE COND=NORMAL

--------------------------- DATA SET UNALLOCATION ----------------------------

(JRN0346I) SYSPRINT DD UNALLOC COND=NORMAL

(JRN0346I) SYSIN DD UNALLOC COND=NORMAL

(JRN0346I) SORTOUT DD UNALLOC COND=NORMAL

(JRN0346I) SORTIN DD UNALLOC COND=NORMAL

(JRN0346I) SYSPRINT DD UNALLOC COND=NORMAL

(JRN0346I) SYSIN DD UNALLOC COND=NORMAL

(JRN0346I) SORTOUT DD UNALLOC COND=NORMAL

(JRN0346I) SORTIN DD UNALLOC COND=NORMAL

(JRN0333I) JOB is enqueued for output processing - JOBID=JOB00013, ABEND=0

CATPROC

JOB 실행에서 CATALOGED PROCEDURE를 사용할 때 PROCEDURE의 내용을 저장한다.

XX-------- SORTPROC in SYS1.PROCLIB --------XX


//SORTIN DD DUMMY

//SORTOUT DD DUMMY


XX-------- SORTPROC in SYS1.PROCLIB --------XX


//SORTIN DD DUMMY

//SORTOUT DD DUMMY


제4장 SPOOL 55

JESMSG

JOB과 관련된 정보와 각각의 STEP에 대한 정보가 저장된다.

---< JOB INFO >-----------------------------------------------------------------

JOB ID : JOB00013

JOB NAME : TESTPROC NODENAME : NODE1

JOB CLASS : A , JOB STATUS : D(R00000) , JOB PRTY : 5 , RUNNER INDEX : 0

JOB USER : NOUSER

JCL PATH : /home/obmvos3/openframe/volume_default/SYS1.JCLLIB/TESTPROC

TIME STAMP : SUBM 20091104163438, EXEC 20091104163439, TERM 20091104163440

RES USAGE : CPU - 0s (p:1s) , 0%

---<STEP INFO>------------------------------------------------------------------

STEP : [STEP01/PS010]

CPU 0s(p: 0s)

SORTIN TEST.DATASET1 R:3 W:0

SORTOUT TEST.DATASET2 R:0 W:3

SYSIN JOB00013(obmvos3.TESTPROC.JOB00013.D000000) R:1 W:0

SYSPRINT;20 JOB00013(obmvos3.TESTPROC.JOB00013.D000003) R:0 W:20

STEP : [STEP02/PS010]

CPU 0s(p: 0s)

SORTIN TEST.DATASET1 R:3 W:0

SORTOUT TEST.DATASET3 R:0 W:3

SYSIN JOB00013(obmvos3.TESTPROC.JOB00013.D000004) R:1 W:0

SYSPRINT;20 JOB00013(obmvos3.TESTPROC.JOB00013.D000007) R:0 W:20

다음은 JESMSG에 저장되는 JOB 정보에 대해 설명한 표이다.

설명필드

할당된 JOB의 고유번호이다.JOB ID

JOB 이름이다.JOB NAME

JOB이 실행된 TJES 노드 이름이다.NODENAME

JOB CLASS이다.JOB CLASS

JOB의 현재 상태(반환 값)이다.JOB STATUS

실행한 JOB의 JOB 스케줄링 우선순위이다.JOB PRTY

JOB을 실행한 Runner Slot 번호이다.RUNNER INDEX

JOB을 실행한 사용자이다.JOB USER

USER가 submit한 JCL 파일의 위치 및 파일이름이다.JCL PATH

JOB이 submit된 시각, JOB 실행의 시작 및 종료 시각이다.TIME STAMP

JOB 실행에 사용된 CPU 시간을 나타낸다.RES USAGE

- CPU


설명필드

- 0s : tjclrun 및 fork된 자식 프로세스의 CPU 사용량의 합 (현재는 프로세스

가 종료되었으므로 0)

- (p:2s) : tjclrun이 fork된 시점부터 종료 시까지의 시간 즉, JOB 수행시간

- 0% : JOB 수행시간 대비 CPU 사용량

다음은 JESMSG에 저장되는 STEP 정보에 대해 설명한 표이다.

설명필드

해당 JOBSTEP의 이름이다.STEP

해당 JOBSTEP 처리에 사용된 CPU 시간(실제 처리시간)이다.CPU

해당 JOBSTEP에서 발생한 SYSUT1에 대한 I/O 카운트이다.SYSUT1

해당 JOBSTEP에서 발생한 SYSUT2에 대한 I/O 카운트이다.SYSUT2

해당 JOBSTEP에서 발생한 STEPLIB에 대한 I/O 카운트이다.STEPLIB

해당 JOBSTEP에서 발생한 SYSPRINT에 대한 I/O 카운트이다.SYSPRINT

JESJCL

INPJCL에 대하여 JCL 문장의 parse tree가 저장된다.

<JESJCL>

JOB STREAM=[/home/obmvos3/openframe/spool/JOB00013/INPJCL], JOBPOS=[0]

========================================================================

/JOB[name=TESTPROC,lineno=1]={

|[key=CLASS]={STR,value=[A]}

|[key=MSGCLASS]={STR,value=[X]}

|[key=MSGLEVEL]={SUB,value={

| |[pos=1]={STR,value=[1]}

| |[pos=2]={STR,value=[1]}

|}}

|-------- child statements --------

|/EXEC[name=STEP01,lineno=2]={

| |[pos=1]={STR,value=[SORTPROC]}

|}

|/DD[name=PS010.SORTIN,lineno=3]={

| |[key=DSN]={STR,value=[TEST.DATASET1]}

| |[key=DISP]={SUB,value={

| | |[pos=1]={STR,value=[SHR]}

| | |[pos=2]={STR,value=[KEEP]}

| |}}

제4장 SPOOL 57

|}

|/DD[name=PS010.SORTOUT,lineno=4]={

| |[key=DSN]={STR,value=[TEST.DATASET2]}

| |[key=DISP]={SUB,value={

| | |[pos=1]={STR,value=[NEW]}

| | |[pos=2]={STR,value=[CATLG]}

| |}}

| |[key=DCB]={SUB,value={

| | |[key=RECFM]={STR,value=[FB]}

| | |[key=LRECL]={STR,value=[10]}

| | |[key=BLKSIZE]={STR,value=[100]}

| |}}

|}

|/DD[name=SYSIN,lineno=6]={

| |[pos=1]={STR,value=[*]}

| |[key=DATA]={DAT,value={count=1

{{{/DAT ------------------------------


}}}/DAT ------------------------------

| |}}

|}

...

JCL에서 SYSOUT으로 정의된 SPOOL 데이터 셋

주로 JCL에 기술된 유틸리티나 애플리케이션에서 Output으로 사용된다. 현재 이 예제에서는 STEP01,

STEP02에서 각각 SORT 메시지를 저장하는 SYSPRINT문에 대하여 SPOOL 데이터 셋이 생성되었다.

<STEP01/PS010 SYSPRINT SAZA.TESTPROC.JOB00012.D000004>

dfsort version 5.0.1(1) obmvos3@TP3:ofsrc5/batch(#1) 2009-09-04 19:32:57

163439 M SRT0001M parsing starts.

163439 M SRT0002M parsing finishes.

<<PROSORT SCRIPT>>

DEFREC FIXED,SIZE=10

DATASIZE 1M

MEMORY 512M

WORKSPACE = (

/home/obmvos3/openframe/temp/sort0,


/home/obmvos3/openframe/temp/sort2)



163439 U MSGXXXXU 3 records are released

163439 U MSGXXXXU 3 records are returned

163439 M SRT3002M sorting finishes.

163439 M SRT9002M 3 records are written.

<STEP02/PS010 SYSPRINT SAZA.TESTPROC.JOB00012.D000009>

dfsort version 5.0.1(1) obmvos3@TP3:ofsrc5/batch(#1) 2009-09-04 19:32:57

163439 M SRT0001M parsing starts.

163439 M SRT0002M parsing finishes.

<<PROSORT SCRIPT>>

DEFREC FIXED,SIZE=10

DATASIZE 1M

MEMORY 512M

WORKSPACE = (



/home/obmvos3/openframe/temp/sort2)


163439 U MSGXXXXU 3 records are released

163439 U MSGXXXXU 3 records are returned

163439 M SRT3002M sorting finishes.

163439 M SRT9002M 3 records are written.

제4장 SPOOL 59

제5장 OUTPUT Processing

OUTPUT Processing은 JOB 수행 도중에 생성된 SYSOUT을 JOB이 종료된 후에 처리하는 단계이다.

OpenFrame에서 프린터로 출력하는 작업은 엄밀히 말하면 물리적인 프린터를 직접 가동시키는 것은 아

니고, 외부 프린터 솔루션에 프린트할 데이터와 프린트에 사용될 리소스 정보(FORM, FORMS, CHARS

등)를 전달하는 것이다. 외부 프린터 솔루션에 데이터와 정보를 전달하기 위해 print.conf [PRINTn] 섹션에

있는 COMMAND와 DRIVER_PATH에 필요한 명령어와 공유 라이브러리의 경로를 설정해야 한다.

5.1. OUTPUTOUTPUT이란 OUTPUT Processing에서 처리되는 단위로, JOB 수행이 완료된 후 생성된 SPOOL 데이터

셋은 OUTPUT Processing 단계를 거치게 된다.

하나의 SPOOL 데이터 셋이 한 개의 OUTPUT으로 처리된다.

5.2. OUTPUT 처리JOB 수행이 끝나면 SPOOL 데이터 셋은 OUTPUT 단위로 OUTPUTQ에 등록된다. 등록된 OUTPUT은

ofrpmsvr에 의해 스케줄링되어 프린트되거나 인터널 리더에 의해 다시 submit된다. 그리고 ofrpmsvr은

print.conf의 [PRINTERn] 섹션의 CLASS 설정과 OUTPUT CLASS와 비교하여 스케줄링하고, OUTPUT

DISPOSITION에 따라 OUTPUT을 처리한다.

5.2.1. OUTPUT CLASS

OUTPUT에 부여된 1 바이트 문자로 A-Z, 0-9가 사용된다. OUTPUT CLASS는 JCL에서 지정한다.

다음에서는 PRINT DD의 OUTPUT CLASS가 Y로 지정된다.

//PRINT DD SYSOUT=Y

OUTPUT CLASS를 애스터리스크(*)로 지정하는 경우 애스터리스크(*)로 지정하면 JOB문에서 MSGCLASS

로 지정된 CLASS가 OUTPUT CLASS로 지정된다.

다음 예에서는 PRINT DD의 OUTPUT CLASS가 X로 지정된다.

//COPY02 JOB CLASS=I,MSGCLASS=X,MSGLEVEL=(1,1)

...

//PRINT DD SYSOUT=*

제5장 OUTPUT Processing 61

5.2.2. OUTPUT DISPOSITION

OUTPUT에 부여된 조치사항이다. JOB이 성공적으로 종료되었는지 여부에 따라 정상 처리(Normal Dispo

sition)와 비정상 처리(Abnormal Disposition)로 나뉜다.

OUTPUT DISPOSITION의 종류와 성격은 다음과 같다.

설명종류

사용자가 release할 때까지 처리를 대기한다.HOLD

OUTPUT이 스케줄링되어 프린트 되어야 함을 의미한다. 프린터 솔루션을 호

출한 후 OUTPUT이 삭제된다.

WRITE

OUTPUTQ에서 삭제한다.PURGE

WRITE와 같다. 다만 출력작업이 끝난후 삭제하지 않고, LEAVE 상태로 남아

있는다.

KEEP

HOLD와 같다. 다만 사용자가 release하게 되면 KEEP상태로 된다.LEAVE

OUTPUT DISPOSITION은 다음과 같은 방법으로 지정한다.

1. OUTPUT CLASS에 따라 환경파일에 설정된 값으로 지정된다.

환경파일은 tjes.conf의 [OUTclass] 섹션에서 OUTPUT DISPOSITION이 클래스에 따라 다음과 같은 예

처럼 정의된다.

OUTPUT CLASS가 A인 OUTPUT은 '(WRITE,WRITE)'로 지정되고, OUTPUT CLASS가 B이면

'(HOLD,PURGE)'로 지정된다.

만약 OUTPUT CLASS에 해당하는 DISP가 [OUTclass] 섹션에 정의되어 있지 않으면 기본 값으로

'(PURGE,PURGE)'가 사용된다.

[OUTclass]

A=WRITE,WRITE

B=HOLD,PURGE

2. JCL에서 HOLD로 지정한다.

다음과 같이 SYSOUT의 HOLD 오퍼랜드를 사용하여 HOLD를 지정할 수 있다.

//PRINT DD SYSOUT=A,HOLD=YES

3. JCL에서 KEEP으로 지정한다.

다음과 같이 /*OUTPUT 문장을 사용하여 KEEP을 지정할 수 있다.

/*OUTPUT 2400 KEEP=YES

//PRINT DD SYSOUT=(A,,2400)


프린트되어야 할 OUTPUT들은 OUTPUT DISPOSITION이 WRITE 또는 KEEP일 때 OUTPUT CLASS 정

보를 print.conf의 [PRINTERn]섹션에 등록된 클래스 정보와 비교하여 정보가 맞으면 프린트된다.

[PRINTERn] 섹션에 등록된 클래스 정보가 SYSOUT의 OUTPUT CLASS를 포함하고 있으면, ofrpmsvr은

[PRINTERn]에 설정된 명령어와 공유 라이브러리를 사용하여 외부 프린터 솔루션에 데이터와 프린트 리

소스 정보를 전달한다.

제5장 OUTPUT Processing 63

제6장 TJESMGR 명령어

tjesmgr는 JOB과 TJES를 관리하는 기능 뿐만 아니라 데이터 셋과 관련한 작업과 SPOOL 백업 기능 등

을 수행한다.

tjesmgr는 TACF 또는 OS 사용자로 로그인을 해야 하며, submit할 JCL에 따로 사용자가 파라미터로 등록

되어 있지 않다면, 로그인된 사용자는 JOB을 submit하는 사용자가 된다.

tjesmgr는 tjesmgr에 접속한 후 tjesmgr 실행 화면에서 명령어를 수행하는 것이 일반적이지만, UNIX 시스

템의 명령어 라인에서 하나의 명령어를 실행하는 것도 가능하다. 실행 방법은 tjesmgr –h를 통해서 확인

할 수 있다.

● tjesmgr 사용 방법 조회

$ tjesmgr -h

● tjesmgr 버전 정보 조회

$ tjesmgr -v

● tjesmgr 실행방법

$ tjesmgr -i[ USERID[ [GROUPNAME] ]][/PASSWORD] [command]

다음은 UNIX 명령어 라인에서 PS(Print Screen)를 실행하는 예이다.

$ tjesmgr –iUSERNAME/PASSWORD ps n=TEST

다음은 선행 명령어가 필요한 경우로 명령어 처리를 할 수 없다.

$ tjesmgr –iUSERNAME/PASSWORD

$ PODD JOB00001 di=1

PSJOB 또는 POSPOOL이 먼저 실행되어야 PODD 명령을 실행할 수 있다. 따라서 명령어 라인에서 위의

예제는 실행할 수 없다.

참고

자세한 내용은 “6.2.8. PODD (Print Output DD Information)” 명령어를 참고한다.

제6장 TJESMGR 명령어 65

6.1. JOB 실행 명령어

JOB을 submit하고 JOB의 상태를 변경할 수 있는 명령어들이다.

6.1.1. RUN

입력 파라미터에 따라서 JOB을 submit한다. submit을 하게 되면 JOB은 START 상태로 JOBQ에 쌓이고

PS 명령어를 통해서 JOBQ에 쌓인 JOB을 확인할 수 있다.

RUN(R) <JCLFILE>

[NODE=<node-name>]

[STEP=<restart-step>]

[CAT=<catalog-name>]

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

설명항목

JCL 이름 또는 UNIX 파일경로를 지정해 주거나 DATASET(member) 형식으

로 지정할 수 있다. JCL 이름으로 설정하면 tjes.conf의 [PROCLIB] 섹션의

JCLLIB과 USERLIB에 설정된 DATASET에서 JCL을 찾는다.

<JCLFILE>

node-name을 지정한 경우는 지정한 노드에서 JOB이 수행되도록 submit 할

수 있다.

[NODE=<node-name>]

node-name을 지정하지 않은 경우는 tjesmgr.conf 의 [DEFAULT_OPTION]

섹션의 DEFAULT_RUNNING_NODE에 설정된 값에 따라서 현재 노드에서

만 JOB을 수행할 수 있도록 할지 아니면, 전체 노드 중 아무 노드에서나 JOB

을 수행할 수 있도록 할지를 결정한다.

restart-step을 지정하게 되면 JCL에 지정된 STEP부터 JOB이 실행된다.[STEP=<restart-step>]

JCLFILE을 DATASET(member) 형식으로 설정할 때 데이터 셋이 사용자 카

탈로그에 등록되어 있다면 CAT=<catalog-name>를 지정한다.


6.1.2. START

입력된 job-ID 또는 job-name에 해당하는 JOB들의 상태를 HOLD 상태에서 START 상태로 바꾼다.

HOLD 상태의 JOB들에 대해서만 START 명령어가 유효하다.

START {<job-ID>|N=<job-name>}


6.1.3. HOLD

입력된 job-ID 또는 job-name에 해당하는 JOB들의 상태를 START 상태에서 HOLD 상태로 바꾼다. HOLD

상태의 JOB은 스케줄링이 되지 않는다.

START 상태의 JOB들에 대해서만 유효하다.

HOLD {<job-ID>|N=<job-name>}

6.1.4. SUSPEND

입력된 job-ID 또는 job-name에 해당하는 JOB들의 상태를 WORKING 상태에서 SUSPEND 상태로 바꾼

다. 즉, 실행 중인 JOB을 일시 정지시킨다.

WORKING 상태의 JOB들에 대해서만 유효하다.

SUSPEND {<job-ID>|N=<job-name>}

6.1.5. RESUME

입력된 job-ID 또는 job-name에 해당하는 JOB들의 상태를 SUSPEND 상태에서 RESUME 상태로 바꾼다.

즉, 일시 정지된 JOB을 다시 실행시킨다.

SUSPEND 상태의 JOB들에 대해서만 유효하다.

RESUME {<job-ID>|N=<job-name>}

6.1.6. STOP

입력된 job-ID 또는 job-name에 해당하는 JOB들의 상태를 WORKING 상태에서 STOP 상태로 바꾼다. 즉,

실행 중인 JOB을 중지시킨다.

RESUME 상태이거나 WORKING 상태의 JOB들에 대해서만 유효하다.

STOP {<job-ID>|N=<job-name>}

6.1.7. REMOVE

입력된 job-ID 또는 job-name에 해당하는 JOB들을 제거한다.

DONE, ERROR, STOP, FLUSH 상태의 JOB들에 대해서만 유효하다.

REMOVE {<job-ID>|N=<job-name>}


6.1.8. CANCEL

입력된 job-ID 또는 job-name에 해당하는 JOB들을 제거(purge)한다.

HOLD 상태이거나 START 상태의 JOB들에 대해서만 유효하다.

CANCEL {<job-ID>|N=<job-name>}

6.1.9. NICE

입력된 job-ID 또는 job-name에 해당하는 JOB들에 중앙 처리 장치의 사용시간에 대한 상대적인 우선순위

를 설정한다. 2번째 인자인 <number>는 0에서 20까지의 숫자이며, 숫자가 낮을 수록 우선순위가 높다. 이

우선순위는 중앙처리장치의 사용시간의 우선순위이며, 입출력의 우선순위는 아니다.

WORKING 상태의 JOB들에 대해서만 유효하다.

NICE {<job-ID>|N=<job-name>} <number>

6.1.10. OUTQUEUEPURGE

입력된 job-ID 또는 out-number에 해당하는 JOB들의 OUTPUT들을 OUTPUTQ에서 제거한다. out-number

는 POLIST나 POJOB 명령어로 출력되는 OUTPUTID의 숫자를 말한다.

OUTQUEUEPURGE(OR) {<job-ID>|ON=<out-number>}

참고

OUTPUT에 대한 자세한 내용은 “5.1. OUTPUT” 을 참고한다.

6.1.11. INQUEUECLASS

입력된 job-ID 또는 job-name에 해당하는 JOB들의 class을 변경한다.

HOLD 상태이거나 START 상태인 JOB들에 대해서만 유효하다. 주로 해당 클래스의 Runner가 전부 할당

되어 있어서 대상 JOB을 바로 실행하지 못하는 경우에 사용하게 된다.

INQUQUECLASS(IC) {job-ID|N=<job-name>} C=<class>


6.2. JOB/OUTPUT 명령어

JOB을 submit한 후의 JOB 진행 상태와 결과 그리고 OUTPUT 관련 정보를 볼 수 있는 명령어이다.

6.2.1. PS (Print Screen)

입력 파라미터의 조건에 해당하는 JOBQ에 있는 JOB들에 대한 JOBNAME, JOBID, CLASS, STATUS,

RC, NODE, JCL 리스트를 보여준다.

PS [{ N=<job-name> |

[C=<class>] [S=<job-status>] [RC=<return-code>] [NODE=<node-name>] |

<from-job-ID> [C=<class>] [S=<job-status>] [RC=<return-code] [NODE=<node-name] |

<job-status> } ]

디스플레이 정보

JOBQ상의 JOB에 대한 디스플레이 정보는 다음과 같다.

설명정보

디스플레이 대상 JOB의 JOBNAME이다.JOBNAME

디스플레이 대상 JOB의 JOBID이다.JOBID

디스플레이 대상 JOB CLASS이다.CLASS

디스플레이 대상 JOB의 현재 STATUS이다.STATUS

디스플레이 대상 JOB의 리턴코드이다.RC

JOB이 실행된 노드명이다.NODE

JOB이 기술되어있는 JCL 이름이다.JCL

참고

CLASS, STATUS, RETCODE, NODENAME과 같은 순서로 조건을 주어야 한다.

- 올바른 예) PS c=A, s=W, rc=0

- 틀린 예) PS s=W, c=A → 파싱 에러 발생

6.2.2. PSJOB (Print Screen JOB detail information)

입력된 job-ID에 해당하는 JOB에 대한 상세 정보를 출력한다. 만약, 대상 JOB의 상태가 WORKING인 경

우에는 상세 정보를 1초 단위로 업데이트해서 출력한다.

PSJOB(PSJ) <job-ID>



PSJOB 디스플레이 정보는 다음과 같다.

설명정보

디스플레이 대상 JOB의 JOBID이다.JOBID

JOB이 실행된 노드명이다.NODE NAME

디스플레이 대상 JOB의 JOB 이름이다.JOB NAME

디스플레이 대상 JOB CLASS이다.JOB CLASS

디스플레이 대상 JOB의 현재 STATUS이다.JOB STATUS

DONE, ERROR, FLUSH인 경우 괄호( )안에 JOB의 리턴 값이 들어간다.

디스플레이 대상 JOB의 우선순위이다.JOB PRTY

JOB이 실행된 Runner index이다. Runner Slot에 대한 정보는 PSJCLRUN

에서 확인할 수 있다.

JCLRUNNER INDEX

디스플레이 대상 JOB 상태가 WORKING 중에 WAIT하고 있는 이유이다.JOB WAIT

디스플레이 대상 JOB을 submit한 USER이다.JOB USER

디스플레이 대상 JOB의 JCL 경로를 나타낸다.JCL PATH

JOB의 submit, start, end 시간을 나타낸다.TIME STAMP

해당 JOB의 리소스 사용량을 나타낸다.RES USAGE

- PROCESS : 프로세스 총 사용시간이다.

- CPU : CPU 총 이용시간이다.

- CPU ?% : working중인 프로세스의 CPU 점유율로, 해당 JOB 상태가

WORKING 중인 경우만 나타난다.

- MEM ?Kb : working중인 프로세스의 메모리 크기로, 해당 JOB 상태가

WORKING인 경우만 나타난다.

디스플레이 대상 JOB의 STEP별 정보를 보여준다.STEP LIST

- [???]: STEP name

- START : STEP 시작시간

- RC : STEP의 리턴코드

- CPU : STEP에서 CPU 이용시간

- / ??s : STEP의 총 소요시간

디스플레이 대상 JOB의 SPOOL LIST를 보여준다.SPOOL LIST


설명정보

POSPOOL의 디스플레이 정보와 동일하다.

대상 JOB의 OUTPUT 처리에 대한 내용을 나타낸다.OUTPUT PROCESS-ING

STATUS

WORKING중인 JOB의 경우의 디스플레이 정보는 다음과 같다.

설명정보

현재 처리하고 있는 STEP을 나타낸다.[STEPNAME] CURRENT

PROCESSING

- R: 해당 데이터 셋의 읽기 시도 횟수이다.DDNAME JOBID(DSNAME)

R:? W:?- W: 해당 데이터 셋의 쓰기 시도 횟수이다.

주의

PSJOB 명령은 UNIX command line으로는 실행을 할 수 없다.

6.2.3. PSIO (Print Screen Input/Output information)

입력된 job-ID에 해당하는 JOB의 데이터 셋 I/O 횟수를 보여준다.

PSIO <job-ID>

다음은 PSIO의 입력 항목에 대한 설명이다.

설명항목

입력된 job-ID에 해당하는 JOB의 데이터 셋 I/O 횟수를 보여준다.<job-ID>


데이터 셋 I/O 디스플레이 정보는 다음과 같다.

설명정보

해당 STEP의 이름이다.[STEP]

JCL에 기술된 DD 이름이다.DDNAME

데이터 셋 이름이다.DSNAME

STEP별 데이터 셋의 검색된 횟수이다.RTV (Retrieved count)

STEP별 데이터 셋의 추가된 횟수이다.INS (Inserted count)


설명정보

STEP별 데이터 셋의 업데이트된 횟수이다.UPD (Updated count)

STEP별 데이터 셋의 삭제된 횟수이다.DEL (Deleted count)

6.2.4. PO (Print Output status)

JOBID별 OUTPUT 상태를 보여준다.

PO


JOBID별 OUTPUT 상태에 대한 디스플레이 정보는 다음과 같다.

설명정보

디스플레이 대상 JOBID이다.JOBID

디스플레이 대상 OUTPUT 상태이다.OUTPUT STATUS

6.2.5. POLIST (Print Output detail LIST)

OUTPUT 리스트들의 상세 정보를 보여준다.

POLIST


OUTPUT 리스트에 대한 디스플레이 정보는 다음과 같다.

설명정보

디스플레이 대상 OUTPUT ID이다.OUTPUTID

디스플레이 대상 JOBID이다.JOBID

디스플레이 대상 JOB 이름이다.JOBNAME

디스플레이 대상 DD에 부여된 ID이다.DDID

JCL에 기술되었던 DD 이름이다.DDNAME

디스플레이 대상 OUTPUT CLASS이다.CLS (OUTPUT CLASS)

OUTPUT 상태이다.ST (OUTPUT STATUS)

디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.FORMS

디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.CHARS


설명정보

디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.FORMDEF

디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.PAGEDEF

디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.WRITER

참고

DDID, FORMS, CHARS, FORMDEF, PAGEDEF, WRITER들은 PRINT 관련 정보들이다. 이에 대한

자세한 내용은 “제4장 SPOOL”과 “제5장 OUTPUT Processing”을 참고한다.

6.2.6. POJOB (Print Output of JOB)

입력된 job-ID에 해당하는 JOB의 OUTPUT 정보를 보여준다.

POJOB(POJ) <job-ID>

다음은 POJOB의 입력 항목에 대한 설명이다.

설명항목

입력된 job-ID에 해당하는 JOB의 OUTPUT 정보이다.<job-ID>


JOB의 OUTPUT에 대한 디스플레이 정보는 다음과 같다.

설명정보

디스플레이 대상 OUTPUT ID이다.OUTPUTID

디스플레이 대상 DD에 부여된 ID이다.DDID

JCL에 기술되었던 DD 이름이다.DDNAME

디스플레이 대상 OUTPUT CLASS이다.CLS

OUTPUT 상태이다.ST

디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.FORMS

디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.CHARS

디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.FORMDEF

디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.PAGEDEF

디스플레이 대상 JOB의 프린트 관련 옵션 정보이다.WRITER


참고

POJOB의 디스플레이 정보는 POLIST의 디스플레이 정보와 동일하다.

6.2.7. POSPOOL (Print Output SPOOL of JOB)

입력된 JOBID에 해당하는 JOB의 SPOOL 정보를 보여준다.

POSPOOL <job-ID>

다음은 POSPOOL 입력 항목에 대한 설명이다.

설명항목

입력된 job-ID에 해당하는 JOB의 SPOOL 정보이다.<job-ID>


SPOOL에 대한 디스플레이 정보는 다음과 같다.

설명정보

DDINDEX로 PODD 명령을 실행하는 경우 입력 파라미터로 사용된다.NO

해당 SPOOL이 생성된 STEP 이름이다.STEP

해당 SPOOL의 DD 이름이다.DDNAME

해당 SPOOL의 크기이다.SIZE

해당 SPOOL의 데이터 셋 이름이다.DSNAME

관련 환경설정

SPOOL_LIST는 SPOOL을 보여줄 조건을 설정한다.

<tjesmgr.conf >

[DEFAULT_OPTION]

SPOOL_LIST={ALL|EXIST|GTZERO}


6.2.8. PODD (Print Output DD Information)

입력된 job-ID의 dd-index 또는 dd-name에 SPOOL을 tjesmgr.conf의 [DEFAULT_OPTION] 섹션의

VIEWER 항목에 설정한 뷰어로 열어준다. PODD 명령어를 사용하기 위해서는 PSJOB이나 POSPOOL

명령이 선행되어야 한다.

PODD <job-ID> { DI=<dd-index> | DN=<dd-name> }

관련 환경설정

SPOOL을 열수 있는 뷰어를 지정한다.

<tjesmgr.conf>

[DEFAULT_OPTION]

VIEWER=viewer

6.2.9. PSHISTORY (Print Screen of JOB History)

PSHISTORY 명령을 실행하면 입력 창이 뜨고, 사용자로부터 입력 받은 조건에 해당하는 내용을 찾아 뷰

어로 보여준다. 아무런 조건도 주지 않은 경우 전체 로그를 보여준다.

PSHISTORY(PSH)

입력 파라미터

사용자에게 다음의 파라미터에 대한 입력을 요구한다.

설명파라미터

JOB을 submit한 USERID를 설정한다.USERID

날짜의 범위를 지정한다.DATE

SUBMIT, EXECUTE, SUSPEND, RESUME, FINISH, REMOVE 중에서 조건

을 설정한다.

OPERATION

JOBID를 설정한다.JOBID

관련 환경설정

HISTORY의 결과를 보여줄 뷰어를 지정한다.

<tjesmgr.conf >

[DEFAULT_OPTION]

VIEWER=viewer


해당 환경파일에 설정되어 있는 로그 파일에서 검색한다.

<tjes.conf >

[LOG]

JOBLOG=joblog

검색한 내용을 임시로 기록할 위치이다.

<ofsys.conf >

[DIRECTORY]

TEMP_DIR=temp_dir

6.3. INITIATOR 명령어

JOB의 실행을 위한 TJES 환경에 관련된 명령어들이다.

6.3.1. BOOT

전체 노드의 TJES를 부트한다. 부트가 된 노드에서는 JOB을 실행할 수 있다. Runner Slot에 JOB을 할당

할 수 있게 된다.

BOOT [NODE=<node-name>]

다음은 BOOT 입력 항목에 대한 설명이다.

설명항목

node-name을 준 경우 대상 노드만을 부트한다.[NODE=<node-name>]

6.3.2. SHUTDOWN

전체 노드의 TJES를 다운(down)시킨다. 다운을 하게 되면 비어있는 Runner Slot들을 모두 다운 상태로

변경하여 추가적인 JOB의 스케줄링을 제한하고 WORKING 중인 Runner Slot들은 JOB이 끝나는 대로 다

운 상태로 변경한다.

SHUTDOWN [NODE=<node-name>]

다음은 SHUTDOWN 입력 항목에 대한 설명이다.

설명항목

node-name을 준 경우 대상 노드만을 다운시킨다.[NODE=<node-name>]


참고

명령어에 대한 자세한 사항은 “6.3.10. PSJCLRUN (PSR)”을 참고한다.

6.3.3. NODECLEAR

해당 노드의 모든 JOB을 STOP시킨다. 보통 해당 노드가 비정상적으로 되어서 해당 노드에 있는 JOB을

더 이상 컨트롤할 수 없을 때 사용한다.

NODECLEAR NODE=<node-name>

6.3.4. NODESTATUS (NODEST)

전체 노드의 상태를 보여준다.

NODESTATUS(NODEST)


전체 노드에 대한 상태 디스플레이 정보는 다음과 같다.

설명정보

노드명이다NODENAME

obmjinit 서버의 상태이다. (Active, Downed)OBMJINIT_STATUS

TJES의 부트 상태이다. (Booted, Not booted)BOOT_STATUS

6.3.5. JCLRUNACTIVE (RA) / JCLRUNINACTIVE (RI)

명령어 라인에서 입력 받은 Runner Slot의 상태를 Active에서 Inactive로 또는 Inactive에서 Active로 변경

한다. 바뀐 정보는 PSJCLRUN을 통해 확인할 수 있다.

JCLRUNACTIVE(RA)/JCLRUNACTIVE(RI) I=<index>,,, [NODE=<node-name>]

인덱스는 여러 개를 지정하거나 또는 범위를 지정할 수도 있다.

형식: I=<index>,,,

node-name을 지정하지 않은 경우 자기 노드의 Runner Slot 상태를 변경한다.


다음은 JCLRUNACTIVE, JCLRUNINACTIVE 명령 사용시 범위 값을 지정하는 방법에 대한 예를 보여준

다.

$ RA I=0,1,2,3

$ RI I=0-9

관련 환경설정

현재 노드를 찾을 때 사용된다.

<tjes.conf >

[NODEINFO]

NODENAME=nodename

6.3.6. JCLRUNCLASS(RC)

해당 Runner Slot의 클래스를 입력으로 받은 클래스로 변경한다.

JCLRUNCLASS(RC) I=index,,, CS=<classes> [NODE=<node-name>]

인덱스는 여러 개를 지정하거나 또는 범위를 줄 수도 있다.

형식: I=<index>,,,

node-name을 지정하지 않은 경우 자기 노드의 클래스 설정을 변경한다.

다음은 JCLRUNCLASS 명령을 사용하여 범위 값과 클래스를 지정하는 방법에 대한 예를 보여준다.

$ JCLRUNCLASS I=0,1,2,3 CS=A

$ RC I=0-9 CS=AB

관련 환경설정

자기 노드를 찾을 때 사용된다.

<tjes.conf>

[NODEINFO]

NODENAME=nodename


6.3.7. PSCLASS(PSC)

클래스별로 JOB들의 상태 카운트를 보여준다. 클래스별로 JOB들의 NODE, CLASS, HOLD, START,

WORIKING, SUSPEND, DONE, STOP, ERROR, FLUSH 카운트를 보여준다.

PSCLASS(PSC)

6.3.8. SHOWCLASS(SC)

클래스의 상태를 보여준다. 클래스가 HOLD로 되어있으면 해당 클래스로 submit하는 JOB은 항상 HOLD

상태로 가게 된다.

SHOWCLASS(SC)


클래스에 대한 디스플레이 정보는 다음과 같다.

설명정보

클래스 이름이다.CLASS

클래스가 HOLD로 되어있는지 여부를 보여준다. (Y,N)HOLD

관련 환경설정

클래스 상태의 초기값을 지정한다. 환경 설정 파일에서 지정하지 않으면 기본값은 START이며, SHOW

CLASS 명령어를 출력할 때 N에 해당하는 값이다.

<tjes.conf>

[JOBCLASS]

class-name=HOLD|START

6.3.9. CHANGECLASS(CC)

해당 클래스의 상태를 변경한다.

CHANGECLASS(CC) C=<class> HOLD = {Y|N}

관련 환경설정

클래스 상태의 초기값을 지정한다. 환경 설정 파일에서 지정하지 않으면 기본값은 START이며,

CHANGECLASS 명령어를 출력할 때 N에 해당하는 값이다.


<tjes.conf >

[JOBCLASS]

class-name=HOLD|START

6.3.10. PSJCLRUN (PSR)

해당 노드의 Runner Slot 상태를 보여준다.

PSJCLRUN(PSR) [NODE=<node-name>]

다음은 PSJCLRUN (PSR)의 입력 항목에 대한 설명이다.

설명항목

node-name을 주지 않은 경우 자기 노드의 Runner Slot 상태를 보여준다.[NODE=<node-name>]


Runner Slot에 대한 디스플레이 정보는 다음과 같다.

설명정보

Runner 인덱스이다. JCLRUNACTIVE(RA), JCLRUNINACTIVE(RI),

JCLRUNclass(RC)에서 사용된다.

IDX

tjes.conf의 [INITDEF] 환경설정에 정의된 Runner Slot 이름이다.SLOTNAME

Runner Slot의 상태이다. (Active, Inactive, Downed)STATUS

Runner Slot에 할당되어있는 클래스들이다.class

Runner Slot에 할당된 JOB에 대한 정보들이다.JOBID,

해당 Runner Slot의 클래스나 STATUS를 RA, RI, RC나 SHUTDOWN 등의

명령으로 바꾸는 경우, 대상 Runner Slot에 JOB이 할당되어있으면 나중에

바뀔 것이라는 메시지가 나타난다.

JOBNAME,

JOBclass,

PID예) STATUS will be [DOWNED] after JOB finished

관련 환경설정

자기 노드를 찾을 때 사용된다.

<tjes.conf >

[NODEINFO]

NODENAME=nodename


Runner Slot들의 기초설정을 한다.

<tjes.conf >

[INITDEF]

6.4. 데이터 셋 명령어

데이터 셋을 조회하거나 생성, 삭제 또는 복사하기 위한 명령어들이다.

참고

USERCATALOG와 관련해서는 tjesmgr의 “SETCAT 명령어” 및 OpenFrame 안내서 중 “데이터 셋

안내서”의 "제4장 통합 카달로그"를 참고한다.

6.4.1. PSCATALOG (PSCAT)

입력 조건에 해당하는 카탈로그에 등록되어있는 데이터 셋 리스트를 보여준다.

PSCATALOG(PSCAT) <entry-prefix> [CAT=<catalog-name>]

다음은 PSCATALOG (PSCAT)의 입력 항목에 대한 설명이다.

설명항목

entry-prefix로 시작하는 모든 데이터 셋이 디스플레이 대상이 된다.<entry-prefix>

사용자 카탈로그에 등록되어 있는 데이터 셋을 찾아서 보여준다.[CAT=<catalog-name>]


카탈로그에 등록되어 있는 데이터 셋 디스플레이 정보는 다음과 같다.

설명정보

검색한 데이터 셋이다.CATALOG NAME

디스플레이 대상 데이터 셋이 들어있는 볼륨이다.VOLUME

디스플레이 대상 데이터 셋의 타입이다.ENTTYPE

데이터 셋의 타입에는 NON-VSAM, CLUSTER, AIX, PATH, GDG, UCAT,

ALIAS 등이 있다.

디스플레이 대상 데이터 셋의 종류이다.VSAM

VSAM 데이터 셋인 경우만 KSDS, RRDS 등의 데이터 셋 종류를 나타낸다.


설명정보

디스플레이 대상 데이터 셋의 종류이다.NVSM

Non-VSAM 데이터 셋인 경우만 PDS, SDS, GDS 등의 데이터 셋 종류를 나

타낸다.

6.4.2. SETCATALOG (SETCAT)

카탈로그로 하여 데이터 셋 관련 명령어에서 사용한다.

SETCATALOG(SETCAT) <catalog-name>

다음은 SETCATALOG (SETCAT)의 입력 항목에 대한 설명이다.

설명항목

입력으로 받은 catalog-name을 기본 카탈로그로 하여 데이터 셋 관련 명령어

에서 사용한다. catalog-name를 주지 않은 경우 마스터 카탈로그를 기본 카

탈로그로 한다

<catalog-name>

다음과 같이 지정하고 PSCAT, PSDS 등을 실행했을 때 CAT 파라미터를 지정하지 않은 경우 TAPECAT

을 기본 카탈로그로 해서 정보를 보여준다.

$ SETCAT TAPECAT

카탈로그의 지정 순위

1. CAT parameter로 지정된 user catalog

2. SETCAT으로 지정된 user catalog

3. Dataset alias에 따른 user catalog

4. master catalog


6.4.3. PSDATASET(PSDS)

입력에 해당하는 데이터 셋의 상세정보를 보여준다.

PSDATASET(PSDS) <dataset-name> [CAT=<catalog-name>]

[MEM=<member-prefix>] [VOL=<volume-serial>]

다음은 PSDATASET(PSDS)의 입력 항목에 대한 설명이다.

설명항목

상세정보를 조회하고자 하는 데이터 셋 이름을 입력한다.<dataset-name>

catalog-name에 등록되어있는 데이터 셋을 찾아서 보여준다.[CAT=<catalog-name>]

멤버가 있는 데이터 셋의 경우 MEM을 지정한 경우 해당 멤버를 검색해

서 보여준다.

[MEM=<member-prefix>]

카탈로그 되어있지 않은 데이터 셋의 상세정보를 보고 싶은 경우에 사

용되며, VOL을 지정한 곳에서 데이터 셋을 찾아서 보여준다.

[VOL=<volume-serial>]


데이터 셋에 대한 상세한 디스플레이 정보는 다음과 같다. ( ) 안의 정보는 데이터 셋이 VSAM type인 경우

이다.

설명정보

디스플레이 대상 데이터 셋 이름이다.Data Set Name

디스플레이 대상 데이터 셋의 타입이다.Data Set Type

디스플레이 대상 데이터 셋이 등록되어 있는 카탈로그 이름이다.Catalog Name

디스플레이 대상 데이터 셋 생성시 참고한 Management 클래스이다.Management Class

디스플레이 대상 데이터 셋의 생성일자이다.Creation Date

디스플레이 대상 데이터 셋의 실제 파일의 소유자이다.Data Set Owner

디스플레이 대상 데이터 셋의 만료일자이다.Expiration Date

디스플레이 대상 데이터 셋 생성시 참고한 Storage 클래스이다.Storage Class

디스플레이 대상 데이터 셋이 들어있는 볼륨이다.Volume Serial

디스플레이 대상 데이터 셋의 디바이스 타입이다.Device Type

테이프 데이터 셋인 경우 ‘TAPE Device’라고 나타난다.

디스플레이 대상 데이터 셋 생성시 참고한 Data 클래스이다.Data Class

디스플레이 대상 데이터 셋의 DSORG이다.Organization

디스플레이 대상 데이터 셋의 RECFM이다.Record Format (AVGLRECL)


설명정보

(디스플레이 대상 데이터 셋의 평균 길이이다.)

디스플레이 대상 데이터 셋의 KEY의 길이이다.KEYLEN

디스플레이 대상 데이터 셋의 길이이다.Record Length (MAXLRECL)

(디스플레이 대상 데이터 셋의 최대 길이이다.)

디스플레이 대상 데이터 셋의 KEY의 위치이다KEYPOS

디스플레이 대상 데이터 셋의 블록 크기이다.BLKSIZE (CISIZE)

(디스플레이 대상 데이터 셋의 CISIZE이다.)

(디스플레이 대상 데이터 셋의 AIX의 KEYPOS이다.)(AIXRKP)

디스플레이 대상 데이터 셋의 allocation하는 경우 최초 할당 크기이다.Primary Space

디스플레이 대상 데이터 셋의 allocation하는 경우 확장횟수이다.Number of Extents

디스플레이 대상 데이터 셋의 allocation하는 경우 다음 할당 크기이다.Secondary Space

디스플레이 대상 데이터 셋의 실제 크기이다.Data Set Size

테이프 데이터 셋의 경우 압축 상태로 되어있는데, DATASIZE 크기는

압축이 되지 않았을 때의 크기이다.

디스플레이 대상 데이터 셋을 마지막으로 조회하거나 수정한 날짜이다.Last Access Date

디스플레이 대상 데이터 셋을 마지막으로 조회하거나 수정한 시간이다.Last Access Time

디스플레이 대상 데이터 셋과 관련된 데이터 셋들을 보여준다.Associations

주로 VSAM 데이터 셋의 정보를 볼 때 나타난다.

멤버가 있는 데이터 셋의 경우 해당 멤버에 대한 디스플레이 정보이다.

설명정보

디스플레이 대상 멤버의 이름이다.Name

디스플레이 대상 멤버의 실제 파일의 소유자이다.Owner

디스플레이 대상 멤버의 실제 파일크기이다.Size

디스플레이 대상 멤버를 마지막으로 조회하거나 수정한 날짜 및 시간이

다.

Last Access Date


6.4.4. PSENTRY(PSENT)

입력에 해당하는 엔트리의 상세정보를 보여준다. PSDATASET와 다른 점은 GDG, PATH, ALIAS와 같이

실제 데이터 셋은 아니지만 카탈로그에 등록되어있는 엔트리들에 대한 정보도 보여준다.

PSENTRY(PSENT) <entry-name> [CAT=<catalog-name>]

다음은 PSENTRY(PSENT)의 입력 항목에 대한 설명이다.

설명항목

상세정보를 조회하고자 하는 엔트리 이름을 입력한다.<entry-name>

catalog-name에 등록되어있는 엔트리을 찾아서 보여준다.[CAT=<catalog-name>]


엔트리에 대한 상세한 디스플레이 정보는 다음과 같다.

설명정보

디스플레이 대상 엔트리 이름이다.Entry Name

디스플레이 대상 엔트리의 타입이다.Entry Type

디스플레이 대상 엔트리가 등록되어 있는 카탈로그 이름이다.Catalog Name

디스플레이 대상 엔트리의 생성일자이다.Creation Date

디스플레이 대상 엔트리의 소유자이다.Entry Owner

디스플레이 대상 엔트리의 만료일자이다.Expiration Date

디스플레이 대상 엔트리가 GDG일 때 GDS의 생성 한계 개수이다.GDG Limit

디스플레이 대상 엔트리와 관련된 엔트리들을 보여준다.Associations

6.4.5. DATASETLIST (DSLIST)

입력 조건에 해당하는 VTOC에 등록되어있는 데이터 셋 리스트를 보여준다.

VTOC에 등록되어있는 데이터 셋들은 전부 Non-VSAM 데이터 셋이다.

DATASETLIST(DSLIST) [<dataset-prefix>] [VOL=<volume-serial>]

다음은 DATASETLIST(DSLIST)의 입력 항목에 대한 설명이다.

설명항목

dataset-prefix로 시작하는 모든 데이터 셋이 디스플레이 대상이 된다.[<dataset-prefix>]

지정한 볼륨에 있는 데이터 셋이 디스플레이 대상이 된다.[VOL=<volume-serial>]


디스플레이

VTOC에 등록되어 있는 데이터 셋 디스플레이 정보는 다음과 같다.

설명정보

검색한 데이터 셋이다.VTOC name

디스플레이 대상 데이터 셋이 들어있는 볼륨이다.VOLUME

디스플레이 대상 데이터 셋의 구조이다.DSORG

디스플레이 대상 데이터 셋의 레코드 포맷이다.RECFM

디스플레이 대상 데이터 셋의 레코드 길이이다.LRECL

6.4.6. DATASETCREATE (DSCREATE)

명령을 실행하면 사용자 입력 창이 나타나고 사용자로부터 입력 받은 조건에 해당하는 Non-VSAM 데이

터 셋을 생성한다.

DATASETCREATE(DSCREATE)

입력 파라미터

다음은 DATASETCREATE의 입력 파라미터에 대한 설명이다.

설명파라미터

생성할 Non-VSAM 데이터 셋의 이름으로 반드시 입력해야 하는 필수항목이

다.

NAME

Non-VSAM 데이터 셋이 저장될 볼륨의 위치이다. 기본값은 UNIT에 따르거

나 SMS 규칙을 따른다.

VOLUME

아무런 값도 지정되지 않은 경우 기본값으로 설정된 볼륨에 따른다.

데이터 셋의 UNIT을 지정한다. 기본값은 VOLUME에 따른다.UNIT

입력을 받은 UNIT과 VOLUME이 서로 일치하지 않는 경우 에러가 발생한다.

데이터 셋의 DSORG를 지정한다.DSORG

데이터 셋의 레코드 포맷을 지정한다.RECFM

데이터 셋의 KEY의 길이를 지정한다. ISAM 데이터 셋의 경우에 지정할 수

있다.

KEYLEN

데이터 셋의 최대 레코드 길이를 지정한다.LRECL


설명파라미터

데이터 셋의 KEY의 위치를 지정한다. ISAM 데이터 셋의 경우에 지정할 수

있다.

KEYPOS

데이터 셋의 블록 크기를 지정한다. 기본값은 4096이다BLKSIZE

데이터 셋의 allocation시의 최초 할당 크기를 지정한다. (단위: KB)PRIMARY

데이터 셋의 다음 할당 크기를 지정한다. (단위: KB)SECONDARY

데이터 셋의 만기일을 지정한다. 기본값은 99991231이다.EXPIRATION

사용자 카탈로그를 지정한다.CATALOG

사용자 카탈로그를 지정하지 않는 경우 마스터 카탈로그 또는 ALIAS에 따른

카탈로그로 한다.

생성 관련 명령은 tjesmgr의 SETCATALOG 명령어의 옵션을 따르지 않는다.

데이터 셋의 생성만을 하고 카탈로깅을 하지 않을 경우에 지정한다.NOCATALOG

참고

VSAM 데이터 셋을 생성에 관한 자세한 내용은 OpenFrame 안내서 중 “유틸리티 참고 안내서” 를 참

고한다.

6.4.7. DATASETCOPY (DSCOPY)

입력에 해당하는 from-dataset-name을 to-dataset-name으로 복사한다.

DATASETCOPY(DSCOPY) <from-dataset-name> [CAT=<catalog-name>]

<to-dataset-name> [CAT=<catalog-name>]

[<volume-serial> [<unit-name>]]

다음은 DATASETCOPY(DSCOPY)의 입력 항목에 대한 설명이다.

설명항목

소스 데이터셋의 이름이며, <from-dataset-name>을 지정할 때 기본

카탈로그에 등록되어 있지 않은 경우 바로 뒤에 [CAT=<catalog-

name>]을 지정해줘야 해당 데이터 셋을 찾을 수 있다.

<from-dataset-name>

사용자 카탈로그를 지정한다. 지정하지 않은 경우 마스터 카탈로그

또는 ALIAS에 따른다,

CAT=<catalog-name>

타겟 데이터셋의 이름이며, <to-dataset-name>을 지정할 때 기본 카

탈로그에 등록되어 있지 않은 경우 바로 뒤에 [CAT=<catalog-name>]

을 지정해줘야 해당 데이터 셋을 찾을 수 있다.

<to-dataset-name>


설명항목

to-dataset-name의 볼륨과 UNIT의 정보를 from-dataset-name의 정

보와 다르게 하고자 할 때 지정한다.

<volume-serial> / <unit-name>

참고

기본 카탈로그에 대한 내용은 “6.4.2. SETCATALOG (SETCAT)” 명령어를 참고한다.

6.4.8. DATASETMOVE (DSMOVE)

입력에 해당하는 from-dataset-name을 to-dataset-name으로 이동한다.

DATASETCOPY(DSCOPY) <from-dataset-name> [CAT=<catalog-name>]

<to-dataset-name> [CAT=<catalog-name>]

[<volume-serial>]

다음은 DATASETMOVE (DSMOVE)의 입력 항목에 대한 설명이다.

설명항목

소스 데이터셋의 이름이며, <from-dataset-name>을 지정할 때 기본

카탈로그에 등록되어 있지 않은 경우 바로 뒤에 [CAT=<catalog-

name>]을 지정해줘야 해당 데이터 셋을 찾을 수 있다.

<from-dataset-name>

사용자 카탈로그를 지정한다. 지정하지 않은 경우 마스터 카탈로그

또는 ALIAS에 따른다,

CAT=<catalog-name>

타겟 데이터셋의 이름이며, <to-dataset-name>을 지정할 때 기본 카

탈로그에 등록되어 있지 않은 경우 바로 뒤에 [CAT=<catalog-name>]

을 지정해줘야 해당 데이터 셋을 찾을 수 있다.

<to-dataset-name>

to-dataset-name의 볼륨정보를 from-dataset-name의 정보와 다르게

하고자 할 때 지정한다.

<volume-serial>

6.4.9. DATASETDELETE (DSDELETE)

입력에 해당하는 Non-VSAM 데이터 셋들을 삭제한다.

DATASETDELETE(DSDELETE) [FORCE] <dataset-name> [CAT=<catalog-name]


다음은 DATASETDELETE (DSDELETE)의 입력 항목에 대한 설명이다.


설명항목

삭제하고자 하는 Non-VSAM 데이터 셋의 실제 파일이 존재하지 않는

경우에도 에러를 발생시키지 않고 카탈로그에 있는 정보만을 삭제한다.

[FORCE]

삭제 대상 데이터 셋 이름을 입력한다.<dataset-name>

카탈로그에 등록되어있는 경우 catalog-name을 지정한다.[CAT=<catalog-name>]

카탈로그에 등록되어있지 않은 데이터 셋을 삭제할 경우 volume-serial

를 지정한다.


6.4.10. DATASETRECATALOG (DSRECAT)

명령을 실행하면 사용자 입력 창이 나타나고 입력조건에 해당하는 Non-VSAM 데이터 셋을 리카탈로그한

다.

실제 파일만 존재하고 카탈로그에 등록되어있지 않은 Non-VSAM 데이터 셋을 카탈로그에 등록할 때, 또

는 이미 카탈로그에 등록되어있는 Non-VSAM 데이터 셋의 카탈로그 내용을 바꾸고 싶을 때 사용한다.

DATASETRECATALOG(DSRECAT)

입력 파라미터

다음은 DATASETRECATALOG의 입력 파라미터에 대한 설명이다.

설명파라미터

리카탈로그할 Non-VSAM 데이터 셋의 이름으로 반드시 입력해야 하는

필수항목이다.

NAME

리카탈로그할 데이터 셋의 현재 등록되어있는 카탈로그이다. 기본값은

마스터 카탈로그이다.

CATALOG(S)

리카탈로그할 Non-VSAM 데이터 셋이 있는 볼륨의 위치이다.VOLUME

데이터 셋의 DSORG를 지정한다.DSORG


데이터 셋의 KEY의 길이를 지정한다. ISAM 데이터 셋의 경우에 지정할

수 있다.

KEYLEN

데이터 셋의 최대 레코드 길이를 지정한다.LRECL

데이터 셋의 KEY의 위치를 지정한다. ISAM 데이터 셋의 경우에 지정할

수 있다.

KEYPOS



사용자 카탈로그를 지정한다.CATALOG


설명파라미터

사용자 카탈로그를 지정하지 않는 경우 마스터 카탈로그 또는 ALIAS에

따른 카탈로그로 한다.

6.4.11. DATASETUNCATALOG (DSUNCAT)

입력에 해당하는 데이터 셋들을 카탈로그에서 삭제한다.

DATASETUNCATALOG(DSUNCAT) <dataset-name> [CAT=<catalog-name>]

다음은 DATASETUNCATALOG (DSUNCAT)의 입력 항목에 대한 설명이다.

설명항목

카탈로그에서 삭제할 데이터 셋의 이름을 지정한다.<dataset-name>

대상 데이터 셋이 등록되어 있는 카탈로그를 지정한다.[CAT=<catalog-name>]

6.4.12. DATASETIMPORT (DSIMPORT)

외부로 반출한 파일을 읽어서 데이터 셋으로 복원한다. 명령을 실행하면 사용자 입력 창이 나타나고 사용

자로부터 입력 받은 조건에 해당하는 Non-VSAM 데이터 셋으로 복원한다

DATASETIMPORT(DSIMPORT) <from-filepath>

다음은 DATASETIMPORT (DSIMPORT)의 입력 항목에 대한 설명이다.

설명항목

Non-VSAM 데이터 셋이 저장되어 있는 UNIX 절대 파일경로를 입력

한다.

<from-filepath>

입력 파라미터

다음은 DATASETIMPORT 입력 파라미터에 대한 설명이다.

입력 파라미터들로 외부로 반출할 때의 데이터 셋 이름과 형식을 바꿀 수 있다. 이미 등록이 되어있으면

기존의 데이터 셋을 덮어쓰기 한다.

설명파라미터

변경할 Non-VSAM 데이터 셋의 이름이다.NAME

Non-VSAM 데이터 셋이 저장될 볼륨의 위치이다.VOLUME



설명파라미터

데이터 셋의 최대 레코드 길이를 지정한다. 기본값은 80이다.LRECL



사용자 카탈로그를 지정한다. 사용자 카탈로그를 지정하지 않는 경우 마

스터 카탈로그 또는 ALIAS에 따른 카탈로그로 한다.

CATALOG

생성 관련 명령은 tjesmgr의 SETCATALOG 명령어의 옵션을 따르지 않

는다.

6.4.13. DATASETEXPORT (DSEXPORT)

입력에 해당하는 Non-VSAM 데이터 셋을 외부로 반출한다.

DATASETEXPORT(DSEXPORT) <from-dataset-name> <to-filepath>


다음은 DATASETEXPORT (DSEXPORT)의 입력 항목에 대한 설명이다.

설명항목

외부로 반출한 Non-VSAM 데이터 셋을 입력한다.<from-dataset-name>

Non-VSAM 데이터 셋을 반출할 UNIX 절대 파일경로를 입력한다.<to-filepath>

from-dataset-name이 기본 카탈로그에 등록이 되어 있지 않은 경우 지정

한다.


6.4.14. DATATOUCH (DSTOUCH)

입력에 해당하는 Non-VSAM 데이터 셋의 마지막 수정 날짜를 변경한다.

DATATOUCH(DSTOUCH) <dataset-name> [VOL=<volume-serial>]

[CAT=<catalog-name>] [DATE=<yyyymmdd>]

다음은 DATASETEXPORT (DSEXPORT)의 입력 항목에 대한 설명이다.

설명항목

수정날짜를 변경할 Non-VSAM 데이터 셋을 입력한다.<dataset-name>

Non-VSAM 데이터 셋이 위치한 볼륨이다.VOL

사용자 카탈로그를 지정한다.[CAT=<catalog-name>]

수정날짜를 지정한다.[DATE=<yyyymmdd>]


6.4.15. GDGCREATE

명령을 실행하면 입력을 받을 창이 뜨고 입력 조건에 맞게 GDG 데이터 셋을 생성한다.

GDGCREATE

입력 파라미터

다음은 GDGCREATE 입력 파라미터에 대한 설명이다.

설명파라미터

생성할 GDG 데이터 셋의 이름으로 반드시 입력해야 하는 필수항목이다.NAME

GDS 데이터 셋의 제한값으로 반드시 입력해야 하는 필수항목이다.LIMIT

생성할 GDG 데이터 셋의 만기일을 지정한다.EXPIRATION

GDG 데이터 셋이 등록될 사용자 카탈로그를 지정한다. 사용자 카탈로그

를 지정을 하지 않는 경우 마스터 카탈로그 또는 ALIAS에 따른 카탈로그

에 등록된다.

CATALOG

생성 관련 명령은 tjesmgr의 SETCATALOG 명령어의 옵션을 따르지 않

는다.

6.4.16. GDGDELETE

입력에 해당하는 GDG 데이터 셋을 삭제한다. GDG 멤버가 있는 경우에는 에러가 발생한다. 이런 경우

GDG 멤버를 먼저 삭제해야 한다.

GDGDELETE <dataset-name> [CAT=<catalog-name>]

다음은 GDGDELETE의 입력 항목에 대한 설명이다.

설명항목

삭제할 GDG 데이터 셋을 입력한다.<dataset-name>

GDG 데이터 셋이 등록되어있는 카탈로그를 지정한다.[CAT=<catalog-name>]


6.4.17. PSLOCK (PSL)

입력에 해당하는 데이터 셋의 lock 정보를 보여준다.

PSLOCK(PSL) [<job-ID> | DSN=<dataset-prefix> [CAT=<catalog-name>]]

다음은 PSLOCK (PSL)의 입력 항목에 대한 설명이다.

설명항목

지정한 job-ID로 lock이 걸린 리스트를 보여준다.<job-ID>

데이터 셋의 전체 이름 또는 prefix를 입력한다. 해당 데이터 셋이나 prefix

로 시작하는 모든 lock이 걸린 데이터 셋의 리스트를 보여준다.

DSN=<dataset-prefix>

검색하고자 하는 데이터 셋이 카탈로그가 되어있을 때 지정한다.[CAT=<catalog-name>]


다음은 PSLOCK 디스플레이 정보에 대한 설명이다.

설명항목

1. Lock을 요청하고 있는 상태이면 R이 보여진다.옵션(1,2 컬럼)

2.Lock을 설정한 또는 요청한 프로세스가 실행 중이면 애스터리스크(*)

가 보여 진다. 프로세스의 노드가 다른 경우는 보여지지 않는다.

lock을 설정하거나 요청한 프로세스 ID이다.PID

lock을 설정하거나 요청한 JOBID이다.JOBID

lock을 설정하거나 요청한 노드이다.NODEID

요청한 lock의 타입이다.LOCKTYPE

- Exclusive: 대상 데이터 셋을 수정하기 위해서 사용하는 타입으로 다른

JOB에서 Lock을 공유할 수 없다.

- Shared: 대상 데이터 셋을 조회하기 위해서 사용하는 타입으로 다른 곳

과 lock을 공유할 수 있다.

요청한 lock의 이름이다.CATALOG_DSN

lock 이름은 “USERCATALOG_NAME:DATASET_NAME”으로 구성되어

있다.


6.4.18. LOCKCLEAR

입력에 해당하는 데이터 셋의 lock을 제거한다. 비정상적으로 JOB이 종료되어 lock이 풀리지 않은 경우에

사용한다.

LOCKCLEAR { <job-ID>

| P=<process-id,,,> [NODE=<node-name>]

| NODE=<node-name> ALL

| ALL }

다음은 LOCKCLEAR의 입력 항목에 대한 설명이다.

설명항목

지정할 경우 해당 job-ID로 lock이 걸린 lock들을 제거한다.<job-ID>

지정할 경우 해당 process-id로 lock이 걸린 lock들을 제거한다. pro

cess-id는 여러 개를 줄 수 있다.

P=<process-id,,,>

노드의 전체 lock을 제거한다. ALL만을 준 경우 모든 lock을 제거한

다.

NODE=<node-name> ALL

다음은 A 노드의 프로세스 1000, 1001, 1002, 1003번에 걸린 모든 lock을 제거하는 예를 보여준다.

$ LOCKCLEAR P=1000,1001,1002,1003 NODE=A

6.4.19. PSVOLUME (PSV)

명령을 실행하면 볼륨에 대한 정보를 보여준다.

PSVOLUME(PSV)


볼륨에 대한 디스플레이 정보는 다음과 같다.

설명정보

볼륨 시리얼이다.SER

전체 볼륨 크기이다TOTAL(MB)

현재 볼륨 사용률이다.USAGE(%)

사용할 수 있는 볼륨 크기이다.FREE(MB)

볼륨의 UNIX 파일경로이다PATH

관련 환경설정volume에 대한 설정은 <volume.conf>를 참고한다.


참고

volume.conf 환경설정에 관한 자세한 내용은 OpenFrame 안내서 중 ”데이터 셋 안내서”를 참고한다.

6.5. SPOOL 백업 명령어SPOOL을 백업하기 위해 사용하는 명령어이다.

6.5.1. SPOOLBACKUP (SPBA)

입력에 해당하는 SPOOL을 백업한다. BACKUP을 하고 나면 SPOOL은 tjes.conf의 [SPOOL] 세션의

BACKUP 항목에 정의된 디렉터리에 압축 파일로 저장된다.

SPOOLBACKUP(SPBA) { DT=<yyyymmddhhmiss> | <start-job-ID>,<end-job-ID> }

다음은 SPOOLBACKUP (SPBA)의 입력 항목에 대한 설명이다.

설명항목

JOB을 submit한 시간을 입력한다. 주어진 시간 이전에 submit된 JOB

의 SPOOL에 대해서 백업한다.

DT=<yyyymmddhhmiss>

백업하려는 JOBID의 범위를 입력한다.<start-job-ID>,<end-job-ID>

관련 환경설정

백업한 SPOOL들을 저장할 디렉터리이다.

<tjes.conf>

[SPOOL]

SPOOL_BACKUP_DIR=spool_backup_dir

백업한 SPOOL의 내용을 보고 싶을 때 복원할 디렉터리이다.

<tjes.conf>

[SPOOL]

SPOOL_UNPACK_DIR=spool_unpack_dir


6.5.2. SPOOLBACKUPLIST (SPBL)

입력 조건에 해당하는 년/월에 백업된 날짜들을 보여준다.

SPOOLBACKUPLIST(SPBL) DATE={ <yyyymm>|<yyyy> }

다음은 SPOOLBACKUPLIST (SPBL)의 입력 항목에 대한 설명이다.

설명항목

검색할 년/월이다.DATE={ <yyyymm>|<yyyy> }


SPOOLBACKUPLIST에 대한 디스플레이 정보는 다음과 같다.

설명정보

SPOOL이 백업된 날짜를 보여준다.BACKUP_DATE

6.5.3. SPOOLPS (SPPS)

입력 조건에 해당하는 날짜에 백업된 SPOOL 리스트를 보여준다.

SPOOLPS(SPPS) { DATE=<yyyymmdd> [N=<job-name-prefix>]

| N=<job-name-prefix> }

다음은 SPOOLPS (SPPS)의 입력 항목에 대한 설명이다.

설명항목

백업된 날짜이다.DATE=<yyyymmdd>

백업된 JOB에서 찾고자 하는 job-name의 prefix를 지정한다.N=<job-name-prefix>


SPOOLPS에 대한 디스플레이 정보는 다음과 같다.

설명정보

디스플레이 대상 SPOOL 리스트 번호이다.NO

SPOOL 리스트 번호는 SPOOLRESTORE, SPOOLPSJOB,

SPOOLPSIO 등에서 사용된다.

디스플레이 대상 JOB 이름이다.JOBNAME

디스플레이 대상 JOB ID이다.JOBID


설명정보

디스플레이 대상 JOB이 submit 되었던 날짜이다.submit_TIME

디스플레이 대상 JOB이 백업되었던 날짜이다.BACKUP_DATE

6.5.4. SPOOLRESTORE (SPRE)

입력 조건에 해당하는 백업된 SPOOL의 내용을 조회할 수 있게 임시 디렉터리에 복원한다. SPOOLRE

SOTRE를 하기 위해서는 SPOOLPS를 먼저 실행해야 한다.

SPOOLRESTORE(SPRE) I=<index>

다음은 SPOOLRESTORE (SPRE)의 입력 항목에 대한 설명이다.

설명항목

SPOOLPS에서 출력된 디스플레이 대상 SPOOL 리스트 번호이다.I=<index>

관련 환경설정

SPOOL이 백업될 디렉터리이다.

<tjes.conf>

[SPOOL]

SPOOL_BACKUP_DIR=spool_bakup_dir

SPOOL의 내용을 보기 위해 임시로 복원하게 될 디렉터리이다.

<tjes.conf >

[SPOOL]

SPOOL_UNPACK_DIR=spool_unpack_dir

6.5.5. SPOOLCLEAR (SPCL)

입력조건에 해당하는 임시 디렉터리에 복원된 SPOOL을 제거한다.즉, SPOOLRESTORE을 통해서 복원

되었던 SPOOL들을 제거한다.

SPOOLCLEAR(SPCL) I=<index>

다음은 SPOOLRESTORE (SPRE)의 입력 항목에 대한 설명이다.

설명항목



6.5.6. SPOOLPSJOB (SPPSJ)

입력조건에 해당하는 복원된 JOB의 상세 정보를 보여준다. SPOOLPS과 SPOOLRESTORE 명령어를 우

선 실행해야 SPOOLPSJOB 명령어의 결과를 볼 수 있다.

SPOOLPSJOB(SPPSJ) I=<index>

다음은 SPOOLPSJOB (SPPSJ)의 입력 항목에 대한 설명이다.

설명항목

SPOOLPSJOB에서 출력될 디스플레이 대상 SPOOL 의 인덱스 번호이다.I=<index>


PSJOB의 JOB이 끝났을 때의 정보와 동일하다. 단, OUTPUT에 대한 정보는 출력되지 않는다.

6.5.7. SPOOLPSIO (SPPSIO)

입력조건에 해당하는 복원된 JOB의 I/O 정보를 보여준다. SPOOLPS과 SPOOLRESTORE 명령어를 우

선 실행해야 SPOOLPSIO 명령어의 결과를 볼 수 있다.

SPOOLPSIO(SPPSIO) I=<index>

다음은 SPOOLPSIO (SPPSIO)의 입력 항목에 대한 설명이다.

설명항목



STEP별 데이터 셋들의 읽기/쓰기 횟수를 보여준다.

6.5.8. SPOOLPODD (SPPODD)

입력조건에 해당하는 복원된 JOB의 SPOOL을 설정한 뷰어로 열어준다.

SPOOLPODD(SPPODD) I=<index> SPDI=<dd-index>

다음은 SPOOLPODD (SPPODD)의 입력 항목에 대한 설명이다.

설명항목

SPOOLPS에서 나온 번호이다.I=<index>


설명항목

보고자 하는 dd-index를 지정한다.SPDI=<dd-index>

참고

SPOOLPODD 명령은 PODD 명령과 동일하므로 자세한 내용은 “6.2.8. PODD (Print Output DD In

formation)” 명령을 참고한다.

6.5.9. SPOOLPOSPOOL (SPPOSPOOL)

입력조건에 해당하는 복원된 JOB의 SPOOL 정보를 보여준다. SPOOLPS과 SPOOLRESTORE 명령어를

우선 실행해야 SPOOLPOSPOOL 명령어의 결과를 볼 수 있다.

SPOOLPOSPOOL(SPPOSPOOL) I=<index>

다음은 SPOOLPOSPOOL (SPPOSPOOL)의 입력 항목에 대한 설명이다.

설명항목



POSPOOL의 정보와 동일하다.

6.6. 기타 명령어

6.6.1. PSPRINT (PSP)

명령을 실행하면 환경파일에 등록되어 있는 프린터의 정보를 보여준다.

PSPRINT(PSP)


환경파일에 등록되어 있는 프린터에 대한 디스플레이 정보는 다음과 같다.

설명정보

프린터 이름이다.PRINTER_NAME

OUTPUT CLASS들이다.CLASS

프린터를 실행할 명령어이다.PRINTER_COMMAND


설명정보

프린터 라이브러리가 있는 경로이다.DRIVER_PATH

관련 환경설정

프린터를 설정한다.

<print.conf >

[PRINTERn]

6.6.2. CLS

명령을 실행하면 tjesmgr의 화면을 제거한다.

CLS

6.6.3. EDIT

입력한 filepath을 지정한 에디터로 열어준다.

EDIT <filepath>

다음은 LICENSE의 입력 항목에 대한 설명이다.

설명항목

절대경로를 입력한다.<filepath>

관련 환경설정

파일을 열수 있는 에디터를 지정한다.

<tjesmgr.conf >

[DEFAULT_OPTION]

EDITOR=editor

6.6.4. VERSION

명령을 실행하면 TJES의 버전정보를 보여준다.

VERSION


6.6.5. HELP

입력 명령어에 해당하는 명령어 사용법을 보여준다.

명령어를 주지 않은 경우 모든 명령어의 사용법을 보여준다.

HELP [<tjesmgr_command>]

6.6.6. LICENSE

입력에 해당하는 라이선스 파일의 정보를 보여준다.

LICENSE { <product> | <filepath> }

다음은 LICENSE의 입력 항목에 대한 설명이다.

설명항목

PRODUCT로는 현재 TJES, TSAM, TACF, HIDB, OSC, OSI가 있다.<product>

라이선스 파일의 이름만을 입력한 경우 환경파일에 등록되어 있는 라이선스

디렉터리에서 해당 라이선스 파일을 찾아서 정보를 보여준다.

<filepath>

관련 환경설정

라이센스 디렉터리이다.

<ofsys.conf>

[DIRECTORY]

LICENSE_DIR=license_dir

6.6.7. ERROR

입력한 error-number에 해당하는 에러 메시지를 보여준다.

ERROR <error-number>

6.6.8. CURRENTUSER

현재 로그인된 사용자의 ID를 보여준다.

CURRENTUSER (CU)


6.6.9. SWITCHUSER

명령을 실행하면 사용자 입력 창이 나타나고 사용자로부터 입력 받은 ID에 해당하는 사용자로 로그인된

다.

SWITCHUSER (SU)

입력 파라미터

다음은 SWITCHUSER의 입력 파라미터에 대한 설명이다.

설명파라미터

로그인할 사용자 ID를 입력한다.ID

로그인할 사용자의 그룹을 입력한다.GROUP NAME

로그인할 사용자의 패스워드를 입력한다.PASSWORD

6.7. JSS3 관련 명령어JOBNET에 관한 정보를 변경, 열람할 수 있는 명령어로 SETNET, DISPLAYNETLIST가 있다.

6.7.1. SETNET (SN)

파라미터값으로 주어진 JOB 또는 JOBNET 내의 모든 JOB의 상태를 변경한다.

SETNET {JOBID | NI=<netid>} CMD=<HOLD|RELS|NHOLD|FLUSH> [integer]

설명항목

명령어의 적용 대상 JOB의 ID이다.JOBID

이 항목을 지정할 경우 해당 JOB의 속성만 변경된다.

명령어의 적용 대상 JOBNET의 ID이다.NI

이 항목을 지정할 경우 해당 JOBNET에 속한 NET의 JOB 전체 속성이 변경

된다.

JOB 또는 JOBNET 내의 모든 JOB에 대한 상태 변화 종류를 가리키는 명령

어이다.

CMD

1번째 항목으로 다음을 선택했을 경우 CMD에서 선택 가능한 값은 다음과 같

다.

- JOBID: 선택 가능한 값은 HOLD, RELS, NHOLD, FLUSH이다. 각 값에 대

한 자세한 내용은 표 이후에 설명한다.


설명항목

- NI: HOLD, RELS, NHOLD, FLUSH 중 NHOLD를 제외한 값이 가능하다.

CMD 값이 NHOLD일 때 JOB의 NHOLD 값의 변화 정도를 의미한다. 해당 값

은 2번째 파라미터인 CMD의 값이 NHOLD일 때만 유효하며 이외의 경우는

무시된다.

[integer]

다음은 명령어 파라미터 중 CMD값에 대한 설명이다.

설명값

JOBID를 파라미터로 설정한 경우 해당 JOB의 JOBNET 속성을 오퍼레이터

HOLD로 변경한다.

HOLD

NETID를 파라미터로 설정한 경우 해당 JOBNET에 속하는 모든 JOB의

JOBNET 속성을 오퍼레이터 HOLD로 변경한다.

JOBID를 파라미터로 설정한 경우 해당 JOB의 JOBNET 속성의 오퍼레이터

HOLD 상태를 해제한다.

RELS


JOBNET 속성의 오퍼레이터 HOLD 상태를 해제한다.

파라미터로 지정된 JOB의 NHOLD값을 [integer]만큼 변경한다.NHOLD

JOBID를 파라미터로 설정한 경우 해당 JOB과 모든 제귀적인 후행 JOB들의

JOBNET 속성의 상태를 FLUSH 상태로 변경한다.

FLUSH


JOBNET 속성을 FLUSH 상태로 변경한다.

참고

명령어는 NET의 JOB 상태가 HOLD 또는 START 상태였을 때 유효하다.


6.7.2. DISPLAYNETLIST (DNL)

입력된 NETID에 해당하는 JOBNET에 대한 정보를 출력한다. NETID가 주어지지 않은 경우 시스템 내의

모든 JOBNET에 대한 간략한 정보를 출력한다.

DISPLAYNETLIST(DNL) [NETID]


DISPLAYNETLIST 디스플레이 기본 정보는 다음과 같다.

설명정보

JOBNET 이름이다.JOBNETNAME

JOBNET 내의 총 JOB수이다. 미입력 JOB 수를 포함한다. 미입력 JOB이란

아직 SUBMIT 되지는 않았지만, 후속 JOB으로 릴리즈할 JOB이다.

TOTALCNT

JOBNET 내의 입력이 끝난 JOB 수이다. 이는 재입력한 JOB 수를 포함한다.INPUTCNT

JOBNET 내의 종료가 끝난 JOB 수이다.FINISHCNT

JOBNET의 오퍼레이터 속성이다. 값은 EMPTY, HOLD, FLUSH, NORMAL

중의 하나이다.

NETSTAT

- EMPTY: 해당 NET의 JOB 엔트리가 비어있는 상태이다.

- HOLD: 오퍼레이터의 HOLD 상태이다.

- FLUSH: JOBNET의 FLUSH 상태이다.

- NORMAL: 위 3가지 상태 외의 정상적인 상태이다.

DISPLAYNETLIST 디스플레이 특정 JOBNET 정보는 앞의 DISPLAYNETLIST 디스플레이 기본 정보를

포함해서 다음의 정보를 추가로 출력한다.

설명정보

해당 JOBNET 내의 JOBID이다.JOBID

해당 JOBNET 내의 JOB 이름이다.JOBNAME

해당 JOB이 실행되기 위해서 릴리즈되어야 할 NHOLD 수이다.NHOLD

선행 JOB이 정상적으로 끝났을 때 해당 JOB의 처리 방법을 표시한다. 값은

D(Default), F(Flush), R(Ratain)의 값이 나올 수가 있다. 자세한 내용은 "JCL

문법 안내서"의 NET문을 참고한다.

NORMAL

선행 JOB이 비정상적으로 끝났을 때 해당 JOB의 처리 방법을 표시한다. 값

은 D(Default), F(Flush), R(Ratain)의 값이 나올 수가 있다. 자세한 내용은

"JCL 문법 안내서"의 NET문을 참고한다.

ABNORMAL


설명정보

해당 JOBNET의 JOB이 오퍼레이터 HOLD 상태인지를 나타내주며, Y/N 값

으로 표시된다.

OPHOLD

해당 JOB이 정상 종료해도 후행 JOB에서 이상종료(ABEND)로 처리되는 조

건이 표시된다. 0~4095의 부호없는 정수이다. 자세한 내용은 "JCL 문법 안내

서"의 NET문을 참고한다.

COND

해당 JOB의 동일 NET 내에 있는 후행 JOB들을 표시한다.RELEASE

해당 JOB의 다른 NET 내에 있는 후행 JOB들을 표시한다.NETREL

참고

오퍼레이터 HOLD 상태의 JOB은 PS 커맨드에서 STATUS 필드의 값이 [w]start (wait-start) 상태로

표시된다.


제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 설치 안내서”를 참고한다.

7.1.1. Tmax 서버

TJES의 운영을 위해서 다음의 서버들이 구동되어있어야 한다.

● TJES 서버

역할서버명

JOB 스케줄러obmjschd

JOB Initiatorobmjinit

제7장 환경설정 107

역할서버명

JOB 매니저obmjmsvr

JOB 히스토리obmjhist

JOB SPOOL 백업obmjspbk

프린터 매니저ofrpmsvr

● TJES 관련 서버

역할서버명

보안 관리ofrsasvr

Lock 관리ofrlmsvr, ofrlmwrk

사용자 인터페이스 담당 서버ofruisvr

콘솔 관리ofrcmsvr

OpenFrame을 설치하는 경우 TJES 서버와 TJES 관련 서버들은 자동으로 등록된다.

다음은 Tmax 환경에 등록된 TJES 서버의 예제이다.

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_domain, MIN = 1, MAX = 1,


obmjspbk SVGNAME = svg_domain, MIN = 1, MAX = 1,


ofrpmsvr SVGNAME = svg_domain, MIN = 1, MAX = 1, SVRTYPE=UCS,


참고

TJES 관련 서버의 설정에 관해서는 OpenFrame 안내서 중 "Base 안내서"를 참고한다.


위의 내용 중에 SVGNAME=svg_domain은 전체 노드 중에 한곳에서만 구동되어야 한다는 것을 의미하

고, MIN=1,MAX=1로 되어있는 설정은 하나의 서버만이 구동되어야 함을 의미한다.

따라서 obmjschd의 경우는 전체 노드 중에 한곳에서만, 하나의 서버만으로 구동이 되고, obmjinit의 경우

는 노드마다, 하나의 서버만으로 구동이 된다.

또한, obmjmsvr의 경우는 노드마다, 여러 개의 서버들이 구동이 될 수 있다. 사이트 부하 상황에 맞춰 MIN

을 설정해서 사용한다. 주어지지 않으면 MIN=1 이다.

상기 서버들을 구동시키고 정상적으로 서버가 구동되고 있는지 확인하는 방법은 다음과 같다.

● Tmax 서버 구동

$ tmboot

● Tmax 서버들의 상태 조회

$ tmadmin

$$1 node (tmadm): si

다음은 Tmax 서버가 정상적으로 동작하고 있는지 결과를 보여주는 화면으로 status가 RDY이면 서버

가 구동 중인 상태이고, NRDY이면 서버가 다운된 상태를 나타낸다.

------------------------------------------------------------------------

clh svrname (svri) status count qcount qpcount emcount

------------------------------------------------------------------------

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.1.2. 멀티 노드 설정

TJES를 멀티 노드로 운영하기 위해서는 다음과 같은 몇 가지 추가 설정이 필요하다. 참고로 같은 도메인

에 속한 모든 노드의 Tmax 설정파일은 동일해야 한다.

다음은 NODE1과 NODE2로 멀티노드 TJES를 구현하는 경우에 대한 설명이다.

NODE 추가

멀티 노드로 설정하고자 하는 모든 노드를 추가해야 한다. 예는 다음과 같다.

*NODE

DEFAULT:

DOMAINNAME = "domofb"

NODE1

HOSTNAME = "tmaxi4",

IP = "192.168.1.35",

TMAXHOME = "/openframe/oftobm4/openframe/tmax",

TMAXDIR = "/openframe/oftobm4/openframe/tmax",

APPDIR = "/openframe/oftobm4/openframe/server",

TLOGDIR = "/openframe/oftobm4/openframe/tmax/log/tlog",

ULOGDIR = "/openframe/oftobm4/openframe/tmax/log/ulog",

SLOGDIR = "/openframe/oftobm4/openframe/tmax/log/slog",

CLHOPT = " -o /openframe/oftobm4/openframe/tmax/log/clh.log -e /

openframe/oftobm4/openframe/tmax/log/clh.err",

TPORTNO = 9400, SHMKEY = 94000, RACPORT = 9450

NODE2

HOSTNAME = "tmaxi1",

IP = "192.168.1.13",

TMAXHOME = "/openframe/oftobm4/openframe/tmax",

TMAXDIR = "/openframe/oftobm4/openframe/tmax",

APPDIR = "/openframe/oftobm4/openframe/server",

TLOGDIR = "/openframe/oftobm4/openframe/tmax/log/tlog",

ULOGDIR = "/openframe/oftobm4/openframe/tmax/log/ulog",

SLOGDIR = "/openframe/oftobm4/openframe/tmax/log/slog",

CLHOPT = " -o /openframe/oftobm4/openframe/tmax/log/clh.log -e /

openframe/oftobm4/openframe/tmax/log/clh.err",

TPORTNO = 9400, SHMKEY = 94000, RACPORT = 9450


SVRGROUP 절 수정

SVRGROUP 절에 새로운 노드에 해당하는 서버그룹 추가와, 동일한 서버를 구동하기 위한 COUSIN 설

정, fail-over를 위한 svg_domain의 BACKUP 설정이 필요하다.

svg_domain

NODENAME = "NODE1",BACKUP="svg_domain2"

svg_domain2

NODENAME = "NODE2"

svg_node1

NODENAME = "NODE1",COUSIN="svg_node2"

svg_node2

NODENAME = "NODE2"

ROUTING 절 추가 및 서비스에 ROUTING 명시

멀티노드 구성을 위해 몇몇 서비스는 Tmax의 Data-Driven-Routing 기능을 사용한다. 이 때 라우팅에 사용

하는 데이터는 노드이름이다.

SERVICE 절은 전체가 아닌, 수정되어야 하는 서비스만 나열한다.

*ROUTING

rt_nodename FIELD = "FIELD/FB_NODENAME",

RANGES = "'NODE1':svg_node1,'NODE2':svg_node2,*:svg_node1"

*SERVICE

OBMJMSVRJDETAIL SVRNAME = obmjmsvr, ROUTING = rt_nodename

OBMJINITCTLNODE SVRNAME = obmjinit,ROUTING = rt_nodename

OBMJINITCTLJOB SVRNAME = obmjinit,ROUTING = rt_nodename

OBMJINITCTLINIT SVRNAME = obmjinit,ROUTING = rt_nodename

OBMJINITRUN SVRNAME = obmjinit,ROUTING = rt_nodename

OBMJINITSTATUS SVRNAME = obmjinit,ROUTING = rt_nodename

OBMJINITCHECK SVRNAME = obmjinit,ROUTING = rt_nodename

참고

각각의 자세한 설정 내용은 “Tmax 관리자 안내서”를 참고한다.


7.2. TJES 설정OpenFrame TJES의 환경 파일은 설치하는 경우 기본값으로 또는 설치 중의 사용자 입력 값으로 자동 설

정되므로 별도의 설정을 필요로 하지 않는다.

7.2.1. OpenFrame 환경 파일 형식

OpenFrame에서 사용하는 환경 파일들은 OpenFrame을 설치하는 경우 지정한 $OPENFRAME_HOME/con

fig 디렉터리에 있다.

환경 파일의 형식은 다음과 같다.

<xxx.conf>

[ 섹션 이름 ]

키 이름 = 키 값

7.2.2. TJES 환경 파일

tjes.conf 환경 파일은 다음으로 구성되어 있다.

아래의 환경을 변경하고 이를 시스템에 적용하려면 기본적으로 Tmax 서버를 다운시켰다가 재기동해야

한다.

[NODEINFO]

노드에 대한 정보를 설정하는 섹션이다.

NODENAME = value

NODELIST = value1;value2...

다음은 [NODEINFO]의 설정 항목에 대한 설명이다.

설명항목

현재 노드의 이름을 설정한다.NODENAME

전체 노드의 이름들을 설정한다. 각 노드 간의 구분은 세미콜론(;)으로 한다.NODELIST

참고

[NODEINFO] 섹션에서 설정되는 노드명은 Tmax 환경 파일의 *NODE에 지정된 노드명과 동일해야

한다.


OpenFrame을 최초 설치하는 경우 NODELIST에는 하나의 이름만 설정되어 있으며, OpenFrame에서 멀

티 노드를 사용하려는 경우 추가된 노드의 이름을 NODELIST에 설정해 주어야 한다.

예) nodeA 노드 만을 사용하는 경우 - nodeA 노드의 환경

[NODEINFO]

NODENAME=nodeA

NODELIST=nodeA

예) nodeA, nodeB 노드를 사용하는 경우 - nodeA 노드의 환경

[NODEINFO]

NODENAME=nodeA

NODELIST=nodeA;nodeB

예) nodeA, nodeB 노드를 사용하는 경우 - nodeB 노드의 환경

[NODEINFO]

NODENAME=nodeB

NODELIST=nodeA;nodeB

[SYSTEM_DS]

TJES에서 사용하는 시스템 데이터 셋을 설정하는 섹션이다. 시스템 데이터 셋들은 OpenFrame을 최초

설치하는 경우 자동으로 생성된다.

JOBQ = dataset name

TJES_STAT = dataset name

OUTPUTQ_BASE = dataset name

OUTPUTQ_PJOBID = dataset name

OUTPUTQ_PJOBNAME = dataset name

다음은 [SYSTEM_DS]의 설정 항목에 대한 설명이다.

설명항목

JOBQ로 사용될 데이터 셋의 이름을 설정한다.JOBQ

JESST로 사용될 데이터 셋의 이름을 설정한다.TJES_STAT

OUTPUTQ로 사용될 데이터 셋의 이름을 설정한다.OUTPUTQ_BASE

OUTPUTQ로 사용될 데이터 셋에 대해 JOBID로 Alternative Indexing

을 한 데이터 셋에 부여할 이름을 설정한다.

OUTPUTQ_PJOBID

OUTPUTQ로 사용될 데이터 셋에 대해 JOBNAME으로 Alternative

Indexing을 한 데이터 셋에 부여할 이름을 설정한다.

OUTPUTQ_PJOBNAME


참고

위의 데이터 셋 이름들은 초기 설정 값 그대로 사용할 것을 권장한다.

다음은 OpenFrame을 최초 설치하는 경우 자동으로 생성되는 [SYSTEM_DS]에 대한 예제이다.

JOBQ=SYS1.JOBQ

TJES_STAT=SYS1.JESST

OUTPUTQ_BASE=SYS1.OUTPUTQ

OUTPUTQ_PJOBID=SYS1.OUTPUTQ.PJOBID

OUTPUTQ_PJOBNAME=SYS1.OUTPUTQ.PJOBNAME

[JOBDEF]

TJES에서 JOB을 관리하기 위한 섹션이다.

STARTNUM = value

ENDNUM = value

FULL_WARNING = value

다음은 [JOBDEF]의 설정 항목에 대한 설명이다.

설명항목

JOBID의 시작과 끝을 설정함과 동시에 JOBQ의 크기가 설정된다.STARTNUM

기본 설정이 STARTNUM=1, ENDNUM=9999로 설정되어있기 때문에 JOBID

는 JOB00001부터 JOB09999까지 생성이 되고 JOBQ에는 9999개까지의

JOB 정보가 들어갈 수 있다.

ENDNUM

STARTNUM과 ENDNUM의 변경 값을 시스템에 적용하려면 tjesinit 툴을 사

용하여 초기화 작업을 다시 해주어야 한다. 초기화 작업을 할 경우 JOBQ의

모든 정보가 삭제되므로 현재 JOBQ의 정보를 보관하고자 하는 경우 SPOOL

BACKUP 명령을 통해 SPOOL을 백업해놓기를 권장한다.

(SPOOL 백업에 대한 내용은 “2.6. JOB의 백업”을 참고한다.)

JOBQ가 몇 퍼센트까지 사용될 경우 JOBQ가 꽉 찬다는 경고 메시지를 보여

줄 지를 설정한다.

FULL_WARNING

참고

초기화에 관한 내용은 OpenFrame 안내서 중에 “툴 참조 안내서”의 “tjesinit”을 참고한다.


다음은 JOBID시작은 1, 끝은 9999, warning은 80%로 설정한 [JOBDEF]에 대한 예제이다.

STARTNUM=1

ENDNUM=9999

FULL_WARNING=80

[JOBCLASS]

TJES의 JOB CLASS 의 기본 속성에 관한 섹션이다.

class=[START|HOLD]

다음은 [JOBCLASS]의 설정 항목에 대한 설명이다.

설명항목

JOB CLASS별 기본 속성을 기술한다. class는 A-Z, 0-9 이 가능하다. 누락된

class는 각 속성의 기본값을 가진다.

class

- [START | HOLD] : class로 submit 된 JOB의 상태를 지정한다. 생략시에

START 상태이다. JCL의 JOB 구문의 기술된 값이 이 설정 값보다 우선한다.

참고

자세한 내용은 TJESMGR 명령어 중 “6.3.8. SHOWCLASS(SC)”를 참고한다.

[SCHEDULING]

TJES에서 JOB 스케줄링에 관한 섹션이다.

DUPL_JOBNAME= [YES|NO]

PRTYJECL= [YES|NO]

PRTYJOB= [YES|NO]

PRTYHIGH=value

PRTYLOW=value

PRTYRATE=1440

INTERVAL=10

다음은 [SCHEDULING]의 설정 항목에 대한 설명이다.

설명항목

동일한 JOBNAME을 갖는 JOB을 동시에 실행할지 여부를 결정한다.DUPL_JOBNAME

기본값은 NO이다.


설명항목

submit한 JCL에서 JECL의 PRTY을 사용할지 여부를 결정한다.PRTYJECL

기본값은 YES이다.

submit한 JCL에서 JCL의 PRTY을 사용할지 여부를 결정한다.PRTYJOB


스케줄러에서 우선순위를 변경할 최대값을 결정한다.PRTYHIGH

최대값보다 큰 우선순위는 에이징 처리를 하지 않는다.

스케줄러에서 우선순위를 변경할 최소값을 결정한다.PRTYLOW

최소값보다 작은 우선순위는 에이징 처리를 하지 않는다.

하루에 에이징을 몇번할지 rate를 설정한다.PRTYRATE

86400(24시간)/prtyrate 초 후에 JOB의 우선순위를 1증가시킨다.

일정 시간 동안 작업이 실행되지 못하는 JOB들의 우선순위를 높여서 오래

기다린 JOB일수록 빨리 실행될 수 있다.

스케줄러가 스케줄링하는 간격을 초단위로 설정한다. 기본값은 10이다.INTERVAL

간격이 너무 길면 START된 JOB들이 빨리 실행되지 않고, 너무 짧게 설정되

면 스케줄링 처리를 자주 함으로써 부하가 생길 수 있다.

[RESOURCE]

TJES에서 사용할 UNIX 자원에 대한 섹션이다.

SHMKEY=values

다음은 [RESOURCE]의 설정 항목에 대한 설명이다.

설명항목

TJES에서 obmjinit와 tjclrun간 통신을 위한 공유 메모리 키를 설정한다.SHMKEY


[PROCLIB]

JOB을 실행하기 위해 필요한 데이터 셋에 대한 섹션이다.

JCLLIB=datasetname[:datasetname...]

USERLIB=[catalog]_datasetname[:[catalog]_datasetname...]

PROCnn=datasetname[:datasetname...]

다음은 [PROCLIB]의 설정 항목에 대한 설명이다.

설명항목

JCL들을 찾을 사용자 PDS 데이터 셋들이다.USERLIB

사용자들이 사용할 JCL들을 USERLIB에 저장해 놓으면 JCL의 이름만으로

JOB을 submit할 수 있다. JCLLIB과 USERLIB 중에 JCL을 찾을 때 우선순위

는 USERLIB에 기술한 데이터 셋부터 찾는다.

JCL 내에서 PROC나 INCLUDE들을 찾을 때 기본으로 찾게 될 PDS 데이터

셋으로 00부터 99까지 설정할 수 있다. 데이터 셋을 구분하기 위해 콜론(:)을

사용한다.

PROCnn

[DYNAMIC_LIBRARY]

TEMPLIB=datasetname

다음은 [DYNAMIC_LIBRARY]의 설정 항목에 대한 설명이다.

설명항목

사용자 라이브러리의 변경이 있을 때 기존 라이브러리를 임시로 저장할 PDS

데이터 셋 이름이다.

TEMPLIB

참고

상세한 내용은 OpenFrame 안내서 중 “툴 참조 안내서”의 “dlclean"와 “dlupdate”를 참고한다.


[LOG]

TJES에 관한 로그파일에 대한 섹션이다.

JOBLOG=filepath

SUBMITLOG=filepath

다음은 [LOG]의 설정 항목에 대한 설명이다.

설명항목

JOB의 상태변화를 기록하는 JOBLOG의 filepath를 지정한다.JOBLOG

JCL submit 시도와 결과를 기록하는 SUBMITLOG의 filepath를 지정한다.SUBMITLOG

log 가 기록될 파일의 절대 경로를 지정한다. 파일 이름의 &SYSDATE 는

YYMMDD 형식의 날짜로 치환된다. $(OPENFRAME_HOME)/log 밑에 저장

할 것을 권고한다.

filepath

참고

1. JOBLOG 와 SUBMITLOG 에 대한 자세한 내용은 “2.5. 로그” 를 참조한다.

2. 로그에 대한 분석은 TJESMGR의 JOBHISTORY를 통해서 할 수 있다. JOBHISTORY에 대한 자

세한 내용은 TJESMGR 명령어 중 “6.2.9. PSHISTORY (Print Screen of JOB History)”를 참고한다.

다음은 $(OPENFRAME_HOME)/log 밑에 날짜에 따라 jobYYMMDD.log 와 submitYYMMDD.log 형식으

로 log 파일을 생성하는 [LOG] 예제이다.

JOBLOG = $(OPENFRAME_HOME)/log/job&SYSDATE.log

SUBMITLOG=$(OPENFRAME_HOME)/log/submit&SYSDATE.log

[SPOOL]

TJES의 SPOOL에 대한 섹션이다.

SPOOL_VOLUME_SER=volume serial

SPOOL_BACKUP_DIR=dir-path

SPOOL_UNPACK_DIR=dir-path

다음은 [SPOOL]의 설정 항목에 대한 설명이다.

설명항목

volume.conf에 지정된 SPOOL VOLUME SERIAL을 설정한다.SPOOL_VOLUME_SER

BACKUP 기능 사용시 SPOOL 백업 데이터가 저장될 디렉터리를 설

정한다.

SPOOL_BACKUP_DIR


설명항목

백업된 SPOOL 데이터를 조회하고자 할 때 임시로 사용할 디렉터리

를 설정한다.

SPOOL_UNPACK_DIR

참고

자세한 내용은 “2.6. JOB의 백업”과 TJESMGR 명령어의 “6.5.1. SPOOLBACKUP (SPBA)” 을 참고

한다.

다음은 [SPOOL]의 설정한 예이다.

SPOOL_VOLUME_SER=VSPOOL

SPOOL_BACKUP_DIR=$OPENFRAME_HOME/spbackup

SPOOL_UNPACK_DIR=$OPENFRAME_HOME/sptemp

[SPOOL_TRANSFER]

PROTOCOL=[FTP|RCP|SCP]

IP_ADDRESS=ip-address

HOST_NAME=host-name

USER=username

PASSWD=password

DIR_PATH=dir-path

다음은 [SPOOL_TRANSFER]의 설정 항목에 대한 설명이다.

설명항목

네트워크 전송에 사용할 PROTOCOL을 지정한다.PROTOCOL

- FTP

- RCP

- SCP

전송받을 노드의 IP_ADDRESS를 지정한다. PROTOCOL이 FTP, SCP일때

지정해야 한다.

IP_ADDRESS

전송받을 노드의 HOST_NAME을 지정한다. PROTOCOL이 RCP일때 지정

해야한다.

HOST_NAME

전송받을 노드에 접속하기 위한 USER NAME을 지정한다.USER

전송받을 노드에 접속하기 위한 PASSWORD를 지정한다. PROTOCOL이

FTP일 때 지정해야 한다.

PASSWD

전송받을 노드에 데이터를 저장하기 위한 디렉토리를 지정한다.DIR_PATH


주의

이 설정은 다른 노드로 스풀데이터를 전송해서 OUTPUT PROCESSING을 수행할 필요가 있을 경우

에만 사용해야한다.

다음은 [SPOOL_TRANSFER]를 설정한 예이다.

PROTOCOL=FTP

IP_ADDRESS=192.168.1.43

HOST_NAME=tmaxh4

USER=obm

PASSWD=******

DIR_PATH=/ofenframe/user/obm/openframe/data/spool_tmp

[SPOOL_TRANSFER_BACKUP]

PROTOCOL=[FTP|RCP|SCP]

IP_ADDRESS=ip-address

HOST_NAME=host-name

USER=username

PASSWD=password

DIR_PATH=dir-path

다음은 [SPOOL_TRANSFER_BACKUP]의 설정 항목에 대한 설명이다.

설명항목

네트워크 전송시 사용할 PROTOCOL을 지정한다.PROTOCOL

- FTP

- RCP

- SCP

전송받을 노드의 IP_ADDRESS를 지정한다. PROTOCOL이 FTP, SCP일때

지정해야 한다.

IP_ADDRESS

전송받을 노드의 HOST_NAME을 지정한다. PROTOCOL이 RCP일때 지정

해야한다.

HOST_NAME

전송받을 노드에 접속하기 위한 USER NAME을 지정한다.USER

전송받을 노드에 접속하기 위한 PASSWORD를 지정한다. PROTOCOL이

FTP일 때 지정해야한다.

PASSWD

전송받을 노드에 데이터를 저장하는 디렉터리를 지정한다.DIR_PATH


참고

이 설정은 [SPOOL_TRANSFER]를 통해 스풀 데이터 전송 실패시 BACKUP으로 사용하게 되는 설

정이다.

다음은 [SPOOL_TRANSFER_BACKUP]을 설정한 예이다.

PROTOCOL=FTP

IP_ADDRESS=192.168.1.43

HOST_NAME=tmaxh4

USER=obm

PASSWD=******

DIR_PATH=/ofenframe/user/obm/openframe/log

[OUTDEF]

USE_OUTPUTQ=[YES|NO]

OUTMUN=value

DATA_DIR=dir-path

다음은 [OUTDEF]의 설정 항목에 대한 설명이다.

설명항목

OUTPUT Processing을 수행 여부를 지정한다.USE_OUTPUTQ

OUTPUTQ의 크기를 설정한다.OUTNUM

SPOOL에서 해당 OUTPUT의 데이터를 복사할 디렉터리 지정한다.DATA_DIR

다음은 [OUTDEF] 설정한 예이다.

USE_OUTPUTQ=YES

OUTNUM=8000

DATA_DIR=$OPENFRAME_HOME/outputq


[OUTCLASS]

SYSOUT의 OUTPUT CLASS에 따라 기본 OUTPUT DISPOSITION과 기본 lrecl을 설정할 수 있다.

#class=[normal disp][,abnormal disp] [: default lrecl]

다음은 [OUTCLASS]의 설정 항목에 대한 설명이다.

설명항목

OUTPUT CLASS가 A인 SPOOL 데이터 셋은 JCL에서 OUTPUT DISPOSI

TION을 기술하지 않았을 때, 기본 OUTPUT DISPOSITION으로

(WRITE,WRITE)을 사용한다.

#class

lrecl을 기술하지 않았으면 120으로 사용한다.

[OUTCLASS]를 지정하는 예는 다음과 같다.

A=WRITE,WRITE:120

[INTRDR]

TJES의 인터널 리더에 대한 섹션이다.

HOLD=[YES|NO]

NODENAME=nodename

USERNAME=username

GROUPNAME=groupname

PASSWORD=password

ENPASSWD=encrypted password

다음은 [INTRDR]의 설정 항목에 대한 설명이다.

설명항목

인터널 리더로 JCL을 submit할 때 JOB의 상태를 HOLD로 할지 여부를 설정

한다.

HOLD

인터널 리더로 JCL을 submit할 때 JOB을 실행할 노드를 설정한다.NODENAME

인터널 리더로 JCL을 submit할 때 TACF 인증을 받을 사용자를 설정한다.USERNAME

인터널 리더로 JCL을 submit할 때 TACF 인증을 받을 사용자 그룹을 설정한

다.

GROUPNAME

인터널 리더로 JCL을 submit할 때 TACF 인증을 받을 사용자 비밀번호를 설

정한다.

PASSWORD

인터널 리더로 JCL을 submit할 때 TACF 인증을 받을 사용자 비밀번호를 암

호화해서 설정한다.

ENPASSWD


설명항목

PASSWORD나 ENPASSWD는 하나만 설정해야 한다.

[INITDEF]

TJES의 Runner의 초기 설정 값에 대한 섹션이다.

INITNUM=values

INITxxxx=name,classes,[ACTIVE|INACTIVE]

다음은 [INITDEF]의 설정 항목에 대한 설명이다.

설명항목

전체 Slot의 개수를 지정한 것이다.INITNUM

각 Runner Slot 를 설정한다.INITxxxx

INITxxxx 에서 xxxx는 Runner Slot 번호를 지정한다. 동일한 설정을 가지는

연속된 다수의 Runner는 INITnnnn-mmmm를 키로 하여 한번에 설정 할 수

있다.

- name : Runner Slot의 이름으로, 현재는 특별한 의미를 가지지 않는다.

- classes : Runner Slot에 할당할 수 있는 JOB CLASS를 설정한다.

- [ACTIVE|INACTIVE] : Runner Slot의 초기 상태를 지정한다. JOB 을 수행

할 수 있는 ACTIVE와 JOB을 수행할 수 없는 INACTIVE 둘 중 하나를 선택한

다.

[TACF]

TACF를 통해 JOBNAME과 SPOOL에 대한 권한 체크에 관한 섹션이다.

CHECK_JOBNAMEAUTH=[YES|NO]

CHECK_SPOOLAUTH=[YES|NO]

다음은 [TACF]의 설정 항목에 대한 설명이다.

설명항목

SUBMIT, REMOVE, START, HOLD 등 JOB 에 관한 제어를 하는 경

우 JOBNAME 에 관한 권한 체크를 할지에 대한 여부를 설정한다.

CHECK_JOBNAMEAUTH

tjesmgr에서 PODD command로 SPOOL을 열어볼 수 있는 권한 체

크를 할지에 대한 여부를 설정한다.

CHECK_SPOOLAUTH


7.3. TJESMGR 설정본 장에서는 tjesmgr에서 사용하는 tjesmgr.conf 환경 파일에 대한 설명을 한다.

[DEFAULT_OPTION]

tjesmgr의 명령어를 실행하는 경우 참고하는 정보를 설정하는 섹션이다.

SPOOL_LIST=[ALL|EXIST|GTZERO]

EDITOR=value

VIEWER=value

DEFAULT_RUNNING_NODE=[MY|ANY]

다음은 [DEFAULT_OPTION]의 설정 항목에 대한 설명이다.

설명항목

- ALL: 모든 SPOOL을 보여준다.SPOOL_LIST

- EXIST: SPOOL 파일이 존재하는 것만 보여준다.

- GTZERO: SPOOL 파일 크기가 0보다 큰 것만 보여준다.

파일을 열수 있는 에디터를 지정한다.EDITOR

에디터를 지정하는 예는 다음과 같다.

예) EDITOR=vi &FILEPATH

SPOOL을 열수 있는 뷰어를 지정한다.VIEWER

뷰어를 지정하는 예는 다음과 같다.

예) VIEWER=vi –R &FILEPATH

HP 또는 AIX 장비에서는 vi 만을 주는 경우 화면의 일부분부터 나오

는 경우가 있다. 이런 경우 vi –w &ROWCOUNT –R &FILEPATH로

설정하면 모든 내용이 깨지지 않고 출력된다.

- MY : JOB이 submit될 때 노드가 지정되지 않았을 경우 자기노드에

서만 JOB이 실행될 수 있도록 한다.

DEFAULT_RUNNING_NODE

- ANY : JOB이 submit될 때 노드가 지정되지 않았을 경우 어느 노드

에서나 JOB이 실행될 수 있도록 한다.


[DEFAULT_USER]

tjesmgr를 실행하는 경우 자동으로 로그인할 수 있는 정보를 설정하는 섹션이다.

[DEFAULT_USER] 섹션을 설정하면 tjesmgr를 실행할 때 이 섹션에 설정된 사용자 정보로 로그인한다.

USERNAME=username

GROUPNAME=groupname

PASSWORD=password

다음은 [DEFAULT_USER]의 설정 항목에 대한 설명이다.

설명항목

tjesmgr에 접속할 사용자를 설정한다.USERNAME

tjesmgr에 접속할 사용자가 속한 GROUPNAME을 설정한다.GROUPNAME

tjesmgr에 접속할 사용자의 비밀번호를 설정한다.PASSWORD

[TACF]

tjesmgr에서 TACF의 환경을 설정하는 섹션이다.

ASKGRPNM=[YES|NO]

ALLOWED_USER=username

CHECK_CMDAUTH=[YES|NO]


설명항목

NO로 설정하면 tjesmgr 실행하는 경우 GROUPNAME은 묻지 않는다.ASKGRPNM

ALLOWED_USER에 설정된 USER만이 tjesmgr에 로그인할 수 있다.ALLOWED_USER

ALLOWED_USER 항목이 없을 경우 모든 USER가 로그인 가능하다.

YES로 설정하면 tjesmgr의 명령어에 대한 권한을 확인한다.CHECK_CMDAUTH

참고

TACF에 관한 자세한 내용은 OpenFrame 안내서 중 “TACF 안내서”를 참고한다.


7.4. OUTPUT 설정print.conf 환경 파일 중에서 OUTPUT을 위한 설정에 대하여 설명한다.

[PRINTER1]

PRINTER1 - PRINT9까지 설정할 수 있다.

CLASS=value

COMMAND=value

DRIVER_PATH=driver-path

다음은 [PRINTER1]의 설정 항목에 대한 설명이다.

설명항목

PRINTER1에서 처리할 수 있는 OUTPUT의 OUTPUT CLASS를 지정

한다.

CLASS

외부 프린터 솔루션에 데이터와 정보 전달을 위한 명령어를 설정한다.COMMAND

외부 프린터 솔루션의 인터페이스를 위해 만들어진 공유 라이브러리의

경로로 프린터 솔루션마다 달라지므로 정확한 설정이 필요하다.

DRIVER_PATH

다음은 [PRINTER1]을 설정한 예이다.

CLASS=AB38

COMMAND=lpr

DRIVER_PATH=$OPENFRAME_HOME/lib/libdfltprt.so

[INTRDR]

DRIVER_PATH=driver-path

다음은 [INTRDR]의 설정 항목에 대한 설명이다.

설명항목

인터널 리더 구동을 위해 만들어진 공유 라이브러리의 경로를 기술한다.DRIVER_PATH

다음은 [INTRDR]를 설정한 예이다.

DRIVER_PATH=$OPENFRAME_HOME/lib/libirdrprt.so


7.5. TJCLRUN 설정tjclrun이 동작하는 방식에 대한 설정파일인 tjclrun.conf를 설명한다.

[JOB]

TJES에서 JOB을 처리하기 위해서 요구되는 최소한의 JCL JOB문의 파라미터가 생략된 경우 사용할 기

본값을 설정한다.

CLASS={jobclass}

MSGCLASS={msgclass}

MSGLEVEL[1]={msglevel_statement}

MSGLEVEL[2]={msglevel_message}

다음은 [JOB]의 설정 항목에 대한 설명이다.

설명항목

필수 설정항목이며 JOB문의 CLASS 파라미터가 생략된 경우 사용할 기본

JOB CLASS 값을 설정한다.

CLASS

jobclass는 알파벳 A-Z, 숫자 0-9 중의 한 글자로 설정한다.

필수 설정항목이며 JOB문의 MSGCLASS 파라미터가 생략된 경우 사용할

기본 JOB MSGCLASS 값을 설정한다.

MSGCLASS

msgclass는 알파벳 A-Z, 숫자 0-9 중의 한 글자로 설정한다.

필수 설정항목이며 JOB문의 MSGLEVEL의 첫번째 서브 파라미터가 생략된

경우 사용할 기본 MSGLEVEL 값을 설정한다.

MSGLEVEL[1]

msglevel_statement는 0 또는 1 또는 2 중 하나로 설정해야 한다.

필수 설정항목이며 JCL JOB문에 MSGLEVEL의 두번째 서브 파라미터가 생

략된 경우 사용할 기본 MSGLEVEL 값을 설정한다.

MSGLEVEL[2]

msglevel_message는 0 또는 1중 하나로 설정해야 한다. 지정된 msglevel_mes

sage에 따라 출력되는 로그 메시지의 구체적인 내용은 추후 변경될 수 있다.

어느 경우나 JOB의 비정상 종료를 나타내는 에러 메시지는 항상 출력된다.

- 0 : JOB SPOOL의 SYSMSG에 데이터 셋 할당 등의 결과나 JOB 처리에 따

른 로그 메시지가 출력되지 않는다.

- 1 : 데이터 셋 할당 등의 처리 결과 및 JOB 처리에 따른 로그 메시지가 출력

된다.


다음은 [JOB]을 설정한 예이다.

CLASS=A

MSGCLASS=A

MSGLEVEL[1]=1

MSGLEVEL[2]=1

[PERFORM]

USE_PERFORM=[YES|NO]

<perform-value>=<nice-value>

다음은 [PERFORM]의 설정 항목에 대한 설명이다.

설명항목

옵션 설정항목이며 PERFORM 파라미터를 이용해서 CPU 우선순위

를 변경할지 여부를 지정한다. 지정하지 않은 경우 JCL의 PERFORM

파라미터는 무시된다.

USE_PERFORM


JCL의 PERFORM에 지정될 값과 CPU 우선순위의 매핑 테이블이

다. USE_PERFORM을 YES로 지정한 경우 반드시 설정을 해주어야

한다.

<perform-value>=<nice-value>

JCL의 PERFORM은 1-999의 범위이고 UNIX에서 CPU 우선순위

(nice value)의 범위는 0-39이다. 따라서 이에 맞게 매핑 테이블을 설

정해 준다.

다음은 [PERFORM]을 설정한 예이다.

USE_PERFORM=NO

1-10 = 0

11-20 = 1

...

391-999 = 39

참고

nice value는 플랫폼 마다 상이하기 때문에 정확한 값은 각 플랫폼에서 manpage를 참고한다.


[DD]

INSDSET_LRECL=[number]

다음은 [DD]의 설정 항목에 대한 설명이다.

설명항목

옵션 설정항목이며 JCL에서 instream-dataset의 레코드 길이를 지정해준다.INSDSET_LRECL

tjclrun에서는 instream-dataset의 길이가 지정된 길이보다 작다면 스페이스

를 채우고 크다면 뒷 부분은 잘라낸다.

기본값은 80이다.

다음은 [DD]를 설정한 예이다.

INSDSET_LRECL=80

[DDTAB]

DDTAB_MAX=[number]

다음은 [DDTAB]의 설정 항목에 대한 설명이다.

설명항목

옵션 설정항목이며 tjclrun이 JOB을 실행함에 있어서 사용되는 JCL에서 (JCL

프로시저 포함) 처리 가능한 최대 JCL DD문의 개수를 설정한다.

DDTAB_MAX

기본값은 512이다.

예를 들어 DDTAB_MAX=1024라고 설정하면 INPJCL 및 해당 JOB에서 호출

되는 JCL 프로시저를 포함하여 1024개까지의 DD문만 하나의 JOB에서 사용

할 수 있다. 그 이상의 DD문이 존재하면 에러로 처리되고 JOB은 비정상 종

료 처리되며, SYSMSG 상에 에러 메시지 'No free DD entry in ddtab'이 출력

된다. 이 경우 DDTAB_MAX 값을 상향 조정하는 것을 고려해야 한다.

다음은 [DDTAB]을 설정한 예이다.

DDTAB_MAX=1024

DDTAB_MAX=1024라고 설정하면 INPJCL 및 해당 JOB에서 호출되는 JCL 프로시저를 포함하여 1024개

까지의 DD문만 하나의 JOB에서 사용할 수 있다.


[SYSLIB]

tjclrun이 실행하는 프로그램의 하위 Batch 실행 프로그램이나 공유 라이브러리 등을 찾는데 사용되는 기

본 디렉터리들을 설정한다. [SYSLIB] 섹션에는 가급적 고객사에서 공용으로 사용되는 디렉터리만 포함하

고 특정 JOB이나 JOB STEP에서만 제한적으로 사용되는 프로그램을 포함하는 디렉터리는 JCL에 JOBLIB

이나 STEPLIB DD를 사용해서 지정하도록 하는 것이 좋다. 그렇게 하지 않은 경우 Batch 프로그램의 로

딩 작업을 하는 경우 성능이 저하될 수 있다.

BIN_PATH=[pathlist]

LIB_PATH=[pathlist]

COB_PATH=[pathlist]

BIN_PATH, LIB_PATH, COB_PATH에 대한 설정을 하지 않으면 대신 해당 사용자의 환경변수가 내부적

으로 사용된다. 즉, BIN_PATH를 설정하지 않은 경우 환경변수 PATH의 값이 BIN_PATH 값으로 설정된

것처럼 동작한다.

설정 값을 나타내는 pathlist는 절대 경로명으로 지정해야 한다. 여러 경로명의 리스트로 값을 설정하는 경

우에는 각 경로명을 콜론(:)으로 구분한다. pathlist의 값이 길어지더라도 한 라인에 입력해야 한다. pathlist

의 최대 길이는 4096 바이트이다.

다음은 [SYSLIB]의 설정 항목에 대한 설명이다.

설명항목

옵션 설정항목이며, 환경변수 PATH에 해당하는 값으로, tjclrun이 실행하는

Batch 프로그램을 찾는 기본 디렉터리 경로명의 리스트를 설정한다.

BIN_PATH

JCL에 JOBLIB이나 STEPLIB DD가 지정된 경우에는 먼저 JOBLIB이나

STEPLIB에서 실행 파일을 찾아보고 JOBLIB이나 STEPLIB에 해당하는 위치

에 실행 파일이 존재하지 않는 경우에 BIN_PATH에 설정된 디렉터리들에서

실행 파일을 찾는다.

옵션 설정항목이며, 환경변수 LIBPATH(IBM AIX의 경우), SHLIB_PATH(HPUX

의 경우), LD_LIBRARY_PATH(SUNOS나 Linux의 경우)에 해당하는 값으로,

LIB_PATH

tjclrun이 실행하는 Batch 프로그램에서 사용되는 공유 라이브러리를 찾는 기

본 디렉터리 경로명의 리스트를 설정한다.

JCL에 JOBLIB이나 STEPLIB DD가 지정된 경우에는 지정된 JOBLIB이나

STEPLIB에 해당하는 위치에서 필요로 하는 공유 라이브러리가 있는지 먼저

찾아보고, 없으면 LIB_PATH에 설정된 디렉터리들에서 공유 라이브러리를

찾는다.

옵션 설정항목이며, MFCOBOL에서 사용하는 환경변수 COBPATH에 해당

하는 값으로, tjclrun이 실행하는 COBOL 프로그램에서 사용하는 COBOL 프

COB_PATH

로그램용 공유 라이브러리나 서브 프로그램을 찾는 기본 디렉터리 경로명의

리스트를 설정한다.


설명항목

JCL에 JOBLIB이나 STEPLIB DD가 지정된 경우에는 지정된 JOBLIB이나

STEPLIB에 해당하는 위치에서 필요로 하는 COBOL 프로그램용 공유 라이

브러리나 서브 프로그램을 먼저 찾아보고, 없으면 COB_PATH에 설정된 디

렉터리들에서 찾는다.

참고

Mainframe에서는 오브젝트에 대한 Batch 프로그램이나 공유 라이브러리 등의 구분이 없는 반면

OpenFrame(UNIX)에서는 각각의 경우가 구분되어 있기 때문에 JCL에 사용자가 지정한 JOBLIB이

나 STEPLIB DD는 BIN_PATH, LIB_PATH, COB_PATH 모두에 영향을 준다.

반면 tjclrun.conf에 BIN_PATH, LIB_PATH, COB_PATH를 별도로 나누어 지정할 수 있게 한 이유는

각 OpenFrame(UNIX)에서 Batch 프로그램이나 공유 라이브러리 등의 오브젝트 타입 별로 찾아볼

디렉터리 공간을 별도로 설정하여 오브젝트를 좀 더 효율적으로 찾게 하기 위해서 이다.

특정 UNIX 환경에서 (현재까지 알려진 바로는 IBM AIX 시스템) tjclrun에 setuid root 권한을 부여하

고 설치하여 운영하는 경우 보안상의 이유로 운영 시스템 차원에서 tjclrun을 실행할 때 환경변수

LIBPATH를 클리어하는 문제가 있다. 이 경우에는 고객사에 설치된 OpenFrame 환경에서 tjclrun을

직접 재링크(relink) 해주어야 한다. 또한 BIN_PATH, LIB_PATH, COB_PATH 설정들도 생략하지 말

고 명시적으로 설정해 주어야 한다.

이와 관련된 좀 더 자세한 내용은 “3.1.12. 보안”의 “setuid root tjclrun”를 참고한다.

다음은 [SYSLIB]를 설정한 예이다.

BIN_PATH=${OPENFRAME_HOME}/bin:${OPENFRAME_HOME}/util:${COBDIR}/bin:/usr/lo

cal/bin:/bin

LIB_PATH=${OPENFRAME_HOME}/lib:${TB_HOME}/client/lib:${TMAXDIR}/lib:${COBDI

R}/lib:${ORACLE_HOME}/lib:/usr/lib:/lib:/lib/i686:/usr/local/lib

COB_PATH=${COBPATH}

[PGM]

USE_PGMRTS00=[YES|NO]

다음은 [PGM]의 설정 항목에 대한 설명이다.

설명항목

옵션 설정항목이며, tjclrun이 유틸리티 프로그램 PGMRTS00을 이용하여 공

유 라이브러리로 컴파일된 Batch 애플리케이션을 호출할지 여부를 설정한

다. 기본값은 NO이다.

USE_PGMRTS00


설명항목

NO로 설정하면 tjclrun은 실행파일로 컴파일된 프로그램만 호출할 수 있다.

YES로 설정하면 tjclrun은 지정된 프로그램이 실행파일이 아닌 경우 PGM

RTS00 유틸리티를 호출하고 PGMRTS00이 공유 라이브러리로 컴파일된

Batch 프로그램을 동적으로 로딩하여 실행할 수 있도록 한다.

결과적으로 사용자 관점에서는 공유 라이브러리 형태로 컴파일된 Batch 프

로그램도 JCL에서 호출할 수 있게 된다.

다음은 [PGM]을 설정한 예이다.

USE_PGMRTS00=NO

[ACCOUNT]

SETUID=[YES|NO]

USERID=[userid]

다음은 [ACCOUNT]의 설정 항목에 대한 설명이다.

설명항목

옵션 설정항목이며, tjclrun 프로세스 및 tjclrun이 JOB을 위해서 호출하는

Batch 프로그램의 프로세스 소유자(owner userid)가 JCL JOB에 기술된 USER

파라미터의 값으로 수행되도록 할지 여부를 설정한다.

SETUID

YES로 설정하는 경우 tjclrun 프로그램을 setuid root 권한을 부여하여 설치해

야 하며, JOB의 실행 중에 호출되는 프로그램은 JCL JOB문의 USER에 지정

된 사용자가 실행한 것으로 프로세스 어카운팅되며, JOB 실행 중에 생성되

는 파일이나 기타 리소스에 대한 권한 검사(TACF 권한 검사와 별도로 OS에

서 기본적으로 수행되는 권한 검사) 역시 JCL에 기술된 JOB USER에 대해서

행해진다.

NO로 설정한 경우 TJES 시스템을 부팅한 운영자, 특히 Runner Slot 프로세

스의 소유자가 tjclrun 및 JOB STEP에서 실행되는 Batch 프로그램의 프로세

스 소유자로 사용된다. 이 경우 JCL JOB문의 USER 파라미터를 이용하여

JOB 별로 다른 사용자가 수행하는 것으로 처리하는 방식은 지원되지 않는다.

모든 OS 레벨의 권한 체크는 운영자의 권한으로 수행되며 해당 JOB을 수행

하는 프로세스의 소유자 역시 동일한 운영자의 OS userid로 어카운팅된다.



설명항목

옵션 설정항목이며, 위의 SETUID 설정을 YES로 설정한 경우에만 추가적으

로 사용되는 설정 값이다. SETUID를 YES로 하면서 항상 특정 사용자로만

JOB을 실행하게 하려는 경우에 활용할 수 있다.

USERID

userid를 지정하는 경우는 SETUID에서 YES로 설정한 경우의 동작을 수행하

기는 하지만 JCL JOB문의 USER 파라미터에 지정된 사용자 대신에 항상 설

정파일에 USERID=[userid]에 지정된 사용자가 사용된다.

USERID를 설정하지 않으면 사용되지 않으며 기본값은 없다.

[TACF]

CHECK_DSAUTH=[YES|NO]

CHECK_UTAUTH=[YES|NO]


설명항목

옵션 설정항목이며, tjclrun의 TACF 지원 기능 중에서 데이터 셋에 대한 TACF

접근 권한 검사를 수행할지 여부를 설정한다.

CHECK_DSAUTH


옵션 설정항목이며, tjclrun의 TACF 지원 기능 중에서 주요 유틸리티 프로그

램에 대한 TACF 실행 권한 검사를 수행할지 여부를 설정한다.

CHECK_UTAUTH


[JCL]

IGNORE_TRAIL=[YES|NO]

다음은 [JCL]의 설정 항목에 대한 설명이다.

설명항목

옵션 설정항목이며, JCL 파일의 마지막 부분이 JCL 문장이 아닌 경우는

Mainframe에서는 //SYSIN DD * 가 생략된 입력 스트림 데이터 셋으로 처리

된다.

IGNORE_TRAIL

OpenFrame에서는 마이그레이션 과정 중에 공백라인이나 불필요한 라인들

이 추가되는 경우가 빈번히 발생된다. 이러한 경우에 JCL 파일의 TRAIL(마


설명항목

지막 부분)을 //SYSIN DD *가 생략된 입력 스트림 데이터 셋으로 간주할지

아니면 무시할지를 설정한다.

YES로 설정하면 TRAIL은 무시되어 버려지고, NO로 설정하면 TRAIL은

SYSIN DD *가 생략된 입력 스트림 데이터 셋으로 처리된다.

기본값은 YES이다.

참고

특별한 내용 없이 공백으로만 이루어진 TRAIL은 이 설정과 상관없이 항상 무시된다.

[AMS]

CONNECTION=[KEEP|NOKEEP]

다음은 [AMS]의 설정 항목에 대한 설명이다.

설명항목

옵션 설정항목이며, Runner가 실행되는 동안 AMS의 연결을 계속 유지할 것

인지 아니면 필요할 때마다 연결을 맺어서 사용할 것이지를 설정한다.

CONNECTION

기본값은 KEEP이다.

[DEBUG]

PROFILE=[YES|NO]

다음은 [DEBUG]의 설정 항목에 대한 설명이다.

설명항목

옵션 설정항목이며, tjclrun 자체의 성능을 조사하기 위한 실행 프로파일 정보

를 출력할지 여부를 지정한다.

PROFILE

YES를 지정하면 tjclrun 인터널 로그에 주요 실행 단계별 시간정보를 포함하

는 성능 분석을 위한 로그 메시지가 추가적으로 출력된다.

NO를 지정하면 해당 메시지가 출력되지 않는다. tjclrun 자체의 성능 문제를

분석하는 경우가 아니라면 YES로 설정하지 않을 것을 권장한다.



7.6. Return Code 설정rc.conf는 Batch 프로그램의 종료코드 별로 JOB COND나 EXEC COND를 일으키는 예외상황으로 볼지

여부를 설정하기 위한 환경 설정이다.

[PGM_NAME]

프로그램 이름별로 여러 개의 예외상황을 설정한다.

{pgmname}={rc_spec}

설명항목

특정 프로그램 이름을 지정한다.{pgmname}

해당 프로그램의 종료코드 중에서 예외상황으로 간주해야 하는 종료코드를

나열한다.

{rc_spec}

종료 코드를 나열하는 방법은 다음과 같다.

rc_spec={[(RC|RC-RC),]...}

설명항목

RC는 종료코드를 나타내는 0-4096 사이의 숫자이다.rc_spec={[(RC|RC-

RC),]...}예를 들면 "8,12,16-24"와 같은 형태로 {rc_spec}을 지정할 수 있다. 여러 개

의 종료코드를 콤마(,)로 구분하여 입력한다.

종료코드의 범위를 지정할 때는 하이픈(-)을 이용해서 나타낸다.

예를 들어 8,12,16-24라고 설정하면 8, 12 그리고 16부터 24 사이의 종료코

드는 예외상황이 발생한 것으로 간주된다.

다음은 [PGM_NAME]을 설정한 예이다.

IKJEFT01=8-255

MYPGM1=8-255

MYPGM2=8,16-4096

...


[PGM_TYPE]

프로그램 종류별로 여러 개의 예외상황을 설정한다.

{pgmtype}={rc_spec}

설명항목

pgmtype에 COBOL, PLI, OTHER, ALL을 지정할 수 있다.{pgmtype}

- COBOL : COBOL 컴파일러로 작성된 프로그램에 대해서 수행되는 종료코

드 검사를 나타낸다.

- PLI : PLI 컴파일러로 작성된 프로그램에 대해서 수행되는 종료코드 검사를

나타낸다.

- OTHER : 프로그램 종류가 알려지지 않은 기타 프로그램에 대한 종료코드

검사를 나타낸다. 일반적인 C언어로 작성된 프로그램은 여기에 해당된다.

- ALL : 지정한 조건은 rc.conf의 다른 설정에 의해서 예외상황이 만족되지 않

는 경우에 항상 검사된다.

예를 들어 COBOL 프로그램이 종료코드 8로 종료한 경우 위에 예시된

COBOL=16-4096에 의해서 예외상황이 만족되지 않는다. 이때 ALL이 설정

되어 있는 경우는 추가적으로 ALL=8-255에 대해서 예외상황 검사가 수행되

고 해당 STEP은 예외상황이 만족되는 것으로 처리된다. ALL 설정이 없는 경

우는 예외상황이 만족되지 않는 것으로 처리된다.

[PGM_NAME] 섹션에서 설명한 내용과 동일하다. [PGM_TYPE] 섹션에서는

프로그램 종류별로 예외상황에 해당하는 종료코드를 지정한다.

{rc_spec}

참고

{pgmtype} ALL에 의한 다른 예외상황(JOB CONDITION)이 만족되지 않는 경우에 추가적으로 행해

지는 예외상황 검사를 원하지 않는 경우는 ALL 설정을 하지 않도록 한다.

다음은 [PGM_TYPE]를 설정한 예이다.

COBOL=16-4096

PLI=1000,2000,3000

OTHER=16-255

ALL=8-255


색인

Symbols[ACCOUNT], 132

[AMS], 134

[DD], 129

[DDTAB], 129

[DEBUG], 134

[DEFAULT_OPTION], 124

[DEFAULT_USER], 125

[DYNAMIC_LIBRARY], 117

[INITDEF], 123

[INTRDR], 122, 126

[JCL], 133

[JOB], 127

[JOBCLASS], 115

[JOBDEF], 114

[LOG], 118

[NODEINFO], 112

[OUTCLASS], 122

[OUTDEF], 121

[PERFORM], 128

[PGM_NAME], 135

[PGM_TYPE], 136

[PGM], 131

[PRINTER1], 126

[PROCLIB], 117

[RESOURCE], 116

[SCHEDULING], 115

[SPOOL_TRANSFER_BACKUP], 120

[SPOOL_TRANSFER], 119

[SPOOL], 118

[SYSLIB], 130

[SYSTEM_DS], 113

[TACF], 123, 125, 133

BBase, 4

CCANCEL, 24

CATPROC, 37, 40, 55

CHANGE, 24

ColdBoot, 8

DDATASETCREATE – 입력 파라미터, 86

DATASETIMPORT - 입력 파라미터, 90

DATASETLIST - 데이터 셋 디스플레이 정보, 86

DATASETRECATALOG – 입력 파라미터, 89

DONE, 14

EERROR, 15

EXEC COND, 34

Exec phase, 33

EXECUTE, 24

FFINISH, 25

FLUSH, 15

GGDGCREATE - 입력 파라미터, 92

HHOLD, 14, 62

IINPJCL, 40, 53

INSDSET, 41

INSPROC, 37

JJESJCL, 41, 57

JESMSG, 41, 56

JESMSG상의 JOB 정보, 56

JESMSG상의 JOBSTEP 정보, 57

JESST, 9

JOB COND, 34

색인 137

JOB CONTROL, 43

JOB CONTROL 상태, 44

JOB START/FINISH, 44

JOBCAT DD/STEPCAT DD, 40

JOBID, 17

JOBLIB DD/STEPLIB DD, 39

JOBQ, 9, 17

JOBQ디스플레이 정보, 69

KKEEP, 62

LLEAVE, 62

Lock phase, 33

Oobmjhist, 3, 108

obmjinit, 3, 107

obmjmsvr, 3, 108

obmjschd, 3, 107

obmjspbk, 4, 108

ofrcmsvr, 108

ofrlmsvr, 108

ofrlmwrk, 108

ofrpmsvr, 4, 108

ofrsasvr, 108

ofruisvr, 108

OUTPUT, 61

OUTPUT Processing, 61

OUTPUTQ, 10

PPO – OUTPUT 상태 디스플레이 정보, 72

PODD, 22

POJOB, 22

POLIST – OUTPUT 리스트 디스플레이 정보, 72

POSPOOL, 22

POSPOOL-SPOOL 디스플레이 정보, 74

PSCATALOG - 데이터 셋 디스플레이 정보, 81

PSDATASET – 데이터 셋 디스플레이 정보, 83

PSENTRY – 엔트리 디스플레이 정보, 85

PSHISTORY – 입력 파라미터, 75

PSIO, 22

PSJCLRUN - Runner 상태 정보, 80

PSJOB, 22

PSJOB – 데이터 셋 I/O 디스플레이 정보, 71

PSJOB – 모니터링 디스플레이, 71

PSJOB 디스플레이 정보, 70

PSLOCK – 디스플레이 정보, 93

PSPRINT-프린터 디스플레이 정보, 99

PSVOLUME – 볼륨 디스플레이 정보, 94

PURGE, 62

RREMOVED, 26

RESUME, 25

Runner Slot, 4

Ssetuid root tjclrun, 46

setuid 작업, 46

SHOWCLASS – class 상태 정보, 79

SPOOL, 5, 17, 51

SPOOL 백업 명령어, 26

SPOOLBACKUP, 26

SPOOLBACKUPLIST, 26

SPOOLBACKUPLIST – 디스플레이 정보, 96

SPOOLCLEAR, 26

SPOOLPODD, 26

SPOOLPOSPOOL, 26

SPOOLPS, 26

SPOOLPS – 백업된 SPOOL 리스트 디스플레이 정보,

96

SPOOLPSIO, 26

SPOOLPSJOB, 26

SPOOLRESTORE, 26

START, 14

STEP START/FINISH, 44

STOP, 15

SUBMIT, 24

SUSPEND, 14, 25

SYSIN DD, 39

SYSMSG, 41, 53


SYSOUT, 42

SYSOUT DD/SYSPRINT DD, 39

TTACF 대리자, 45

tjclrun, 4

tjclrun의 JOB 실행 단계, 30

TJES 시스템 데이터 셋, 5

WWarmBoot, 7

WORKING, 14

WRITE, 62

ㄷ

데이터 셋 I/O 보고, 45

데이터 셋 Lock 대기, 44

데이터 셋 할당, 44

ㅅ

스페셜 DD, 38

ㅇ

입력 스트림 데이터 셋, 38

ㅍ

프로그램 STEP, 34

프로시져 STEP, 34

색인 139

openframe tjes 안내서 - tmaxsoft · 2019. 4. 9. · openframe 시스템의 vos3 jcl의 문법...

Documents