Part 3 Change Deployment
Performing Change DeploymentLink copied to clipboard
This chapter describes how the software level (fixes and maintenances) of a cloned environment can be synchronized with the software level of an SMP/E managed base environment using the ICE Change Deployment facility.
A cloned environment can be either SMP/E managed or non-SMP/E managed.
When a cloned environment is non-SMP/E managed, ICE creates a Deployment Package on the base environment. The package contains all the changes (fixes and maintenances) that have been applied to the base environment since its installation. ICE automatically deploys the contents of the package to the cloned environment.
For more information, see Change Deployment to a non-SMP/E managed clone environment
When a cloned environment is SMP/E managed, ICE compares the SMP/E CSI Target Zones of the base and cloned environments. The comparison report contains all the differences between the SMP/E CSI Target Zones of the base and cloned environments. Using the report a user can apply the missing fixes to the cloned environment to bring its software level up to the level of the base environment.
For more information, see Change Deployment to a SMP/E managed clone environment
Change Deployment to a non-SMP/E managed clone environmentLink copied to clipboard
This section describes how changes (for example, fixes and maintenances) in an SMP/E managed base IOA environment can be easily and reliably transferred to a cloned non-SMP/E managed IOA environment.
The changes can include
-
ad hoc PTFs applied to the base IOA environment
-
one or more maintenances applied to the base IOA environment
The tool enables you to move all changed elements from the base IOA environment to bring the cloned IOA environment to the same level as the base IOA environment.
The change deployment procedure, which transfers the new elements from the base environment to the cloned environment, consists of the following stages:
-
An ICE-managed process at the base (source) IOA environment builds a change deployment package that consists of the SMP/E managed data sets. A DFDSS job is used to build the package.
-
If necessary, the user manually copies the change deployment package from base (source) environment to the cloned (target) environment.
-
An ICE-managed process at the cloned (target) IOA environment extracts and deploys the change deployment package. Only changed elements are deployed.
For more information, see
RequirementsLink copied to clipboard
-
Change Deployment to a non-SMP/E managed clone environment is based on DFDSS. FDR is not supported.
-
The TSO user who performs a change deployment procedure must have SUPERUSER authority for zUNIX files (UID 0 or READ access to FACILITY BPX.SUPERUSER files).
-
Before performing a change deployment procedure, make sure that your system meets the following requirements:
-
The maintenance level and the level of the ad hoc PTFs of the cloned environment must be lower than the base environment.
-
The space requirements for the maintainable data sets in the cloned environment are identical to their requirements in the base environment. For example, if a maintainable data set was reallocated in the maintenance process, it must be similarly reallocted during the deployment process.
-
New products or NLS installed on the base environment are not deployed to the cloned IOA. In such cases, the Change Deployment process is not supported.
-
Newer versions of the User Exit source samples introduced by the upgrade and deployed to the clone cannot be adjusted and installed using ICE of the non-SMP/E cloned environment in the same way as in the base environment. If such changes are required, they should be implemented in the base environment and then deployed to the cloned environment.
Building the change deployment packageLink copied to clipboard
-
Open ICE from the base environment.
-
Select Clone, Deploy IOA Environment.
-
From the IOA Cloning and Changes Deployment panel, select Deploy Changes.
-
Select Deploy fixes and maintenances to cloned non-SMP/E environment.
-
Enter Y in the message panel to proceed with the deployment package building process.
-
Press Enter.
A window opens displaying the deployment package data set name.
The data set name has the following format: ilprefa.Dmmddsss ; where: mm = month (from 01 to 12), dd = day of month (from 01 to 31); sss = are the first three digits of the 5-digit number of seconds since 12:00 midnight (from 000 to 863). The prefix "D" indicates "deployment package." For example, IOA.V900D.D0322401.
-
Choose one of following options:
-
Y - Yes, submit the job automatically.
-
The deployment process continues automatically. Continue with step 8.
-
-
N - No, stop the deployment process.
-
The deployment process stops.
-
-
E - Edit the IOAFJCDP job.
-
The IOAFJCDP job opens so that you can edit it. After you have made the required changes, submit the IOAFJCDP job to create the deployment package file. Continue with step 8.
-
-
-
The IOAFJCDP job invokes the standard IBM DFDSS utility to pack all the changed files in the IOA source environment into the deployment package file. The maximum return code for successfully running IOAFJCDP is 4.
-
If the cloned (target) environment is on a separate system from the base (source) environment, copy the deployment package file to the target system.
Deploying the package at the cloned siteLink copied to clipboard
Describes how to deploy the change package from the cloned environment.
-
Open ICE from the clone environment.
-
Select Clone, Deploy IOA Environment. The Major Steps Selection panel opens.
For more information, see
Step 1 – Change Deployment - Preparations
In the table of contents below, headings (that start with the word "Step") correspond to minor steps in deployment preparations.
Step 1.1 – Start New Change Deployment Cycle
This step initiates a new Change Deployment cycle.
If the previous deployment cycle has not yet been completed, a message is displayed. You must first complete the previous cycle or restore the IOA environment from a backup before you can start a new deployment cycle.
All log and status information from the previous cycle is deleted.
Step 1.2 – Back Up Your INCONTROL System
You must back up your INCONTROL system before continuing with the Change Deployment.
The backup generated by this step only contains the INCONTROL system files. User data libraries are not included.
-
Select Minor Step 2, Backup your INCONTROL system.
-
Submit the appropriate job using one of the following options:
-
Run a DFDSS job that creates a logical backup of the INCONTROL system files to a dataset on DASD. The name of the backup dataset is written to the job log in ICE. After the job has been completed the DFDSS input deck used for the backup can be found in ilprefa.INSTWORK(IOACDBKP).
In addition to the backup, a Fallback job named MNTJREST is also created in the INSTWORK library.
-
If you do not have DFDSS, select the second option: Run a job that creates a list of all the datasets that need to be backed up. After running this job, the list of datasets that require backup is located in ilprefa.INSTWORK(IOACDBKL). Use this list as input for your backup utility of choice in order to back up the IOA environment.
In addition to the above list, a Fallback job MNTJREST is also created in the INSTWORK library. This job must be customized before it can be submitted. Follow the instructions in the RSTBKP step in the job to adjust the job before submitting it.
-
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 1.3 – Analyze the Deployment Package
This step extracts and analyzes the Deployment Package.
To proceed with this step you are asked to provide the Deployment Package name. In addition, allocation attributes and SMS-related options for the temporary extracted data sets are needed to perform this step.
Step 1.4 – View APAR List
This step displays the list of all APARs that will be installed during this Change Deployment cycle.
Step 1.5 – View Deployed Members List
This step displays the list of all members that will be deployed during this Change Deployment cycle. Members deployed to the GENERAL library are further propagated by ICE to their appropriate non-SMP/E managed target libraries in Step 2.7 – Propagate Members to Environment Libraries.
Step 1.6 – Select Change Deployment Mode and Method
In this step you select the Change Deployment method and mode you wish to use to perform the Change Deployment process:
-
The Simplified method is suitable for minor changes if the target data sets have enough free space and do NOT require enlargement. Otherwise, if the Simplified method is selected and target data sets that must be enlarged are in use, a full shutdown of all INCONTROL address spaces might be required in order to enlarge these data sets.
-
The Enhanced method allows for minimizing the outage of monitors by switching INCONTROL address spaces and jobs to mirror data sets and automatically enlarge the target primary data sets if they don't have enough free space. The switching of monitors from primary libraries to the mirror ones and back is performed by restarting the monitors one by one.
The Simplified method is suitable in the following cases:
-
For "sandbox" IOA environments - environments that have no active INCONTROL components.
-
For IOA environments that can tolerate full shutdown of all INCONTROL products for manual enlargement of the IOA environment data sets (if required).
-
If the list of new and updated members from the previous step contains only members from data sets that are not in use by monitors, for example, SAMPLE, SAMPEXIT, or INSTxxx data sets. These and similar data sets can be manually enlarged if required without impacting any running INCONTROL products.
In other cases the Enhanced deployment method is preferable.
In this step you also select the deployment mode. In TEST mode you can review the changes that are to be deployed in PROD mode. Expected free space requirements in the target primary data sets can also be evaluated in advance in TEST mode.
Step 2 – Change Deployment
In the table of contents below, headings (that start with the word "Step") correspond to minor steps in the deployment procedure.
Step 2.1 – Create Mirror Libraries
This step creates a set of mirror libraries from the primary libraries. These mirror libraries are used by the products during the deployment process when the primary libraries are updated and enlarged (if required).
-
Select Minor Step 1, Create Mirror Libraries.
-
If necessary, use the 'A' command to adjust additional settings:
-
On the Long Parameter Data Entry screen, you can set or change the mirror libraries prefixes.
-
On the Allocation Attributes Entry screen, you can set or change the DASD/SMS allocation attributes from those used during the previous time that this step was run.
-
All parameters in the Long Parameter Data Entry screen are mandatory. Specify values for all parameters and fix any errors in the prefix definitions before you use PF11 to proceed to the Allocation Attributes Entry screen or before you exit and save parameters.
-
For the values of the various fields, you can use the Primary library value as reference. To do so, enter '=' in the Mirror field. For prefixes, adjust the value to match the Mirror naming convention.
-
- Submit the job to create the mirror libraries.
- Press PF3 (END) to return to the Minor Steps Selection panel.
Step 2.2 - Switch to Mirror Libraries
This step switches internal references and prefixes from the primary to the mirror set of libraries. After the switch, address spaces and jobs of this IOA environment start using the mirror libraries instead of the primary libraries.
-
Select Minor Step 2, Switch to Mirror Libraries.
-
Use the 'S' command to perform the switch.
After a successful switch, the status changes from yellow 'PRIMARY' to green 'MIRROR'.
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 2.3 - Restart Address Spaces
This step instructs you to move the active products from the primary libraries to the mirror libraries. This frees the primary libraries and makes them available for the deployment process. If required, the primary libraries can be enlarged and updated without interfering with the running address spaces.
To proceed with the deployment, all active address spaces must be restarted. This causes them to start using the mirror libraries instead of the primary libraries.
After all INCONTROL components are switched to the mirror libraries, you can proceed to the next step.
-
Select Minor Step 3, Restart Address Spaces.
-
Use the 'S' command to show a list of address spaces that are still allocated to primary libraries.
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 2.4 - Enlarge Primary Libraries
This step enlarges primary libraries, to satisfy the free space requirements of this deployment cycle. This step processes only those libraries that do not have enough free space to proceed with the deployment. Depending on the primary data sets and their free space availability, you might need to submit the job several times until a successful termination. Active address spaces are not impacted during the process, since at this phase they use the corresponding mirror libraries.
-
Select Minor Step 4, Enlarge Primary Libraries.
-
If necessary, use the 'A' command to set or change DASD/SMS allocation attributes from those used during installation of the primary libraries or the previous time that this step was run.
-
Submit the job to enlarge relevant primary libraries.
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 2.5 – Extract and Deploy the Deployment Package
This step deploys new and updated members to primary libraries. To proceed with this step, you are asked to provide the Deployment Package name. Also allocation attributes and SMS-related options for the temporary extracted data sets are needed to perform this step.
-
Select Minor Step 5, Extract and Deploy Deployment Package.
-
Provide required parameters.
-
Submit the job.
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 2.6 – Handle User Exit Updates
This step lists the new versions of user-exit samples introduced by the deployment. These exits were identified as already being implemented in your system.
Select Minor Step 6, Handle User Exit Updates, to display the list.
If no installed user exits were replaced by the deployment, the following message is displayed:
The step will be marked COMPLETE. No Installed User Exits were replaced in this deployment.
For each member in this list, consider whether you want to use the new version of the exit and, if so, do the following:
-
Back up the source of the installed exit member and its usermod job. They are both located in the ilprefa.CUSTEXIT library. The usermod job, has the same name as the sample exit name, except that the first two characters are replaced by "UM." For example, the usermod job for installing CTDX008B is UMDX008B.
-
Manually install the exit member in the cloned environment.
Return to Major Step 2, Change Deployment.
Step 2.7 – Propagate Members to Environment Libraries
INCONTROL BASE libraries are shipped with members that contain symbolic variables that must be resolved according to local values that are determined during installation. During the installation of INCONTROL products, members related to the products are copied from IOA libraries to the appropriate product libraries and the variables are resolved. This process of copying elements from a BASE library to a working product library and resolving the symbolic variables is termed propagation.
If product members that require propagation are replaced in the BASE libraries by the maintenance, they need to be propagated to the working product libraries, for the changes to take effect. Propagation is not performed automatically - to avoid overwriting the product members (in the working libraries) that may have local modifications.
Propagation during Change Deployment is performed against the primary BASE and working libraries. The changes come into effect after the 'Switch to Primary set to Activate Deployment' step. If you made local modifications to the members in your working library, back up the members and, after the propagation step has completed, reapply the modifications to the new versions of the members (based on the backups).
-
Select Minor Step 7, Propagate Members to Environment Libs.
If there are no members that require propagation in the deployment, the step is marked COMPLETE. Continue with the next step.
-
Enter L in the S column in the row with the "Propagate selected elements" description, to display a list of elements that were introduced by this maintenance and require propagation.
A panel opens with a table that lists the elements and propagation data. Statuses are displayed for the elements according to the following propagation considerations:
-
Elements that can be propagated without further analysis. There is no chance of overwriting local modifications, since they did not exist previously in the working library. These elements have a 'New' status and are pre-selected with an S (this selection cannot be removed).
-
Elements that must be propagated. There is a chance of overwriting local modifications, since they previously existed in the working library. These elements have a 'MustReplace' status and are pre-selected with an S (this selection cannot be removed). Make sure to back up the appropriate members as described above.
-
Elements that require further analysis before they are propagated. There may be a chance of overwriting local modifications, since they did exist previously in the working library. These elements have a 'Replacement' status.
For assistance in deciding which elements to propagate or to obtain more information about any of the elements in the list, use the following line command for each element:
B - view the new version of the element
For the elements that are being propagated, check if there are local modifications that were made previously and must be reapplied. Back up the appropriate elements to preserve the modifications for reference.
-
-
Select the elements from the list that you want to propagate, by entering S in the O column next to the elements. Press PF3 (END) to close the panel.
-
Submit the job.
If you enter L after the job has completed, elements that have been propagated have a Propagated! status.
-
When the job has completed, examine the status. If the job did not complete successfully, use B to browse the log for more details.
-
After propagation, apply the local modifications as they existed previously using local site procedures. Use the backups that you created in step 2 as references.
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 2.8 – Post Deployment Exception Handling
During this step you must review and handle the post deploy exception situations relevant to this deployment and environment.
Step 2.9 - Perform Pre-activate Actions
This step may contain sub-steps that should be performed before the updated software can be used.
Step 2.10 - Switch to Primary Set to Activate Deployment
This step switches relevant references and prefixes from the mirror to the primary set of libraries. Address spaces and jobs of this IOA environment that start or restart after the switch will use the primary libraries instead of the mirror libraries.
-
Select Minor Step 10, Switch to Primary Set to Activate Deployment.
-
Use the 'S' command to perform the switch.
After a successful switch, the status changes from yellow 'MIRROR' to green 'PRIMARY'.
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 2.11 – Copy Elements into Site Libraries
During the original installation, certain libraries may have been copied to libraries outside the IOA libraries and afterwards modified locally. In this step, the locally modified libraries are identified, so they can be backed up first. (Otherwise, the new members in these libraries will overwrite the modified members.) In this step, the selected elements are copied to the site libraries. After the job has completed successfully, the local modifications must be reapplied to these members.
PROCJCL elements may be brought in a deployment. Previously, members of the PROCJCL library may have been copied by the installation jobs to a library specified by the PROCLIB installation parameter.
If any PROCJCL members for the installed products are replaced by the deployment, they can be listed using the L option, and selected to be recopied using the S option. If any of the selected members had local modifications in the site library, back them up first, before copying the elements, and re-work the changes after this step is completed.
-
Select Minor Step 11, Copy Elements into Site Libraries.
If either the PROCLIB parameter is set to the default value (DONTCOPY, do not copy to a site library), or if no PROCJCL elements are replaced in this deployment for the products installed, an appropriate message is issued, and the step is marked COMPLETE. Continue with the next step.
-
If there are candidate elements to be copied, a panel opens with a table listing the elements and copy data.
-
Enter S in the O column next to the elements that you decide to copy and press PF3 (END) to return to the Minor Steps Selection panel.
If any of these elements have local modifications, back them up now, and reapply the modifications to the new copies after successfully copying the elements to the site libraries.
Step 2.12 – Restart Address Spaces
This step instructs you to move the active products from the mirror libraries to the primary libraries. This is required in order to activate the deployment by starting to use the updated primary libraries.
To proceed with the deployment, all INCONTROL address spaces must be restarted. This causes them to start using the primary libraries where the deployment was installed.
After all INCONTROL components are switched to the primary libraries, you can proceed to the next step.
-
Select Minor Step 12, Restart Address Spaces.
-
Use the 'S' command to show address spaces still allocated to mirror libraries.
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 3 – List post Deploy changes activities
Select Major step 3, List post Deploy changes activities.
Perform the following minor steps:
Step 3.1 - Compatibility Mode Considerations
The following ICE steps allow you to set Compatibility Mode to the level you are upgrading to or to retain your current Compatibility Mode.
This step should only be performed after testing, and once you are satisfied with the stability of the upgraded system.
You should consider NOW whether to set Compatibility mode to the new level. Doing so is normally recommended and will enable working with all the latest functions and features, but the fallback of the deployment will not be available once the compatibility mode is set to the new level.
In the following situations, you should NOT set the compatibility mode to the new level:
-
Any IOA datasets (for example, the Condition file) are shared with another environment at a lower level.
-
Control-M is installed, and Control-M/Enterprise Manager is still on a lower level.
For such cases, you can change the compatibility mode at a later time (after all components are at the level that you are upgrading to) using the MODE parameters in ICE.
Perform the following:
-
Select Minor Step 1, Compatibility Mode Considerations.
Information about setting the compatibility mode is displayed.
-
If you decide to set the compatibility mode to the new level, shut down all INCONTROL address spaces at this time, before performing Step 3.2, to prevent working in mixed compatibility modes.
To help you with this action, Step 3.2 identifies the key datasets that are in use and prompts you to stop them before you continue with setting the new compatibility mode.
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 3.2 - Set Compatibility Mode
This step enables you to set the compatibility mode to a new level or keep it at the current level.
Caution:
-
This step is irreversible.
-
Fallback of the deployment will not be possible.
-
Ensure that all INCONTROL address spaces are down.
-
Select Minor Step 2, Set Compatibility Mode.
-
In the pop-up question (Do you wish to set Compatibility Mode to newVersion?), enter either Y (Yes) or N (No), and then press PF3.
-
Depending on your choice:
-
If you entered N, Minor Step 2 is marked COMPLETE.
-
If you entered Y, customize the compatibility mode level for each INCONTROL product.
For example, you might want to set the compatibility mode of most INCONTROL products to the new level while keeping one product, Control-M for z/OS, at the old level. In such a case, leave the MODECTM value as is, and set all other MODExxx parameters to the new version.
-
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 3.3 - Start Address Spaces
This step reminds you to restart the INCONTROL address spaces that you shut down before setting the new compatibility mode in the previous step.
If you set the compatibility mode for Control-M (parameter MODECTM) to the new level, remember to promote the level in Control-M/Enterprise Manager, as well.
-
Select Minor Step 3, Start Address Spaces.
Information is displayed regarding restarting the address spaces.
-
Press PF3 (END) to return to the Minor Steps Selection panel.
Step 3.4 – Complete Change Deployment
Caution:
-
This step is irreversible.
-
All the mirror data sets are deleted during this step.
Follow the on-screen instructions for this step.
Step 4 - Fallback (Optional)
In the table of contents below, headings (that start with the word "Step") correspond to minor steps in the deployment procedure.
Step 4.1 - Perform Fallback
This step switches internal references and prefixes from the Primary set of libraries to the Mirror set of libraries. After the switch, address spaces and jobs of this IOA environment start using the Mirror libraries instead of the Primary libraries.
As an alternative or in addition to this step, the IOA environment can be restored back to the pre-deployment level of the system, provided that the compatibility mode has not been changed and the backup file has been created in Step 1.2 – Back Up Your INCONTROL System. To restore from the backup, use a copy of the MNTJREST job from the INSTWORK library of your IOA environment.
Step 4.2 – Start Address Spaces
In this step you must re-start all INCONTROL address spaces that were shut down, to complete the Fallback process.
Change Deployment to a SMP/E managed clone environmentLink copied to clipboard
The section describes how the software level (fixes and maintenances) of an SMP/E managed cloned environment can be synchronized with the software level of an SMP/E managed base environment using the Change Deployment facility of ICE.
Change Deployment stepsLink copied to clipboard
On the base environment
-
Open ICE from the base environment.
-
Select Clone, Deploy IOA Environment.
-
From the IOA Cloning and Changes Deployment panel, select Deploy Changes.
-
Select Generate report for comparison with cloned SMP/E environment.
ICE builds the SMP/E Target Zone report of the base environment. The name of the report (ilprefa.CSITZN) is displayed.
-
Rename the report and copy it to the cloned environment.
The name of the report on the cloned environment must be different from ilprefa.CSITZN.
On the cloned environment
-
Open ICE from the cloned environment.
-
Select Clone, Deploy IOA Environment.
-
From the IOA Cloning and Changes Deployment panel, select Deploy Changes.
-
Select Compare SYSMODs in this environment with report from Base.
-
Enter the name of the report you chose in step 5 of On the base environment.
-
Enter Y and press Enter to proceed.
ICE rebuilds the SMP/E Target Zone report of the cloned environment and compares it to the SMP/E Target Zone report from the base environment.
The detailed comparison report contains all the differences between the SMP/E CSI Target Zones of the base and cloned environments. Using the report a user can apply the missing fixes to the cloned environment to bring its software level up to the level of the base environment.