Be able to use ZIIP feature with Log Data Manager.

IZPCA Log Data Manager feature is an ISPF/TSO application which needs to be coded in a special way in order to allow the caller environment to use Ziip processors. To avoid this inconvenience BATCH environment calling DRLPLC should be used instead.

Ok, its fine. But what about a workaround: 

DRLEDLMC is the REXX program that manages the log datasets queue. It allocates and provide the required datasets: SYSIN, DRLOUT, DRLDUMP and DRLLOG, and links with the collector. Additionally, it has an special run option CLEANUP=YES to be used in case the link with the collector abended. When it is called this way, it only resets the logs queue and keeps track of the failed log.

 We propose to add to the DRLEDLMC a new parameter, lets say INCLUDE=YES, set to NO by default. By default, DRLEDLMC will do as actual does. But if INCLUDE is YES it could write in a provided INCLUDE DD, the JCL statements a usual BATCH collection would require, for example:

 //SYSIN DD *
<collector statement associated to LOGID>

/*

//DRLOUT DD DISP=OLD,DSN=<DSPREFIX>.Dnnnnn.Tnnnnn.DRLOUT

//DRLDUMP DD DISP=OLD,<DSPREFIX>.Dnnnnn.Tnnnnnn.DRLDUMP

//DRLLOG DD DISP=SHR,DSN=<first log to be collected>

//                DD DISP=SHR,DSN=<second log to be collected>

Allocating DRLOUT and DRLDUMP as actually does, but it will not allocate the DRLLOG neither will link to the collector.

On the other side, when called to CLEANUP and with INCLUDE set to YES: additionally, it will write a DUMMY set of JCL statements as it could be:

//DRLIN    DD DUMMY

//DRLOUT   DD SYSOUT=*,DCB=(RECFM=F,LRECL=80)

//DRLDUMP  DD SYSOUT=*,DCB=(RECFM=VB,LRECL=32756)

//DRLLOG   DD DUMMY

With these arrangements we can split the actual step of Log Data Manager collection in 3 steps:

1.     First call to DRLMEDLMC will build an INCLUDE member suitable to collect in BATCH environment (able to use ZIIP processors).

2.     Batch collection using the traditional BATCH environment using the JCL INCLUDE build in the previous job by the log data manager. Obviously, this step must be executed in a different job just after the first one.

3.     Second unconditional (even executed) step to call DRLMEDLMC just after batch collector with parameter CLEANUP=YES

It is not a perfect solution, but it will allow a suitable workaround to collect using Log Data Manager and ZIIP features.