PL/I for MVS and VM and OS PL/I programs

The following table shows various compiler options that can be used to prepare Enterprise COBOL for z/OS Version 4 programs for use with the IBM Problem Determination Tools products (Debug Tool for z/OS, Fault Analyzer for z/OS and Application Performance Analyzer for z/OS). The methods suggested in the following table indicate if the load module produced is suitable for a production environment. Load modules suitable for a production environments have no significant run-time overhead.

For the test environment, you need both the listing and the LANGX file (for Fault Analyzer for z/OS and Application Performance Analyzer for z/OS). In production, only the LANGX file is suggested.

Table 1. Examples of compiler options and source information files supported by IBM Problem Determination Tools products for PLI for MVS and VM and OS PLI
Compiler options Source information file type produced Is the load module production ready? Options supported and suggested for Debug Tool for z/OS Options supported and suggested for Fault Analyzer for z/OS Options supported and suggested for Application Performance Analyzer for z/OS
TEST(ALL), AGGREGATE, ATTRIBUTES (FULL), ESD, LIST, MAP, NEST, NOPT, OPTIONS, SOURCE, STMT, XREF(FULL) Compiler listing No Suggested for test. (Using Debug Tool in production for this compiler is not recommended.) Supported Supported
LANGX file No N/A Supported N/A
NOTEST, AGGREGATE, ATTRIBUTES (FULL), ESD, LIST, MAP, NEST, OPTIONS, SOURCE, STMT, XREF(FULL) Compiler listing Yes N/A Supported Suggested for production and test
LANGX file Yes N/A Suggested for production and test N/A
Note: The highlighted row or rows in the table above indicate the suggested compiler options and source information file types for each product.

Perform the following steps for compiling your PL/I for MVS and VM and OS PL/I programs:

  1. Create a library (PDSE is suggested unless PDS is required for your organization) for compiler listing files. This is only needed in test environments where debugging will be performed. Specify LRECL=125 minimum,RECFM=VBA,BLKSIZE= lrecl+4 to 32k.
  2. Allocate libraries (PDSE is suggested unless PDS is required for your organization) for LANGX files. Allocate one or more LANGX libraries for each environment, such as test and production.
  3. Create a corresponding LANGX library for each load library. Specify LRECL=1562 or greater,RECFM=VB,BLKSIZE= lrecl+4 to 32k.
  4. For all programs, such as batch, CICS, and IMS:
    • In test environments, specify compiler options TEST(ALL), NOPT, AGGREGATE, ATTRIBUTES(FULL), ESD, LIST, MAP, NEST, OPTIONS, SOURCE, STMT, XREF(FULL).

      TEST(ALL) and NOOPT are required by Debug Tool. TEST adds debug hooks, which add some runtime overhead. Symbolic data required by Debug Tool is stored in the module, which can make it significantly larger.

      The other options format the compiler listing as required by Debug Tool and by the xxxLANGX utility.

    • In production environments, specify compiler options NOTEST, AGGREGATE, ATTRIBUTES(FULL), ESD, LIST, MAP, NEST, OPTIONS, SOURCE, STMT, XREF(FULL).

      NOTEST disables Debug Tool, but provides the best performance.

      The other options format the compiler listing as required for the xxxLANGX utility.

      This produces a production-ready module that can be used with Fault Analyzer for z/OS and Application Performance Analyzer for z/OS but not Debug Tool for z/OS.

  5. Modify the SYSPRINT DD in the compiler step. This is the compiler listing. Save this to a permanent file. The compiler listing is the input to the xxxLANGX utility and is the source information file for Debug Tool for z/OS
    Note: This compiler typically renames CSECTs according to an internal compiler algorithm. Therefore, it is not recommended to store PL/I compiler listings or side files using CSECT names as they might not be found by Application Performance Analyzer for z/OS or Fault Analyzer for z/OS. Instead, use the primary entry point name.
  6. Add a step after the compiler step to run the xxxLANGX utility. This utility reads the compiler listing and saves a LANGX file. This is the source information file for Fault Analyzer for z/OS and Application Performance Analyzer for z/OS. Equivalent xxxLANGX utilities are available in Debug Tool for z/OS as EQALANGX, in Fault Analyzer for z/OS as IDILANGX and in Application Performance Analyzer for z/OS as CAZLANGX. Save it in the LANGX file library and specify a member name that is equal to the primary entry point name of your application program.
  7. Modify the promotion process to promote LANGX files. When a load module is promoted, for example, from test to production, promote the corresponding LANGX file or files. A promotion can be a recompile, copy, or move. Perform the same steps with the LANGX file that you perform with the module during promotion.
  8. Optionally, include a Debug Tool Language Environment exit module into the load module during the linkage editor step. This is one way to enable Debug Tool’s panel 6 in ISPF, a simple panel-driven method to start the debugger automatically when a program runs, without JCL changes, based on the program name and user ID. Use module EQADBCXT for batch programs (including IMS batch), EQADICXT for IMS/TM programs and EQADDCXT for DB2 stored procedures. Do not include the exit module for CICS programs.
  9. For CICS applications only, if the Debug Tool DTCN transaction will be used to start Debug Tool, link-edit the Debug Tool CICS startup exit module EQADCCXT into the application load module to enable Debug Tool in CICS. This is not needed if using the CADP transaction instead of DTCN.