View Only

Extending Element OPTIONS - Not all Elements are alike

By Joseph Walther posted 13 days ago

Recommend

Introduction

Not all mainframe programs are alike.

Each programming language has a unique compiler for translating source code into executables. Additional program attributes require further processing variations. For example, a COBOL program might require a specific compiler, a Reentrant attribute, an MQ stub, Amode/Rmode values, or a hundred others. If an attribute is not processed properly, a program might not build at all, or if it might build, but not run properly.

This document presents an approach that empowers Endevor Administrators to manage an unlimited number of program attributes in an adaptable and user-friendly way. The approach can bring significant time-savings to both Endevor Administrators and application developers, and allow a site to simplify its Endevor Type and Processor Group names.

Endevor Types

Endevor’s techdocs documentation suggests that Type names be generic, such as COBOL or ASM. Generic names are legible and easily understood by developers and administrators alike. The name itself communicates a specific detail about an element.

A Problem with Processor Groups

Endevor processor group names get messy - especially if traditional naming methods are used. When processor group names alone support many diverse program attributes, the names become encrypted and unrecognizable. For example, suppose developers at your site see COBOL processor group names and descriptions such as these:

The name COBNBL01, for example, tells you little about attributes or processing requirements. You must read the descriptive text to see how one differs from the others.

Using processor group names like these causes the number of processor groups to increase over time, for multiple environments, systems, and types. Endevor administrators can be kept very busy in managing them. Developers may find it tiresome to scroll up and down long lists to find the appropriate selection for their program. Processor group names become increasingly meaningless - forced to adhere to 8-byte encrypted names.

Is there a better way? How can processor group names be generic - comparable to Type names? Could Endevor support processor group names like BATCH, BATCHDB2, ONLINE, and ONLINDB2? The steps presented in this document can make an impact on simplifying processor groups.

Step 1 - The CONPARMX Processor Utility - introduces the concept of Element Options. The CONPARMX documentation states that CONPARMX “lets administrators reduce processor complexity and the number of processor groups”.

Step 2 - Extending element options with VALUECHK - takes Element Options to another level, further reducing details typically required by processor group names.

Step 1 - The CONPARMX processor utility

The use of Endevor’s CONPARMX utility is the first step in simplifying and reducing the number of processor groups.

The CONPARMX utility introduces the concept of OPTIONS, You may think of OPTIONS as element “config files” - providing processing attributes that dictate specific actions in Endevor processors. OPTIONS contain statements in this format.

Vprogram =  "Double-quoted-value"
Vprogram =  'Single-quoted-value'

Where Vprogram is a called program within an Endevor processor step. Examples include IGYCRCTL, IEWL, CCNDRVR, DFHECP1$ and ASMA90. These are IBM utilities for translating, compiling, or link-editing. Vendor programs and your programs may also be Vprogram values.

The quoted-value is a parameter string value to be passed to Vprogram when called by a processor. Parameter strings can be surrounded by either double quotes or single quote characters and can wrap around multiple lines if needed. This example OPTIONS element provides details for COBOL compile and link steps.

IGYCRCTL ='FLAG(I,I),DYNAM,OBJECT,NOADV,NOSSR,' +     
          'APOST,TRUNC(STD),DATA(31),RENT'            
IEWL = "LIST,LET,MAP,XREF,AMODE(31),RMODE(ANY),RENT"

The CONPARMX utility allows developers to use OPTIONS, rather than working with processor groups.

More About OPTIONS

Minimally, OPTIONS are the meta-data for your CONPARMX processor steps.

You can use OPTIONS element names to establish a hierarchy of values. For example:

An OPTIONS element named DEFAULT can provide enterprise default values
An OPTIONS element name that matches a SYSTEM, can be the SYSTEM default
An OPTIONS element name that matches a TYPE or Processor Group name, can be the default for elements with that TYPE or Processor Group
An OPTIONS element name that matches a program name, overrides all the others and provides values for only that program

A SYSTEM default can provide values for all elements within an application: For Example:

ASMA90 = "RENT,TERM,XREF(SHORT),USING(MAP,WARN(13)),LIST(133)"
IGYCRCTL = 'OBJECT,APOST,AWO,DATA(24),FASTSRT,LIB,FLAG(W),'+
           'RESIDENT,LIST,RENT,TRUNC(BIN),'+
           'NODBCS,SOURCE,MAP,NOSEQ,XREF,NONUMBER,LIST,'
IEWL = 'LIST,MAP,RENT,REUS,NOLET,XREF,SIZE=(256K,64K),'

If an OPTION element does not exist at the element level, or if the element OPTION does not provide a value, then the value assigned in the SYSTEM or other defined default OPTION element will be used.

OPTIONS element locations on the Endevor map determine where they may be used. An OPTIONS element might be located in environments DEV, QA or PROD, for example. An OPTION found in DEV, will be available for Generates in the DEV environment, but not in QA or PROD. OPTIONS found in PROD are available for Generate actions everywhere. However, if one is found in both DEV and PROD, and a Generate action is performed in DEV, then the DEV version is used, instead of the one in PROD.

Your OPTIONS elements might be the meta-data that supports your CONPARMX steps but could instead, or additionally, be used to support elements in another way.

Step 2 - Extending element options with VALUECHK

Suppose that support for IBM’s Message Queuing (MQ) becomes necessary where these processor groups are defined. No CONPARMX step processes message queuing, but rather existing steps must be altered.

An Endevor Administrator would typically introduce new processor groups, while retaining the existing ones, effectively doubling the number of processor groups.

Subsequently, if IBM introduces a new compiler, and support for old and new Compilers is required, then processor groups would double in size (again).

The processor utility VALUECHK offers an alternative - extending the use of element OPTIONS elements in a new way.

Vprogram =  "Double-quoted-value"
Vprogram =  'Single-quoted-value'

attribute-name =  "quotedvalue"
attribute-name =  'quotedvalue'
attribute-name = number

The additional syntax allows OPTIONS to designate virtually any processing attribute.

The attribute-name can be anything that makes sense, and the assigned values are either quoted or numbered appropriately for the attribute. The examples below provide details for compile and link steps as processed by CONPARMX, and then specify “extended” selections for the compiler, the MQSeries, and other attributes:

IGYCRCTL ='FLAG(I,I),DYNAM,OBJECT,NOADV,NOSSR,' +     
          'APOST,TRUNC(STD),DATA(31),RENT'            
IEWL = "LIST,LET,MAP,XREF,AMODE(31),RMODE(ANY),RENT" 
* Other Element options..... (comment line) 
Compiler = "New"
TCIP = "Y"
MQSeries = "Y"
CICS-Precompile = "Y"
NCAL_Load_Module = 'Y'

Rather than creating new processor groups and modifying processors, Administrators can modify processors to support extended OPTIONS and communicate the supported OPTIONS syntax to developers. Existing processor groups can be legible names like BATCH, BATCHDB2, ONLINE, and ONLINDB2.

Developers can change OPTIONS elements in the same manner they change other elements. Many of the benefits described in the Solution Advantages section become reality.

The next session discusses the simple processor code that handles the extended OPTIONS statements.

The VALUECHK processor Utility

VALUECHK, found on GitHub, is a processor utility that has been in use at several Endevor sites since 2007. It can be used in Endevor processors to react to extended OPTIONS statements. See also the README file. VALUECHK processes simple English-like statements that specify values for attribute names. The names can be given in mixed-case characters up to 50 characters long, rendering very descriptive attributes easily recognized by Endevor users. When VALUECHK is executed within an Endevor processor, it makes the processor responsive to values assigned in extended OPTIONS.

VALUECHK expects two run-time parameters. It assumes the first parameter indicates an attribute-name, and the second indicates a possible value. OPTIONS input is searched for statements using the attribute-name. If the last specification of the attribute-name assigns a value that matches the second parameter, then VALUECHK gives a return code of 1. Otherwise, the return code is set to 0.

An IEBUPDTE (or CONWRITE) step can fetch OPTIONS elements (members) from Endevor output libraries for Type OPTIONS. IEBUPDTE gives a return code of 0 if the member is found, and a return code of 4 if not found. These are example processor steps for processing extended OPTIONS.

//*---------------------------------------------------------------     
//**  Get program specific OPTIONS for ELEMENT (If one EXISTS)  **     
//*---------------------------------------------------------------     
//GET#OPTE EXEC PGM=IEBUPDTE,COND=(4,LT),MAXRC=4                
//SYSIN    DD  *                                                       
./  REPRO NEW=PS,NAME=&C1ELEMENT                                       
//SYSUT1   DD DISP=SHR,DSN=&OPTIONS,                                   
//            MONITOR=COMPONENTS,ALLOC=LMAP                            
//SYSUT2   DD DSN=&&OPTIONE,DISP=(OLD,PASS)      
//SYSPRINT DD DUMMY                      
//*---------------------------------------------------------------     
//* Test Choice for OLD/NEW COBOL Compiler RC=1 if New               	
//COMPILER EXEC PGM=VALUECHK,PARM='Compiler New’
//STEPLIB  DD DSN=CAIEDUC.NDVR.LOADLIB,DISP=SHR    	
//OPTIONS  DD DSN=&&OPTIONE,DISP=(SHR,PASS)    
//*-----------------------------------------------------  
//* Test Choice for MQSeries RC=1 if True   ------------             	
//MQ       EXEC PGM=VALUECHK,PARM='MQSeries Y' 
//STEPLIB  DD DSN=CAIEDUC.NDVR.LOADLIB,DISP=SHR    	
//OPTIONS  DD DSN=&&OPTIONE,DISP=(SHR,PASS)      
//*-----------------------------------------------------
//* Test Choice for CICS-Precompile RC=1 if True -------               	
//CICSPREC EXEC PGM=VALUECHK,PARM='CICS-Precompile Y' 
//STEPLIB  DD DSN=CAIEDUC.NDVR.LOADLIB,DISP=SHR    	
//OPTIONS  DD DSN=&&OPTIONE,DISP=(SHR,PASS)    
//******************************************************

Each VALUECHK step executed in your processor enables an OPTIONS statement to control the processor flow. Subsequent statements in the processor leverage the VALUECHK return codes to respond to the choices made in OPTIONS statements.

//*   IF CICS-Precompile = Y then Run the COBOL CICS Translator
//CICSTRAN EXEC PGM=CONPARMX,
//            PARM=(DFHECP1$,'(&PRMCICSA)',$&&C1PRGRP(1,7),&C1PRGRP,
//                &C1ELEMENT,'(&PRMCICSZ)','Y','N'),
//            COND=(1,NE,CICSPREC),MAXRC=4

. . .

//  IF COMPILER.RC = 1 THEN
//STEPLIB  DD DISP=SHR,DSN= ......     Steplib for new compiler
//  ELSE
//STEPLIB  DD DISP=SHR,DSN= ......     Steplib for current compiler
//  ENDIF

The return code of the CICSPREC step causes the COBOL CICS Translator step to be either executed or bypassed. The COMPILER step's return code determines the STEPLIB selection for a new or current COBOL compiler. In general, values provided in the OPTIONS statements control what happens in the processor.

Include other VALUECHK steps as needed. Only simple processor changes are required when demand for future attributes becomes necessary. The proliferation of new processor groups is unnecessary.

For choosing the “New” compiler, a program element will have a same-named OPTIONS element containing this statement.

Compiler = 'New'

When the COBOL program is Generated, the processor’s COMPILER step will set the return code to 1, causing the STEPLIB for the new compiler to be selected on the COMPILE step.

Your processor and OPTIONS configuration can cause programs not accompanied by a similar OPTIONS statement to be compiled with a “current” compiler.

Example COBOL processor Compiler selection

Below is an example of a COBOL processor - to the COMPILE step. It shows the System-level OPTION being included in the search for OPTIONS statements that select the Compiler. If the COMPILER step finds multiple Compile statements within its input, the last one wins. In this case, since the concatenation ends with the element-level statements, then element OPTIONS have the final word on the choice of the Compiler.

//*******************************************************************
//**    COBOL COMPILE AND LINK-EDIT PROCESSOR
//**     with support for COBOL version 6                          **
//*******************************************************************
//GCIINBL PROC AAA=,
//     CPARMA='LIST,ADV',
//     CPARMZ='NOSSR',
//     LNGPRFX='SYSEDUC.COBOL.V6R3M0',
//     LIBPRFX='CEE',
//     LIBPRF1='&LIBPRFX',
-INC SETSTMTS    Standard processor includes
//**********************************************************************
//*   ALLOCATE TEMPORARY LISTING DATASETS                              *
//**********************************************************************
//INIT     EXEC PGM=BC1PDSIN,MAXRC=0
//C1INIT01 DD DSN=&&COBLIST,DISP=(,PASS),
//            UNIT=&WRKUNIT,SPACE=(TRK,(10,10)),
//            DCB=(RECFM=FBA,LRECL=133,BLKSIZE=0,DSORG=PS)
//C1INIT02 DD DSN=&&OPTIONS,DISP=(,PASS),
//            UNIT=&WRKUNIT,SPACE=(TRK,(1,1)),
//            DCB=(RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS)
//C1INIT03 DD DSN=&&OPTIONE,DISP=(,PASS),
//            UNIT=&WRKUNIT,SPACE=(TRK,(1,1)),
//            DCB=(RECFM=FB,LRECL=80,BLKSIZE=0,DSORG=PS)
//*---------------------------------------------------------------     
//**  Get System OPTIONS ELEMENT                                **     
//*---------------------------------------------------------------     
//GET#OPTS EXEC PGM=IEBUPDTE,COND=(4,LT),MAXRC=4                
//SYSIN    DD  *                                                       
./  REPRO NEW=PS,NAME=&C1SY                                       
//SYSUT1   DD DISP=SHR,DSN=&OPTIONS,        <SOL libs for OPTIONS
//            MONITOR=COMPONENTS,ALLOC=LMAP                                         
//SYSUT2   DD DSN=&&OPTIONS,DISP=(OLD,PASS)      
//SYSPRINT DD DUMMY                                        
//*---------------------------------------------------------------
//**  Get program specific OPTIONS for ELEMENT (IF one EXISTS)  **
//*---------------------------------------------------------------
//GET#OPTE EXEC PGM=IEBUPDTE,COND=(4,LT),MAXRC=4
//SYSPRINT DD DUMMY
//SYSIN    DD  *
./  REPRO NEW=PS,NAME=&C1ELEMENT
//SYSUT1   DD DISP=SHR,DSN=&OPTIONS,        <SOL libs for OPTIONS
//            MONITOR=COMPONENTS,ALLOC=LMAP
//SYSUT2   DD DSN=&&OPTIONE,DISP=(OLD,PASS)
//*---------------------------------------------------------------------
//* TEST FOR LATEST COBOL COMPILER RC=1 IF TRUE
//*-------------------------------------------------------------------
//COMPILER EXEC PGM=VALUECHK,PARM='Compiler New'
//STEPLIB  DD DSN=CAIEDUC.NDVR.V150S0A.SMPLPROD.LOADLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//OPTIONS  DD DSN=&&OPTIONS,DISP=(SHR,PASS)  
//         DD DSN=&&OPTIONE,DISP=(SHR,PASS)   <Last 1 overrides others
//*********************************************************************
//* READ SOURCE AND EXPAND INCLUDES
//*********************************************************************
//CONWRITE EXEC PGM=CONWRITE,COND=(4,LT),MAXRC=0,
// PARM='EXPINCL(&EXPINC)'
//ELMOUT   DD DSN=&&ELMOUT,DISP=(,PASS),
//            UNIT=&WRKUNIT,SPACE=(TRK,(100,100),RLSE),
//            DCB=(RECFM=FB,LRECL=80,BLKSIZE=0),
//            MONITOR=&MONITOR
//*******************************************************************
//**    COMPILE THE ELEMENT                                        **
//*******************************************************************
//COMPILE  EXEC PGM=CONPARMX,COND=(4,LT),MAXRC=4,ALTID=N,
//             PARM=(IGYCRCTL,'(&CPARMA)','$$$$DFLT','&C1PRGRP',
//             '&C1ELEMENT','(&CPARMZ)','&CONCAT','N')
//PARMSDEF DD  DSN=&OPTIONS,
//             DISP=SHR,ALLOC=LMAP
//*-- Based on the return code of the Compiler step,
//*--       use the appropriate Compiler STEPLIB (and other libs)
//    IF (COMPILER.RUN AND COMPILER.RC=1) THEN
//STEPLIB  DD  DISP=SHR,DSN=SYSEDUC.COBOL.V6R3M0.SIGYCOMP  Cobol 6
//         DD  DISP=SHR,DSN=CEE.SCEERUN
//         DD  DISP=SHR,DSN=CEE.SCEERUN2
//    ELSE            
//STEPLIB  DD  DSN=&CLECOMP,DISP=SHR
//         DD  DSN=&CLERUN,DISP=SHR
//    ENDIF
//*--------
//    IF (COMPILER.RUN AND COMPILER.RC=1) THEN
//SYSUT8   DD  UNIT=&WRKUNIT,SPACE=(CYL,(1,1))     New compiler files
//SYSUT9   DD  UNIT=&WRKUNIT,SPACE=(CYL,(1,1))
//SYSUT10  DD  UNIT=&WRKUNIT,SPACE=(CYL,(1,1))
//SYSUT11  DD  UNIT=&WRKUNIT,SPACE=(CYL,(1,1))
//SYSUT12  DD  UNIT=&WRKUNIT,SPACE=(CYL,(1,1))
//SYSUT13  DD  UNIT=&WRKUNIT,SPACE=(CYL,(1,1))
//SYSUT14  DD  UNIT=&WRKUNIT,SPACE=(CYL,(1,1))
//SYSUT15  DD  UNIT=&WRKUNIT,SPACE=(CYL,(1,1))
//SYSMDECK DD  UNIT=&WRKUNIT,SPACE=(CYL,(1,1))
//    ENDIF
//*******************************************************************
//*     COPYLIB CONCATENATIONS                                     **
//*******************************************************************
//SYSLIB   DD DSN=&&NULLSYS,
//            DISP=(NEW,DELETE,DELETE),
//            UNIT=SYSDA,
//            SPACE=(TRK,(1,1,1),RLSE),
//            DSORG=PO,RECFM=FB,LRECL=80
//         DD  DSN=&PROJECT..&NODE..&C1SU..COPY,
//             MONITOR=&MONITOR,ALLOC=(LMAP,COND),
//             DISP=SHR
//         DD  DSN=&CSYSLIB1,
//             MONITOR=&MONITOR,ALLOC=LMAP,
//             DISP=SHR
//SYSIN    DD  DSN=&&ELMOUT,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

. . .

Solution Advantages

OPTIONS are Endevor elements that can surpass the processing diversity frequently given to processor groups. The full use of OPTIONS elements has these advantages:

OPTIONS are simple English-like statements that are quickly recognizable. Names can be fully descriptive, using mixed-case characters up to 50 characters long
You can support as many attributes as you need. There is no need to fit them into an 8-byte name (like a processor group). New attributes can be easily and safely introduced, despite how many are already in-use
OPTIONS are given change levels with each change. You can review and return to any older level. (When a processor group is changed for an element, there is no audit trail)
OPTIONS can be tagged with a CCID, Approved in a package, and be backed-out or in
Ownership is flexible. Administrators always own processor groups. OPTIONS can be owned by Administrators or Application teams or shared – Administrator’s choice. When ownership is shared, developers can frequently help themselves without involving Endevor administrators
Administrators may elect to become Approvers for OPTIONS and/or to engage an OPTIONS Processor and Processor tool for syntax and compliance checking
Processor group names can be normalized.

If you would like to learn more about using OPTIONS to make your processors responsive, please post a comment or reach out to joseph.walther@broadcom.com.

0 comments

15 views

Endevor