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.
Original Message:
Sent: Mar 22, 2023 05:29 PM
From: Mathew Goldstein
Subject: Define a seasonal stage in defaults table?
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]
Original Message:
Sent: Mar 22, 2023 05:13 PM
From: Eoin OCleirigh
Subject: Define a seasonal stage in defaults table?
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 +64273888404
Original Message:
Sent: Mar 22, 2023 03:31 AM
From: Joseph Stein
Subject: Define a seasonal stage in defaults table?
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
Original Message:
Sent: Mar 21, 2023 10:03 PM
From: Mathew Goldstein
Subject: Define a seasonal stage in defaults table?
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]
------------------------------