The content of Sysview for Db2 ILOG datasets written to the JES output of the GSS started task

Products

• SYSVIEW Performance Management Option for DB2 for z/OS

Issue/Introduction

Every time there is a message SRV198 ILOG Dump required for LOGnn#n in the ISRVLOG of the GSS started task (STC),
a SYS000nn dataset gets allocated to the GSS STC, and the contents of that ILOG subfile are dumped to it.

It is a JES sysout dataset, and the content looks like:

...
ILOG Listing for ILOG 20.1 8 Sep 2011 
11/09/08 21.53.04 0 SYSTEM DB2 - -TERM UTIL(J217A89D)
11/09/08 21.53.05 0 SYSTEM DB2 - 09/08/11 21:53:05 J217A89D 
11/09/08 21.53.06 0 SYSTEM DB2 - 09/08/11 21:53:06 J217A89D 
11/09/08 21.53.06 0 SYSTEM DB2 - -START DB(GRPBILL) SPAC
11/09/08 21.53.06 0 SYSTEM DB2 - 09/08/11 21:53:06 AUTH SCHD 
11/09/08 21.53.12 0 SYSTEM DB2 - 09/08/11 21:53:12 J217A89D 
....

 

It fills the spool file with tens of thousands of lines.
This is the result of the sample Imod, $USER_ILOG_FULL, being loaded at GSS start up.

Resolution

This is happening because the following conditions are in place:

1. The sample Imod dataset supplied with GSS has been included in the Imod datasets allocated when GSS starts, using the ISET parm.
   
   
2. The Imods in the dataset have had their status changed from TEST to PROD. Otherwise they would not be loaded by GSS.

Among the sample Imods is $USER_ILOG_FULL.

This Imod is called by the Imod $INT_ILOG_FULL, which is the Imod initially invoked to process a full ILOG file.

The $USER_ILOG_FULL Imod is a sample, provided for clients to use if they want to write the contents of an Ilog file to a dataset when it fills, before getting reset for reuse.

If the $USER_ILOG_FULL Imod is not loaded, then $INT_ILOG_FULL will just reset the Ilog file for resuse, and processing continues.

As originally coded, $USER_ILOG_FULL should attempt to write the content of the Ilog file to an invalid node, using CLASS=A.

Normally in this situation, the client will see the following message repeatedly in the GSS ISRVLOG:

'Invalid workstation'

In this case, the client's JES environment was able to successfully process the Imod's output request, which resulted in the SYS000nn dataset being allocated by JES, and the contents of the ILOG file dumped to it.

The client can remedy this situation in one of three ways:

1. Neutralize the ISET statement in the RUNPARM PARMLIB member that causes the sample Imod dataset to be included when GSS starts. Use an '*' in column 1 to do this.
   
   
2. Change the status of the $USER_ILOG_FULL Imod to TEST. Use the same JCL that was used to set the status to PROD in the first place.
   
   
3. Rename the IMOD using the SRVMAINT utility. Sample JCL and control cards follow:

   //jobcard
   //STEP1 EXEC PGM=SRVMAINT,REGION=0M
   //STEPLIB DD DISP=SHR,DSN=gss.loadlib
   //SYSPRINT DD SYSOUT=*
   //DD1 DD DISP=SHR,DSN=gss.sample.imod.dsn
   //DD2 DD SYSOUT=*
   //SYSIN DD *
   RENAME IMOD $USER_ILOG_FULL IN DD1 NEWNAME new_imod_name
   /*

Provide a valid job card and make the necessary name substitutions for the GSS loadlib, Imod dataset and Imod new name.

Once the changes are made, recycle the GSS address space.

You should no longer see the contents of the ILOG files appearing in the JES output of the GSS started task.