CONPARMX – Dissecting a New Approach

One of the newer utilities introduced with CA Endevor SCM is “CONPARMX”. With the introduction of this utility, CA provided an opportunity to a new approach to an old “vexing” problem; a good way of introducing things like a parameter list for compiles and linkedits without the need for doing extensive symbolic overrides or “symbolic substring value substitutions” (aka ZCONCAT aka if you don’t know, don’t worry about it!)

I have found that adhering to the principles of “Process Normalization”, exploiting CONPARMX fits quite nicely into providing a structured framework that is easier to administer.  So while I have written an entire article on “Process Normalization”, a quick recap is worth consideration.

To summarize, normalization seeks to identify objects in terms of “what they are” versus “how they are managed”. In other words, TYPE definitions such as COBOL, PLI, ASM, and FORTRAN would be considered normalized. Each TYPE definition is exactly that; a definition of the TYPE of language to be processed.

TYPE definitions such as COBMAIN, COBDB2, or COBSUB would NOT be considered normalized. In these examples, the TYPE of language (implicitly COBOL but who really knows?) is mixed up with part of its processing or use (mainline, DB2, subroutine…. But are they really?).

In a non-normalized environment, one finds many definitions for the same language. In the example cited above, there are at least 3 definitions for COBOL! Yet, COBOL is COBOL is COBOL.

In a normalized environment, there is generally ONE definition for a language (COBOL) and Endevor PROCESSOR GROUPS differentiate the handling of specific elements defined to the language TYPE. In other words, if I have a COBOL program that uses DB2 and is a subroutine, I associated it to the processor group that is defined to handle DB2 and subroutines.

Clearly, this approach eases the definitions of TYPES but results in the need to reflect different combinations of different parameters into processor group definitions. This can be an onerous task but also now simplified with CONPARMX.

In the manual, CA describes the CONPARMX utility as follows:

“The CONPARMX utility lets administrators reduce processor complexity and the number of processor groups. CONPARMX dynamically builds execution parameters for processor programs such as compilers or the linkage editor. The build process uses the symbols defined in the processor and one or more of the following groups of options, which may or may not be concatenated:

Default options

Processor group options

Element options

“Using this utility avoids the need to create and update large numbers of processors or processor groups with different input parameters.”

Figure 1 -CA Endevor SCM – 18.0

Put another way, many generate processes require parameters to be specified in order to achiever desired results. DB2, for instance, requires a pre-compile. Compilers themselves have many parameters, as does the linkage-editor.

The traditional way of providing unique combinations of parameters has been as indicated earlier; different processor groups invoking different combinations. A less traditional way has been to use symbolic substring substitutions. A “sneaky way” has been when developers discover they can override the Endevor administrator and provide compile parameters in-stream with their code (something every Endevor administrator should be aware of and provide a quick program to check for. If found, I would fail the generate!).

To illustrate the traditional way, consider the piece of processor below:

//             MAXRC=4,
//             PARM=('LIB,OPT,RES,X,MAP,TRUNC(BIN),OFF',
//             'NUMPROC(MIG),&COMPPARM')

Figure 2 – Compile Step in Processor

In this example, certain compile parameters are considered “technical standards” for the site and are thus “hard-coded” in the compile step (eg. LIB, OPT, RES, X, MAP, etc). Other values are “developer’s choice” and controlled by the value(s) specified in symbolic overrides defined for the processor group in &COMPPARM.

Now consider the following “grid” of processor groups:


Figure 3 – Grid of Processor Groups

Using this key, we can determine the “extra” compile parameters to be provided for each processor group. The highlighted options are the “technical standards” and are covered by the processor automatically by being hard-coded. Note that processor group “CB2AA” only uses the highlighted options and thus does not require any values to be placed in symbolic &COMPPARM.

However, processor group “CB2AB” requires the Endevor administrator to provide the value APOST and thus must override every occurrence of CB2AB at their installation with &COMPPARM=’APOST’. Processor group “CB2AC” requires &COMPPARM=’APOST,RENT’… and so forth through the entire table.

This process of providing, verifying, modifying, and setting up overrides can be labour-intensive although also typically a “one time effort”. Batch administration allows for the values to be placed quickly.

Among the challenges, however, is the fact that mistakes can be easily made and inconsistency accidentally propagated if the administrators models future processor groups on one that was defined to a system incorrectly.

CONPARMX provides for the opportunity to more cleanly and clearly define multiple processor groups without the need to provide extensive or complex symbolic overrides. The syntax for the utility is as follows:

//                 MAXRC=n,
// PARM=(parm1,'(parm2)',parm3,parm4,parm5,'(parm6)','parm7','parm8')
//            ALLOC=PMAP

Figure 4 – CONPARMX Syntax

As documented by CA, each parameter (parm) translates to a different purpose:

  • Parm1 = program name
  • Parm2 = processor symbolic
  • Parm3 = default options member name
  • Parm4 = processor group options member name
  • Parm5 = element options member name
  • Parm6 = another processor symbolic entry
  • Parm7 = concatenation instruction
  • Parm8 = write to file instruction

Walking through a conversion of a processor from the “traditional” code to the new code is the easier way to understand how CONPARMX works, so let’s start with our traditional processor compile step:

//             MAXRC=4,
//             PARM=('LIB,OPT,RES,X,MAP,TRUNC(BIN),OFF',
//             'NUMPROC(MIG),&COMPPARM')

Figure 5 – Compile step in processor

Step 1: Isolate the program to be executed by CONPARMX

//             MAXRC=4,
//             PARM=(IGYCRCTL,…)

Figure 6 – Isolate program to be executed

Step 2: Define the mandatory parameters.

Generally speaking, PARM2 are meant to be the “first” parameters you want CONPARMX to use with the program defined in PARM1. Based on our example, those mandatory options should be “LIB,OPT,RES,X,MAP,TRUNC(BIN),OFF,NUMPROG(MIG)”. We COULD define those into a symbolic and then code them into the processor…. And that’s very tempting…..

But then we notice PARM3…. And decide against using PARM2 at all! So for now, accept that after Step 2 that the step in the processor now looks as follows:

//             MAXRC=4,
//             PARM=(IGYCRCTL,,…)

Figure 7 – Ignoring PARM2

Step 3: Define the default options member name.

PARM3 is a good place to specify the technical defaults options that we WERE going to define to PARM2. PARM3 is the first member that CONPARMX will use to search the library specified in the DDNAME  PARMSDEF. If we make a member named something like “$$$$DFLT”, then the member in the library (controlled by Endevor!) will ultimately contain the default values for all programs being invoked by CONPARMX.

As our first entry in member $$$$DFLT, the entry looks as follows:


One of the benefits of this approach is that if the technical defaults for the site should change, the Endevor administrator need only reflect the change in ONE location that is tracked and automatically picked up by all processors throughout the installation.

After making the necessary change, our processor step now looks as follows:

//             MAXRC=4,
//             PARM=(IGYCRCTL,,$$$$DFLT,…)
//PARMSDEF  DD DSN=library.of.process.grps,
//             MONITOR=COMPONENTS,
//             ALLOC=PMAP

Figure 8 – Specifying $$$$DFLT

Step 4: Continue with PARM4 for Processor Groups

Following the example of what was done for PARM3, we want to drive additional parameters based on the name of the processor group. So, we add the symbolic for processor group as PARM4.

//             MAXRC=4,
//             PARM=(IGYCRCTL,,$$$$DFLT,&C1PRGRP,…)
//PARMSDEF  DD DSN=library.of.process.grps,
//             MONITOR=COMPONENTS,
//             ALLOC=PMAP

Figure 9 – Adding Processor Group name

Now CONPARMX will look into the library specified for PARMSDEF to find the member name that matches the processor group name. Using the grid defined earlier and looking just at processor groups CB2AA, CB2AB, and CB2AC, we see that

  • CB2AA has no additional parameters
  • CB2AB needs APOST
  • CB2AC needs APOST and RENT

Since CB2AA has no additional parameters, we don’t need to do any action. CONPARMX will look for member CB2AA in the PARMSDEF library and, when not found, will simply ignore the parameter. This is precisely what we want it to do.

Member CB2AB, however, will have an entry as follows:


Member CB2AC will have an entry as follows:


Step 5: Do we want PARM5?

PARM5 allows for “element specific” parameters to be specified. Personally, I’m not an advocate of using element-specific parameters. My philosophy is that if it’s good enough for an element, it’s good enough for a processor group! But we may still want to provide for it with the knowledge that CONPARMX will ignore member names “not found”.

//             MAXRC=4,
//             PARM=(IGYCRCTL,,$$$$DFLT,&C1PRGRP,&C1ELEMENT…)
//PARMSDEF  DD DSN=library.of.process.grps,
//             MONITOR=COMPONENTS,
//             ALLOC=PMAP

Figure 10 – Providing for element-specific

Step 6: Making CONPARMX act in reverse and other odd actions

PARM6, PARM7, and PARM8 are not covered by this article. They affect the order in which the parameters are invoked and “stopping points” in terms of what to do. If the reader would like more details or has a need for invoking parameters outside of what has been documented here, I recommend referring to the CA Endevor manual for more information.

The final product of our conversion will now look as follows:

//             MAXRC=4,
//             PARM=(IGYCRCTL,,$$$$DFLT,&C1PRGRP,&C1ELEMENT,,’N’,’N’)
//PARMSDEF  DD DSN=library.of.process.grps,
//             MONITOR=COMPONENTS,
//             ALLOC=PMAP

Figure 11 – Final State of converted compile step

What Have We Accomplished?

  • Elimination of parameter overrides as part of defining new processor group names
    • Vastly simplifies introduction of new groups identifying unique combinations of program parameters
    • No longer necessary to visit every override in every system
      • Assured that processor group parameters are the same Endevor-wide
  • Eased definition of processor groups
    • Names drive included parameters
    • Included parameters are now part of tracked Endevor elements
      • Endevor for Endevor administrators!
  • One stop definition, update, and override
    • The dataset library.PRGRP contains all your processor group names and what they override, independent of environment, system, etc.


Figure 12 – Type definition and library usage for PARMSDEF


Figure 13 – PARMSDEF Library Member Contents

One thought on “CONPARMX – Dissecting a New Approach

  1. Thanks for the article John.
    It might be of interest to some readers that the use of CBL or PROCESS statements in source code can be prohibited by the setting of &ALOWCBL=NO. This field is defined in IGYCOPT and can be overridden when creating a module IGYCDOPT which can be invoked ahead of any other version. For COBOL 6 the JCL to do this is in member IGYWUOPT.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s