JCL을 COBOL에 매핑하는 방법과 그 중요성

인컴 2026년 6월 15일 COBOL 게시물, Data, 데이터 현대화, 영향 분석, 영향 분석 소프트웨어, 테크 토크

모든 기업용 메인프레임은 대부분의 현대 개발자가 직접 작성해 본 적이 없는 두 가지 언어가 긴밀하게 연결되어 실행됩니다. COBOL은 비즈니스 로직, 계산, 파일 처리, 레코드 변환, 규제 보고 등을 구현합니다. JCL(작업 제어 언어)은 이러한 로직의 실행을 총괄하여 어떤 프로그램이 어떤 순서로 어떤 파일을 어떤 조건에서 실행할지, 그리고 성공 또는 실패 시 어떤 결과가 발생할지 등을 정의합니다. 이 두 언어는 서로 없이는 완전할 수 없습니다. COBOL 프로그램은 입력 파일의 출처나 출력 파일의 위치를 알 수 없지만, JCL은 첫 번째 레코드를 읽기 전에 이 두 가지 질문에 대한 답을 제공합니다.

메인프레임 시스템을 유지 관리, 감사 또는 현대화하는 조직에게 JCL과 COBOL 간의 관계를 이해하는 것은 선택 사항이 아닌 필수 배경 지식입니다. 모든 변경 전 영향 분석, 마이그레이션 전 문서화, 전문가 은퇴 전 지식 이전 등 모든 작업의 전제 조건입니다. 매일 밤 청구를 처리하는 작업, 분기별 규제 보고서를 생성하는 배치 실행, 한 시스템에서 다른 시스템으로 데이터를 전송하는 프로시저 등 이 모든 것은 JCL로 정의되고 COBOL로 실행되며, JCL과 COBOL을 모두 다뤄본 경험이 있는 소수의 엔지니어만이 이해할 수 있습니다.

JCL에서 COBOL로 매핑하는 도구가 필요하신가요?

둘러보기 SMART TS XL!

더 많은 정보

차례

JCL이란 무엇인가요?

JCL은 Job Control Language의 약자입니다. IBM 메인프레임 시스템에서 배치 작업을 실행하기 위해 사용되는 스크립팅 언어입니다. JCL은 데이터를 직접 처리하지 않습니다. 운영 체제에 프로그램 실행 방법을 알려줍니다. 즉, 어떤 프로그램을 실행할지, 어떤 파일을 사용할 수 있도록 할지, 어떤 메모리와 CPU 리소스를 할당할지, 단계가 실패할 경우 어떻게 처리할지, 그리고 단일 작업 내의 여러 단계를 어떤 순서로 실행할지 등을 지정합니다.

모든 JCL 작업은 세 가지 기본 명령 유형으로 구성됩니다.

JOB 문은 시스템에 작업을 식별하고 회계, 우선순위 및 일정 매개변수를 정의합니다.

EXEC 문은 단계에서 실행할 프로그램 또는 프로시저를 지정합니다.

DD(데이터 정의) 문은 프로그램이 읽거나 쓸 데이터 세트를 정의하며, 여기에는 데이터 세트의 위치, 형식 및 처리 방식이 포함됩니다.

JCL

//PAYBATCH JOB (ACCT#7), 'PAYROLL RUN',
//          CLASS=A, MSGCLASS=X, NOTIFY=&SYSUID
//*
//STEP010  EXEC PGM=PAYROLL1
//STEPLIB  DD   DSN=PROD.PAYROLL.LOADLIB,DISP=SHR
//EMPFILE  DD   DSN=PROD.PAYROLL.EMPLOYEE,DISP=SHR
//TRANSACT DD   DSN=PROD.PAYROLL.TRANS.D&&DATE,DISP=SHR
//PAYRPT   DD   SYSOUT=A
//SYSOUT   DD   SYSOUT=*
//SYSIN    DD   DUMMY

이 예에서 : PAYBATCH 는 직무명입니다. STEP010 그것은 업무의 한 단계입니다. PGM=PAYROLL1 실행할 COBOL 프로그램의 이름을 지정하고, DD 문은 프로그램이 접근할 수 있는 모든 파일을 정의합니다. COBOL 프로그램은 PAYROLL1 어디에 있는지 모르거나 신경 쓰지 않는다. EMPFILE or TRANSACT 물리적 위치에서 가져온 경우, 단순히 ddname으로 읽습니다. JCL은 실행이 시작되기 전에 물리적 위치, 레코드 형식 및 액세스 모드를 확인합니다.

JCL 카탈로그에 등록된 프로시저(PROC)

메인프레임 팀은 모든 작업에 대해 동일한 JCL 패턴을 작성하는 대신 재사용 가능한 실행 패턴을 캡슐화하는 카탈로그화된 프로시저(PROC)를 정의합니다. PROC는 프로시저 라이브러리에 저장된 템플릿이며, 개별 작업은 이를 참조하고 필요에 따라 특정 매개변수를 재정의합니다.

JCL

//PAYPROC  PROC RUNDATE=TODAY
//COMPILE  EXEC PGM=IGYCRCTL,PARM='OBJECT,NODUMP'
//SYSIN    DD   DSN=PROD.COBOL.SRC(&MEMBER),DISP=SHR
//SYSOBJ   DD   DSN=&&OBJSET,DISP=(NEW,PASS),
//              UNIT=SYSDA,SPACE=(TRK,(10,5))
//LKED     EXEC PGM=IEWL,PARM='LIST,LET,XREF'
//SYSLIN   DD   DSN=&&OBJSET,DISP=(OLD,DELETE)
//SYSLMOD  DD   DSN=PROD.PAYROLL.LOADLIB(&MEMBER),
//              DISP=SHR
//         PEND

작업에서 프로시저 호출하기:

JCL

//COMPILE  EXEC PAYPROC,MEMBER=PAYROLL1,RUNDATE=20251205

이 단일 EXEC 문은 실행 시 전체 PROC로 확장됩니다. MEMBER RUNDATE 대체된 곳이라면 어디든 &MEMBER &RUNDATE PROC는 JCL-to-COBOL 매핑이 복잡한 주요 이유 중 하나입니다. 하나의 작업이 단일 PROC 참조를 통해 수십 개의 COBOL 프로그램을 호출할 수 있으며, 실제로 호출되는 프로그램은 실행마다 달라지는 기호 매개변수에 따라 달라집니다.

JCL과 COBOL의 차이점은 무엇인가요?

JCL과 COBOL은 종종 함께 언급되지만, 완전히 다른 역할을 수행합니다. 어느 한쪽이 다른 쪽을 대체하는 것이 아니며, 메인프레임 배치 처리가 제대로 작동하려면 둘 다 필수적입니다.

외형 치수	Jcl	코볼
목적	실행을 지휘합니다	비즈니스 로직을 구현합니다.
그것이 정의하는 것	작업, 단계, 파일, 조건	프로그램, 데이터 구조, 계산
실행될 때	프로그램 실행 전(설정) 및 실행 후(정리)	프로그램 실행 중
데이터 읽기/쓰기	데이터셋 할당(DD 문)을 통해	FILE SECTION 및 READ/WRITE 문을 통해
오류 처리	반환 코드, 조건부 단계 실행	예외 처리기, 오류 루틴 실행
이식성	IBM z/OS 전용	컴파일러를 사용하면 플랫폼 간 이식성이 향상됩니다.
누가 썼나요?	시스템 프로그래머, 배치 엔지니어	애플리케이션 개발자
현대판	CI/CD 파이프라인 + 컨테이너 오케스트레이션	응용 프로그램 코드 (Java, Python, C++)

둘 사이의 관계를 가장 쉽게 이해하는 방법은 다음과 같습니다. JCL은 배포 및 오케스트레이션 계층이고, COBOL은 애플리케이션 계층입니다. 최신 클라우드 네이티브 시스템에서 JCL의 역할은 Kubernetes 작업 매니페스트, 셸 스크립트, CI/CD 파이프라인 단계 등이 담당합니다. COBOL의 역할은 Java, Python 또는 Go로 작성된 애플리케이션 서비스가 담당합니다.

JCL이 COBOL을 호출하는 방법: 실행 체인

JCL 작업에서 COBOL 실행까지의 경로는 일관된 순서를 따릅니다. 각 단계를 이해하는 것은 JCL-COBOL 매핑에 포함되어야 할 내용을 이해하는 데 기본이 됩니다.

1단계: 작업 제출. JCL 작업이 작업 입력 하위 시스템(JES)에 제출됩니다. JES는 작업을 대기열에 추가하고 명령문을 읽기 시작합니다.

2단계: 단계 설정. 각 EXEC 단계에 대해 시스템은 STEPLIB DD 문으로 지정된 로드 라이브러리에서 명명된 프로그램을 찾습니다. STEPLIB이 지정되지 않은 경우 시스템은 시스템 링크 라이브러리를 검색합니다.

3단계: 데이터셋 할당. 프로그램 실행 전에 시스템은 이 단계의 DD 문으로 정의된 모든 데이터셋을 할당합니다. 여기에는 파일 열기, 입력 데이터셋 존재 여부 확인, 출력 데이터셋 생성 등이 포함됩니다.

4단계: 프로그램 실행. COBOL 프로그램이 실행됩니다. 이 프로그램은 JCL에 정의된 ddname을 사용하여 파일에 접근합니다. OPEN INPUT EMPFILE COBOL에서 DD 문에 직접적으로 매핑됩니다. EMPFILE JCL에서.

5단계: 반환 코드 평가. COBOL 프로그램이 종료되면 반환 코드(일반적으로 성공 시 0, 경고 시 4, 오류 시 8, 심각한 오류 시 12 또는 16)를 설정합니다. JCL은 이를 사용합니다. COND 매개변수 또는 IF/THEN/ELSE 이 코드를 기반으로 후속 단계를 실행해야 하는지 여부를 결정하는 구조입니다.

6단계: 데이터셋 처리. 이 단계 후, 시스템은 각 DD 문에 정의된 데이터셋 처리 방식(유지, 삭제, 카탈로그화, 카탈로그 해제 또는 다음 단계로 전달)을 처리합니다.

다음 예시는 이 과정이 실제로 어떻게 진행되는지 보여줍니다. 왼쪽은 JCL 코드이고, 오른쪽은 해당 COBOL 요소입니다.

JCL

//STEP020  EXEC PGM=ACCTREC
//STEPLIB  DD   DSN=PROD.ACCOUNT.LOADLIB,DISP=SHR
//INFILE   DD   DSN=PROD.ACCT.DAILY.INPUT,DISP=SHR     ← maps to COBOL SELECT/ASSIGN
//OUTFILE  DD   DSN=PROD.ACCT.PROCESSED,               ← maps to COBOL SELECT/ASSIGN
//              DISP=(NEW,CATLG,DELETE),
//              UNIT=SYSDA,SPACE=(CYL,(5,2),RLSE)
//RPTFILE  DD   SYSOUT=A                                ← maps to COBOL WRITE report
//SYSOUT   DD   SYSOUT=*

COBOL 프로그램 ACCTREC 포함한다 :

코볼

       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT INFILE    ASSIGN TO INFILE.         *> maps to DD INFILE
           SELECT OUTFILE   ASSIGN TO OUTFILE.        *> maps to DD OUTFILE
           SELECT RPTFILE   ASSIGN TO RPTFILE.        *> maps to DD RPTFILE

       DATA DIVISION.
       FILE SECTION.
       FD  INFILE
           RECORDING MODE IS F
           BLOCK CONTAINS 0 RECORDS
           RECORD CONTAINS 200 CHARACTERS.
       01  ACCOUNT-RECORD.
           05  ACCT-NUMBER    PIC X(10).
           05  ACCT-BALANCE   PIC S9(13)V99 COMP-3.
           05  ACCT-STATUS    PIC X(2).

The SELECT INFILE ASSIGN TO INFILE COBOL의 파일 제어(FILE-CONTROL) 섹션에서 DD 문에 연결됩니다. INFILE JCL에서. 이것이 기본적인 매핑 관계입니다. COBOL은 논리적인 파일 이름을 사용하고, JCL은 이를 물리적인 데이터 세트로 변환합니다.

JCL 비정상 종료 코드: 그 의미는 무엇일까요?

JCL 비정상 종료 코드(abend codes)는 작업 단계가 예기치 않게 종료된 이유를 나타냅니다. 이러한 코드는 작업 출력에 표시됩니다. S000 (시스템 비정상 종료) 또는 U0000 (사용자 비정상 종료) 코드. 이러한 코드를 이해하는 것은 배치 작업 실패를 진단하는 데 필수적입니다.

Abend 코드	타입	공통 원인
S001	시스템	데이터셋 읽기 또는 쓰기 중 I/O 오류 발생
S013	시스템	JCL DD와 COBOL FD 간의 DCB 속성 불일치, 레코드 길이 또는 형식 불일치
S0C4	시스템	저장소 보호 예외 발생, 프로그램이 할당된 영역 외부의 메모리에 접근하려고 시도했습니다.
S0C7	시스템	데이터 예외 발생, 숫자 이외의 데이터에 대한 산술 연산 시도 (COBOL에서 매우 흔한 비정상 종료 오류)
S322	시스템	시간 제한을 초과했습니다. 작업 실행 시간이 TIME 매개변수에서 허용한 시간보다 길었습니다.
S806	시스템	로드 모듈을 찾을 수 없습니다. EXEC PGM=에 지정된 프로그램이 검색된 로드 라이브러리에 없습니다.
S913	시스템	데이터셋 접근 보안 위반, RACF 또는 이와 유사한 접근 거부
U0000	사용자	사용자 코드로 호출되는 STOP RUN이라는 COBOL 프로그램의 응용 프로그램 정의 비정상 종료
U4076	사용자	IMS 관련 비정상 종료, 데이터베이스 접근 실패

가장 흔한 프로덕션 비정상 종료 유형은 다음과 같습니다. S0C7이 오류는 COBOL 프로그램이 공백이나 숫자가 아닌 문자가 포함된 필드에 대해 산술 연산을 시도할 때 발생합니다. 일반적인 원인은 COBOL 프로그램에서 예상하는 데이터 형식과 JCL에서 전달하는 실제 데이터 형식 간의 불일치이며, JCL-COBOL 매핑을 통해 이러한 불일치를 발견하여 심각한 운영 오류를 방지할 수 있습니다.

COND 매개변수와 조건부 실행

JCL은 이전 단계의 반환 코드를 기반으로 어떤 단계가 실행될지 제어합니다. COND 매개 변수 :

JCL

//STEP010  EXEC PGM=VALIDATE,COND=(4,LT)
//STEP020  EXEC PGM=PROCESS, COND=(4,LT,STEP010)
//STEP030  EXEC PGM=CLEANUP, COND=(0,NE,STEP010)

COND=(4,LT) 즉, 이전 단계의 반환 코드가 4보다 작으면 이 단계를 건너뛰라는 의미입니다. COND=(4,LT,STEP010) 즉, STEP010의 반환 코드가 4보다 작으면 이 단계를 건너뛰라는 의미입니다. COND=(0,NE,STEP010) 즉, STEP010의 반환 코드가 0이 아니면 STEP030을 건너뛰고, STEP010이 성공한 경우에만 정리 작업을 실행합니다.

최신 JCL은 다음을 사용합니다. IF/THEN/ELSE/ENDIF 대신 다음과 같이 작성하면 읽기가 더 쉽습니다.

JCL

//IF010    IF (STEP010.RC = 0) THEN
//STEP020  EXEC PGM=PROCESS
//         ENDIF
//IF020    IF (STEP010.RC > 4) THEN
//STEP030  EXEC PGM=ERRORHANDLER
//         ENDIF

조건부 실행 경로 매핑은 JCL-COBOL 분석에서 가장 중요하면서도 가장 흔히 간과되는 요소 중 하나입니다. 이전 단계가 실패했을 때만 실행되는 COBOL 프로그램은 오류 조건, 롤백 로직 또는 복구 절차를 처리할 수 있는데, 이러한 기능은 해당 프로그램을 구동하는 JCL 없이 COBOL 소스 코드만 보면 전혀 드러나지 않습니다.

JCL, COBOL, 그리고 DB2: 3계층 구조

대부분의 메인프레임 트랜잭션 시스템은 JCL 및 COBOL과 함께 IBM의 관계형 데이터베이스인 DB2라는 세 번째 구성 요소를 포함합니다. COBOL 프로그램은 내장된 SQL 문(EXEC SQL 블록)을 통해 DB2에 접근합니다. JCL은 특정 DD 문을 통해 DB2 서브시스템 연결과 DBRM(데이터베이스 요청 모듈)을 관리합니다.

JCL

//DBRM     DD   DSN=PROD.DBRMLIB.DATA(ACCTREC),DISP=SHR
//SYSPRINT DD   SYSOUT=*

코볼

       WORKING-STORAGE SECTION.
       EXEC SQL
           INCLUDE SQLCA
       END-EXEC.

       PROCEDURE DIVISION.
       MAIN-LOGIC.
           EXEC SQL
               SELECT ACCT_BALANCE, ACCT_STATUS
               INTO   :WS-BALANCE, :WS-STATUS
               FROM   ACCOUNT_MASTER
               WHERE  ACCT_NUMBER = :WS-ACCT-NUM
           END-EXEC.

           IF SQLCODE NOT = 0
               PERFORM DB2-ERROR-ROUTINE
           END-IF.

JCL-COBOL-DB2 스택에서 JCL은 런타임 환경과 데이터셋 접근을 제공하고, COBOL은 비즈니스 로직을 구현하고 데이터베이스를 호출하며, DB2는 COBOL 프로그램에 포함된 SQL에 따라 데이터를 저장하고 검색합니다. DB2를 사용하는 모든 COBOL 프로그램의 완전한 종속성 맵에는 해당 프로그램을 호출하는 JCL 작업뿐만 아니라 읽고 쓰는 DB2 테이블, 접근하는 열, 그리고 동일한 테이블에 접근하는 다른 프로그램까지 모두 포함되어야 합니다. 테이블 스키마 변경은 해당 테이블을 참조하는 모든 COBOL 프로그램에 영향을 미치기 때문입니다.

현대화에 있어 JCL-to-COBOL 매핑이 중요한 이유

JCL을 COBOL로 매핑하는 것은 단순히 기술적인 작업이 아닙니다. 오히려 위험 관리 작업입니다. 메인프레임 시스템에 대한 모든 변경 사항, 즉 JCL 매개변수 수정, 단계 추가, 데이터 세트 이름 변경 또는 작업이 호출하는 COBOL 프로그램 수정 등은 변경된 구성 요소를 넘어 광범위한 영향을 미칩니다. 변경 작업을 수행하기 전에 이러한 영향 범위를 정확하게 파악하는 유일한 방법은 현재 존재하는 모든 구성 요소와 그 연결 방식을 완벽하게 파악하는 것입니다.

마이그레이션 전 : 메인프레임에서 클라우드로 배치 워크로드를 이전하려면 어떤 JCL 작업이 있는지, 해당 작업이 호출하는 COBOL 프로그램은 무엇인지, 단계 간에 어떤 데이터 세트가 흐르는지, 실행 순서는 어떻게 되는지, 그리고 단계가 실패할 경우 어떤 일이 발생하는지 알아야 합니다. 이러한 정보가 없으면 마이그레이션 팀은 불완전한 문서 또는 문서가 전혀 없는 상태에서 작업을 진행하게 됩니다. 그 결과 단계가 누락되고, 종속성이 프로덕션 환경에서 발견되며, 전환 일정이 지연됩니다.

코드 변경 전 유의사항 : 어떤 JCL 작업이 해당 COBOL 프로그램을 호출하는지 확인하지 않고 COBOL 프로그램을 수정하면, 서로 다른 조건이나 데이터셋 구성에서 실행되는 작업들이 제대로 작동하지 않을 수 있습니다. 겉보기에는 로컬적인 JCL 매개변수 변경이라도 특정 데이터셋 속성에 의존하는 COBOL 프로그램의 동작에 영향을 미칠 수 있습니다. 영향 분석을 위해서는 변경 작업을 수행하기 전에 JCL에서 COBOL 프로그램, 그리고 데이터셋으로 이어지는 전체 연결 고리를 파악해야 합니다.

지식 전달 측면에서 보면 , 20년 동안 배치 시스템을 관리해 온 COBOL 개발자가 은퇴할 때, 그들은 JCL 작업과 COBOL 프로그램이 어떻게 연결되는지에 대한 정신적 모델을 가지고 떠납니다. 문서화된 연결 관계도는 이러한 지식을 다음 팀에 전달할 수 있는 유일한 방법입니다. 이러한 관계도가 없다면, 새로운 개발자들은 안전하게 수정할 수 없는 시스템을 물려받게 됩니다.

규정 준수 감사의 경우 : 규제 감사에서는 재무 계산, 데이터 변환 또는 접근 제어가 문서화된 대로 작동하는지 입증해야 하는 경우가 많습니다. JCL과 COBOL 간의 관계가 문서화되어 있지 않으면, 감사 압력 하에서 시스템을 역설계하지 않고는 이를 입증하는 것이 불가능합니다.

JCL 관리 도구 및 분석 플랫폼

이 기사에 사용된 검색 콘솔 데이터의 다국어적 특성(이탈리아어, 프랑스어, 스페인어, 일본어, 독일어 등 다양한 언어로 JCL 관리 도구에 대한 문의가 포함됨)은 메인프레임 IT 커뮤니티가 전 세계적으로 얼마나 널리 분포되어 있는지, 그리고 모든 지역의 팀들이 얼마나 일관되게 동일한 문제에 직면하고 있는지를 보여줍니다. 즉, JCL 및 COBOL 문서가 불완전하거나, 오래되었거나, 아예 존재하지 않는다는 것입니다.

JCL 분석 및 관리에 사용할 수 있는 도구는 세 가지 범주로 나뉩니다.

IBM 네이티브 툴링 : IBM은 JES(Job Entry Subsystem) 기능, JES 스풀 관리 및 IBM z/OS 배치 런타임을 제공합니다. 이러한 툴링은 실행 및 모니터링을 처리하지만 프로그램 간 종속성 분석이나 시각화는 제공하지 않습니다.

타사 작업 스케줄러 인 CA7, TWS(Tivoli Workload Scheduler) 및 Broadcom의 ESP Workload Automation은 수천 개의 작업에 걸쳐 배치 스케줄링을 관리하고, 종속성 기반 스케줄링을 제공하며, 실패 시 알림을 보냅니다. 이러한 스케줄러는 작업 수준의 종속성을 이해하지만 일반적으로 각 단계 내에서 호출되는 COBOL 프로그램을 분석하지는 않습니다.

정적 코드 분석 및 종속성 매핑 플랫폼 : JCL 및 COBOL 소스 코드를 구문 분석하여 어떤 작업이 어떤 프로그램을 호출하는지, 어떤 프로그램이 어떤 데이터 세트에 액세스하는지, 그리고 시스템 전체에서 데이터가 어떻게 흐르는지에 대한 구조적 모델을 구축하는 도구입니다. 이러한 도구는 작업 스케줄러 및 IBM 기본 도구로는 불가능한 계층 간 가시성을 제공합니다. 예를 들어 특정 JCL DD 문과 이에 매핑되는 COBOL FILE-CONTROL 항목 간의 관계, 또는 데이터 세트에 쓰는 COBOL 프로그램과 해당 데이터 세트를 입력으로 읽는 다음 작업 간의 관계를 파악할 수 있습니다.

SMART TS XL 이 도구는 세 번째 범주에 속하며 COBOL, JCL, PL/I, 어셈블러, SQL, Java 등 기업 환경의 모든 언어를 포괄하도록 확장하여 단일 언어 도구로는 제공할 수 없는 언어 간 구조 분석을 제공합니다.

방법 SMART TS XL 엔터프라이즈 규모에서 JCL을 COBOL로 변환합니다.

단일 작업에 대해 3단계로 JCL을 COBOL로 수동 매핑하는 것은 가능하지만, 5만 개의 JCL 작업, 20만 개의 COBOL 프로그램, 그리고 40년 동안 축적된 수백만 개의 데이터셋 참조를 가진 조직에서는 불가능합니다. 특정 PROC, 해당 PROC를 호출하는 데 사용되는 기호 매개변수, 이러한 매개변수가 해석되는 COBOL 프로그램, 그리고 이러한 프로그램이 액세스하는 데이터셋 간의 관계를 그 규모에서는 수동으로 추적하는 것이 불가능합니다.

SMART TS XL 이 도구는 기호 매개변수 치환을 사용하는 PROC, 인스트림 프로시저, INCLUDE 멤버, 오버라이드 및 조건부 실행 로직을 포함하여 JCL 및 COBOL 소스 코드를 구문 분석하고 시스템의 모든 구조적 관계를 나타내는 통합 상호 참조 모델을 구축합니다. 이 모델은 수동으로 업데이트되는 문서가 아니라 소스 코드에서 재생성되므로 쿼리 및 탐색이 가능하며 항상 최신 상태를 유지합니다.

The JCL 확장 이 기능은 기호 매개변수 대체를 해결하여 각 호출 작업에서 적용된 재정의를 고려하여 모든 PROC에서 호출된 실제 프로그램과 데이터 세트를 표시합니다. &PGMNAME 기호 매개변수는 모델에서 호출하는 모든 주체에 걸쳐 해당 매개변수가 해석되는 모든 구체적인 프로그램으로 나타나며, 미해결 참조로 나타나지 않습니다.

애플리케이션 종속성 매핑 기능은 JCL 작업부터 COBOL 프로그램, DB2 테이블, 하위 프로그램에 이르기까지 전체 그래프를 구축하여 시스템의 모든 구성 요소와 그 사이의 모든 연결을 보여줍니다. 현대화 변경 작업을 시작하기 전에 팀은 다음과 같은 질문을 할 수 있습니다. 어떤 작업이 이 프로그램을 호출하는가? 이 프로그램은 어떤 데이터 세트를 읽는가? 다른 어떤 프로그램이 해당 데이터 세트에 쓰는가? 순차적으로 실행되는 다음 작업은 무엇인가?

영향 분석 기능은 제안된 변경 사항에 대한 결과 범위를 열거하여 보여줍니다. 예를 들어, 이 카피북을 수정하면 이를 포함하는 모든 프로그램을 볼 수 있고, 이 데이터셋 레이아웃을 변경하면 이를 참조하는 모든 JCL DD 문을 볼 수 있으며, 작업에서 이 단계를 제거하면 해당 출력에 의존하는 모든 하위 단계를 볼 수 있습니다.

JCL을 COBOL로 매핑하는 작업을 진행 중인 팀의 경우 레거시 현대화 프로그램, SMART TS XL 이는 아스타디아, TSRI, 어드밴스드 등 현대화 업체들이 변환 작업을 시작하기 전에 필요한 기반을 제공합니다. 즉, 기존 시설에 대한 완벽하고 정확한 구조적 목록을 제공하여 변환 범위를 추측이 아닌 분석을 통해 정의할 수 있도록 합니다.

지도는 영토가 아니라 출발점이다.

JCL과 COBOL은 사라지지 않을 것입니다. 급여 처리, 보험 청구 처리, 규제 보고서 작성, 금융 거래 정산 등을 담당하는 배치 시스템은 클라우드 마이그레이션이 계획, 승인, 자금 조달 및 실행될 때까지 메인프레임에서 계속 운영될 것입니다. 이러한 마이그레이션 과정은 일반적으로 몇 달이 아닌 몇 년이 걸립니다. 그 기간 동안 시스템은 유지 관리, 수정 및 이해되어야 합니다.

JCL과 COBOL 간의 매핑은 일회성 프로젝트가 아닙니다. 프로그램이 수정되고, 작업이 추가되고, 데이터 세트가 재구성될 때마다 구조적 모델을 최신 상태로 유지하는 지속적인 작업입니다. 이러한 작업에 투자하는 팀은 업계 대부분이 블랙박스로 취급하는 시스템을 자신 있게 변경할 수 있는 능력을 유지합니다. 반면, 그렇지 않은 팀은 시스템을 완전히 파악할 수 없는 환경에서 변경 작업을 수행하게 되는데, 이러한 환경에서는 누락된 종속성이 컴파일 오류를 발생시키지 않더라도 새벽 3시에 야간 배치 실행 중에 심각한 운영 장애를 초래할 수 있습니다.