Dear all,
I have been using the IDMS/DB Analyzer component of our IDMS utilities suite to generate statistical information about the space utilisation of our IDMS databases. I promise to post more information on our use of the facility in the future, but right now we seem to have struck what could be a bug in the program. The utility program in question is USNDRVR. The JCL for execution under z/OS is documented here:
z/OS and OS/390 Environment, we use the first form of the JCL on that page, under the heading for 'Statistics Accumulation and Report Preparation'.
We noticed something strange about this job though, it only runs successfully if we have a library within the STEPLIB concatenation that is not APF Authorised. Typically the IDMS libraries used to make up our default STEPLIB concatenation are all APF Authorised, however during testing of this utility program I had my personal TSO load library also allocated to STEPLIB. On removing my library the JCL now fails with an S0C4 that looks like this:
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000004
TIME=15.27.14 SEQ=14046 CPU=0000 ASID=006F
PSW AT TIME OF ERROR 078D2000 800C1604 ILC 4 INTC 04
ACTIVE MODULE ADDRESS=00000000_000AC000 OFFSET=00015604
NAME=GSSNKWP
DATA AT PSW 000C15FE - 50184040 50244040 50264040
AR/GR 0: 009FE954/00000001 1: 00000000/12E7F864
2: 00000000/000C2E70 3: 00000000/000C1D98
4: 00000000/00000000 5: 00000000/000D0D3C
6: 00000000/000C2E70 7: 00000000/000C1DD0
8: 00000000/000D1D40 9: 00000000/00000000
A: 00000000/00000000 B: 00000000/12E80098
C: 00000000/12E7DEC8 D: 00000000/12E7F818
E: 00000000/800D0D38 F: 00000000/00000000
The behaviour is consistent, we've tested several scenarios and concluded that the only difference is the presence or not of a non-APF Authorised dataset within the STEPLIB concatenation, thus removing the APF authorisation for all programs within the concatenation. The working hypothesis is that something within the USNDRVR program checks its APF setting and takes a branch down code that is not executed when not APF'd. This seems to be the reverse of the usual situation where losing APF capability might cause a program to fail, but that is what we are seeing: Program works when not all libraries in the STEPLIB are APF, and fails when only APF authorised libraries are in the STEPLIB.
I was wondering if anyone else had encountered this situation before, or even better had a chance to do a test on your system and verify (or not) our findings before I raise a ticket with Broadcom Support. I've included the basic JCL and instream that we are using to reproduce this below. Note that the DB Analyzer runs for quite some time against any substantial Sub-Schema, so in our case we are using a deliberately small cut-down version of our Sub-Schema just for testing and in order to get the job to run in moments rather than hours (and yes, we've also reproduced this problem with one of our full sized Sub-Schemas as well, so the selection of Sub-Schema doesn't appear to be the root cause of the problem).
Here's a sample job:
//IDMSEXEC EXEC PGM=USNDRVR
//STEPLIB DD DISP=SHR,DSN=HLQ.LOAD.CULLINST
// DD DISP=SHR,DSN=HLQ.LOAD.CULLCUST
// DD DISP=SHR,DSN=HLQ.LOAD.CULL
//SORTLIB DD DISP=SHR,DSN=SYS1.SORTLIB
//SORTMSG DD SYSOUT=*
//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,1)
//SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,1)
//SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,1)
//SYSLST DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYS001 DD UNIT=SYSDA,SPACE=(CYL,(15,10))
//SYS002 DD UNIT=SYSDA,SPACE=(CYL,(15,10))
//SYSIPT DD *
PROCESS = ALL,
SUBSCHEMA = TEMP,
SELECTION = AUTOMATIC
/*
//SYSIDMS DD *
LOCAL=ON
PREFETCH=ON
//SYSOUT DD SYSOUT=*
//DBMSOUT DD SYSOUT=*
//DBMSDMP DD SYSOUT=*
//STAT1 DD DSN=HLQ.IDMS.STAT,
// DISP=(,CATLG,DELETE),
// UNIT=SYSDA,
// SPACE=(TRK,(1,2),RLSE)
//LDEL DD DSN=HLQ.IDMS.LDEL,
// DISP=(,CATLG,DELETE),
// UNIT=SYSDA,
// SPACE=(TRK,(1,2),RLSE)
//*
Thanks for looking and wishing everyone a good weekend!
Cheers - Mike