Define a seasonal stage in defaults table?

[Mathew Goldstein]

One of our migrations paths to production contains a pre-production stage that we need only part of the year. We require promotion packages to move to and from that pre-production stage. Instead of retaining that stage all year round, I am considering adding the stage to the defaults seasonally, when it is needed, then commenting it out from the defaults table. To make the addition and removal of the stage visible to the users we can define this seasonal pre-production stage to a single stage environment. Does anyone do this? Assuming that we can assure the stage will have no elements when it is removed, will this work?

------------------------------
[FirstName]
------------------------------

[Joseph Stein]

Hi Matthew,

Sounds like dynamic environments is perfect for you.

You need to make some initial definitions in C1DEFLTS to enable the definitions.

After that you can delete and define the seasonal environments as needed without any modification to C1DEFLTS.

You might also want to enable deferred allocation of Endevor related files which will allocate only those data sets when they are needed and you can conveniently delete them along with the environment.

Joseph

[Eoin OCleirigh]

I like the idea of using dynamic environments, but can a dynamic environment be "inserted" into the regular path?
It might be that you'd have to convert all environments to dynamic...

I feel a simpler approach would be to simply define two C1DEFLxx tables and switch between them (seasonally perhaps) but controlled by ENUXSITE - you could even using the sample provided with Endevor and the special EN$DFTxx DDs to switch easily between long/short map.
My biggest concern would be around making sure your "pre-Prod" environment was completely empty before switching, so that you don't leave the element catalog with entries pointing at a "missing" environment.  But potentially having the 'choice' of map through multiple defaults would make it easy to swatch to the long map, and resolve the 'orphaned' elements (promote or delete), and then carry on.
Don't forget to review your security and possibly shipping rules to support the "sometimes there" environment.
Either way sounds fun and so, while no, I haven't done this for "realsies" yet,  I think it should work and we'd all like to hear back how it goes.

Cheers,
Eoin 

------------------------------
Eoin O'Cleirigh
Lead Systems Engineer @ ANZ [phone]
------------------------------

[Mathew Goldstein]

I think the primary complication will be the automated administrative JCL that references the here today - gone tomorrow environment. For example, the backup JCL. So we may want to retain the environment definition in the defaults table year around and only remove it from the migration path. We can then also either change the ESI profile for the environment to make the environment invisible to users when it is hibernating or change the environment description to indicate when the environment is hibernating and when it is active.

------------------------------
[FirstName]
------------------------------

[Steve Blackett]

Our shop has the type of setup in one of our Endevor instances you describe. It's a production path viewable by the release team only and has what I'd imagine are similar challenges. We're on a route to standardise this to having permanent environments defined within the standard default configuration. However whilst attempting to see what could be done, there is the option of having two plus sets of defaults pointing at different maps and Endevor has a way of moving between these very easily now (without the logon proc/steplib changes). The names must be different but it could suit your requirement as you move forwards and backwards.

As I recall I didn't need to place an ENUXSITE to enable this processing. There is a default REXX supplied by Broadcom to allow this realtime change.

------------------------------
Mainframe DevOps
HSBC
United Kingdom
------------------------------

[Eoin OCleirigh]

I suspect as you work though those changes there might not be as much to do as you think.
Leaving the environment "defined" but empty, and/or "disconnected" from the map would sill allow UNLOAD ENV xxx or even '*'
DFDSS Dump syntax can just have wild cards  - it'll back up stuff that matches and ignore anything that just misses the wild patterns.

Processors that do any sort of back-copy or back-bind might be more fun!  I'd consider adding a SYMBOL that you can set seasonally (or refer to in your alt defaults) that you can use in your processors to assist with this logic so that they can also adjust to the 'variable path'.

------------------------------
Eoin O'Cleirigh
Lead Systems Engineer @ ANZ [phone]
------------------------------

[John Scott]

Hello Matthew,

Another option could be available if you are using external security interface (ESI) that is ACF2, Top Secret, or RACF.

In this case you switch on and off the users visibility of the environment via a PERMIT security command for the environment.

This command can be issued manually or automated / scheduled so it is issued seasonally making the environment disappear / reappear without needing any housekeeping changes.

On the other option mentioned using dynamic environments, we find these useful for 'on demand' parallel development along with deferred file create and this is automated including clear down using Endevor processors).

Setting up Self Service Parallel Development with Endevor Dynamic Environments - YouTube

We offer this on demand for parallel development and it can be triggered by zowe in a devops pipeline.

[Eoin OCleirigh]

Hi John,

Certainly ESI can be used to 'hide' and/or deny access to an Environment (almost dynamically) - but if that Environment were on the map (users would still need access) even if it's not "visible".  The point is not being able to see an Environment does not change the map, you'd still have to promote through it - you'd have to have a separate C!DEFLTS table to have the Seasonal/non-Seasonal map.  If you had two (or more defaults and were switching using using ENUXSITE - I'd recommend that the season that does not have it mid-map, still lists the Environment but as a child only (to allow view/recovery of any orphaned elements, and for admins to carry on maintenance of Inventory information (types, processor groups etc.).
Regards,
Eoin

For more information on Enuxsite and dynamically switching see the ENUXSITE section at https://techdocs.broadcom.com/us/en/ca-mainframe-software/devops/ca-endevor-software-change-manager/19-0/reference/api-and-user-exits-reference/exits-reference.html

------------------------------
Eoin O'Cleirigh
Lead Systems Engineer @ ANZ [phone]
------------------------------

[John Scott]

Yes Eoin you are right, you should not remove access to the environment is users still need to use it. If you have only one defined route to live with this environment on that route-to-live the first thing to do is provide one or more parallel routes and this will involve an update to the defaults table. You may define them manually (usable with ENUXSITE) or use Dynamic Environments - you could even use both ! Ask the users what they need from the lifecycle, automate the set up and make it flexible and repeatable.  

[Mathew Goldstein]

The libraries remain in place and the preproduction testing configuration could continue to concatenate those empty libraries. I am inclined to switch between stand-alone. and next to last environment in a migration path, configuration either by maintaining two copies of the defaults table and swapping which one is active or by updating one copy of defaults table that is always active. I can imagine coding conditionals using variable values (maybe defined in the PARMLIB?) in the tables so that the tables are more dynamic, but such additional capabilities adds complexity that can be costly.

------------------------------
[FirstName]
------------------------------