Retrieval of current DSNZPARM and DSNHDECP settings

History:
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)
E.g.
"Macro Name"            DSN6SPRM
"Parameter Name"     STATSINT
"Current Setting"        00005
"Description ..."          REAL TIME STATS
"Install Panel ID"        DSNTIP8
"Fld No."                    11

Consider:
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: 743

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:

SELECT ...,
CASE T1.PARMVALUE
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,

AUDITST=11000011001000000000000000000000

SMFACCT=11100011000000000000000000000000
SMFSTAT=10111100000000000000000000000000

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.

Forum

MSSQL linked server attaching to DB2 LUW

Started by Mike Jett in Application Development and DB2. Last reply by Mike Jett 12 hours ago. 2 Replies

I am trying to create a linked server from MSSQL 2014  to DB2 11.1  I am able to create one linked server and get it to work with one DB.  I have not been able to figure out how to add additional catalogs(DB's).  Is it possible to use just one…Continue

Tags: server, linked

Db2 12 Migration Planning & Customer Experiences - Part 1

Started by Sandy Flippen in What's hot ? Sep 12. 0 Replies

Register Now! NEXT CONTENT! Upcoming double webcast Db2 12 Migration Planning and customer experiences. Live Q &A session! PART 1 http://ibm.biz/BdzKxv 24th Sept 11:00 AM EST PART 2…Continue

PlanetDB2.com [Latest Blogs from the Biggest Names in DB2]

© 2019   Created by Surekha Parekh.   Powered by

Badges  |  Report an Issue  |  Terms of Service