Endevor | COBOL | Element specific Override Parm handling

[ANEESH]

Hi All,

 

We are currently running with the Cobol V6.2 and Endevor v17 and are in a process of externalizing the parms for the Compiler and Linkedit steps.

 

Handling the Element specific Override parms looks to be the tricky one.

(moreover, usage of PROCESS/CBL statements are restricted.)

 

I have gone through the CONPARMX utility document to understand its approach.

However, stuck to find out the best possible method in handling and maintaining the Element specific parms.

 

Is it good to allow developers create and maintain it through endevor by storing it under a Type(say ELMPARM) ?

 

Is it required to allow EMLPARM element be available at every endevor stage along with its cobol program? If yes, how can we handle it in the cobol generate processor ?

 

Or

is it enough to maintain it in an admin environment away from the standard SDLC path(DEV to PROD).

 

another Concern would be during Parallel development and package migration, where 2 or more developers are working on the same program and ELMPARM is conflicting them.

 

Is there any other better approach that we can try out.?

can someone shed some light on this please ?

 

Thanks in Advance !

Regards,
Aneesh

[Eoin OCleirigh]

Hi Aneesh,

Yes, using CONPARMX and allowing your developers to maintain a member that is in CONPARMX's search concatenation is best practice.  Most sites that use this refer to the special type as OPTIONS, but ELMPARM would be fine too.  Allowing the programmer to maintain it, for those special case programs, and even promote it along with the element it supplies the non-standard options for, allows the normal approval/promotion process to work "as expected", even for parallel/sandboxed use cases.  Sometimes the overrides are temporary, for debugging or exploratory purposes and they are never promoted, which might be fine too. 

Another common approach is to use the processor group name to be in the search concatenation, so that you might end up with a concatenation of SITE, PROCESSOR_GROUP, and ELEMENT - that way the actual processor group is limited to adding a name and appropriate description, without having to code per stage symbols, and it's NAME is the key to pointing to the special options.

I am sure that many others will ring in with their support or improved suggestions, but it sounds like you are already on the right track.

------------------------------
Sr Principal Software Engineer
------------------------------

[Lorenzo Duca]

Hi ANEESH,
another simple solution may by not to restrict all CBL statement in source element.
Specific Compiler Option imbedded in source program moves in map with the element itself, and may by merged in conflict between different parallel versions in the same way of source code.
Specific parameter that you don't want to be used, (e.g. NORENT, DATA(24), and so on) may be checked in generate processor with a custom step before (or after) compiler execution, and check may by not equal in different stage: for example entry-stage may permit TEST/DEBUG Option, but non in last compiling stage where load module are built for Production;
this is the same check you should implement if you use separate type (e.g. ELMPARM) in order to avoid Option nout suitable for your run-time context.  

I hope this could help.

Best regards,
Lorenzo

------------------------------
System Analyst
Intesa Sanpaolo S.p.A.
------------------------------

[Mathew Goldstein]

We scan the COBOL source code for particular COBOL compiler options that we want to standardize and control via ESCM only (including OPT and TEST) and fail the generate action whenever those particular options are coded in the source code. IMO, processor group level CONPARMX, with the ESCM administrators managing them in their own ESCM system, will almost always be better than processor group symbolic overrides. If program element level CONPARMX results in fewer processor group definitions then that may also be worthwhile, that is more of a business context based decision. We have a symbolic value conditional to enable production compiles with TEST because, albeit rarely, the production compiled execution fails while the pre-production compiled execution was successful.

[ANEESH]

Thank you all for sharing your thoughts and ideas.