Add a Comment

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.