A bind job can fail before a COBOL program ever reaches its first OPEN or FETCH. In many Db2 for z/OS shops, the first place to check is the TSO DSN command stream in SYSTSIN, because that is where BIND, REBIND, RUN, SPUFI, and related subcommands are issued.
DSN is the Db2 command processor that runs as a TSO command. It can be used in the foreground under TSO/ISPF or in batch through programs such as IKJEFT01. Once a DSN session starts, the subcommands tell Db2 what action to perform.
Where DSN fits
Db2 administration and application work uses several command paths. Some commands are Db2 system commands such as -DISPLAY DATABASE. Others are DSN subcommands used inside a DSN session, such as BIND PACKAGE or RUN PROGRAM. The old article mixed those categories together, so this refresh separates the common DSN work from general Db2 command usage.
- DSN command: starts a Db2 command processor session from TSO.
- DSN subcommands: run inside DSN, including
BIND,REBIND,FREE,RUN,DCLGEN,SPUFI,END, and comments beginning with*. - Db2 system commands: can be issued through DSN or from operator/admin paths, usually beginning with a hyphen, such as
-DISPLAYor-START.
Common DSN subcommands
| Subcommand | Used for | Production note |
|---|---|---|
DSN | Starts the Db2 command processor session for a subsystem. | Check SYSTEM(DB2P) or the subsystem name before running bind or run jobs. |
BIND | Creates or replaces an application package or plan from a DBRM. | Review collection, qualifier, owner, validation timing, and isolation before release. |
REBIND | Refreshes an existing package or plan without using a new DBRM. | Use with care after RUNSTATS or access-path changes; keep fallback steps clear. |
FREE | Deletes a package or plan. | Confirm no active application depends on the object before removing it. |
RUN | Runs an application program under DSN. | Check plan name, program load library, and runtime SQL errors together. |
DCLGEN | Generates host-language declarations for tables or views. | Regenerate declarations when column definitions used by COBOL change. |
SPUFI | Runs SQL from an input file in an ISPF foreground session. | Good for controlled testing, not for unattended production jobs. |
END | Ends the DSN session. | Always close the command stream cleanly in batch SYSTSIN. |
* | Marks a DSN command-stream comment. | Use comments to identify release number, package, and change ticket. |
Batch DSN example with BIND PACKAGE
In batch, a DSN command stream is normally placed in SYSTSIN. The example below starts DSN for subsystem DB2P, binds package member ACCTUPD, and ends the session.
//BINDPKG EXEC PGM=IKJEFT01
//STEPLIB DD DISP=SHR,DSN=DB2P.SDSNLOAD
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(DB2P)
BIND PACKAGE(APP1COLL) -
MEMBER(ACCTUPD) -
ACTION(REPLACE) -
ISOLATION(CS) -
VALIDATE(BIND)
END
/*When this job fails, read SYSTSPRT and SYSPRINT before changing the bind cards. The messages usually show whether the problem is an authorization issue, missing DBRM, invalid option, unavailable subsystem, or SQL object problem.
RUN PROGRAM example
RUN can execute an application program through DSN. Many production sites use normal batch JCL or schedulers for application execution, but RUN is still useful in examples and controlled test jobs.
//RUNPGM EXEC PGM=IKJEFT01
//STEPLIB DD DISP=SHR,DSN=DB2P.SDSNLOAD
// DD DISP=SHR,DSN=APP1.LOADLIB
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
DSN SYSTEM(DB2P)
RUN PROGRAM(ACCTUPD) PLAN(ACCTPLAN)
END
/*If the program starts but fails during SQL execution, move from DSN diagnostics to application diagnostics: SQLCODE, SQLSTATE, SQLERRMC, package name, plan name, and the business key being processed.
DCLGEN and SPUFI usage
DCLGEN
DCLGEN creates host-variable declarations that match a table or view. For COBOL teams, it helps keep copybooks consistent with Db2 column names and data types. Regenerate and review DCLGEN output after table changes, especially nullable columns and decimal precision changes.
SPUFI
SPUFI is the SQL processor using file input under ISPF. It is practical for testing SQL, checking catalog rows, or validating a small query before it is added to a program. Keep production fixes in controlled jobs or approved tooling rather than ad hoc foreground edits.
Common mistakes
- Running
BINDagainst the wrong subsystem after copying JCL from test to production. - Binding a package into the wrong collection and then running a plan that does not reference it.
- Using
REBINDwithout recording the prior access path or fallback plan. - Deleting a package with
FREEbefore checking dependent jobs and online transactions. - Ignoring
SYSTSPRTand looking only at the job return code.
Quick troubleshooting checklist
| Symptom | First checks |
|---|---|
| Bind job fails | Subsystem name, DBRM library, member name, package collection, owner, qualifier, and bind authority. |
| Program cannot find package or plan | Collection, package name, plan name, package list, and runtime JCL. |
| Access path changed after REBIND | RUNSTATS timing, catalog statistics, bind options, and package copy/fallback procedure. |
| SPUFI SQL works but program fails | Host variables, indicator variables, package bind options, authorization ID, and SQLCA handling. |
Related Db2 topics
Use this reference with Db2 Binding Application, Db2 Binding and Rebinding, Db2 Packages, Db2 Commands Quick Reference, and Db2 Application Environment.
FAQ
What is the DSN command in Db2 for z/OS?
DSN is the Db2 command processor that runs as a TSO command. It starts a session where subcommands such as BIND, REBIND, RUN, DCLGEN, and SPUFI can be issued.
Can DSN run in batch?
Yes. DSN commands are often run in batch through IKJEFT01, with the command stream placed in SYSTSIN and output written to SYSTSPRT.
What is the difference between BIND and REBIND?
BIND creates or replaces a package or plan using DBRM input. REBIND refreshes an existing package or plan, often after catalog statistics or environment changes.
