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
------------------------------
Original Message:
Sent: 11-07-2019 02:46 AM
From: Aneesh Y G
Subject: Endevor | COBOL | Element specific Override Parm handling
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.
I am feeling complexity in handling the Element specific Override parms.
(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