Runtime Configurations

This section explains the concept of a Code Pipeline runtime configuration (RTConfig). It also lists the RTConfig definitions provided with Code Pipeline, then discusses the WZZRC and WZZRCCNF allocation modules. Miscellaneous considerations in defining and using RTConfigs are also presented, followed by an annotated sample of WZZRCCNF.

Overview of runtime configuration

Many Code Pipeline operations make use of a combination of REXX, CLISTs, programs, panels, and skeletons. Some of these are base code supplied with Code Pipeline, some are customized versions created by the customer, and some are new programs, panels, CLIST/REXX, etc. used to extend the functionality of Code Pipeline.

A good example of this is the Generate operation that compiles a source file and possibly runs a link-edit to create a program load module. In the Generate, there is often a compile options panel and some skeleton JCL used by CLISTs and REXX to build and submit the Generate job. Code Pipeline ships with basic panels, skeleton JCL, and CLIST/REXX routines for the Generate. However, every customer will have a need to customize some or all of these. Additional customization will occur over time as the customer environment and Code Pipeline product usage changes. Since Code Pipeline is an SCM, customers will actually use Code Pipeline to manage the site customization of Code Pipeline. They do this using a pre-defined application called SITE that is created during the Code Pipeline installation process. Panels, skeletons, CLISTs, REXX, and other Code Pipeline component types are checked out to the TEST level in the SITE application, modified, then promoted up through the lifecycle to HOLD and on to PROD. If the customer’s Code Pipeline environment allocates the SITE PROD level data sets ahead of the BASE data sets that ship with Code Pipeline, then Code Pipeline users will get the SITE customized version of panels, REXX, etc.

The challenge is: How can customized versions be tested before they are promoted to the PROD level in the SITE application, thus propagating them to all Code Pipeline users? You could create some CLISTs to set a TSO user’s allocation order to put the SITE TEST or HOLD level ahead of the PROD level and Code Pipeline BASE data sets, but this will not affect operations that are run under a Set Processor (Code Pipeline/SX task).

The solution (introduced in Code Pipeline 4.4) is to enable the customer to create a set of runtime configuration (RTConfig) definitions. Each RTConfig will have a unique name and a set of data set allocations in a specific order. When a Code Pipeline user specifies an RTConfig, they are selecting a set of runtime data set allocations. The RTConfig value will be passed through to the Set Processor for any sets they use for operations. Most Code Pipeline users will simply use the default RTConfig for everything they ever do. If, however, they need to test a site customization before it is promoted to the PROD level in the SITE application, they can use an RTConfig name that will be provided by their Code Pipeline administrator.

The RTConfig is also used to define the data set allocations used for any Code Pipeline test environment that a customer may set up.

Default RTConfig definitions

The default set of RTConfig definitions that are created during a standard Code Pipeline installation are:

• ISPP – Defines the production Code Pipeline data set allocations. Most users will always use this.
• ISPPHOLD – Defines the production Code Pipeline with the SITE HOLD data sets ahead of the SITE PROD and Code Pipeline Base data sets.
• ISPT – Defines the test Code Pipeline data set allocations.
• ISPTHOLD – Defines the test Code Pipeline with the SITE HOLD data sets ahead of the SITE PROD and Code Pipeline Base data sets.
• ISPTTEST – Defines the test Code Pipeline with the SITE TEST and HOLD data sets ahead of the SITE PROD and Code Pipeline Base data sets.

A customer is free to replace or add to these definitions. RTConfig names can be up to eight characters and must be unique within the customer’s site.

Many customers will only make use of this default set of RTConfig definitions. However, larger customers—or those with more complicated environments—will likely add their own RTConfig definitions. There is no limit to the number of definitions that can exist.

Code Pipeline Allocations modules WZZRC and WZZRCCNF

The allocations definition table WZZRCCNF, introduced in Code Pipeline 4.4, contains the various data set allocations for different Code Pipeline systems and configurations. Different configuration entries, identified by their name, can be defined, and they can each specify different data set names. Configurations can be defined for PROD and TEST Code Pipeline systems, allowing test data sets to be concatenated in front of production data sets, fix data sets to be concatenated in front of production data sets, and so on.

All Code Pipeline clients now use the load module resulting from the assembly and link of this table for their data set allocations. This allows any Set or Deploy process—as well as a Code Pipeline step in a submitted batch job—to use the same allocations that the Code Pipeline client is using.

The allocations are actually performed by the load module WZZRC, which has six aliases/entry points. Never execute WZZRC directly, but always use the appropriate entry point. The descriptions in this appendix will refer to WZZRCxxx. The entry points are described in detail later in this appendix. WZZRC and its six alias names must be copied to a LINKLIST data set that is APF authorized. This is because it can be used to invoke IKJEFT01, which must run APF authorized.

The WZZRCCNF table source must be updated to match your Code Pipeline configuration data set structure and must include the appropriate DD names and data set names. The table must be assembled and linked, and the resulting load module must be placed in a LINKLIST data set. This can be the authorized LINKLIST data set which contains WZZRC.

WZZRCxxx is passed a configuration name. It loads WZZRCCNF, looks up the configuration, and allocates the appropriate data sets. It then passes control to the appropriate program, CLIST, or REXX EXEC.

Module WZZRCCNF

WZZRCCNF contains a series of connected tables used to define data sets to be allocated. The following eight Assembler macros described in this section are used to create the tables:

• WZZRCCON
• WZZRCSEQ
• WZZRCLVL
• WZZRCDD
• WZZRCDSN
• WZZRCSYS
• WZZRCTMP
• WZZRCTRC

WZZRCCON

WZZRCCON is the starting point for a configuration entry. The parameters are:

WZZRCTMP

WZZRCTMP identifies a set of temporary data set allocation settings. The label (in columns 1 to 8) of the statement is the name of the set (see TEMPDS under WZZRCDSN).

UNIT=

Unit name to be used (for example, UNIT=SYSDA).

STORCLAS=

SMS storage class (for example, STORCLAS=SMS).

SPACE=

Same as SPACE= in JCL (for example, SPACE=(TRK,(1,1,1)).

DCB=

Same as DCB= in JCL (for example, DCB=(RECFM=FB,LRECL=80,BLKSIZE=3120)).

WZZRCTRC

WZZRCTRC identifies a set of trace control statements. The label (in columns 1 to 8) of the first statement in a set is the name of the set (see TRCDEF under WZZRCCON). The label field of the second and subsequent trace statements in a set should be left blank. Multiple sets can be specified. You should include a label on the first statement in any additional sets.

The parameter to the statement is a quoted string containing a standard Code Pipeline trace control statement.

Module WZZRC

Module WZZRC has multiple aliases and corresponding entry points. All aliases expect a parameter of the configuration name. WZZRCSPF expects only the configuration name. All of the others except WZZRCJCL expect the configuration name to be followed by a slash, and then a program, TSO command, CLIST member name, or REXX EXEC name that is to be executed, followed by any parameters that are to be passed to it.

WZZRCSPF

WZZRCSPF is used in foreground TSO when already in ISPF. It does not allocate the TEMP level or SYSTEM level data sets. It starts Code Pipeline as a new ISPF application by executing:

SELECT CMD(WZZRCSPF xxxxxxxx) NEWAPPL(yyyy) NOCHECK PASSLIBwhere xxxxxxxx is the name of the appropriate runtime configuration entry and yyyy is the new APPL within ISPF to be used to run WZZRCSPF.

WZZRCSPF can be used to invoke a standalone REXX exec outside of Code Pipeline. For example, this could be for situations where Deploy Packages need to be released by operations.

Execute the following command to allocate the libraries for the configname and execute the REXX exec:

On exit from the REXX exec, the libraries will be freed.

WZZRCBAT

WZZRCBAT is used in background tasks (batch jobs, started tasks) where Code Pipeline will be run in batch ISPF (for example, ISPWSX and ISPWRX). It allocates all data sets.

WZZRCTSO

WZZRCTSO is used in background tasks (batch jobs, started tasks) where TSO commands will be run. It only allocates SYSEXEC, SYSPROC, and ISPLLIB data sets (using DD name TASKLIB).

WZZRCJOB

WZZRCJOB is used in background tasks (batch jobs, started tasks) where a program needs to execute (for example, WZZBP). It only allocates ISPLLIB data sets (using DD name TASKLIB).

WZZRCCMD

WZZRCCMD is used in foreground TSO where a batch utility program is being run in the foreground (for example, REXX EXEC WZZA### running WZZRLB). No allocations are performed. It starts Code Pipeline as a new ISPF application by executing:

SELECT CMD(WZZTS) NEWAPPL(xxxx) PASSLIBwhere xxxx is the new APPL within ISPF to be used to run WZZRCCMD.

WZZRCJCL

WZZRCJCL is used in test mode. Pseudo JCL is written to DD WZZALLOC. If the configuration name is followed by a slash, what follows the slash identifies the entry point it is to simulate (for example, WZZRCSPF or WZZRCBAT, etc.).

Additional considerations

This section contains miscellaneous information about defining and using RTConfigs.

Removing hardcoded DDNAMES

If any skeletons or PROCLIB members are updated to use WZZRCxxx, any hardcoded DDNAMEs that will be allocated (STEPLIB, SYSPROC, SYSEXEC, etc.) should be removed. Skeletons processed by ISPF file tailoring get access to the client’s current configuration name using the ISPF variable WRTCONF (see skeleton WZU@TSO in SAMPLIB). Started tasks, such as SX and RX, are passed the client’s current configuration name in the start command using the parameter RTCONF (see PROCLIB member WZISPWSX in SAMPLIB).

Executing WZZRCBAT or WZZRCTSO and IKJEFT01

When executing WZZRCBAT or WZZRCTSO and IKJEFT01, there are multiple techniques you can use. The following examples all run WZZRCBAT and the LISTALC command with a parameter of STATUS (list all allocations showing DDNAME and disposition).

It is important to note that if IKJEFT01 is passed a parameter, it will attempt to execute it, treating it as a command, CLIST, or REXX EXEC.

Run WZZRCBAT with configuration name PROD and have it attach IKJEFT01. The command is passed to IKJEFT01 as a parameter. IKJEFT01 will run the command. This technique will work fine as long as the PARM string is not too long and you only want to run the one command.

Example 1:

Run WZZRCBAT with configuration name PROD and have it attach IKJEFT01. IKJEFT01 reads the command(s) from SYSTSIN. This technique allows you to run multiple commands, and all will be run in the Code Pipeline environment created by WZZRCBAT.

Run IKJEFT01 and pass to it a parameter string which includes WZZRCBAT with configuration name PROD and the TSO command. WZZRCBAT will run the TSO command using the IKJEFTSR service. This technique will work fine as long as the PARM string is not too long and you only want to run the one command.

Example 3:

Run IKJEFT01 which reads from SYSTSIN. Have it run WZZRCBAT with configuration name PROD. WZZRCBAT runs the TSO command using the IKJEFTSR service. This technique will only allow you to run the one command because when the command ends, WZZRCBAT ends. WZZRCBAT frees the Code Pipeline environment it creates when done, but it does not free the allocations, and so you cannot include a second WZZRCBAT in SYSTSIN.

Example 4:

WZZALLOC and pseudo JCL

If a DD card //WZZALLOC is included when executing WZZRCSPF, WZZRCBAT, WZZRCTSO, or WZZRCJOB, pseudo JCL will be generated that reflects the allocations performed.

WZZDEBUG and debugging information

If a DD card //WZZDEBUG is included, debugging information is generated. It is displayed on the terminal in ISPF using TPUT, and is displayed in the JOBLOG for started tasks and batch jobs using WTO. You can see each data set being allocated, then the DDNAMEs being concatenated. This DD card can be a DUMMY DD because nothing is written to it.

WZZRCTMP and temporary data sets

If the same WZZRCTMP definition is used in multiple WZZRCDD statements (for example, ISPTLIB and ISPTABL), the same temporary data set will be used in the second and subsequent allocations, as long as it is allocated to real DASD and not VIO.

Enqueues and table updates

ISPF serializes updates to tables (ISPTABL DD) by issuing an exclusive enqueue for the first DSNAME in the ISPTLIB concatenation. If the first data set is a permanent data set, problems can occur. For example, if two users attempt to update a table at the same time, the second enqueue will fail and the update will be rejected, causing the job to fail. In ISPF, the user’s profile is supposed to be the first data set in the ISPTLIB concatenation, and therefore no enqueues should collide. In batch and started tasks, BMC Software suggests that a temporary data set be allocated as the first data set in the ISPTLIB concatenation. Code Pipeline guarantees that the temporary data set is unique (it includes the job number in hexadecimal). The best way to ensure a temporary data set is on the front of the ISPTLIB concatenation is to use the new level TEMP. The level only needs one DD name, ISPTLIB, and one data set, TEMPDS=TABLES. This level is not used by WZZRCSPF.

WZZRCDSN and real DDNAMEs

When using the DD= parameter on the WZZRCDSN macro, complications can arise if the DDNAME is the real DDNAME we need to use (for example, ISPLLIB). To do this, you must have SITE data sets. Because the required DDNAME is already in use, it must be concatenated onto something (for example, the BASE data sets), at which point it “disappears”. Then, when allocating the SITE data sets, we can use the real DDNAME for the SITE data sets and concatenate the temp DDNAME that holds all the data sets previously allocated (for example, BASE and SYSTEM) after it.

SYSNAME restriction of z/OS images

If you use SYSNAME lists to restrict configurations to certain z/OS images, you can define multiple configurations with the same name, but use different data sets on the different z/OS images. This means you can share the one copy of WZZRCCNF. This would allow a user on ZOS1 to trigger a task on ZOS2 which uses the same configuration name but uses different data sets (different naming conventions on the different z/OS images). Note that this does require that each z/OS image have a unique &SYSNAME value.

SYSNAME and multiple configurations

When defining multiple configurations with the same name, if some are restricted by SYSNAME= while one is not, the configuration without the SYSNAME= should be positioned after the others. That ensures it will be selected only when the others have been rejected (current &SYSNAME is not on the list(s)).

DD name allocation requirement

Currently, WZZRCxxx requires that at least one data set is defined to be allocated to the following DD names:

• SYSPROC
• ISPLLIB
• ISPMLIB
• ISPPLIB
• ISPSLIB
• ISPTLIB
• ISPPROF
• ISPTABL
• WZ@RW
• WZ@WW

There is an exception to this requirement: If no data sets are defined to be allocated, but the DD name is already allocated, Code Pipeline will use the existing allocation.

This allocation requirement can cause problems at some sites. If tasks are being initiated on multiple systems (for example, for Deploy), and you know that some DDs are not going to be used (for example, WZ@RW and WZ@WW)—or maybe the data sets do not even exist on the remote systems—there are several ways to deal with this situation:

• You can define two configurations with the same name, limit the first configuration to the main system(s) where Code Pipeline is running using the SYSNAME= parameter, and not specify SYSNAME= on the second configuration. In the first configuration, include normal definitions for WZ@RW and WZ@WW. In the second configuration, you can specify temporary data sets instead, using a WZZRCTMP definition created specifically for this purpose.
• You can define two configurations with the same name, limit the first configuration to the main system(s) where Code Pipeline is running using the SYSNAME= parameter, and not specify SYSNAME= on the second configuration. In the first configuration, include normal definitions for WZ@RW and WZ@WW. In the second configuration, you can specify a data set name of NULLFILE, in which case a dummy data set will be allocated.
• You can create multiple WZZRCCNF tables which allocate the appropriate different data sets and use the different tables on the various z/OS images. This is an effective solution, but it does require that multiple table sources be updated if any changes are required.

Merging multiple sequences

It is possible to define multiple sequences that merge at a level. The first sequence should include all the levels. The second and subsequent sequences should only list the unique levels and the level where they merge. For example, if two sequences are A1 → B → C and A2 → B → C, you would specify WZZRCSEQ LIST=(A1,B,C) and WZZRCSEQ LIST=(A2,B). A warning message will be issued at assembly time for the second sequence stating “this sequence shares entries with a prior sequence.”

VIO data sets

Some of Code Pipeline’s REXX EXECs have trouble working with VIO data sets (for example, LISTDSI does not support VIO data sets). All temporary data sets allocated by WZZRCxxx should be allocated on real DASD. If VIO is allocated, a warning message is issued and execution continues. Temporary VIO data sets cannot be shared between multiple DD names because Code Pipeline needs a VOLSER to reuse the same data set, and VIO data sets do not have a VOLSER.

Testing WZZRCCNF and WZZRCxxx updates

To test updates to WZZRCCNF and/or WZZRCxxx, you can create special JCL which includes a //JOBLIB DD or //STEPLIB DD pointing to a load library containing the appropriate version of WZZRC, its six aliases, and the appropriate version of WZZRCCNF. This load library must include WZZRC, even if you are only testing an updated version of WZZRCCNF. If z/OS loads WZZRCxxx from the LINKLIST, it will also load WZZRCCNF from the LINKLIST (if your JOBLIB/STEPLIB is not APF-authorized), thus ignoring your updated WZZRCCNF in your JOBLIB or STEPLIB. This situation is related to the way z/OS handles multiple load modules when some are APF-authorized (WZZRC and its aliases) and some are not (WZZRCCNF).

Annotated sample WZZRCCNF

The following series of figures presents a sample WZZRCCNF with each figure followed by an explanation.

WZZRCCNF – Prologue

The preceding figure depicts a standard Assembler prologue.

WZZRCCNF – Production configuration definitions

In the preceding figure, two production Code Pipeline configurations are defined:

• ISPP is the default configuration and uses the following levels:
  • SITEPROD – production site data sets
  • BASEPROD – production base data sets
  • SYSTEM – standard system data sets
  • WZ@TBLS1 – Code Pipeline .M and .O tables data sets
  • TEMPTLIB – temporary ISPTLIB data set.
  • WDLGPROD –

    Workbench for Eclipse

    Custom Dialogs datasets
  • SRVRDEF=YES – This is the default runtime config for Code Pipeline for Eclipse users that connect to this Code Pipeline CM.
• ISPPHOLD uses the following levels:
  • SITEHOLD – hold site (production site data sets too)
  • BASEPROD – production base data sets
  • SYSTEM – standard system data sets
  • WZ@TBLS1 – Code Pipeline .M and .O tables data sets
  • TEMPTLIB – temporary ISPTLIB data set.
  • WDLGHOLD –

    Workbench for Eclipse

    Custom Dialogs datasets

WZZRCCNF – Test configuration definitions

In the preceding figure, the following six test Code Pipeline configurations are defined:

• ISPT uses the following levels:
  • SITEPROD – production site data sets
  • BASETEST – test base data sets
  • SYSTEM – standard system data sets
  • WZ@TBLS1 – Code Pipeline .M and .O tables data sets
  • TEMPTLIB – temporary ISPTLIB data set
  • WDLGPROD –

    Workbench for Eclipse

    Custom Dialogs datasets
  • SRVRDEF=YES – This is the default runtime config for Code Pipeline for Eclipse users that connect to this Code Pipeline CM.
• ISPTFIX uses the following levels:
  • SITEPROD – production site data sets
  • BASETESTFIX – test base fix data sets (test base data sets too)
  • SYSTEM – standard system data sets
  • WZ@TBLS1 – Code Pipeline .M and .O tables data sets
  • TEMPTLIB – temporary ISPTLIB data set
  • WDLGPROD –

    Workbench for Eclipse

    Custom Dialogs datasets
• ISPTHOLD uses the following levels:
  • SITEHOLD – hold site (production site data sets too)
  • BASETEST – test base data sets
  • SYSTEM – standard system data sets
  • WZ@TBLS1 – Code Pipeline .M and .O tables data sets
  • TEMPTLIB – temporary ISPTLIB data set
  • WDLGHOLD –

    Workbench for Eclipse

    Custom Dialogs datasets
• ISPTTEST uses the following levels and definitions (applicable to z/OS images on list SYSLIST, namely ZOS1, ZOS2, and ZOS3):
  • SITETEST – test site (hold and production site data sets too)
  • BASETEST – test base data sets
  • SYSTEM – standard system data sets
  • WZ@TBLS1 – Code Pipeline .M and .O tables data sets
  • TEMPTLIB – temporary ISPTLIB data set
  • WDLGTEST –

    Workbench for Eclipse

    Custom Dialogs datasets
  • SYSLIST – List of z/OS &SYSNAME values.
• ISPTTEST uses the following levels and definitions (applicable to all other z/OS images):
  • SITETEST – test site (hold and production site data sets too)
  • BASETEST – test base data sets
  • SYSTEM – standard system data sets
  • WZ@TBLS2 – Code Pipeline .M and .O tables data sets
  • TEMPTLIB – temporary ISPTLIB data set
  • WDLGTEST –

    Workbench for Eclipse

    Custom Dialogs datasets
• ISPTTRC uses the following levels and definitions:
  • SITETEST – test site (hold and production site data sets too)
  • BASETEST – test base data sets
  • SYSTEM – standard system data sets
  • WZ@TBLS1 – Code Pipeline .M and .O tables data sets
  • TEMPTLIB – temporary ISPTLIB data set
  • WDLGTEST –

    Workbench for Eclipse

    Custom Dialogs datasets
  • TRACEDEF – Code Pipeline trace definitions

WZZRCCNF – Temporary data set level sequence

Define the sequence of one temporary data set level, TEMPTLIB, to be used when allocating ISPTLIB. The definition shown in the preceding figure specifies just one DDNAME, ISPTLIB, and just one data set, which uses the TABLES temporary data set definition. This data set will be allocated in front of any ISPTLIB data sets defined at the SITE, BASE, and SYSTEM levels.

WZZRCCNF – Site sequence level definitions

Define the sequence of three site levels as shown in the preceding figure: SITETEST followed by SITEHOLD followed by SITEPROD. When SITETEST is used, SITEHOLD and SITEPROD will also be used. When SITEHOLD is used, SITEPROD will also be used. Define the levels as follows:

• Define the SITETEST level, specifying the DDNAMEs and DSNAMEs.
• Define the SITEHOLD level, specifying the DDNAMEs and DSNAMEs.
• Define the SITEPROD level, specifying the DDNAMEs and DSNAMEs.

WZZRCCNF – Tables sequences

In the preceding figure, four separate sequences of tables levels are defined for the Code Pipeline .M and .O tables. WZ@TBLS1 and WZ@TBLS2 are used in some configurations, but WZ@TBLS3 and WZ@TBLS4 are not used in any configurations and are included for demonstration purposes only. Define the table sequences as follows:

• Define the WZ@TBLS1 level, specifying the two DDNAMEs and corresponding DSNAMEs. Configuration ISPTTEST uses this level on z/OS images ZOS1, ZOS2, and ZOS3.
• Define the WZ@TBLS2 level, specifying the two DDNAMEs and corresponding DSNAMEs. Configuration ISPTTEST uses this level on z/OS images other than ZOS1, ZOS2, and ZOS3.
• Define the WZ@TBLS3 level, specifying the two DDNAMEs and corresponding temporary data sets. No configurations use this level. It is included for demonstration purposes only.
• Define the WZ@TBLS4 level, specifying the two DDNAMEs and corresponding dummy data sets. No configurations use this level. It is included for demonstration purposes only.

WZZRCCNF – Production base level sequence

The sequence of one production base level, BASEPROD, for the production Code Pipeline  base data sets is defined in the preceding figure. The BASEPROD level is defined here by specifying the DDNAMEs and corresponding DSNAMEs.

WZZRCCNF – Test base level sequence

The sequence of two test base levels, BASETESTFIX and BASETEST, for the test Code Pipeline base data sets is defined in the preceding figure. Define the levels as follows:

• Define the BASETESTFIX level, specifying the DDNAMEs and corresponding DSNAMEs.
• Define the BASETEST level, specifying the DDNAMEs and corresponding DSNAMEs.

WZZRCCNF – System level sequence

In the preceding figure, the sequence of one system level called SYSTEM (for the standard ISPF system data sets) is defined. To define the SYSTEM level, specify the DDNAMEs and corresponding DSNAMEs. These are the standard ISPF data sets that are typically allocated in a TSO logon proc or in a CLIST run immediately after logon.

WZZRCCNF – Temporary data set allocation settings

The preceding figure illustrates how to define the following three sets of temporary data set allocation settings:

• TABLES is used for the temporary ISPTABL data set and the temporary ISPTLIB data set that is concatenated in front of any other ISPTLIB data sets. If multiple WZZRCDSN macros use the same WZZRCTMP settings, then they use the same data set, which is the desired behavior for ISPTABL and ISPTLIB.
• PROFILE is used for the temporary ISPPROF data set.
• TEMPTABL is used for the temporary data set allocated to WZZ@RW and WZZ@WW, if level WZ@TBLS3 was used. (No configuration in this sample uses it.)

These definitions should only be referenced in the TEMP and SYSTEM levels, so that they are not allocated in foreground ISPF, when WZZRCSPF is being used. UNIT and STORCLASS values can be updated to meet your system requirements.

WZZRCCNF – System names lists

The preceding figure shows how to define one list of system names (z/OS system variable &SYSNAME). Any configurations referencing this list will only be selected if the &SYSNAME variable of the z/OS image where the task is running is included in the list.

WZZRCCNF – Trace statement definitions

One set of trace definitions are defined in the preceding figure, and WZZRCCNF is terminated with an END statement.