每台企業級大型主機都運行著兩種相互交織的語言，而大多數現代開發人員從未編寫過這兩種語言。 COBOL 實現業務邏輯、計算、文件處理、記錄轉換和監管報告。 JCL（作業控制語言）則負責協調這些邏輯的執行，定義哪些程式運作、運作順序、使用哪些檔案、在什麼條件下執行，以及程式成功或失敗時的處理方式。這兩種語言缺一不可。 COBOL 程式並不知道其輸入檔來自哪裡，也不知道其輸出檔指向哪裡；而 JCL 則在讀取第一筆記錄之前就回答了這兩個問題。
對於維護、審計或改造大型主機系統的組織而言，瞭解 JCL 與 COBOL 之間的關係並非可有可無的背景知識，而是所有工作的先決條件：任何變更前都需進行影響分析，任何遷移前都需進行文檔編寫，任何專家退休前都需進行知識轉移。處理夜間計費的作業、產生季度監管報告的批次程序、將資料從一個系統傳輸到另一個系統的程序，所有這些都由 JCL 定義，由 COBOL 執行，而只有少數同時精通這兩種語言的工程師才能真正理解它們。
什麼是JCL？
JCL 代表作業控制語言 (Job Control Language)。它是 IBM 大型主機系統上用於提交批次作業執行的腳本語言。 JCL 本身並不會處理資料。它告訴作業系統如何執行程式：執行哪個程式、提供哪些檔案、分配哪些記憶體和 CPU 資源、步驟失敗時如何處理，以及單一作業中多個步驟的執行順序。
每個 JCL 作業都由三種基本語句類型組成：
作業語句用於向系統標識作業，並定義計費、優先權和調度參數。
EXEC 語句，指定要在步驟中執行的程序或程序。
DD（資料定義）語句定義了程式將讀取或寫入的資料集，包括它們的位置、格式和處置方式。
cl
//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 是儲存在過程庫中的範本；各個作業引用它並根據需要覆蓋特定參數。
cl
//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從作業中呼叫 PROC：
cl
//COMPILE EXEC PAYPROC,MEMBER=PAYROLL1,RUNDATE=20251205這條單獨的 EXEC 語句在執行時會展開成完整的 PROC， MEMBER 以及 RUNDATE 替換處 &MEMBER 以及 &RUNDATE 出現。 PROC 是 JCL 到 COBOL 映射複雜的主要原因之一：一個作業可能透過單一 PROC 引用呼叫數十個 COBOL 程序，而實際呼叫的程序取決於每次執行都會變化的符號參數。
JCL 和 COBOL 有什麼不同？
JCL 和 COBOL 經常被放在一起提及，但它們的功能完全不同。兩者互不替代，對於大型機批次功能的正常運作都不可或缺。
| 尺寸 | JCL公司 | COBOL |
|---|---|---|
| 目的 | 統籌執行 | 實現業務邏輯 |
| 它的定義 | 工作、步驟、文件、條件 | 程式、資料結構、計算 |
| 當它運行時 | 程式執行前（設定）和執行後（清理） | 程式執行期間 |
| 讀取/寫入數據 | 透過資料集分配（DD語句） | 透過 FILE SECTION 和 READ/WRITE 語句 |
| 錯誤處理 | 回傳程式碼，條件步驟執行 | 異常處理程序，執行錯誤例程 |
| 可移植性 | IBM z/OS 特定 | 可透過編譯器跨平台移植。 |
| 誰寫的 | 系統程式設計師、批次工程師 | 應用開發者 |
| 現代等效物 | CI/CD 管線 + 容器編排 | 應用程式程式碼（Java、Python、C++） |
理解二者關係最簡單的方法是：JCL 是部署和編排層；COBOL 是應用層。在現代雲端原生系統中，JCL 的角色將由 Kubernetes 作業清單、shell 腳本和 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中定義的ddnames存取檔案。 OPEN INPUT EMPFILE 在 COBOL 中，它直接對應到名為 DD 的語句。 EMPFILE 在 JCL 中。
步驟 5：返回碼評估。 COBOL 程式結束時，會設定一個回傳碼（通常 0 表示成功，4 表示警告，8 表示錯誤，12 或 16 表示嚴重錯誤）。 JCL 使用 COND 參數或 IF/THEN/ELSE 建構函數以確定是否應根據此程式碼執行後續步驟。
步驟 6：資料集處置。此步驟之後，系統將處理每個 DD 語句中定義的資料集處置：保留、刪除、編目、取消編目或傳遞到下一個步驟。
以下範例展示了該鏈在實際應用中的樣子，左側是 JCL，右側是對應的 COBOL 元素：
cl
//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).这 SELECT INFILE ASSIGN TO INFILE COBOL 的 FILE-CONTROL 部分連接到名為 DD 的語句。 INFILE 在 JCL 中，這是基本的映射關係：COBOL 使用邏輯檔名；JCL 將它們解析為實體資料集。
JCL 異常終止代碼：它們的意義
JCL 異常終止代碼（異常結束代碼）用於標識作業步驟意外終止的原因。它們會顯示在作業輸出中。 S000 （系統異常終止）或 U0000 （使用者異常終止）代碼。理解這些程式碼對於診斷批次作業失敗至關重要。
| 異常終止代碼 | 類型 | 共同的原因 |
|---|---|---|
| S001 | 系統 | 讀取或寫入資料集時發生 I/O 錯誤 |
| S013 | 系統 | DCB 屬性不符、JCL DD 和 COBOL FD 之間的記錄長度或格式不符 |
| S0C4 | 系統 | 儲存保護異常，程式嘗試存取其分配區域之外的內存 |
| S0C7 | 系統 | 資料異常，嘗試對非數值資料進行算術運算（非常常見的 COBOL 異常終止） |
| S322 | 系統 | 逾時，作業運行時間超過了 TIME 參數允許的時間。 |
| S806 | 系統 | 未找到載入模組，EXEC PGM= 中指定的程式不在任何已搜尋的載入庫中 |
| S913 | 系統 | 資料集存取安全違規，RACF 或同等拒絕訪問 |
| U0000 | 用戶名单 | 應用程式定義的異常終止，COBOL 程式透過使用者程式碼呼叫 STOP RUN。 |
| U4076 | 用戶名单 | IMS 特有的異常終止，資料庫存取失敗 |
最常見的生產異常終止， S0C7當 COBOL 程式嘗試對包含空格或非數字字元的欄位進行算術運算時，就會發生此錯誤。典型原因是 COBOL 程式中預期的資料格式與 JCL 提供的實際資料格式不匹配，而這正是 JCL 到 COBOL 映射在導致午夜生產故障之前所發現的差異類型。
COND 參數和條件執行
JCL 控制會根據先前步驟的回傳程式碼執行哪些步驟。 COND 參數：
cl
//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 改為使用更易讀的寫法：
cl
//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 程式可能正在處理錯誤情況、回滾邏輯或恢復過程，而這些功能在僅查看 COBOL 原始程式碼而不查看驅動它的 JCL 時是完全不可見的。
JCL、COBOL 和 DB2：三層堆疊
大多數大型主機事務系統除了 JCL 和 COBOL 之外，還包含第三個元件：IBM 的關聯式資料庫 DB2。 COBOL 程式透過嵌入式 SQL 語句（EXEC SQL 區塊）存取 DB2。 JCL 透過特定的 DD 語句管理 DB2 子系統連線和 DBRM（資料庫請求模組）。
cl
//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 到 COBOL 的映射對現代化至關重要
將 JCL 對應到 COBOL 主要不是一項技術工作，而是一項風險管理工作。對大型主機系統的任何更改，無論是修改 JCL 參數、新增步驟、更改資料集名稱，或修改作業呼叫的 COBOL 程序，都會產生超出被更改元件範圍的影響。在進行更改之前，準確評估這些影響的唯一方法是掌握現有系統及其連接方式的完整映射。
遷移前：將批次工作負載從大型主機遷移到雲端需要了解有哪些 JCL 作業、它們呼叫了哪些 COBOL 程式、步驟之間流轉的資料集、執行順序、步驟失敗時會發生什麼。如果沒有這份清晰的流程圖，遷移團隊只能依賴不完整的文檔，甚至完全沒有文檔。這樣一來，就會遺漏某些步驟，在生產環境中才發現依賴關係，最終導致切換日期延遲。
在進行任何程式碼變更之前：未經檢查哪些 JCL 作業呼叫了 COBOL 程式就對其進行修改，可能會導致在不同條件下或使用不同資料集配置執行的作業發生故障。看似局部的 JCL 參數變更可能會影響依賴特定資料集屬性的 COBOL 程式的行為。影響分析要求在進行任何更改之前了解完整的 JCL-COBOL-資料集呼叫鏈。
知識轉移：當一位維護批次系統二十年的 COBOL 開發人員退休時，他/她會帶走關於 JCL 作業和 COBOL 程序如何連接的思維模式。一份文檔化的連結圖是將這些知識傳遞給下一個團隊的唯一機制。如果沒有這份連結圖，新開發人員將接手一個他們無法安全修改的系統。
對於合規性審計：監管審計通常要求證明財務計算、資料轉換或存取控制的運作符合文件規定。如果 JCL 與 COBOL 之間的關係沒有文件記錄，那麼在審計壓力下，如果不進行系統逆向工程，就無法證明這一點。
JCL管理工具和分析平台
本文的 Search Console 資料具有多語言特性，其中包含義大利語、法語、西班牙語、日語和德語的查詢，這些查詢都詢問有關 JCL 管理工具的問題，這反映了大型主機 IT 社群的全球分佈情況，以及每個地區的團隊都面臨著同樣的問題：他們的 JCL 和 COBOL 文件不完整、過時或根本不存在。
用於 JCL 分析和管理的工具分為三類：
IBM 原生工具：IBM 提供作業輸入子系統 (JES) 功能、JES 假脫機管理和 IBM z/OS 批次執行時間。這些工具負責執行和監控，但不提供跨程式依賴性分析或視覺化功能。
第三方作業排程程序，例如 CA7、TWS（Tivoli Workload Scheduler）和 Broadcom 的 ESP Workload Automation，可以管理數千個作業的批次調度，提供基於依賴關係的調度，並在發生故障時發出警報。它們了解作業層級的依賴關係，但通常不會分析每個步驟中呼叫的 COBOL 程式。
靜態程式碼分析與依賴關係映射平台：這類工具能夠解析 JCL 和 COBOL 原始碼，建構結構模型，展現哪些作業呼叫哪些程式、哪些程式存取哪些資料集以及資料如何在系統中流動。它們提供了作業排程器和 IBM 原生工具無法提供的跨層可見性：例如，特定 JCL DD 語句與其對應的 COBOL 檔案控制條目之間的關係，或寫入資料集的 COBOL 程式與讀取該資料集作為輸入的下一個作業之間的關係。
SMART TS XL 它屬於第三類，並將其擴展到涵蓋企業環境中的每一種語言，包括 COBOL、JCL、PL/I、彙編語言、SQL、Java 等，提供了任何單一語言工具都無法提供的跨語言結構分析。
SMART TS XL 在企業級規模上將 JCL 對應到 COBOL
對於單一作業，手動進行 JCL 到 COBOL 的對應只需三個步驟即可完成。但對於擁有 50,000 萬個 JCL 作業、200,000 萬個 COBOL 程式以及四十多年來累積的數百萬個資料集引用的組織而言，手動映射則變得難以實現。在如此龐大的規模下，手動追蹤特定 PROC、用於呼叫它的符號參數、這些參數解析到的 COBOL 程式以及這些程式所存取的資料集之間的關係是不可能的。
SMART TS XL 它解析 JCL 和 COBOL 原始程式碼，包括帶有符號參數替換的 PROC、串流過程、INCLUDE 成員、重寫和條件執行邏輯，並建立一個統一的交叉引用模型，該模型表示系統中的每個結構關係。該模型可查詢、可導航且始終保持最新，因為它是從原始程式碼重新生成的，而不是作為手動更新的文檔維護的。
这 JCL擴充 此功能解析符號參數替換，以顯示任何 PROC 實際呼叫的程式和資料集，並考慮每個呼叫作業應用的覆蓋。使用 PROC &PGMNAME 作為符號參數，它在模型中表現為它在所有呼叫者中解析為的所有特定程序，而不是作為未解析的參考。
應用程式依賴關係映射功能建構了從 JCL 作業到 COBOL 程式、DB2 表以及下游程式的完整相依性圖，展示了系統中的每個元件及其之間的所有連接。在任何現代化變更之前，團隊可以查詢：哪些作業呼叫了此程式？此程式讀取了哪些資料集？還有哪些程式寫入了這些資料集？接下來運行的作業是什麼？
影響分析功能會針對任何建議的變更產生一系列後果：修改此副本，即可查看包含它的每個程式；變更此資料集佈局，即可檢視引用它的每個 JCL DD 語句；從作業中刪除此步驟，即可查看依賴其輸出的每個下游步驟。
對於面臨 JCL 到 COBOL 映射的團隊來說，這是… 遺產現代化 程序 SMART TS XL 為現代化供應商 Astadia、TSRI、Advanced 等公司在任何轉換工作開始之前奠定基礎：對現有事物進行完整、準確的結構清單，以便透過分析而不是假設來定義轉換範圍。
地圖並非疆域本身，而是起點。
JCL 和 COBOL 不會消失。處理工資、保險索賠、運行監管報告和結算金融交易的批次系統將繼續在大型主機上運行，而雲端遷移的規劃、審批、資金籌措和執行通常需要數年而非數月的時間。在這數年期間，這些系統必須得到維護、修改和理解。
JCL 到 COBOL 的對應並非一次性項目，而是一項持續性的工作：隨著程式的修改、作業的新增和資料集的重組，需要不斷更新結構模型。那些致力於此工作的團隊，能夠自信地對大多數業內人士視為黑盒的系統進行修改。而那些不這麼做的團隊，則在無法完全掌控的環境中，對系統進行修改。在這些環境中，一個缺少的依賴項不會導致編譯器錯誤，卻會在凌晨 3 點的夜間批次運作期間造成生產環境崩潰。
