DB2 & IMS

There are many types of IT professionals who deal with, use, and manage DB2 for z/OS on a daily basis. The vast majority are end users, followed by application developers and programmers. Then there are the DBAs, of which there are many varieties: application-focused, system-focused, performance-focused, and even jacks-of-all-trades. And finally, we have the systems programmers, those who work with installation and system tuning.

Of all these constituents, usually only the systems programmers and some of the DBAs get involved with system-level performance and configuration issues. But this topic is becoming more complex and difficult to manage all the time, so let’s take a look at some of the issues.

Probably the most important aspect of system configuration and tuning involves understanding and managing DSNZPARMs (aka ZPARMs). These are the system parameters that control the overall behavior of a DB2 subsystem.

There are seven macros that, once assembled, produce the DSNZPARMs: DSN6ENV, DSN6ARVP, DSN6LOGP, DSN6FAC, DSN6GRP, DSN6SYSP, and DSN6SPRM. (I won’t explain here what they are or how to set them.)

So far, so good. However, keep in mind there are literally hundreds of these parameters, with more being added all the time. And the documentation on them is limited.

The sheer volume of DSNZPARM parameters can be overwhelming. Oh, sure, some of them are more visible than others. For example, many people know about the locking parameters (NUMLKUS: maximum locks per user; NUMLKTS: maximum locks per user per table space) and some of the others, such as:

• CTHREAD: maximum users

• CONDBAT, MAXDBAT: maximum remote connections, active

• IDFORE, IDBACK: maximum TSO, batch

• DSMAX: maximum number of open data sets.

2 Pages