Db2 DSN Command Reference: BIND, RUN, SPUFI, DCLGEN, and REBIND



DSN runs Db2 commands from TSO.

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 -DISPLAY or -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 BIND against 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 REBIND without recording the prior access path or fallback plan.
• Deleting a package with FREE before checking dependent jobs and online transactions.
• Ignoring SYSTSPRT and 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.