The largest number of parameters externalized is for the database services address space, also called the DBM1 or ADMF address space. These parameters show themselves on the DSN6SPRM macro.
The Bad (But Improving)
Before DB2 V7, the IBM supported method for making changes to DSNZPARM was straightforward and simple. The keywords on the macros were updated to their new values, the macros were assembled, and then link-edited into a new load module. DB2 would then have to be stopped and restarted to load the newly created load module into storage so changes could be activated. This process caused a DB2 outage.
Enter DB2 V7 with a long-awaited alternative, the DB2 -SET SYSPARM command. By issuing this command, you could load into storage a new parameter load module whose name you specified on the command. This made the process of changing DSNZPARM’s keywords more acceptable.
Often, the DB2-SET SYSPARM command is described as a way to dynamically change DSNZPARMs. That’s not entirely accurate. The -SET SYSPARM command allows for replacing the data-only load module currently being referenced by DB2 with a different load module. Generally, individual ZPARM keywords still can’t be dynamically changed. You must still edit the DSNZPARM source, modify the macro’s keywords to a different value, assemble the modified source, and link-edit a new load module.
The -SET SYSPARM command only allows the dynamic replacement of that load module. Even though a new load module is loaded, not all the ZPARM parameters changed are eligible for activation using the -SET SYSPARM command. Parameters still exist that require DB2 to be recycled before they can become active.
At DB2 startup, using the -START DB2 command, the DSNZPARM module, whose name you can optionally specify on the -START command, is loaded into DB2’s storage. If you specify no name, the load module name defaults to DSNZPARM. Let’s assume the default name is used when the
-START DB2 command is issued with no additional parameters. DB2 is now processing using a load module in storage called DSNZPARM. Assume you determine some keyword(s) in the ZPARM source need to be changed. Usually, this source is a copy of the installation job DSNTIJUZ from hlq.SDSNSAMP that has been saved to another location. The appropriate changes are made to the macros, the source is then assembled and link-edited into hlq.SDSNEXIT as a new load module that, in this case, will be called DSNZP001.
The -SET SYSPARM command is issued, specifying the new load module name. The format of the command for this first action is -SET SYSPARM LOAD(DSNZP001). The SET SYSPARM command doesn’t replace the originally loaded module. DSNZPARM is still cached in DB2’s storage. However, DB2 is now processing using DSNZP001. The command’s LOAD keyword will always load a new copy of the ZPARM load module into storage. If you specified no load module name, DSNZPARM is the default load module name.
What if you make more changes and link-edit the new changes into the same load module DSNZP001? To activate them, you use a slightly different format of the command. Issuing the command -SET SYSPARM RELOAD will reload the last load module named into storage, replacing whatever is currently active.