Binding a COBOL DB2 program connects the load module you run to the package Db2 executes. This tutorial covers the full chain: DBRM from precompile, BIND PACKAGE, plan PKLIST, verification, and the consistency errors that appear when any link in that chain is rebuilt alone.
A COBOL program with EXEC SQL does not talk to Db2 merely because it compiled. The SQL must be extracted, bound, and reachable through an application plan. Treat the following stages as one release unit.
| Stage | Primary output |
|---|---|
| Precompile / SQL statement processor | Modified COBOL source + DBRM member |
| COBOL compile | Object module with Db2 call stubs |
| Link-edit | Executable load module in application loadlib |
| BIND PACKAGE | Package in a collection with access paths |
| BIND PLAN (as needed) | Plan PKLIST pointing at the collection |
The consistency token stamped into the DBRM and load module is how Db2 proves that the running program matches the bound package. If you promote a new load module without the matching package, or bind an old DBRM against a new load module, runtime SQL fails even when every JCL step reports return code zero in isolation.
| Area | What to verify |
|---|---|
| Source | COBOL program with embedded SQL that precompiles cleanly for the target Db2 level. |
| Libraries | DBRM library, object library, load library, and Db2 SDSNEXIT/SDSNLOAD concatenations. |
| Names | Agreed program, collection, plan, OWNER, and QUALIFIER naming standards. |
| Authority | BINDADD/BIND plus object privileges required for VALIDATE(BIND). |
| Objects | Tables, views, and indexes referenced by the SQL exist in the QUALIFIER schema. |
Include DCLGEN or equivalent host declarations when the shop standard requires them. Confirm APPLCOMPAT and SQL level expectations for new syntax. For promotion pipelines, identify whether test and production use different collections with the same plan name pattern or different plans entirely.
Run the Db2 precompiler or SQL statement coprocessor so the DBRM member is written to the DBRM library and the modified COBOL source is ready to compile. Compile and link-edit into the application load library. Do not discard the DBRM after a successful compile; bind needs that exact member.
Bind the program DBRM into the target collection. Keep OWNER, QUALIFIER, ISOLATION, and VALIDATE aligned with shop standards.
1234567891011121314151617//BINDPKG EXEC PGM=IKJEFT01,DYNAMNBR=20 //STEPLIB DD DISP=SHR,DSN=DSN.V12R1M0.SDSNEXIT // DD DISP=SHR,DSN=DSN.V12R1M0.SDSNLOAD //DBRMLIB DD DISP=SHR,DSN=APP.TRAIN.DBRMLIB //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DB2T) BIND PACKAGE(TRAINCOLL) MEMBER(EMPRPT01) - ACTION(REPLACE) - OWNER(APPTRAIN) - QUALIFIER(TRAINING) - ISOLATION(CS) - VALIDATE(BIND) - RELEASE(COMMIT) - EXPLAIN(YES) END /*
If the plan already lists TRAINCOLL.*, a package replace is usually enough. For a new collection or first-time plan, bind or rebind the plan explicitly:
12345678910111213//BINDPLN EXEC PGM=IKJEFT01,DYNAMNBR=20 //STEPLIB DD DISP=SHR,DSN=DSN.V12R1M0.SDSNEXIT // DD DISP=SHR,DSN=DSN.V12R1M0.SDSNLOAD //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(DB2T) BIND PLAN(TRAINPLN) - PKLIST(TRAINCOLL.*) - ACTION(REPLACE) - ISOLATION(CS) - RETAIN END /*
RETAIN preserves existing plan authorizations when your shop uses that option. Some sites bind package and plan in one SYSTSIN stream; others separate them for clearer promotion control. Either approach is fine when the final catalog state is correct.
Record program name, DBRM member, collection, package version if used, plan name, bind job name, and load library dataset. That checklist is the fastest way to diagnose -805 and -818 later.
123456789SELECT COLLID, NAME, VERSION, OWNER, QUALIFIER, BINDTIME, VALID FROM SYSIBM.SYSPACKAGE WHERE COLLID = 'TRAINCOLL' AND NAME = 'EMPRPT01'; SELECT PLANNAME, LOCATION, COLLID, NAME FROM SYSIBM.SYSPACKLIST WHERE PLANNAME = 'TRAINPLN' ORDER BY SEQNO;
| Symptom | Likely cause | Corrective action |
|---|---|---|
| Precompile SQL errors | Invalid SQL, missing DECLARE TABLE, or unsupported syntax for APPLCOMPAT | Fix the SQL, regenerate DCLGEN if needed, and re-precompile before bind. |
| Bind authorization failure | Missing BINDADD/BIND or OWNER lacks privileges on referenced objects | Align OWNER/QUALIFIER with granted roles and retry with the correct ID. |
| SQLCODE -805 at first run | Plan PKLIST missing the collection or wrong package set/version | Inspect SYSPACKLIST/SYSPACKAGE and REBIND PLAN with the correct PKLIST. |
| SQLCODE -818 at first run | Load module and bound DBRM came from different precompiles | Rebuild the full chain from one precompile and rebind that DBRM. |
| Unexpected tablespace scan | Stale statistics or missing index when the package was bound | RUNSTATS, review EXPLAIN, then REBIND PACKAGE with approved options. |
Also watch for QUALIFIER mistakes that bind successfully against the wrong schema. VALIDATE(BIND) catches missing objects in the intended qualifier, but it cannot stop you from intentionally pointing at an incorrect yet existing schema. Review QUALIFIER in the bind skeleton as carefully as MEMBER.
Your COBOL program is a robot with a shopping list of Db2 questions. Precompile copies the shopping list onto a special paper (the DBRM). Binding is when Db2 reads that paper, decides the fastest aisles to walk, and files the finished plan in a binder. Running the robot only works when the robot you start is the same one that wrote that paper, and when the classroom plan says it may open that binder.
1. What artifact from COBOL precompile does BIND PACKAGE consume?
2. Why prefer package-plus-plan over binding every DBRM directly into one plan?
3. Which BIND PLAN option associates packages with the plan?
4. SQLCODE -818 after a COBOL change usually means:
5. What should you verify after a successful bind return code?