DB2 DSNZPARM and installation parameter modules

How the installation CLIST creates configuration

IBM supplies an installation CLIST that presents a sequence of ISPF panels. During a first installation, migration, or later update, a systems programmer enters values on those panels. The CLIST validates many entries and uses them to tailor installation jobs. The panels are therefore a friendly front end; they are not themselves the configuration that Db2 loads at startup.

In update mode, DSNTIPB is important because it lets the administrator select the parameter areas to revisit. You do not need to pretend that every installation decision is new when only logging or tracing must change. Near the output stage,DSNTIPO3 contains the PARAMETER MODULE choice. That name tells the generated job which subsystem parameter load module to build. Teams often use a controlled name such as DSNZPPRD or DSNZPTST instead of repeatedly replacing one module without an obvious environment identity.

DSNZPARM: the subsystem parameter load module

DSNZPARM is the conventional default module name. Technically, Db2 can use a differently named module, provided the startup procedure and commands refer to it. The common phrase DSNZPxxx describes site-defined names beginning with DSNZP and ending with characters that identify a member, environment, or version. The module name is limited by normal load-module naming rules, so establish a short naming standard and document what every suffix means.

The installation job DSNTIJUZ assembles parameter macros and link-edits their output into the load module. Do not hand-edit a binary module. Change the installation input, generate or maintain the macro statements, run the reviewed job, keep the output, and promote the resulting module through controlled libraries. That process makes the configuration reproducible and leaves evidence of the exact values that were intended.

These categories help you navigate generated source, but individual options and macro ownership can evolve by Db2 release. Always use the installation and command documentation for your exact function level rather than copying an old subsystem's assembly input blindly.

Loading parameters online or at recycle

A generated module can contain both online-updatable andrecycle-required settings. The command does not magically make every field dynamic. When you issue -SET SYSPARM LOAD(name), Db2 validates the module and applies settings documented as online changeable. A setting that requires a recycle remains at its current value until the member stops and starts using the new module.

1
2
3
-SET SYSPARM LOAD(DSNZPPRD)
-SET SYSPARM RELOAD
-SET SYSPARM STARTUP

LOAD selects a named module. RELOAD reloads the module name used by the previous LOAD, which is convenient after replacing that module in the authorized load library. STARTUP returns this member to the values it had when it started. None of these commands rewrites the startup procedure. If an online LOAD should survive the next recycle, ensure that startup will select the promoted module.

The supplied ADMIN_INFO_SYSPARM procedure provides a queryable view of subsystem parameter information. It is valuable for evidence gathering, automation, and checking whether the running member agrees with a build record. It is an information interface, not a replacement for DSNTIJUZ and not a command that updates parameters. Exact result columns and supported parameters can vary by Db2 level.

Security-sensitive parameters

Ordinary authority to issue SET SYSPARM does not mean every security control may be changed. Parameters involving installation SYSADM, SYSOPR, SECADM, separate security, and related authorization behavior receive stricter checking. Changes to designated security parameters require an appropriately authorized SECADM or the documented installation authority. If the issuer lacks that authority, Db2 can reject those changes while retaining old values. Review messages after every load; a command response alone is not proof that every requested field changed.

DSNZPARM in data sharing

In a data sharing group, each member starts separately and can use its own DSNZPxxx module. SET SYSPARM also has member scope: send the command to the member whose settings should change. This allows legitimate differences, such as member-specific identifiers or workload-related values, but it also creates drift risk. Keep a matrix of shared settings versus approved member exceptions, query every member after a change, and recycle only the members that require recycle-only values.

Never assume that loading a module on member DBP1 changed DBP2. Conversely, do not give every member one module merely for convenience if the module includes values that must differ. A dependable naming convention, member-by-member verification, and retained DSNTIJUZ output are the foundations of safe data sharing configuration.

DSNHDECP: application programming defaults

DSNHDECP is a separate application programming defaults module. It does not replace DSNZPARM. It supplies defaults used by Db2 language-processing tools, especially the precompiler and coprocessor paths that prepare embedded SQL applications. The installation job DSNTIJUA assembles and links DSNHDECP.

• CCSID defaults describe character encoding assumptions for EBCDIC, ASCII, Unicode, and related application data handling.
• Decimal arithmetic defaults influence precision, rounding, and arithmetic behavior expected by prepared applications.
• Encoding scheme defaults tell language processing which encoding to assume when an application does not explicitly supply an option.
• Precompiler and coprocessor defaults establish option values used when source-processing jobs omit an explicit choice.

SQLLEVEL and APPLCOMPAT are related but not identical. SQLLEVEL in the application defaults context controls the SQL language level accepted by the precompiler or coprocessor. APPLCOMPAT is a package-level compatibility control that governs SQL behavior and features when the package executes. Allowing syntax during source processing does not by itself grant a package a higher runtime APPLCOMPAT. The bind or rebind settings and the subsystem's supported function level still matter.

This distinction prevents a common mistake: rebuilding DSNHDECP is not the same as rebinding all packages. Existing packages preserve their cataloged bind attributes until a relevant bind or rebind changes them. Treat DSNHDECP changes as compiler-toolchain changes, test representative source builds, and coordinate them with package compatibility policy.

DSNTIPN: tracing parameters installation panel

DSNTIPN captures high-level installation choices for the Db2 instrumentation facility. It covers defaults associated with accounting,statistics, audit, monitor, andperformance traces. These choices influence which routine measurements start automatically, their classes or destinations, and the baseline overhead and observability posture of the subsystem.

The panel is not a live trace console. The operator command -START TRACE starts a runtime trace and can specify trace type, class, destination, IFCIDs, and filters. Think of DSNTIPN as setting the installed default policy and START TRACE as making an operational request now. Broad performance or audit tracing can produce substantial CPU and output, so choose standing defaults conservatively and use focused runtime traces for investigations.

1
2
3
4
-START TRACE(ACCTG) CLASS(1,2,3) DEST(SMF)
-START TRACE(STAT) CLASS(1) DEST(SMF)
-START TRACE(PERFM) CLASS(30) IFCID(316,318) DEST(GTF)
-DISPLAY TRACE(*)

Accounting records explain work by thread or transaction. Statistics records describe subsystem activity over intervals. Audit traces record selected security events. Monitor traces feed online monitoring products, while performance traces expose detailed events for diagnosis. The exact classes and destinations should follow your site's monitoring design and current IBM documentation.

DSNTIPA: archive log data set parameters

DSNTIPA is the installation panel for archive log data set parameters. Its choices include the archive data set prefix, allocationunit or device, retention information, andcopy options. These values determine how Db2 names and allocates archive log data sets when active logs are offloaded.

DSNTIPA is closely related to logging ZPARMs assembled in the subsystem parameter module, especially the archive and log macro areas. The panel supplies human-friendly input; the generated DSNTIJUZ work turns that input into values the subsystem can use. It does not allocate the active logs or replace BSDS definitions. Active log inventory, archive offload behavior, and archive cataloging are connected parts of logging, but they are not one object.

• Choose a prefix that follows data set naming standards and is covered by security, catalog, SMS, and backup policies.
• Match the unit or device choice to actual archive media and recall requirements; recovery time can suffer if archives are difficult to mount or recall.
• Set retention in coordination with recovery objectives and legal requirements, not as an isolated installation-panel guess.
• Understand whether archive copy choices support single or dual logging and the disaster-recovery design. A second copy only helps when it is managed independently.

A safe parameter-change workflow

• Record the reason, affected members, old values, proposed values, and whether each option is online-updatable or recycle-required.
• Run the installation CLIST in the appropriate update path, beginning with DSNTIPB and confirming the PARAMETER MODULE name on DSNTIPO3.
• Review the generated macro statements and DSNTIJUZ or DSNTIJUA job before execution. Keep assembler and link-edit output as change evidence.
• Promote the module to the correct authorized load library. Confirm library search and refresh requirements before issuing SET SYSPARM.
• Load only on intended members, read every Db2 message, query current information with ADMIN_INFO_SYSPARM where supported, and schedule recycles for non-dynamic values.
• Confirm that startup JCL or procedures select the intended module so the next planned or unplanned restart does not silently restore an older configuration.

Explain It Like I'm Five

Imagine Db2 is a large school. DSNZPARM is the head teacher's rulebook: when doors open, where records go, who may enter special rooms, and how emergencies work. DSNHDECP is a smaller guide for students writing assignments, explaining language and number rules. DSNTIPN chooses how many school activities are recorded, while DSNTIPA tells the archivist how to label and store old diaries. SET SYSPARM can replace pages designed for safe replacement while school stays open; other pages require closing and reopening the school.

Exercises

1. Design DSNZPxxx names for production members DBP1 and DBP2. Explain how the name identifies environment and member without exceeding load-module naming limits.
2. An online LOAD reports success, but one storage parameter is unchanged. List the evidence you would collect before deciding that the member needs a recycle.
3. Compare DSNTIJUZ and DSNTIJUA. Identify which module each builds and one test you would perform after changing each module.
4. Create a tracing plan that keeps low-overhead statistics active but starts a filtered performance trace only during an investigation. Explain the roles of DSNTIPN and START TRACE.
5. Review a hypothetical DSNTIPA design with one archive copy on the same storage system as active logs. Explain the recovery risk and propose a better copy strategy.

Frequently asked questions