Don’t worry, this isn’t a movie review of a 1966 spaghetti western and you’re still reading the right magazine. That style of movie disappeared almost 20 years before DB2 was even announced. This article examines a small part of DB2—a single load module (and the macros that compose it) called DSNZPARM, which is near and dear to many, yet also challenging and sometimes frustrating. This article discusses:

-        The “good” you can accomplish by recognizing which DSNZPARM parameters can and should be changed

-        The “bad” that used to be associated with the effort it took to change a DSNZPARM parameter and activate that change

-        The “really ugly” stuff that can happen if you touch things you don’t understand or shouldn’t be touching.

The Good

DSNZPARM, also affectionately called ZPARM, refers to the data-only subsystem parameter load module that contains DB2’s execution time parameters. When the macros that comprise DSNZPARM are assembled and link-edited into a load module, you have other naming choices. The accepted format is DSNZPxxx, where xxx is some string of characters that will make your ZPARM member names unique. The initial name chosen will be specified on the installation panel DSNTIPO. The ZPARM load module, regardless of what you call it, will reside in the hlq.SDSNEXIT load library. 

In a data-sharing environment, SDSNEXIT is a shared resource across the data-sharing group. Each individual DB2 member in the group will have its own unique DSNZPARM load module. The name(s) chosen for the DSNZPARM load module can be optionally specified as a parameter of the DB2 START command. This lets you start DB2 using different copies of DSNZPARM. 

The assembly of DSNZPARM requires some source code where DB2’s processing values are set. The source is initially created via installation of CLIST DSNTINST and is placed in the DSNTIJUZ installation job stream. Once the source is created, how are   changes to the keywords on the DSNZPARM macros handled? 

The recommended approach for modifying DSNZPARMs is via the DSNTINST installation CLIST. Updates are made through the panels and DSNTIJUZ is replaced in hlq.SDSNSAMP1 or hlq.NEW.SDSNSAMP. This job can be submitted and one of the outputs is a new DSNZPARM module. This may seem pretty straightforward until you have to change one of the “opaque” or “hidden” ZPARMs (because of Level 2 Support recommendations or because a PTF has been applied). Now you’ve created an entry in ZPARMs that can’t, and won’t, be updated by the install process. When the DSNTIJUZ job is replaced by the installation CLIST, you’ll probably lose your changes.

These are examples of why a process is needed to prevent inadvertent loss of changes to DSNTIJUZ. Actually, changes are often made directly to DSNTIJUZ values rather than using the formally described DB2 methods. Why? For some, it will seem easier; for others, it will be out of necessity. Which is better? Both have their place. Using the CLIST ensures the DSNTIDXA input parameter member is updated. This member contains the default installation parameter values. DSNTIDXA is then used as input to the install CLIST and lets the install CLIST initialize all the ZPARM values in the panels to their last values. This module is also used during DB2 release migration. But editing DSNTIJUZ directly allows the modification of any ZPARM keyword, even those not supported by the install CLIST or supplied by an APAR during the maintenance process. Sometimes, editing DSNTIJUZ is the only way to change certain values. 

5 Pages