Today I want to wrap up this series on Endevor processor groups with a few more considerations for coding and using the CONPARMX utility in your Endevor processors and then give you just one example of how I use CONPARMX in my Endevor processors.
Previously:
- Taming the Jungle of Endevor Processor Groups – Part 1
- Taming the Jungle of Endevor Processor Groups – Part 2
- Taming the Jungle of Endevor Processor Groups – Part 3
- Taming the Jungle of Endevor Processor Groups – Part 4
- Taming the Jungle of Endevor Processor Groups – Part 5
- Taming the Jungle of Endevor Processor Groups – Part 6
CONPARMX Additional Considerations
Photo courtesy of Tim Waters
You may have to add a STEPLIB DD statement to point to the load library where the parm1 program is to be called from. There is also a PTF available to correct a problem with the STEPLIB concatenation. So if you need to use a STEPLIB for your parm1 program then save yourself some frustration and apply the PTF before you start working on CONPARMX.
A PARMSDEF DD statement is required. This DD is a concatenation of one or more Fixed Block Logical Record Length=80 (FB-80) type PDS or PDS/E datasets from which the CONPARMX utility reads the options members coded in the CONPARMX parameter string. The options members can be located in any of the concatenated datasets but they do not have to exist at all. I highly recommended that you define a new Endevor type for the options member with a source output library that you would include in the PARMSDEF concatenation. And I would also highly recommend that you have Endevor ACM monitor these libraries on the PARMSDEF concatenation using MONITOR=COMPONENTS so that Endevor will automatically relate the options member to the program source member when the program is generated in Endevor.
The PARMS DD statement is only needed if parm8 is set to Y. If used, the PARMS output file should be defined as an FB-80 sequential dataset.
The PARMSMSGS DD statement is not required. However, if coded, the CONPARMX utility program will write the resulting output options string value to this dataset for diagnostic purposes only. The PARMSMSGS dataset is also an FB-80 sequential dataset with a blocksize of 32720. Even though it’s an FB-80 dataset, CONPARMX will write the resulting output options string to the PARMSMSGS dataset at 72 bytes per line until the options string is exhausted. The maxiumun size of the resulting output options string is 512 bytes, so a maximum of 512 bytes of data will be written to the PARMSMSGS dataset.
If you let parm8 default to a value of “N” or if you specify parm8 to have a value of “N”, then you will need to add any additional DD statements required for the program name specified in parm1. For example, if you are calling the IGYCRCTL COBOL compiler then you will need to add the additional DD statements required by the IGYCRCTL program.
The Endevor MAXRC value should be set in your processor according to the parm1 program being called. If the parm1 program is not being called by CONPARMX (ie, parm8 = “Y”), then the MAXRC should be set to 0. And a return code of 0 from CONPARMX indicates successful processing. A CONPARMX return code of 16 indicates an error condition as described in a WTO message. All other CONPARMX return codes are issued by the parm1 program when called. So for example, a CONPARMX return code 4 from the COBOL compiler would indicate a compiler warning.
Now let’s take a look at an example to see how you might setup CONPARMX in your Endevor processors. (My apologies for the poor formatting in WordPress, but you can also download the following example at: http://www.endevorexperts.net/Endevor/Downloads_files/CONPARMX_example.txt)
//*******************************************************************
//** COMPILE THE ELEMENT **
//*******************************************************************
//COMPILE EXEC PGM=CONPARMX,COND=(0,LT),MAXRC=4,
// PARM=(IGYCRCTL,’(&PARMCOBA)’,$$$$DFLT,&C1PRGRP,&C1ELEMENT,
// ‘(&PARMCOBZ)’,'N’,'N’)
//PARMSDEF DD DSN=&PARMLIB,DISP=SHR,MONITOR=COMPONENTS,ALLOC=LMAP
//PARMSMSG DD SYSOUT=*
//SYSIN DD DSN=&&EXPOUT,DISP=(OLD,PASS)
//SYSLIN DD DSN=&&SYSLIN,DISP=(,PASS,DELETE),
// UNIT=&WRKUNIT,SPACE=(TRK,(100,100),RLSE),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=0),
// FOOTPRNT=CREATE
//SYSUT1 DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))
//SYSUT2 DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))
//SYSUT3 DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))
//SYSUT4 DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))
//SYSUT5 DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))
//SYSUT6 DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))
//SYSUT7 DD UNIT=&WRKUNIT,SPACE=(CYL,(5,3))
//SYSPRINT DD DSN=&&COBLIST,DISP=(OLD,PASS)
//*
Here’s an example of a COBOL Generate processor that is setup to use the CONPARMX utility. Let’s start with the DD statements and then I will review the parm statement.
In this example, the PARMSDEF DD points to a parmlib dataset concatenation as indicated by the DSN=&PARMLIB and the processor keyword ALLOC=LMAP. The parmlib is the source output libraries for the PARM element type that I define to Endevor. Whenever an options member is added to Endevor, it is written to the parmlib source output library where the processors can now access the options members directly from the source output library. Also notice that I have coded a MONITOR=COMPONENTS on the PARMSDEF DD so that Endevor will automatically create the component relationship to the options member.
Next there is a PARMSMSGS DD with the output going to the default output class. This is a good idea when you are setting up and testing the CONPARMX utility in your Endevor processors, but it’s not required.
Then I have all the remaining DD statements required by the COBOL compiler including the SYSIN that points to the output of a previous CONWRITE step, a SYSLIN DD for the output object module, a number of SYSUT DD statements for temporary work datasets, and a SYSPRINT DD for the compile listing.
All of that is pretty easy. Now let’s go back and look at the EXEC statement. You see here that I now execute the CONPARMX utility instead of the actual COBOL compiler. Since a return code 4 from the COBOL compiler is a warning message, I set the MAXRC=4 to indicate that a Return Code 4 Warning from the COBOL compiler is the highest acceptable Return Code for this processor step.
Then I have the PARM statement with 8 positional parm values. Since the parm values are positional, they must be coded in this exact order. If you do not want to supply a parm value for an optional positional parm value then you can just leave that value null and include the comma to separate the null value from the next parm value.
The value of the first parm value or parm1 is IGYCRCTL. That’s the name of the COBOL compiler program name. This is the program name that CONPARMX will call since I set parm8 to a value of “N” (to direct CONPARMX to call the parm1 program and not to build the PARMS output dd). Also, since parm8 is set to “N”, you notice that I do not need to include the output PARMS DD statement.
The value of parm7 is also “N”. This indicates to CONPARMX to NOT concatenate the options from parms 3, 4, and 5. Working backwards from right to left, CONPARMX will use the element options member specified in parm5 as &C1ELEMENT. So at processor execution time the CONPARMX utility will attempt to find the element options member with the same member name as the COBOL source element in the PARMSDEF concatenation. If a matching element options member is not found in the parmlib concatenation, then the CONPARMX utility will look for a processor group options member with the same name as the COBOL source element processor group name from the PARMSDEF concatenation. And if no matching processor group options member is found in the parmlib concatenation, then the CONPARMX utility will look for a default options member named $$$$DFLT from the PARMSDEF concatenation.
Endevor will substitute the &PARMCOBA and &PARMCOBZ variables, remove the surrounding parentheses, and then insert the value of the &PARMCOBA variable ahead of any output options string and append the value of the &PARMCOBZ variable to the end of the output options string.
So you can set the &PARMCOBA variable to include any COBOL options that you always want to include in the options string. Since these options appear first in the options string, the application programmer can override one of these options by coding the option in the element options member since the COBOL compiler will ignore the conflicting option specified in the &PARMCOBA variable and use the overriding option from the element options member. And you can set the &PARMCOBZ variable to include any COBOL options that you always want to enforce in the options string. For example, if you always want to include the LIB compiler option regardless of what the developer may have provided in the element options member then you could set the &PARMCOBZ to include the LIB compiler option and it will override any conflicting NOLIB option that the developer may have set in the element options member.
This is just one example of how you can start using the CONPARMX utility to simplify your Endevor processors and reduce the number of Endevor processor groups in your shop. I hope that you have enjoyed this series on Endevor processor groups.
If you have any questions about the CONPARMX utility or if you would like some help in setting this up for your Endevor environment, then please visit my website at http://www.endevorexperts.net for more information about engaging Endevor consulting services from my company. I would be happy to help you tame your jungle of Endevor processor groups.
Kevin Grimes, Sr. Endevor Consultant
Computer Technology Solutions, Inc.
Related articles
- Taming the Jungle of Endevor Processor Groups – Part 1 (kevingrimes.wordpress.com)
- Taming the Jungle of Endevor Processor Groups – Part 2 (kevingrimes.wordpress.com)
- Taming the Jungle of Endevor Processor Groups – Part 3 (kevingrimes.wordpress.com)
- Taming the Jungle of Endevor Processor Groups – Part 4 (kevingrimes.wordpress.com)
- Taming the Jungle of Endevor Processor Groups – Part 5 (kevingrimes.wordpress.com)
