Customizing CLIST and REXX processing

This part describes how you can customize REXX and CLIST processing. You can customize CLIST processing using exits. You can customize REXX processing using exits and replaceable routines. You can also optimize the performance of REXX execs and CLISTs by storing them in the virtual lookaside facility (VLF).

CLIST Exits
The CLIST language provides a wide range of programming functions. TSO/E provides the following exits that you can use to customize the CLIST language:
- CLIST built-in function exit:
  The CLIST language provides built-in functions that can be performed on variables, expressions, and character strings. In addition to these built-in functions, TSO/E provides an exit that you can use to add your own CLIST built-in functions. For more information, see Writing an exit for installation-written built-in functions (IKJCT44B).
- CLIST statement exit:
  The CLIST language provides statements that let you structure your programs, perform I/O, define and modify variables, and monitor the conditions under which CLISTs execute. In addition to the statements provided by the CLIST language, TSO/E provides an exit that you can use to add your own CLIST statements. For more information, see Writing an exit for installation-written statements (IKJCT44S).
REXX Replaceable Routines and Exits
The REXX language provides a wide range of programming functions. REXX has many characteristics similar to CLIST. However, a significant difference between REXX and CLIST is that you can execute CLISTs only in a TSO/E address space. You can execute REXX execs in any MVS™ address space. TSO/E REXX supports the use of replaceable routines and exit routines to customize REXX processing in different environments.
- Replaceable Routines
  Replaceable routines allow you to customize REXX processing to call the appropriate system-supplied routines for a language processor environment. TSO/E provides the following types of replaceable routines for REXX processing:
  - Exec load
  - Input/Output
  - Data stack
  - Storage management
  - User ID
  - Message identifier
  - Host command environment
- REXX Exits
  You can also customize TSO/E REXX using exit routines, which receive control from exit points in TSO/E REXX routines, perform special processing, and return control to the REXX routine. TSO/E provides the following types of exits for REXX processing:
  - TSO/E-Supplied Exits:
    Pre-environment initialization exit (IRXINITX)
    IRXINITX performs processing before a new language processor environment is initialized.
    
    Post-environment initialization exit (IRXITTS or IRXITMV)
    IRXITTS performs processing after the new language processor environment is initialized for an environment integrated with TSO/E.
    
    IRXITMV performs processing after the new language processor is initialized for an environment not integrated with TSO/E.
    
    Environment termination exit (IRXTERMX)
    IRXTERMX performs processing before a language processor environment is terminated.
  - User-Supplied Exits:
    Exec processing exit
    Use this exit to prevent the execution of a REXX exec or perform special processing before a REXX exec is executed.
    
    Exec initialization exit
    Use this exit to access and update REXX variables.
    
    Exec termination exit
    Use this exit to access and update REXX variables.
    
    Attention handling exit
    Use this exit to perform special attention processing. It can only be used for an environment integrated with TSO/E.
Storing CLISTs and REXX Execs in VLF
You can improve performance of CLISTs and REXX execs that the EXEC command finds at the system-level CLIST (SYSPROC) and application-level CLIST (defined using the TSO/E ALTLIB command), by using the virtual lookaside facility (VLF). To improve performance of these CLISTs and REXX execs, define the IKJEXEC class name in the facility VLF PARMLIB member, COFVLFxx. For example,
```
⋮
CLASS NAME (IKJEXEC)
  EDSN(data set name)    /* (your partitioned data set name) */
  EDSN(data set name)    /* (your partitioned data set name) */
⋮
```
Each eligible data set name (EDSN) entry in that member identifies a data set. The order of the entries is not significant.
To optimize VLF for CLISTs, you should:
- Maintain frequently-used CLISTs in separate data set(s).
- Where possible, place VLF-managed data sets at the front of non-VLF-managed data sets in the SYSPROC concatenation.
- For non-VLF-managed data sets that occur ahead of VLF-managed data sets in the concatenation, minimize copies of CLISTs with the same name as CLISTs in VLF-managed data sets.
- Avoid frequent updates to VLF-managed CLISTs.
- Minimize dynamic changes to CLIST data concatenations.
When setting up the PARMLIB member, your installation should define a data set name in only one VLF class. For more information about COFVLFxx and about using VLF, see . For more information about the TSO/E ALTLIB command, see .

If a library is properly defined in a COFVLFxx member and only one system is involved, VLF change notification is automatic. If several systems share the data, VLF change notification might also be automatic. For information about when VLF change notification is automatic, see . For more information about the VLFNOTE command, see .

The system searches VLF for REXX execs invoked implicitly or explicitly by the EXEC command. However, VLF is not searched for REXX execs invoked as functions or subroutines.

For example, suppose you have two REXX execs, A and B, both managed by VLF. REXX exec A is invoked via the EXEC command. REXX exec B is invoked via an external function from REXX exec A. If both REXX execs are changed on one system, the changes to REXX exec A are not seen on the other systems unless VLFNOTE is issued.