ALLOC=LMAP and &C1STAGE2 not working

[Mathew Goldstein]

When I write processor code like this:

DSN=&#HLQ..&C1STAGE2..&C1SYSTEM..MACRO.BASE,  DISP=SHR,ALLOC=LMAP,                                

it keeps repeating the same stage name (the name of the second stage of the current environment) over and over again.  If I replace the &C1STAGE2 with a &C1STAGE then it works properly, changing the stage name to correspond with the stage names of the map.  Is this a feature or a bug?  Do we have to hardcode every DD for those DD that reference libraries starting in the second stage of a two stage environment?  Could LMAP be updated to accept the second stage symbolics?  LMAP is a good feature but we will not be able to utilize it if it will not work with the second stage symbolics because we specify subsystem libraries at the entry stage and system libraries at all subsequent stages for our input components.

[Josef Thaler]

Hi Mathew,

 

your &C1STAGE2 is probably understood as an "other symbol". See the snippet out of Endevor's doc below.

 

Just an idea to address your need (without knowing your patricular processors): you could create an empty, unused system-oriented library for the first stage, use LMAP for all these libs, preceded by a conditional (//IF //ENDIF) concatenation of the subsystem-lib. Maybe this helps. 

[Mathew Goldstein]

It also occurred to me that we could allocate forever empty input component libraries for the entry stage and that is what I did.  I am not happy with this, however, it is a kludge.

[Karen Turner]

Hi Mathew,

You mentioned in your original post

"Do we have to hardcode every DD for those DD that reference libraries starting in the second stage of a two stage environment?",

What is you scenario that you need to start at the second stage and not the current stage? LMAP and PMAP are designed to build the mp from the current location (env, stage, sys, sub, type) and build the concatantion based on mapping from there.  If you explain your process/need/goal, prehaps we can be of more help.

Karen

[Mathew Goldstein]

The library name in the entry stage is different from the corresponding library name subsequent stages as explained in the original post.  To reiterate, for the input component program elements (such as COPYBOOK), we have separate libraries for each subsystem in the entry stage that includes the subsystem name as a library name qualifier.  We also support sandbox subsystems in our entry stage.  But in the subsequent stages there is a single library for each system (so we drop the subsystem name from the library name).  This allows developers to initially modify common input components in the entry stage without potentially negatively impacting all of the other applications currently under development by other developers in the same ENDEVOR system. When the developer subsequently moves their input component to the next (integration) stage the input component becomes common to all of the applications in the system so that developers can expand their impact testing.  How do we code the processors using ALLOC=LMAP (such as in our type COBOL generate processor) for the input concatenation. starting at the second stage where the library name changed, when we cannot utilize the &C1STAGE2 symbolic?

[Josef Thaler]

Hi Mathew, just another consideration (unfortunately it's not another solution): In my understanding, the intention of ALLOC=PMAP is, that the processors can be used in more than one stage. If you use the processor in the "higher" stages, how would you like to have &C1STAGE2 resolved ? Also again "skipping" one stage?

Kind regards, Josef

[Mathew Goldstein]

I think PMAP should work the same as it does now.  How does PMAP work now in the higher stages?  I never utilize PMAP.  I assume it traverses the environment configurations in the defaults table starting from the current stage, similar to LMAP except it never skips any stages.  So here it would do the same, starting from the second (or first) stage of the current environment instead of starting from the current stage.

[Josef Thaler]

[sorry, slip:] I meant ALLOC=LMAP in my post ...

[Karen Turner]

Hi Mathew,

Thanks for the  explanation, I understand your issue better now.  Depending on how many systems you have would it be a huge imposition to allocate a 1 trk pds for stage.system.copylib in the lower stage(s)?  It does not have to be identified to a type under endevor anywhere, just an empty place holder to use in the processor in order to LMAP to the stage.system.copylibs in the higher stages.  I don't remember how well (or if) Endevor processors handle alias datasets, or if they would work with LMAP, but a single physical dataset can have multiple alias datasets, maybe you can get away with allocating a single stage.copylib for the lower stage and then set up alias names pointing to it for the required number of stage.system.copylibs you may need. You can then refer to the HLQ..&c1st..&c1sy..COPYLIB alias name in the processor. Obviously you would want to test with a small sample.  Just some random ideas.

 

 

Karen

Karen Turner

Technical Support Sr. Specialist

Endevor Support

Software Code Mangement Team

860-902-3064 (IP phone)

508-399-5366 (home)

508-837-0606 (cell)

[Mathew Goldstein]

We duplicate our entire input concatenations, once for the entry stage to reference the library that uniquely includes the subsystem name followed by the usual system only library name with ALLOC=LMAP, and again for all the other stages that references the single system only library name with ALLOC=LMAP.  This requires allocating an always empty, single track entry stage, system only libraries for each of our systems, as has been suggested.   This works, and it is an improvement over not utilizing ALLOC=LMAP for us, so this is what we will do, but it does reduce the overall advantage of ALLOC=LMAP some.

 

We currently utilize an alias for contexts where we want logical partitions on a different sysplex to reference different libraries (we have development and production sysplexes that each consist of multiple partitions).  To eliminate the duplicate input concatenation we would need an alias for each stage except for the final stage.  An entry stage alias by itself would eliminate a single DD from our processors while still requiring duplicate input concatenations.  So the cost/benefit ratio of relying on an alias appears to me to be unfavorable in this context, particularly since our ENDEVOR administrators are not themselves authorized to create an alias.  If the situation were reversed so that we always referenced a subsystem only library with ALLOC=LMAP but needed to reference a system only library for the final stage, then every final stage subsystem library could be an alias for the corresponding system library.  But that reverse context is probably very rare while our context of having subsystem libraries only in the entry stage is likely to be far more common.