search cancel

The content of Insight Ilog datasets is being written to the JES output of the GSS started task. How do you prevent it?


Article ID: 49988


Updated On:


RC Compare for DB2 for z/OS Bind Analyzer for DB2 for z/OS SQL-Ease for DB2 for z/OS SYSVIEW Performance Management Option for DB2 for z/OS Plan Analyzer for DB2 for z/OS Subsystem Analyzer for DB2 for z/OS Database Analyzer for DB2 for z/OS Fast Unload for DB2 for z/OS Fast Check for DB2 for z/OS Fast Index for DB2 for z/OS Rapid Reorg for DB2 for z/OS



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.


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:
    //STEPLIB DD DISP=SHR,DSN=gss.loadlib
    //DD1 DD DISP=SHR,DSN=gss.sample.imod.dsn
    //DD2 DD SYSOUT=*
    //SYSIN DD *

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.


Component: IDB2