Running a COBOL DB2 batch program is more than EXEC PGM=yourmodule. The job must start the TSO Terminal Monitor Program, connect to Db2 with DSN, and RUN the program under the correct plan and libraries. This tutorial shows the prerequisites, JCL pattern, verification checks, and common first-run failures.
Most Db2 batch applications run under the TSO Terminal Monitor Program in background mode. IKJEFT01 reads SYSTSIN commands, starts a DSN session for a subsystem, and the RUN subcommand loads your COBOL program in that Db2-connected environment. The plan named on RUN is the allocation unit that locates packages for the SQL your program issues.
Directly executing the COBOL module without DSN can work only in attachment models designed for that path. For classic TSO/batch Db2 COBOL, DSN RUN is the standard and safest teaching pattern.
| Area | What to verify |
|---|---|
| Build | Current load module built from the same precompile as the bound DBRM/package. |
| Bind | Package exists in the expected collection and the plan PKLIST can find it. |
| Libraries | SDSNEXIT, SDSNLOAD, application loadlib, and any exit or runtime libraries. |
| Authorization | Job USER or associated auth ID can execute the plan and access required data. |
| Files | All application DD names allocated: input, output, work, and sort files as needed. |
Also confirm commit strategy, restart checkpoints, and whether the job should stop on the first negative SQLCODE. A batch program that ignores SQLCODE can update partial data and still look “successful” in SDSF if it sets return code zero.
| Option | Purpose |
|---|---|
| SYSTEM(ssid) | Connects DSN to the Db2 subsystem or group attach name |
| PROGRAM / PROG | Names the application load module to run |
| PLAN | Names the application plan used for Db2 allocation |
| LIB | Library containing the application program |
| PARMS | Passes Language Environment and/or application parameters |
Start with IKJEFT01, include Db2 libraries, allocate SYSTSPRT and SYSTSIN, and add every DD your COBOL program expects. Use DYNAMNBR when your shop standard includes it for DSN workloads.
123456789101112131415161718192021//EMPBATCH JOB (ACCT),'EMPRPT',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID //*---------------------------------------------------------------* //* Run COBOL Db2 batch program EMPRPT01 under plan TRAINPLN //*---------------------------------------------------------------* //GO EXEC PGM=IKJEFT01,DYNAMNBR=20,REGION=0M //STEPLIB DD DISP=SHR,DSN=DSN.V12R1M0.SDSNEXIT // DD DISP=SHR,DSN=DSN.V12R1M0.SDSNLOAD // DD DISP=SHR,DSN=APP.TRAIN.LOADLIB //SYSTSPRT DD SYSOUT=* //SYSOUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //EMPIN DD DISP=SHR,DSN=APP.TRAIN.EMPIN //EMPOUT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DB2T) RUN PROGRAM(EMPRPT01) - PLAN(TRAINPLN) - LIB('APP.TRAIN.LOADLIB') - PARMS('/DEPT=A10') END /*
PROGRAM must be the load module name. PLAN must be the plan that lists the collection containing package EMPRPT01. If your site uses multiple environments, double-check that the job is not pointing a production load module at a test plan, or the reverse.
The example uses a slash before application parameters, which is a common way to separate Language Environment runtime options from program arguments. If your program expects a different layout, follow its runbook. Never copy PARMS from an unrelated sample without reading the COBOL linkage section.
IBM guidance is to keep DSN job steps short. If the application abends or returns a non-zero code, DSN typically terminates. Put unrelated utility work in separate steps so a Db2 application failure does not obscure later processing.
12345-- Example post-run reconciliation for a reporting extract key SELECT COUNT(*) AS EMP_COUNT FROM TRAINING.EMPLOYEE WHERE DEPT_CODE = 'A10' AND ACTIVE_FLAG = 'Y';
| Symptom | Likely cause | Corrective action |
|---|---|---|
| Module not found / IKJ56500I style failure | Wrong STEPLIB/JOBLIB/LIB or misspelled PROGRAM name | Verify the load library membership and the exact module name. |
| SQLCODE -805 | Plan/package mismatch or missing collection on PKLIST | Compare RUN PLAN, SYSPACKLIST, and SYSPACKAGE for the consistency token. |
| SQLCODE -818 | Load module and package timestamps disagree | Rebuild and rebind from one precompile generation, then rerun. |
| SQLCODE -922 / connection failure | Wrong subsystem, Db2 not available, or attachment authorization problem | Confirm SYSTEM name, Db2 status, and job authorization to connect. |
| Abend or non-zero RC ends DSN early | Application error, missing DD, or unhandled SQLCODE | Fix the program or JCL, keep DSN steps short, and rerun a controlled test. |
Missing application DD names often surface as language-environment or COBOL file status problems before any SQL runs. When SQL never starts, check file allocations first. When SQL starts and fails immediately, check plan, package, and authorization next.
Think of IKJEFT01 as a helper who walks your COBOL robot to the Db2 school office. DSN SYSTEM opens the right school building. RUN PROGRAM tells which robot to start. PLAN is the hall pass that lists which binders of answers the robot may use. If the hall pass is wrong, the robot can stand up and still be told it may not open the binder.
1. Which program is commonly used to run a COBOL Db2 batch job under TSO?
2. What does the DSN RUN PLAN option identify?
3. Where should the COBOL load module usually be found?
4. What happens if DSN receives a non-zero return code from the application?
5. A batch program gets SQLCODE -805. What should you check first?