Streamlining Promotion Site Renames and History Management with ASC
Problem statement
Assume you have to rename a promotion site named 'SFO' to a new one named 'BRU'. The easy part is to perform A.A.7 updates in all applications to rename the promotion site from 'SFO' to 'BRU'. Standard ChangeMan ZMF does not have a function to facilitate such a rename, so it would actually have to be done by first inserting the A.A.7 data for the new promotion site (BRU), and then deleting the A.A.7 data for the old promotion site (SFO). This process would need to be repeated for each of your (possibly hundreds of) ChangeMan ZMF applications.
However, after completing this rename, the actual promotion history for each package will still exist (and not be deleted) in CMNPMAST. But there would be no more way to perform a ChangeMan ZMF query of the promotion history for packages that were promoted to the SFO promotion site before the rename, simply because you can no longer select the SFO promotion site during such a query.
To still be able to query such historical promotion history for the (no longer used) SFO promotion site, the typical workaround is to NOT delete the SFO-related data in A.A.7 (combined with blocking access to request promotes to the obsolete SFO promotion site).
Challenges
Challenge 1: RENAME the SFO promotion site to BRU in all A.A.7 defs of all ChangeMan ZMF applications.
Challenge 2: Make sure it is possible to query the old promo history, though only by selecting the NEW (corresponding) name for such promotion site (i.e. BRU).
Solution (for Challenge 1):
Use AbitMORE SCM Commander (ASC)‘s basket processing like so:
Use ASC to build a basket of all application IDs to be processed.
Use ASC to process the basket produced in step 1 to build a new basket containing all existing A.A.7 data for the old promotion site SFO.
Use ISPF to edit the basket produced in step 2 and perform a mass change, replacing any "SFO" string with a "BRU" string.
Use ASC to process the edited basket produced in step 3 and insert the new A.A.7 data for the new site BRU.
Use ASC to process the basket produced in step 2 and delete all existing A.A.7 data for the old promotion site BRU.
Notes:
Apart from completing this challenge 1 in just about 15 minutes, an additional huge advantage is that you reduce the risk of making typos. Especially if you have to do this manually for dozens or hundreds of application IDs, which would typically take hours, if not days.
If for whatever reason you want to perform a rollback, just ASC again for deleting the new A.A.7 data for BRU again (using the basket produced in step 3) combined with inserting the old A.A.7 data for SFO again (using the basket produced in step 2).
Solution (for Challenge 2):
Use AbitMORE SCM Commander (ASC)‘s basket processing like so:
Create an ASC basket containing all existing package promotion history for promotion site SFO.
Create an ASC basket containing all existing component promotion history for promotion site SFO.
Use the basket created in step 1 (after editing to change all SFO to BRU) to create the package promotion history for promotion site BRU.
Use the basket created in step 2 (after editing to change all SFO to BRU) to create the component promotion history for promotion site BRU.
Use the basket created in step 2 (but without any editing) to delete the existing component promotion history for promotion site SFO.
Use the basket created in step 1 (but without any editing) to delete the existing package promotion history for promotion site SFO.
Note: when using ASC to perform complete a challenge like this one, a best practice is to do so using a single package (in an experimental ChangeMan ZMF subsystem. After it all works as desired, it’s a straight forward (easy) step to transform such single package prototype to a basket of (potentially hundreds!) of packages.
Demo (for a single change package)
Initial situation (before starting Challenge 1 and 2):
ABM - Promotion Site List Row 1 to 2 of 2
Command ===> Scroll ===> CSR
Package: ABM 000004 Status: DEV Install date: 20241031
Demote reqd ------------- Last promotion details --------------
Site prior sites Type Promotion lvl Date Time User
BRU NO 0
SFO NO Full Promote 20 INTG 2024/03/01 14:38 ABM3143
******************************* Bottom of data ********************************
Final situation (after completing Challenge 1 and 2)
ABM - Promotion Site List Row 1 to 2 of 2
Command ===> Scroll ===> CSR
Package: ABM 000004 Status: DEV Install date: 20241031
Demote reqd ------------- Last promotion details --------------
Site prior sites Type Promotion lvl Date Time User
BRU NO Full Promote 30 QA 2024/03/01 14:38 ABM3143
SFO NO 0
******************************* Bottom of data ********************************
Even though the above screens only show the package level promotion history, its RELATED component level promotion history was processed in a similar way. So it worked like a charm!
But note the additional challenge we encountered (and resolved): in site BRU, there is only promotion level '30 / QA,' so we also had to update the promotion level from '20 / INTG' to '30 / QA.'
The above applies to only one package, for which we've saved the executed XML services in six separate JCLs. In these JCLs, only the package ID and promotion site names vary, making it a repeatable process. Here is the list of JCL components (execution sequence = as shown in the list below):
VIEW ABITMORE.R.ASC.JCL Row 0000001 of 0000006
Command ===> Scroll ===> CSR
Name Prompt Size Created Changed ID
_________ J1PHPLST 167 2024/07/25 2024/07/26 13:42:34 ABM3143
_________ J2PHCLST 166 2024/07/25 2024/07/26 13:42:52 ABM3143
_________ J3PHPCRE 120 2024/07/25 2024/07/26 13:43:15 ABM3143
_________ J4PHCCRE 120 2024/07/25 2024/07/26 13:43:31 ABM3143
_________ J5PHCDEL 173 2024/07/25 2024/07/26 13:43:38 ABM3143
_________ J6PHPDEL 174 2024/07/25 2024/07/26 13:43:43 ABM3143
**End**
Some more details about the content of each of those 6 JCLs:
J1PHPLST: Create an ASC basket (=LIST) of all existing package promotion history (for promotion site SFO) for package ABM 000004.
J2PHCLST: Create an ASC basket (=LIST) of all existing component promotion history (for promotion site SFO) for package ABM 000004.
J3PHPCRE: Use the basket created by job J1PHPLST (after editing to change all SFO to BRU) to create the package promotion history (of package ABM 000004 for promotion site BRU).
J4PHCCRE: Use the basket created by job J2PHCLST (after editing to change all SFO to BRU) to create the component promotion history (of package ABM 000004 for promotion site BRU).
J5PHCDEL: Use the basket created by job J2PHCLST (but without any editing) to delete the existing component promotion history (of package ABM 000004 for promotion site SFO).
J6PHPDEL: Use the basket created by job J1PHPLST (but without any editing) to delete the existing package promotion history (of package ABM 000004 for promotion site SFO).
It’d be a straightforward (minor) improvement to do this with a basket of packages in just one shot, by only modifying J1PHPLST and J2PHCLST. Depending on what you include in your basket (and if you have sufficient CPU resources available), you could complete everything in just one run of those six jobs. However, it appears that running one job per application ID is the best compromise.
For those who want (not just Abit…) MORE
This prototype has huge potential (= variations of the above challenges) if you want to either fix some promotion history, or reduce the size of CMNPMAST. Here is an example: what is the purpose of keeping the promotion history for all those requests that either failed or were submitted a few days, weeks, months, or years ago? This is another use case where ASC excels: reducing the size of your CMNPMAST control files by permanently purging promotion history records that are likely no longer of interest.
