REXX for CA JCLCheck and JCLNeat › Using CAZ1REXX or CAZ1NREX

Using CAZ1REXX or CAZ1NREX

The following pages provide the purpose and a line-by-line description of the coding conventions for the CAZ1REXX and CAZ1NREX EXECs. The EXEC is broken down into its nine major subroutines to give you a better understanding of how the EXEC works.

If you are using the REXX EXEC under the TSO/E environment, all functions are available to TSO/E users.

If you are using the REXX EXEC in batch (or non-TSO/E) environments, only REXX-specific functions are available. (See the TSO Extensions Version 2 Procedures Language MVS/REXX User's Guide, or the TSO Extensions Version 2 Procedures Language MVS/REXX Reference Guide.)

Important! When you invoke CA JCLCheck (or JCLNeat) under ISPF and use the REXX interface, you use the ADDRESS instruction to invoke any ISPF services.

All variables used in this interface are stem variables. The stem prefix indicates the statement type (for example, JOB in JOB.CLASS). The suffix indicates the parameter type. If the variable is a subparameter, the subparameter name appears after an underscore (for example, DD.DISP_NORMAL). A complete list of variables appears at the end of this chapter and also within the comment sections of the specific statement type subroutines in the REXX EXEC template.

You can code any variable name that does not conflict with the variables that start with $CAJCL.

Values of all variables are retained throughout execution of the REXX EXEC. When the EXEC terminates (encounters an EOJ (End of Job statement)), the variable contents for that statement become null.

Processing is performed at the statement level. This means that information in the variables is set as CA JCLCheck (or JCLNeat) encounters the statement type defined in the REXX EXEC.

For example, every time CA JCLCheck (or JCLNeat) encounters a JOB statement, the JOB stem variable becomes part of the REXX EXEC and undergoes processing according to the IF logic in the subroutine for that statement type.

You can only access data for the current statement from the bottom up. You can look back, but not forward (that is, from DD to EXEC to JOB, but not from JOB to EXEC to DD). For example, at the JOB level you cannot access EXEC or DD variable data. At the EXEC level you can access JOB data, but not DD data. At the DD statement level you can access JOB, EXEC and DD data.

Note: The REXX interface generates only one pool (JOB/EXEC/DD/MSG) at a time. You can save values into any name variable you want for subsequent retrieval.

Important! Do not remove any lines in the REXX EXEC that appear in uppercase text. All variables prefixed with $CA are required.