Retrieval of current DSNZPARM and DSNHDECP settings

With DB2 Version 9.1 for z/OS a new system supplied stored procedure SYSPROC.ADMIN_INFO_SYSPARM was delivered. As the name suggests, this routine can be called to obtain the current settings of the Db2 subsystem parameters (DSNZPARM) and the application default parameters (DSNHDECP).
In DB2 11 for z/OS the supplied sample code of member DSN8ED7 in SDSNSAMP, which extracts the current settings of the Db2 subsystem parameters, was changed from SYSPROC.DSNWZP to SYSPROC.ADMIN_INFO_SYSPARM. Note that SYSPROC.DSNWZP is deprecated.
DSNTEJ6Z in SDSNSAMP prepares this sample code of member DSN8ED7 by compilation, binding, etc.
This compilation requires a C/C++ compiler.

New feature description:
PH06905 replaces the old SDSNSAMP member DSNTEJ6Z: By default, it does no longer compile the DSN8ED7 module, because this one is now part of SDSNLOAD. It only prepares DSN8ED7 by binding, etc. The pure C source is still available in DSN8ED7S and users, who prefer to compile it, can modify DSNTEJ6Z to do so by following instructions in the job prologue.

Extracting the current settings of the Db2 subsystem parameters DSNZPARM and application default parameters DSNHDECP is now available for all users and is easy to use.

The directory of subsystem parameters and application default values and the output of DSN8ED7 can be used to get a complete view. 

The output is equal to previous versions: it generates a table with the following columns:
- "Macro Name" (of SDSNMACS)
- "Parameter Name" (of the previous mentioned macro)
- "Current Setting"
- "Description/Install Field Name" (refer to the Install Panel ID)
- "Install Panel ID" (member name of SDSNSPFP)
- "Fld No." (appropriate field number in the Install Panel ID)
"Macro Name"            DSN6SPRM
"Parameter Name"     STATSINT
"Current Setting"        00005
"Description ..."          REAL TIME STATS
"Install Panel ID"        DSNTIP8
"Fld No."                    11

The IRLMRWT value can be changed by a MODIFY IRLMproc,SET,TIMEOUT=nnnn,subsystem-name command. Such a change is not reflected in the output of SYSPROC.ADMIN_INFO_SYSPARM.

Views: 1236

Add a Comment

You need to be a member of The World of DB2 to add comments!

Join The World of DB2

Comment by Peter Hartmann on July 29, 2019 at 10:40

Hi Joe

The compatibility remark relates to: If this (e.g. stored procedure) is changed, then other customers may complain.

Comment by joe watson on July 23, 2019 at 15:43

Peter,  Thanks for the feedback. 

I do not quite understand the compatibility rational.  Compatible with what?

The suggestion for sql CASE implies, just to accommodate those few zparm items,  the zparm data would first have to translated and ported to a DB2 table. 

Then, a case would be constructed for all permutations of that binary string,  Again, just to get those few zparm items?  That seems, to put it mildly, rather bizarre. 

HA  So, here is an idea.  I will just use an IBM competitor product that already displays the data in a human readable fashion!

Comment by Peter Hartmann on July 23, 2019 at 5:25

Hi Joe

I discussed this IBM internally. The ADMIN_INFO_SYSPARM output is kept due to compatibility. You might use a CASE expression to format liek you want:

WHEN '00000000000000000000000000000000' THEN '0'
WHEN '10000000000000000000000000000000' THEN '1'
WHEN '10000010000000000000000000000000' THEN '1,7'
WHEN '11000000000000000000000000000000' THEN '1,2'

and so on.

The following link might be also interesting.

Comment by joe watson on July 17, 2019 at 14:31

Interesting aside.  ADMIN_INFO_SYSPARM (as well as DSNWZP before) does not translate the trace parms.internal format.  IE,



Which makes that data pretty useless in general an very tedious to interpret specifically.  Some other vendor tools do make the conversion.  EG,

AUDITST                (1,2,7,8,11)

So it is strange that IBM retains that useless 'retrieval' format.  I suggested to DB2 Support to enhance those displays but they were not interested in doing so at the moment.

Comment by Peter Hartmann on July 16, 2019 at 17:18

Hi John

Thanks for making this clear.

My statement relates more to the compile and general usage. Of course the specific usage of the stored procedures requires some authorizations due to good reasons (hacking etc.).

Comment by John McIntosh on July 16, 2019 at 15:54

"Extracting the current settings of the Db2 subsystem parameters DSNZPARM and application default parameters DSNHDECP is now available for all users and is easy to use."

Not exactly. The user who calls SYSPROC.ADMIN_INFO_SYSPARM must have MONITOR1 privilege. Not all users hold that privilege.

Bringing Db2 enthusiasts together virtually. Expert or novice, distributed or mainframe, this is the place for everything DB2.


Introducing IBM Db2 for z/OS Developer Extension for Microsoft Visual Studio Code

Started by Calene Janacek in Application Development and DB2 Jul 30. 0 Replies

We are excited to announce that the first iteration of IBM Db2 for z/OS Developer Extension is available now as a free downloadable extension in the…Continue

QMF Governor

Started by Maitena Gallastegi Ginea in Application Development and DB2. Last reply by Maitena Gallastegi Ginea Jul 30. 4 Replies

Hi,We are using QMF Governor to limit the QMF queries of users.We have configured correctly and it is working OK. We want to get statistics of those queries canceled by QMF Governor but we are not able to discover where that information is stored.…Continue

© 2020   Created by Surekha Parekh.   Powered by

Badges  |  Report an Issue  |  Terms of Service