갑자기 COBOL 소스를 읽을 처지가 되었을 때 최저한 알아두어야 할 것 - DIVISION / PIC / COMP-3 / COPY / PERFORM을 먼저 정리

2026년 03월 17일 01:00 · 小村豪 · COBOL, 레거시 기술, 업무 시스템, 보수, Mainframe

인계, 장해 대응, 벤더제 패키지의 보수. 그러한 장면에서 어느 날 갑자기 COBOL 소스가 날아오는 경우가 있습니다.

파일 이름은 .cbl이나 .cpy
변수 이름은 전부 대문자
01, 05, 77, 88이 나열된다
PIC S9(7)V99 COMP-3 같은 주문과 회계 소프트의 중간 같은 기술이 나온다
게다가 COPY 투성이로, 연 파일만으로는 전체가 보이지 않는다

이 부근에서 뇌가 약간 가루가 됩니다.

다만, 읽기 위한 지도는 그리 크지 않습니다. COBOL에는 처리계나 제품별 차이가 있지만, 기존 업무 시스템을 읽을 때 먼저 짚어야 할 골격은 꽤 공통입니다. 이 글에서는 IBM 계열이나 전형적인 업무 COBOL을 염두에 두고 갑자기 소스를 읽게 된 사람을 위한 최소 세트를 정리합니다.

1. 먼저 결론(한마디로)

먼저 꽤 거칠지만 실무에서 도움이 되는 말로 하면 이렇습니다.

COBOL은 로직의 언어이기 전에, 꽤 강하게 레코드 정의의 언어입니다
PROCEDURE DIVISION만 읽어도 절반밖에 알 수 없습니다. 먼저 DATA DIVISION을 봅니다
PIC는 항목의 형, USAGE는 어떤 표현으로 가질지입니다
COMP-3는 packed decimal입니다. 금액이나 건수의 세계에서 자주 나옵니다
88은 별도 변수라기보다 직전 항목의 값에 이름을 붙인 조건명입니다
REDEFINES는 같은 메모리를 다른 형태로 보는 구조입니다. 복사가 아닙니다
COPY가 있다면 지금 연 소스는 아직 미완성입니다. copybook을 보지 않으면 전체가 보이지 않습니다
PERFORM, IF, EVALUATE, READ, WRITE, CALL을 쫓으면 대체적인 흐름을 잡을 수 있습니다
오래된 소스는 열 위치에 의미가 있는 고정 형식입니다. 겉모습의 공백이 단순한 장식이 아닙니다¹

요컨대, DIVISION, PIC, USAGE, COMP-3, REDEFINES, OCCURS, 88, COPY, PERFORM. 이 부근이 읽히면 미아율이 꽤 내려갑니다.

2. COBOL은 먼저 「데이터의 형」의 언어라고 생각한다

C#이나 Java의 감각으로 읽으면, 처음에는 if나 for나 함수 호출을 쫓고 싶어집니다. 하지만 COBOL은 거기로 가기 전에 「이 프로그램은 어떤 레코드를 받고, 어떤 레코드를 만들며, 어떤 버퍼를 가지고 있는가」를 짚는 편이 빠릅니다.

전형적인 업무 COBOL은 대체로 다음 흐름입니다.

파일이나 DB에서 레코드를 읽는다
WORKING-STORAGE 상의 항목으로 넣는다
조건 분기한다
다른 레코드로 다시 채운다
써낸다

즉, 알고리즘보다 레이아웃이 먼저 서기 쉽습니다.

예를 들어 이런 골격입니다.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. SAMPLE01.

       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT SALES-FILE ASSIGN TO ...

       DATA DIVISION.
       FILE SECTION.
       FD  SALES-FILE.
       01  SALES-REC.
           05  SALE-ID       PIC 9(8).
           05  SALE-AMOUNT   PIC S9(7)V99 COMP-3.

       WORKING-STORAGE SECTION.
       01  WS-EOF            PIC X VALUE 'N'.
           88  EOF           VALUE 'Y'.

       PROCEDURE DIVISION.
           PERFORM UNTIL EOF
               READ SALES-FILE
                   AT END
                       SET EOF TO TRUE
                   NOT AT END
                       PERFORM PROCESS-SALE
               END-READ
           END-PERFORM
           STOP RUN.

이 코드를 읽을 때 먼저 봐야 할 것은 PERFORM보다 먼저 SALE-AMOUNT의 형이나 EOF의 의미입니다. COBOL은 그 순서로 읽으면 갑자기 조용해집니다.

3. 4개의 DIVISION을 먼저 본다

COBOL 소스는 먼저 크게 4개의 DIVISION으로 나뉩니다.

DIVISION	먼저 볼 것
`IDENTIFICATION DIVISION`	프로그램 이름, 오래된 코멘트, 유래
`ENVIRONMENT DIVISION`	파일, 외부 자원, 입출력의 전제
`DATA DIVISION`	레코드 정의, 작업 영역, 인수
`PROCEDURE DIVISION`	실제 처리 순서

특히 중요한 것은 다음입니다.

FILE SECTION 입출력 파일의 레코드 정의가 있다
WORKING-STORAGE SECTION 평소 사용하는 변수, 플래그, 카운터, 작업 버퍼가 있다
LOCAL-STORAGE SECTION 호출마다 초기화되는 영역이 있을 수 있다
LINKAGE SECTION 외부에서 넘겨지는 인수나 서브프로그램의 수용구가 있을 수 있다

LINKAGE SECTION과 PROCEDURE DIVISION USING ...이 보이면 그 프로그램은 단독 완결이 아니라 외부에서 데이터를 받아 동작할 가능성이 높습니다.

4. 고정 형식의 외관에 겁먹지 않는다

오래된 COBOL에서는 소스 1행의 열 위치 그 자체에 의미가 있습니다. 이것을 모른 채 보면 「왜 왼쪽에 이상한 여백이 있는지」가 영원히 알 수 없습니다.¹

고정 형식에서는 대략 이렇습니다.

1 - 6 열: 일련 번호
7 열: indicator
8 - 11 열: Area A
12 - 72 열: Area B

7 열째가 특히 중요합니다.

* 또는 / : 코멘트 행
- : 계속 행
D : debugging line
*> : 도중에도 쓸 수 있는 코멘트

외관의 압박을 낮추기 위해 꽤 거칠게 그림으로 하면 이렇습니다.

1234567 8901 23456789012345678901234567890
      * 코멘트
       IDENTIFICATION DIVISION.
       PROGRAM-ID. SAMPLE01.

여기서의 공백은 현대적인 의미에서의 「정형」이 아니라 부분적으로 구문입니다. 에디터에서 탭 변환하거나 왼쪽으로 기울이거나 거칠게 복사 붙여넣기하면 평범하게 망가집니다. 오래된 소스를 볼 때는 먼저 그 파일이 fixed format인지 free format인지를 의심해 주세요. fixed인데 modern formatter를 대면 꽤 경기 좋게 폭발합니다.

5. DATA DIVISION의 최저한

5.1 레벨 번호

COBOL의 데이터 정의는 들여쓰기가 아니라 레벨 번호로 계층을 만듭니다.²

       01  WS-ORDER.
           05  WS-ORDER-ID    PIC 9(8).
           05  WS-AMOUNT      PIC S9(7)V99 COMP-3.
           05  WS-STATUS      PIC X.
               88  WS-OK      VALUE '0'.
               88  WS-ERROR   VALUE '9'.

       77  WS-COUNT           PIC 9(4).

최저한 이것만 외워두면 충분합니다.

01 : 한 덩어리의 최상위 레코드, 그룹
02 - 49 : 그 아래 계층
77 : 독립된 단 항목
88 : condition-name. 직전 항목의 값에 이름을 붙인다³
66 : RENAMES용. 조우율은 높지 않지만 존재는 한다

중요한 것은 88을 bool의 별도 변수라고 생각하지 않는 것입니다. WS-OK라는 영역이 별도로 있는 것이 아니라, WS-STATUS가 '0'일 때 WS-OK라는 이름으로 읽을 수 있는 느낌입니다.

또 하나 중요한 것은 계층을 결정하는 것은 공백이 아니라 레벨 번호라는 점입니다. 겉모습의 들여쓰기는 참고는 되지만, 최종적으로 믿어야 할 것은 01 / 05 / 10 / 88 쪽입니다.²

5.2 PICTURE

PIC는 그 항목의 형을 나타냅니다. 가장 자주 보는 것은 다음입니다.

기법	대략 의미
`X`	문자
`9`	숫자
`S`	부호 있음
`V`	소수점은 논리상만 가진다
`X(10)`	10 문자
`9(5)`	5자리 수치
`S9(7)V99`	부호 있음, 정수 7자리 + 소수 2자리

예를 들어,

PIC X(10) → 10 문자
PIC 9(5)V99 → 5자리 정수 + 2자리 소수
PIC S9(7)V99 → 부호 있음 7자리 정수 + 2자리 소수

입니다.

여기서 특히 중요한 것은 V입니다. V는 실제의 . 문자를 갖지 않습니다. PIC 9(5)V99는 「소수점 2자리의 수」로서 다루어지지만, 데이터 상에 점 문자가 들어가 있는 것은 아닙니다. 그래서 파일이나 덤프를 「외관의 문자열」로서 해석하면 대개 넘어집니다.

5.3 USAGE / DISPLAY / COMP / COMP-3

PIC가 형이라고 한다면 USAGE는 어떤 표현으로 보유할 것인가입니다. 최저한 다음만 짚으면 꽤 읽을 수 있습니다.⁴⁵

기법	대략 의미	읽을 때의 주의
`DISPLAY`	문자로서 보이는 외부 10진	mainframe에서는 EBCDIC 전제인 경우가 있다⁶
`COMP` / `BINARY`	2진수	외관의 자릿수와 내부 표현은 다르다
`COMP-3` / `PACKED-DECIMAL`	packed decimal	문자로서 읽으면 망가져 보인다

예를 들어,

       01  WS-AMOUNT-DISP   PIC S9(7)V99.
       01  WS-AMOUNT-BIN    PIC S9(7) COMP.
       01  WS-AMOUNT-PACK   PIC S9(7)V99 COMP-3.

이 3개는 전부 「수치」이지만 내용물의 가지는 방식이 다릅니다.

실무에서 가장 효과적인 것은 COMP-3를 본 순간의 반응입니다.

그것은 packed decimal
아마도 금액, 세금, 건수, 레이트계
텍스트로서 보면 망가져 보여도 당연
CSV나 UTF-8의 기분으로 보면 사고난다

는 이해를 가지고 있으면, 덤프나 바이너리 파일의 보이는 방식에서 쓸데없이 panic하지 않게 됩니다.

또 하나만 보충하면, DISPLAY라고 해서 반드시 ASCII 문자열이라고는 한정되지 않습니다. z/OS 계에서는 EBCDIC이 전제가 되므로, 숫자가 문자로 보이고 있어도 바이트값은 ASCII의 '0' - '9'와는 다른 경우가 있습니다.⁶

5.4 REDEFINES / OCCURS / COPY / FILLER

이 4개는 읽을 때의 막힘 포인트입니다.

REDEFINES

REDEFINES는 같은 영역을 다른 형태로 보는 구조입니다. 복사가 아닙니다.⁷

       01  REC-BUF.
           05  REC-TYPE      PIC X.
           05  REC-DATA      PIC X(99).

       01  HEADER-REC REDEFINES REC-BUF.
           05  HDR-TYPE      PIC X.
           05  HDR-DATE      PIC 9(8).
           05  FILLER        PIC X(91).

이것은 C 계로 말하면 union적인 감각에 가깝습니다. 「1개의 100 바이트를 별도 레코드 종별로서 구별한다」같은 쓰는 법에서 자주 나옵니다.

OCCURS

OCCURS는 배열입니다. COBOL에서는 table이라고 불리기 쉽습니다.

       05  WS-ITEM OCCURS 12 TIMES.
           10  WS-PRICE    PIC 9(5).

게다가 OCCURS DEPENDING ON이 나오면 가변 길이 테이블입니다. 이 경우, 후속 항목의 위치까지 영향이 있는 경우가 있으므로 고정 길이의 기분으로 쫓으면 발을 헛디딥니다.⁸

COPY

COPY는 compile time의 include입니다. 즉, 지금 연 소스는 아직 완성형이 아닐 가능성이 있습니다.⁹

       COPY CUSTOMER-REC.
       COPY ERROR-MAP.

레코드 정의, 공통 플래그, SQL용의 host variable, 외부 인터페이스가 copybook에 밀어넣어져 있는 것은 꽤 평범합니다.

COPY가 많아 읽기 어려울 때는 전개 후 소스나 compiler listing을 볼 수 없는지를 확인하는 편이 빠릅니다. IBM Enterprise COBOL에는 MDECK라는 라이브러리 처리 후의 입력 소스를 써내기 위한 option도 있습니다.¹⁰

FILLER

FILLER는 이름이 없는 항목입니다. 다만, 「참조하지 않으니까 무의미」는 아닙니다.

예약 영역
구 사양과의 호환용 구멍
레코드 길이 맞춤
REDEFINES용의 여백

으로서 평범하게 효과적입니다.

FILLER는 이름이 없을 뿐이고 바이트 수로서는 존재한다. 이것을 잊으면 외부 파일과의 매핑에서 1 바이트씩 세계가 어긋나게 됩니다.

6. PROCEDURE DIVISION의 최저한

DATA DIVISION이 지도라면, PROCEDURE DIVISION은 이동 경로입니다.

6.1 PERFORM

PERFORM은 COBOL의 기본적인 제어 이동입니다. 대략 말하면 처리를 부르고 돌아온다입니다.¹¹

자주 보는 형은 다음입니다.

       PERFORM INIT-PROC
       PERFORM UNTIL EOF
           PERFORM READ-PROC
           IF NOT EOF
               PERFORM EDIT-PROC
               PERFORM WRITE-PROC
           END-IF
       END-PERFORM

PERFORM에는 크게 2계통이 있습니다.

단락이나 절을 지정하는 out-of-line PERFORM
그 자리에 블록을 쓰는 inline PERFORM ... END-PERFORM

게다가 오래된 코드에서는 PERFORM A-100 THRU A-199와 같은 범위 지정도 평범하게 나옵니다. 이것은 편리하지만, 단락을 도중에 추가하면 말려드는 사고가 일어나기 쉬우므로 읽을 때는 범위의 종단을 제대로 봅니다.

6.2 IF / EVALUATE / 스코프

조건 분기는 IF가 기본입니다. EVALUATE는 switch/case적인 것이라고 생각하면 대개 맞습니다.

조심해야 할 것은 스코프의 끝나는 방식입니다.¹²

END-IF
END-PERFORM
END-READ

와 같은 명시적인 종단이 있는 코드는 아직 읽기 쉽습니다.

문제는 오래된 코드입니다. COBOL에서는 .이 암묵의 scope terminator로서 작동하며, 아직 닫히지 않은 문장을 한꺼번에 끝나게 합니다.¹²

즉, 단 1개의 마침표로,

어디까지가 IF인가
어디까지가 PERFORM인가
어디서 다음 sentence로 옮기는가

가 바뀝니다.

게다가 NEXT SENTENCE는 CONTINUE와 같지 않습니다. NEXT SENTENCE는 다음 마침표 뒤로 진행하므로, 후속 .의 위치 여하로 날아갈 곳이 바뀝니다.¹²

오래된 COBOL을 읽을 때는 행 끝이 아니라 마침표를 본다 정도로 딱 좋습니다.

6.3 READ / WRITE / CALL

업무 COBOL에서 빈출인 것은 이 부근입니다.

READ
WRITE
REWRITE
START
CALL

특히 READ ... AT END ...는 왕도입니다.

       READ IN-FILE
           AT END
               SET EOF TO TRUE
           NOT AT END
               PERFORM PROCESS-REC
       END-READ

CALL 'SUBPGM' USING ...이 있으면 별도 프로그램으로 날아갑니다. 그때는 불러지는 곳의 LINKAGE SECTION과 PROCEDURE DIVISION USING을 보면, 주고받는 형이 꽤 보입니다.

7. COBOL의 외측에 있는 것

COBOL은 소스만으로 세계가 완결되고 있지 않은 경우가 꽤 있습니다.

파일 정의
실행 환경
DB 접속
트랜잭션 환경
job 제어

가 외측에 나뉘어 있기 때문입니다.

최저한 다음을 짚으면 읽기 쉬워집니다.

파일과 `FILE STATUS`

ENVIRONMENT DIVISION의 FILE-CONTROL과 DATA DIVISION의 FILE SECTION / FD는 세트로 읽습니다.¹³

       SELECT IN-FILE ASSIGN TO ...
           FILE STATUS IS WS-FS.

       FD  IN-FILE.
       01  IN-REC.
           05 ...

FILE STATUS가 있으면 각 I/O 후의 결과 코드가 들어갑니다. 파일계의 장해나 EOF 판정을 읽을 때는 이것을 보지 않으면 시작되지 않습니다.¹⁴

`EXEC SQL`

이것이 나오면 임베디드 SQL입니다.

       EXEC SQL
           SELECT ...
       END-EXEC.

이 경우 COBOL은 「호스트 변수의 그릇」이고, 실제 취득 조건이나 갱신 대상은 SQL 측에 있습니다. 그래서 EXEC SQL의 내용물을 보통의 SQL로서 읽는 것이 지름길입니다.

`EXEC CICS`

이것이 나오면 CICS의 트랜잭션 문맥입니다.¹⁵

       EXEC CICS
           RECEIVE MAP(...)
       END-EXEC.

이 순간 단순한 배치 해독이 아니게 됩니다. 화면, 트랜잭션, 응답 코드, COMMAREA 등 외부 문맥 포함으로 읽을 필요가 있습니다.

JCL이나 실행 정의

mainframe batch에서는 실제로 어느 데이터셋이 할당되는가나 어느 순서로 job이 흐르는가가 COBOL 소스의 외부에 있는 것도 드물지 않습니다. 소스만 봐도 「이 파일은 어디에 있는가」를 모를 때는 코드가 나쁜 것이 아니라 보고 있는 범위가 아직 부족한 것뿐이라는 것이 평범하게 있습니다.

8. 최저한의 읽는 순서

갑자기 COBOL을 읽게 되었을 때는 다음 순서가 안전합니다.

COPY를 전부 씻어낸다 copybook을 열 수 있으면 연다. 무리라면 listing이나 전개 후 소스를 찾는다
01 레벨의 레코드 정의를 줍는다 FILE SECTION, WORKING-STORAGE, LINKAGE SECTION의 최상위를 일람화한다
PIC와 USAGE를 읽는다 금액, 날짜, 건수, 코드, 플래그를 식별한다
READ / WRITE / REWRITE / CALL / EXEC SQL / EXEC CICS를 검색한다 입출력과 외부 경계를 먼저 잡는다
최초의 주 경로만 쫓는다 PROCEDURE DIVISION의 선두에서 PERFORM 연쇄를 따른다
88과 status 항목을 본다 EOF, 정상/이상, 종별 코드의 의미가 읽기 쉬워진다
REDEFINES / OCCURS DEPENDING ON / COMP-3에 표시를 붙인다 나중에 반드시 효과적이므로 먼저 위험물로서 마크해 둔다
파일이라면 FILE STATUS를 본다 I/O 에러계의 오독을 꽤 줄일 수 있다

이 순서라면 갑자기 전문을 정독하지 않아도 됩니다. COBOL은 처음부터 100% 이해하려고 하기보다 레코드, 외부 경계, 주 경로의 3점을 짚고 나서 세부로 가는 편이 훨씬 편합니다.

9. 자주 있는 막힘 포인트

마지막으로 초보자가 꽤 높은 확률로 걸리는 곳을 정리합니다.

`REDEFINES`를 「별도 변수」라고 생각한다

다릅니다. 같은 영역을 다른 형태로 읽고 있습니다. 한쪽을 고쳐 쓰면 다른 한쪽의 보이는 방식도 바뀝니다.⁷

`88`을 「독립된 bool」이라고 생각한다

다릅니다. 직전 항목의 값에 이름이 붙어 있을 뿐입니다. SET WS-OK TO TRUE는 뒤에서는 기저 항목으로 대응값을 넣습니다.³

`COPY`를 무시하고 본문만 읽는다

그것은 지도의 절반을 접은 채로 산에 들어가는 행위입니다. 필드 정의, 공통 플래그, host variable이 몽땅 외부에 있는 것은 평범합니다.⁹

`MOVE`를 단순 대입이라고 생각한다

MOVE는 단순한 memcpy가 아닙니다. 수신 측의 형에 따라 변환, 자리 맞춤, 0 채움, 잘라냄, 편집・역편집이 들어갈 수 있습니다.¹⁶

`.`의 영향을 가볍게 본다

COBOL의 .은 상상보다 무겁습니다. 명시 종단이 없는 오래된 코드에서는 이 마침표가 어디까지 닫혀 있는가를 잘못 보면 제어 플로를 잘못 읽습니다.¹²

packed decimal이나 EBCDIC을 「문자화면 망가짐」이라고 생각한다

망가져 있다고는 한정되지 않습니다. 처음부터 문자열이 아니거나 ASCII가 아닐 뿐이라는 경우가 꽤 있습니다.⁴⁶

`OCCURS DEPENDING ON`의 뒤를 고정 위치라고 생각한다

가변 길이 테이블의 후속 항목은 값에 따라 위치가 움직일 수 있습니다. 고정 길이의 머리로 읽으면 오프셋 계산이 전부 어긋납니다.⁸

10. 먼저 보는 일람표

발견한 말	먼저 생각할 것
`01`	레코드나 그룹의 최상위. 여기서 전체상을 잡는다
`88`	플래그나 상태 코드의 의미명. 분기를 읽는 열쇠
`PIC X(...)`	문자 항목
`PIC 9(...)` / `S9(...)V...`	수치 항목. 자릿수와 소수 위치를 확인
`COMP`	binary
`COMP-3`	packed decimal. 금액・건수의 가능성이 높다
`REDEFINES`	같은 영역을 다른 해석하고 있다
`OCCURS`	배열・table
`OCCURS DEPENDING ON`	가변 길이. 후속 위치에도 주의
`FILLER`	이름은 없지만 길이는 있다
`COPY`	copybook을 보지 않으면 완성형이 보이지 않는다
`PERFORM`	주 경로의 골격
`READ` / `WRITE` / `REWRITE`	파일 I/O
`EXEC SQL`	DB 처리
`EXEC CICS`	트랜잭션 처리
`FILE STATUS`	I/O의 결과 코드

11. 정리

COBOL은 오래됐다고 어려운 것이 아닙니다. 데이터 정의, 외부 파일, 실행 문맥이 밀접하게 결합되어 있기 때문에 최초의 입구가 보이기 어려울 뿐입니다.

읽기 위한 최소 세트를 다시 한 번 정리하면 이렇습니다.

DIVISION으로 지도를 잡는다
DATA DIVISION을 먼저 읽는다
PIC와 USAGE로 항목의 형을 읽는다
COMP-3, REDEFINES, OCCURS, 88, COPY에 표시를 붙인다
PERFORM, READ, WRITE, CALL을 쫓는다
FILE STATUS, EXEC SQL, EXEC CICS로 외부 경계를 짚는다
.의 효과를 가볍게 보지 않는다

여기가 보이면, COBOL은 「수수께끼의 고대 마법」에서 「레코드 처리의 언어」로 바뀝니다. 레거시 기술은 이름이 오래됐기 때문에 무서운 것이 아니라, 처음에 보는 축척을 틀리면 갑자기 알기 어려워질 뿐입니다. 지도의 축척이 맞으면 의외로 평범하게 읽을 수 있습니다.

12. 참고 자료

본문 중의 주된 참조처입니다.

IBM, “Reference format” https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=structure-reference-format / IBM, “Area A or Area B” https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=format-area-area-b / Micro Focus, “Fixed Format” https://www.microfocus.com/documentation/visual-cobol/vc60/DevHub/HRLHLHINTR01U904.html ↩ ↩²
IBM, “Level-numbers” https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=entry-level-numbers ↩ ↩²
IBM, “Format 2: condition-name value” https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=vc-format-2 ↩ ↩²
IBM, “Examples: numeric data and internal representation” https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=data-examples-numeric-internal-representation ↩ ↩²
IBM, “PACKED-DECIMAL (COMP-3)” https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=v6-packed-decimal-comp-3 ↩
IBM, “The EBCDIC character set” https://www.ibm.com/docs/en/zos-basic-skills?topic=mainframe-ebcdic-character-set / IBM, “Handling differences in ASCII SBCS and EBCDIC SBCS characters” https://www.ibm.com/docs/en/cobol-linux-x86/1.2.0?topic=fdcbdr-handling-differences-in-ascii-sbcs-ebcdic-sbcs-characters ↩ ↩² ↩³
IBM, “REDEFINES clause” https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=entry-redefines-clause ↩ ↩²
IBM, “OCCURS DEPENDING ON clause” https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=clause-occurs-depending ↩ ↩²
IBM, “COPY statement” https://www.ibm.com/docs/en/cobol-linux-x86/1.2.0?topic=statements-copy-statement ↩ ↩²
IBM, “Enterprise COBOL compiler options” https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=guide-enterprise-cobol-compiler-options ↩
IBM, “PERFORM statement” https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=statements-perform-statement / IBM, “Procedure division structure” https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=division-procedure-structure ↩
IBM, “Scope terminators” https://www.ibm.com/docs/en/cobol-aix/5.1.0?topic=division-scope-terminators / IBM, “Coding a choice of actions” https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=actions-coding-choice ↩ ↩² ↩³ ↩⁴
IBM, “Describing the structure of a file in detail” https://www.ibm.com/docs/en/cobol-linux-x86/1.2.0?topic=files-describing-structure-file-in-detail ↩
IBM, “FILE STATUS clause” https://www.ibm.com/docs/en/cobol-linux-x86/1.2.0?topic=section-file-status-clause / IBM, “Using file status keys” https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=operations-using-file-status-keys ↩
IBM, “Coding COBOL programs to run under CICS” https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=cics-coding-cobol-programs-run-under ↩
IBM, “Elementary move rules” https://www.ibm.com/docs/en/cobol-zos/6.3.0?topic=moves-elementary-move-rules ↩

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

기존 자산 활용 & 이관 지원

COM / ActiveX / OCX 자산, 네이티브 코드, 32비트 의존성을 유지하면서 단계적인 이관 계획을 지원합니다.

서비스 보기 문의하기

저자 프로필

기사 저자의 프로필 페이지입니다.

블로그 목록으로 돌아가기