The article, “The Good, the Bad and the Really Ugly: DB2’s DSNZPARM Module” (z/Journal April/May 2005), discussed what DB2’s DSNZPARM member is and how it can be maintained, and provided a look at some of the good and bad things you can accomplish when manipulating ZPARMs. In this follow-up article, we explore some specific DSNZPARM keywords, what they mean, how to change them, and the possible effects of those changes. We’ll examine only a subset of the DSNZPARM keywords; for more detailed information, refer to the IBM DB2 Installation Guide.

Often, there’s no right or wrong answer when choosing a value for many of DSNZPARM’s keywords. In fact, if one choice or value is always correct, would there even be a need to have a DSNZPARM module? The opinions reflected here are based on observations and more than 20 years of experience with DB2, but some readers have valid alternative views; the intent here is to encourage a thoughtful view of how DSNZPARM might be coded in your environment. Also, there’s no particular order to how the different keywords are discussed here.

The Environment

The DSN6ENV macro has only one keyword, MVS. In the currently supported releases of DB2, “XA” is the only value that will be specified. This macro describes the DB2 environment and sets global variables used by the other DSN6 macros and must be the first macro assembled. It’s mentioned here only so you know why it’s always first and why you must include it.


Log behavior is controlled by the keywords on the DSN6LOGP and DSN6ARVP macros. The DSN6ARVP macro contains the parameters that control selected archive log functions plus a few odds and ends not directly related to logging. DB2’s log manager externalizes its initialization parameters through the DSN6LOGP macro. Most keywords on both these macros are pretty straight-forward with a set of values accepted by most of the industry. In my opinion, using dual active logs, dual archive logs, and dual Bootstrap Data Sets (BSDS) is the only way a DB2 subsystem should be set up. You control these features on the DSN6LOGP macro by setting the keywords TWOACTV=2, TWOARCH=2, and TWOBSDS=YES, respectively.

The BSDS is DB2’s inventory of all available active and archive log data sets and at least one copy is necessary for DB2 to continue running. If the BSDS becomes unavailable, DB2 will stop. The active log contains all change information and checkpoints. It’s required for most restarts and recoveries. If the correct active isn’t available at DB2 restart, restart will fail. If the correct log isn’t available to the recovery process, the process can’t complete.

Checkpoint frequency has always been a heavily discussed DSNZPARM. Managed by the CHKFREQ keyword on the DSN6SYSP macro, it’s used to manage the frequency DB2 writes checkpoint to the DB2 log by controlling the number of log records written in each checkpoint interval. More frequent checkpoints can reduce DB2’s startup time after a subsystem failure. However, there’s a cost. A checkpoint is a snapshot of all activity in DB2 that would need to be restored at restart. The more activity in a DB2 subsystem, the more expensive it is to take a checkpoint. Taking checkpoints too frequently could possibly have a negative impact on DB2’s performance. If you’re not concerned about restart time, make this value high or use a time interval.

DB2 accepts the number of log records written by specifying a value between 200 and 16 million or a time interval if the value is between one and 60. The ability to specify a number of log records or a time value and the keyword name change from LOGLOAD to CHKFREQ all emerged in a DB2 Version 7 enhancement. And although the CHKFREQ keyword can be changed via the SET SYSPARM command, it’s somewhat unique because its value can also be modified via its own command, SET LOG. SET SYSPARM does require a change to the DSNZAPRM member and the creation of a new load module where the SET LOG command is immediate, although temporary. With DB2 V8, another change that reinforces the “large value” for this keyword was introduced. The default for CHKFREQ was increased tenfold to 500,000 log records. For DB2 subsystems running on zSeries processors, it’s becoming increasingly common to see checkpoint frequencies specified using time with ranges varying from five to 10 minutes. Sometimes, customers will specify a value as low as two minutes because of the amount of work these new processors can perform in a short time. If the interval is reduced, whether specifying a time value or number of log records, the amount of log data being written and the cost of the additional checkpoints should be monitored to ensure the DB2 subsystem’s performance isn’t impacted and the number of log writes per checkpoint is reduced. It’s also recommended that if you’re satisfied with your current checkpoint strategy, you should not change this value.

Information about open page sets is a major part of the data written when a checkpoint record is cut. To improve checkpoint processing and ensure an end Relative Byte Address (RBA) is written to SYSIBM.SYSLGRNX in a timely fashion, there are two more keywords of interest on the SYS6SYSP macro: PCLOSEN and PCLOSET. These keywords control read-only switching based on the time a page set has gone without updates. If no change activity occurs within the time interval on PCLOSET or the checkpoint interval specified by PCLOSEN, the page set is switched internally to read-only processing. Read-only page sets aren’t included in a checkpoint record. With improvements made to these keywords in recent maintenance, there’s now less reason to change them from their default settings. I would suggest changing these values only on advisement of DB2 Level Two support.

4 Pages