CA Jclchk 12.0 : possibility to load a sort of Global Variables used by the whole Jclchk validation run on multiple members


Article ID: 125674


Updated On:


CA JCLCheck Workload Automation


CA JCLCheck™ Workload Automation provides a REXX interface to help enforce site standards by issuing messages when the standards are violated. As best practice, use the REXX interface instead of the Assembler user exit. The REXX exec is easier to implement and does not require a USERMOD to assemble and link it into CA JCLCheck™ Workload Automation. A sample REXX exec that is named CAZ1REXX is provided in the CAZ2OPTN library. Use CAZ1REXX as a template to create your own standards.  
To activate the REXX interface for CA JCLCheck™ Workload Automation, the following tasks must be done:
  • Allocate the library containing the REXX exec to the SYSEXEC DD statement. The SYSEXEC DD statement must be in the CA JCLCheck™ Workload Automation job (batch mode) or TSO logon proc/CLIST (ISPF  mode).
  • Add runtime option STDREXX (name), where name is the REXX exec found in the //SYSEXEC DD statement.
  • Add runtime option REXXMSG if the Message Processing routine is used.

Usually the Rexx available STEM variables are initialized and evaluated at each member validation, but it could be necessary to load tables - global variables and parms which should remain in memory  for the entire  product validation run done for different members, because these tables/variables are the same for all the validated members.
Is this possible and how to do it in the Rexx used?   


Z/OS - CA JCLCheck 


in the CAZ1REXX there is the INITIAL PROCESSING section that is executed only once even if more JCLs are processed in a single validation run. So it is possible to do an EXECIO instruction in this section to load tables containing these global variables , so that , even if the validated member changes, they are still available for use. 

Here a sample CAZ1REXX code added in the 'INITIAL_PROCESSING' section to load the table TABABI and to provide some trace messages : 

trace I  

The sample table TABABI should be added to the batch validation job as follows:   

 //TABABI DD DSN=table.dataset.dsname,DISP=SHR 
Better to run the batch validation using  REGION=0M