Part 4 Multisystem Upgrade

• Overview

  • Categories of data sets handled by the Multisystem Upgrade

  • Overall flow of the Multisystem Upgrade process

  • Scenarios handled by the Multisystem Upgrade process

  • Limitations and requirements

• Multisystem Upgrade steps

  • Before you begin: Check limitations and requirements

  • Step 1: Back up IOA environments

  • Step 2: Prepare the IOA environments for Multisystem Upgrade

  • Step 3: Upgrade the master IOA environment

  • Step 4: Run the Multisystem Upgrade job on the master IOA environment

  • Step 5: Perform pre-APPLY actions on slave IOA environments

  • Step 6: Make updated data set contents available to slave IOA environments

  • Step 7: Run the Propagation job on slave IOA environments

  • Step 8: Manually handle unsupported data sets

  • Step 9: Perform post-APPLY actions on slave IOA environments

• System Symbols support

  • Limitations for use of system symbols

  • Implementing system symbols

Overview

For upgrade of an IOA environment, BMC recommends using the proper ICE facilities — either the Upgrade in Place process or the Ad-hoc maintenance process. These upgrade methods are sufficient for an environment that was created using the ICE-based installation or cloning processes. However, if an IOA environment that you need to upgrade is non-SMP/E-managed and does not have ICE, these upgrade methods cannot be used. For such cases, you can use the Multisystem Upgrade process.

Use the Multisystem Upgrade process when all of the following conditions are met:

• You have several IOA environments of the same software level.

• One of the IOA environments (the master environment) is SMP/E-managed and has ICE.

• The rest of the IOA environments (the slave environments) are non-SMP/E- managed and have no ICE.

• The master IOA environment has all the INCONTROL products that are installed on the slave IOA environments. In other words, if a certain INCONTROL product is installed on at least one slave IOA environment, that product must be installed on the master IOA environment, as well.

The Multisystem Upgrade process enables you to upgrade multiple slave IOA environments. After the master IOA environment is upgraded (using either the Upgrade in Place process or the Ad-hoc maintenance process), the Multisystem Upgrade process enables you to copy updated data sets and members to all slave IOA environments.

Before data sets can be copied to the slave IOA environments, their contents must be checked. Changed data sets, especially non-SMP/E-managed data sets, might contain hard-coded, installation-specific data (such as environment prefixes). Such data sets must be adjusted before they can be copied to slave IOA environments or shared between slave IOA environments. The Multisystem Upgrade process analyzes the software level of data sets and guides you through the necessary actions to take on the data sets.

The following topics further discuss the Multisystem Upgrade process:

• Categories of data sets handled by the Multisystem Upgrade

• Overall flow of the Multisystem Upgrade process

• Scenarios handled by the Multisystem Upgrade process

• Limitations and requirements

Categories of data sets handled by the Multisystem Upgrade

Before you can copy data sets from the master IOA environment to the slave IOA environments or share data sets between the master and slave IOA environments, the Multisystem Upgrade process analyzes the data sets on the IOA environment (including SMP/E-managed and non-SMP/E-managed data sets) and detects those data sets that have changed during upgrade or maintenance. Data sets that have not changed (such as the INCONTROL product repositories and data bases) require no further action. Data sets that are detected as changed are divided into the following categories:

Table 26 Categories of data sets for Multisystem Upgrade

Overall flow of the Multisystem Upgrade process

The following flowchart summarizes the steps involved in a Multisystem Upgrade process.

For more detailed information and instructions, see Multisystem Upgrade steps.

Scenarios handled by the Multisystem Upgrade process

The following table summarizes typical scenarios that are handled by the Multisystem Upgrade process:

Table 26a Typical Multisystem Upgrade scenarios

* For a description of this category of data sets, see Categories of data sets handled by the Multisystem Upgrade.
For a full list of the data sets in this category, see Limitations and requirements

Limitations and requirements

To successfully perfom the Multisystem Upgrade process, ensure that all of the following requirements are met:

• The master IOA environment and all slave IOA environments have the same level of INCONTROL software.

• The master IOA environment has the INCONTROL Installation and Customization Engine (ICE).

• The master IOA environment is SMP/E-managed.

• All slave IOA environments are not SMP/E-managed.

• Slave IOA environments can have different sets of installed IOA products, but all products installed on any of the slave IOA environment are installed on the master IOA environment.

• Contents of the IOA LOAD library are identical on the master IOA environment and all slave IOA environments. This includes the following customizations, which must be identical on all environments:

  • User exits

  • Security exits

  • Type of security subsystem

  • Binding to third-party products

  • Control-T SVC number

• The following libraries on the master IOA environment and on all slave IOA environments must not contain any installation-specific customization, that is, hard-coded, installation-specific values for installation parameters (such as data set prefixes):

  • basepref.GENERAL

  • basepref.GENERALV

  • basepref.GNRL132

  • basepref.INSTCTB

  • basepref.INSTCTD

  • basepref.INSTCTJ

  • basepref.INSTCTM

  • basepref.INSTCTO

  • basepref.INSTCTR

  • basepref.INSTCTT

  • basepref.INSTCTV

  • basepref.PROCJCL

  • ilprefa.CICSSAMP

  • ilprefa.CTRANS

  • ilprefa.DOC

  • ilprefa.IOAENV

  • ilprefa.ISMSGENG

  • ilprefa.ISMSGFRA

  • ilprefa.ISMSGGER

  • ilprefa.ISMSGFRA

  • ilprefa.ISMSGJPN

  • ilprefa.KSL

  • ilprefa.MAC

  • ilprefa.MAINTLIB

  • ilprefa.MSGENG

  • ilprefa.MSGFRA

  • ilprefa.MSGGER

  • ilprefa.MSGJPN

  • ilprefa.PANELENG

  • ilprefa.PANELFRA

  • ilprefa.PANELGER

  • ilprefa.PANELJPN

  • ilprefa.ROSLIB

  • ilprefa.SAMPEXIT

  • ilprefa.SAMPLE

  • ilprefa.SAMPREPS

  • ilprefa.SECSRC

  • ilprefa.SIML

  • ilprefa.SSARMOD

  • steplib (IOA LOAD library)

  • steplibe (IOA LOADE library)

Multisystem Upgrade steps

The following table summarizes the steps that you must follow to perform a Multisystem Upgrade process. Mark the Check column of the following table as you complete each step. All steps must be completed in sequence.

Table 26b Multisystem Upgrade checklist

Before you begin: Check limitations and requirements

Before performing a Multisystem Upgrade, analyze your master IOA environment and all your slave IOA environments and ensure that all IOA environments involved in the Multisystem Upgrade meet the requirements and limitations described in Limitations and requirements.

Step 1: Back up IOA environments

Back up all IOA environments that will be involved in the Multisystem Upgrade, both the master IOA environment and the slave IOA environments.

Step 2: Prepare the IOA environments for Multisystem Upgrade

If this is the first time that a Multisystem Upgrade is performed on this group of IOA environments, you must perform the following tasks to prepare the IOA environments:

• Step 2.1: Apply version 9.0.19 PTFs to the master IOA environment

• Step 2.2: Generate a baseline snapshot

• Step 2.3: Implement System Symbols (optional)

Step 2.1: Apply version 9.0.19 PTFs to the master IOA environment

Support for Multisystem Upgrade begins with version 9.0.19 of the IOA core and INCONTROL products. To support Multisystem Upgrade on IOA environments of earlier 9.0.x versions, apply a pair of PTFs on the master IOA environment.

To apply version 9.0.19 PTFs for Multisystem Upgrade support

On the master IOA environment, use the Ad-hoc maintenance process in ICE to APPLY the following PTFs:

• PG04354

• PG04355

For information about the Ad-hoc maintenance process, see Ad hoc APPLY PTF process.

Step 2.2: Generate a baseline snapshot

Before performing the Multisystem Upgrade, use the ULDCSITZ job (provided by the Multisystem Upgrade process) to generate a baseline snapshot of the SMP/E target zone. The generated snapshot represents the current INCONTROL software level of the master IOA environment and all slave IOA environments. This snapshot is used by the Multisystem Upgrade process to detect data sets and members that have changed during upgrade or maintenance, based on a comparison of SMP/E Target Zones between the master environment and the slave environments.

To create a baseline snapshot

1. On the master environment, tailor the ULDCSITZ job using the Tailor Job option in ICE (available by selecting Maintain your Environment => ICE refresh).

   Specify the following values:

   • Product: IOA

   • Jobname: ULDCSITZ

   • Output library: INSTWORK

2. Submit the ULDCSITZ job.

   The ULDCSITZ job unloads SMP/E Target Zone information into mlprefa.Syymmdd, a sequential data set. If such a data set already exists, it is replaced. The low level qualifier (LLQ) of the data set indicates its creation date.

3. Create a backup copy of the mlprefa.Syymmdd data set.
   Give your backup data set a slightly different name. For example, mlprefa.SyymmddX.

Step 2.3: Implement System Symbols (optional)

The Multisystem Upgrade process strives to maximize the number of data sets that you can use as is on the slave IOA environments. To achieve this goal, you have the option of implementing system symbols at this point, before performing the Multisystem Upgrade. For more information, see System Symbols support.

Step 3: Upgrade the master IOA environment

Upgrade the master IOA environment using the appropriate ICE facility — either the Upgrade in Place process or the Ad-hoc maintenance process (to APPLY select PTFs).

Keep a list of all pre-APPLY and post-APPLY actions (such as Holds) that you perform during upgrade or maintenance. You will need this list in subsequent steps of the Multisystem Upgrade process on the slave IOA environments.

Step 4: Run the Multisystem Upgrade job on the master IOA environment

Run the Multisystem Upgrade job, UPGJMSTR, through ICE on the master IOA environment.

To run the Multisystem Upgrade job

1. On the master environment, tailor the UPGJMSTR job using the Tailor Job option in ICE (available by selecting Maintain your Environment => ICE refresh).

   Set the date of the snapshot to be used in the Multisystem Upgrade, as it appears in the low level qualifier (LLQ) of the mlprefa.Syymmdd data set. To set the date, use JCL variables SLAVEYY, SLAVEMM, and SLAVEDD.

   Choose the relevant mlprefa.Syymmdd data set:

   • The mlprefa.Syymmdd data set created by the UPGJMSTR job during the last successfully completed Multisystem Upgrade process

   • If you have not yet performed a Multisystem Upgrade process: The mlprefa.Syymmdd data set created in Step 2.2: Generate a baseline snapshot

     Warning: If you are running the current step on the same day that the existing data set was generated, you must prevent the existing mlprefa.Syymmdd data set from being overwritten. Rename the existing mlprefa.Syymmdd data set by adding a single character to the end of its name. For example, rename to mlprefa.Syymmdd1. Adjust the SLAVEDD variable accordingly.

2. Submit the UPGJMSTR job.

   The UPGJMSTR job generates the following items:

   • New snapshot of the SMP/E target zone in the mlprefa.Syymmdd data set (with today's date in the LLQ)

   • Software-level report in the SYSTSPRT DD of the CMPCSI step, which lists the differences in software level between the master environment and the slave environments

   • Upgrade report in the SYSTSPRT DD of the RUNBLST step, which contains the following lists:

     • List of updated data sets on the master IOA environment that can be used as is on the slave IOA environments (used later in Step 6: Make updated data set contents available to slave IOA environments)

     • List of members that will be adjusted by the Propagation job on the slave environments (during Step 7: Run the Propagation job on slave IOA environments)

     • List of members that must be handled manually (used later in Step 8: Manually handle unsupported data sets)

     • Full list of all updated members and the data sets to which they belong (that is, all items from the 3 previous lists)

   • Propagation job in the UPGJPROP member within the ilprefa.INSTWORK library, which will be used in Step 7: Run the Propagation job on slave IOA environments

     If the UPGJMST job does not end successfully, that is, the job returns a non-zero RC, check for a detailed error description and guidance in the MSUREP1 member in the INSTWORK library.

Step 5: Perform pre-APPLY actions on slave IOA environments

Perform pre-APPLY actions on each of your slave IOA environments.

The pre-APPLY actions that you perform on the slave environments are the same as those that you performed on the master IOA environment in Step 3: Upgrade the master IOA environment.

Step 6: Make updated data set contents available to slave IOA environments

A list of data sets from the master IOA environment that can be used as is (that is, with no further adjustments necessary) on the slave IOA environments is provided in the first section of the Upgrade report generated by the Multisystem Upgrade job. For more information about this list, see Step 4: Run the Multisystem Upgrade job on the master IOA environment.

To make these updated data sets (and the members within them) available to the slave environments, you can choose any of the following methods:

• Copy the contents of the data sets from the master environment to each of the slave environments

• Share the data sets from the master environment to each of the slave environments

• One example of a method for sharing data sets is to place the data sets on a system residence (SYSRES) volume and to then use indirect cataloging to access the data sets on target IOA environments. This option is applicable when all IOA environments that use these shared data sets use the same data set prefixes. For more information about this option refer to the IBM Knowledge Center and review the "Using indirect volume serial support" topic in the z/OS MVS Initialization and Tuning Reference.

Step 7: Run the Propagation job on slave IOA environments

The Propagation job adjusts data sets on the slave IOA environments.

The Propagation job was generated by the Multisystem Upgrade job, along with a list of updated data sets that can be handled by the Propagation job, as described in Step 4: Run the Multisystem Upgrade job on the master IOA environment.

To run the Propagation job

1. On each slave IOA environment, open the UPGJPROP job and follow the instructions in the job header.

2. Submit the UPGJPROP job.

   The Propagation job copies updated member skeletons from SMP/E managed libraries (for example, basepref.GENERAL) to non-SMP/E managed libraries (for example, ilprefd.JCL). The Propagation job then inserts specific parameters into the copied members in the target non-SMP/E managed libraries, resolving parameter values that are unique to the target IOA environment.

   Warning: Any user modifications that were introduced into the BMC-provided members in these libraries are lost.

Step 8: Manually handle unsupported data sets

Certain data sets must be handled manually. A list of members in these data sets is provided within the Upgrade report generated by the Multisystem Upgrade job, as described in Step 4: Run the Multisystem Upgrade job on the master IOA environment.

Perform the following actions:

1. Copy the members listed in the third section of the Upgrade report from the master IOA environment to all slave IOA environments.

2. Adjust the copied members on each slave IOA environment , as necessary.

   For example, if a member contains environment-specific customization, edit the environment-specific values to match the new environment.

Step 9: Perform post-APPLY actions on slave IOA environments

Perform post-APPLY actions on each of your slave IOA environments.

The post-APPLY actions that you perform on the slave environments are the same as those that you performed on the master IOA environment in Step 3: Upgrade the master IOA environment.

System Symbols support

To enhance the coverage of data sets by the Multisystem Upgrade process, you can implement system symbols within a subset of IOA environment data sets.

For more information about system symbols, refer to the IBM Knowledge Center.

The following topics further discuss the use of system symbols:

• Limitations for use of system symbols

• Implementing system symbols

Limitations for use of system symbols

The following limitations apply to the Multisystem Upgrade process when you use system symbols. These limitations are in addition to the limitations and requirements discussed in Limitations and requirements.

• The master IOA environment and all slave IOA environments must be very similar. The only differences allowed between the environments are in data set prefixes and in the values of certain parameters, as discussed below.

  • Data set prefixes:

    • Differences between corresponding prefixes on the various IOA environments must be limited to cases where these differences can be eliminated by substituting them with system symbols within the prefix value.

    • For example, the prefixes IOA.DEV.SYSX, IOA.TEST.SYSY, and IOA.PROD.SYSZ satisfy the requirement, because the following generic prefix can be used instead of them: IOA.&ENVTYPE..&SYSNAME. In this generic prefix, the &SYSNAME system symbol is predefined by the operating system, and the &ENVTYPE system symbol is a user-defined system symbol that must be defined on all IOA environments that will be involved in the Multisystem Upgrade procedure (that is, on the master IOA environment and all slave IOA environments).

  • Parameter values:

    The following parameters can have different values on the various IOA environments:

    • PROCLIB

    • SITEPROC

    • SYSPROCA

    • SSNAME

    • QNAME

    • PORTx

    The following parameters must have identical values on the various IOA environments:

    • JOBNAME

    • JOBCARD

    • JCL1

    • JCL2

    • INSTID

    • PROCPRFx

• The following libraries on the master IOA environment and all slave IOA environments cannot contain any installation-specific customizations (that is, hard-coded values of installation parameters, including data set prefixes):

  • ilprefa.PROCLIB

  • ilprefa.PROCJCL

  • ilprefb.JCL

  • ilprefd.JCL

  • ilprefj.JCL

  • ilprefm.JCL

  • ilprefo.JCL

  • ilpreft.JCL

  • ilprefa.JCL

Implementing system symbols

If you choose to use system symbols in a Multisystem Upgrade, you must implement system symbols on all IOA environments that will be involved in the Multisystem Upgrade process.

The following table summarizes the steps that you must follow to implement system symbols. Mark the Check column of the following table as you complete each step.

Table 26c System Symbol implementation checklist

Step 1: Back up libraries

Create backup copies of the following libraries on all IOA environments involved in the Multisystem Upgrade process (that is, the master environment and all slave environments):

• ilprefa.PROCLIB

• ilprefa.PROCJCL

• ilprefb.JCL

• ilprefd.JCL

• ilprefj.JCL

• ilprefm.JCL

• ilprefo.JCL

• ilpreft.JCL

• ilprefa.JCL

Step 2: Define system symbols in the DEFPARML member

In the DEFPARML member in the ilprefa.PARM library on the master IOA environment, define all prefixes of INCONTROL products with system symbols.

The syntax of the DEFPARML member is the same syntax used in the DEFPARM member.

An example of prefix definitions can be found in the ilprefa.PARM(DEFPARMS) sample member:

Figure 7 System symbols in prefix definitions

%SYMBOLS%=YES                                      
%BASEPREF%=&IOAS1..&IOAS2..&IOAS3..BASE            
%CTM2SBS%=&IOAS1..&IOAS2..&IOAS3..CTM.OPR.CTM2SBS  
%DAPARM%=&IOAS1..&IOAS2..&IOAS3..IOA.INST.PARM     
%DBPREFA%=&IOAS1..&IOAS2..&IOAS3..IOA.DB           
%DBPREFB%=&IOAS1..&IOAS2..&IOAS3..CTB.DB           
%DBPREFD%=&IOAS1..&IOAS2..&IOAS3..CTD.DB           
%DBPREFM%=&IOAS1..&IOAS2..&IOAS3..CTM.DB           
%DBPREFT%=&IOAS1..&IOAS2..&IOAS3..CTT.DB           
%ILPREFA%=&IOAS1..&IOAS2..&IOAS3..IOA.INST         
%ILPREFB%=&IOAS1..&IOAS2..&IOAS3..CTB.INST         
%ILPREFD%=&IOAS1..&IOAS2..&IOAS3..CTD.INST         
%ILPREFJ%=&IOAS1..&IOAS2..&IOAS3..CTJ.INST         
%ILPREFM%=&IOAS1..&IOAS2..&IOAS3..CTM.INST         
%ILPREFO%=&IOAS1..&IOAS2..&IOAS3..CTO.INST         
%ILPREFT%=&IOAS1..&IOAS2..&IOAS3..CTT.INST         
%MLPREFA%=&IOAS1..&IOAS2..&IOAS3..IOA.MNT          
%OLPREFA%=&IOAS1..&IOAS2..&IOAS3..IOA.OPR          
%OLPREFB%=&IOAS1..&IOAS2..&IOAS3..CTB.OPR          
%OLPREFD%=&IOAS1..&IOAS2..&IOAS3..CTD.OPR          
%OLPREFJ%=&IOAS1..&IOAS2..&IOAS3..CTJ.OPR          
%OLPREFM%=&IOAS1..&IOAS2..&IOAS3..CTM.OPR          
%OLPREFO%=&IOAS1..&IOAS2..&IOAS3..CTO.OPR          
%OLPREFR%=&IOAS1..&IOAS2..&IOAS3..CTR.OPR          
%OLPREFT%=&IOAS1..&IOAS2..&IOAS3..CTT.OPR          
%OLPREFV%=&IOAS1..&IOAS2..&IOAS3..CTV.OPR          
%SPAPREF%=&IOAS1..&IOAS2..&IOAS3..SMP.SPA          
%SPCPREF%=&IOAS1..&IOAS2..&IOAS3..SMP.SPC          
%SPCPREFD%=&IOAS1..&IOAS2..&IOAS3..SMP.SPC         
%SPCPREFT%=&IOAS1..&IOAS2..&IOAS3..SMP.SPC         
%SPDPREF%=&IOAS1..&IOAS2..&IOAS3..SMP.SPD          
%STATFILE%=&IOAS1..&IOAS2..&IOAS3..CTM.OPR.STATFILE
%STEPLIB%=&IOAS1..&IOAS2..&IOAS3..LOAD             
%STEPLIBE%=&IOAS1..&IOAS2..&IOAS3..LOADE            

Ensure that the %SYMBOLS% parameter is set to YES in the DEFPARML member. This parameter defines how the Upgrade processes (either the Upgrade in Place process or the Ad-hoc maintenance process) handle the system symbols defined in the member, and how the Propagation job for the slave IOA environments treats the libraries that are enabled for system symbols — ilprefa.PROCLIB, ilprefa.PROCJCL, and ilprefX.JCL.

Step 3: Define the system symbols in the operating system

On all IOA environments involved in the Multisystem Upgrade process (the master environment and all slave environments), define system symbols in the operating system, including all system symbols that you defined in the DEFPARML member.

You can define the system symbols in the IEASYMxx parmlib member or you can use the IEASYMU2 program. The following example demonstrates how to define system symbols using the IEASYMU2 program.

Figure 8 Defining system symbols using IEASYMU2

//IEASYMU2 EXEC PGM=IEASYMU2,PARMDD=SYSSYMDD
//SYSSYMDD DD *
 IOAS1=SYST
 IOAS2=IOA
 IOAS3=TEST
/*

To update symbolname, you need UPDATE access to the associated RACF profile, as in the following example:

PERMIT IEASYMUP.symbolname CLASS(FACILITY) ID(userid) ACCESS(UPDATE)

For more information about the IEASYMU2 and how to use it for defining system symbols, refer to the IBM Knowledge Center and review the topics about system symbols (especially "Changing system symbols") in the z/OS MVS Initialization and Tuning Reference.

Step 4: Run the System Symbol Propagation job

Run the System Symbol Propagation job, PROPSYM, through ICE on the master IOA environment.

To run the System Symbol Propagation job

1. On the master environment, tailor the PROPSYM job using the Tailor Job option in ICE (available by selecting Maintain your Environment => ICE refresh).

   Set the Output Library to INSTWORK.

2. Submit the PROPSYM job.

   The PROPSYM job performs the following actions:

   • Rebuilds the ilprefa.PROCJCL and ilprefX.JCL libraries, replacing hard-coded data sets prefixes with values that contain system symbols from the DEFPARML member.

     Warning: Any user modifications that were introduced into the BMC-provided members in these libraries are lost.

   • Inserts the prefixes from the DEFPARML member into the IOASYM member within the ilprefa.PROCLIB library as JCL variable definitions that contain system symbols.

Step 5: Enable inclusion of the IOASYM member in IOASET

In this step you enable redefining of hard-coded values of data set prefixes as values that contain the system symbols defined in the DEFPARML member. To do this, you enable the inclusion of the IOASYM member (to which system symbols were propagated) at the end of the IOASET member. Both these members are in the ilprefa.PROCLIB library.

Uncomment the following line in the INCLSYM member within the ilprefa.PROCLIB libary:

//*    INCLUDE MEMBER=IOASYM

Step 6: Activate IOASYM definitions

To activate the system symbols that were enabled in the IOASYM member, perform the following IOA Customization steps through ICE on the master IOA environment:

• Major step 1: IOAPARM Post-Installation > Minor step 4: Parameter Verification

• Major step 1: IOAPARM Post-Installation > Minor step 5: Save Parameters into Installation Libs

For more information about these steps, see 1 Customizing INCONTROL products with ICE in the INCONTROL for z/OS Installation Guide: Customizing.

These steps rebuild the IOASET member in the ilprefa.PROCLIB library and activate the system symbols from the IOASYM member. From this point on, IOA environment jobs and started tasks that refer to the IOASET member resolve data set prefixes using the system symbols defined in the DEFPARML member.

Step 7: Make libraries available to slave IOA environments

Copy the master IOA environment libraries with the propagated system symbols to all slave IOA environments, or share these master IOA libraries with all slave IOA environments. The libraries are:

• ilprefa.PROCLIB

• ilprefa.PROCJCL

• ilprefb.JCL

• ilprefd.JCL

• ilprefj.JCL

• ilprefm.JCL

• ilprefo.JCL

• ilpreft.JCL

• ilprefa.JCL

Step 8: Copy the IOASYM member to the site library

Copy the IOASYM member from the PROCLIB library of the master IOA environment to the site library whose name is specified in the SITEPROC IOA installation parameter.

Perform this step also on all slave IOA environments.

Step 9: Copy procedures to site libraries

If the PROCLIB parameter (for the MVS started tasks library) is NOT set to DONTCOPY, you must copy modified procedures on the master IOA environment to the site procedure libraries of the various INCONTROL products.

The following table lists the steps in ICE for copying procedures to site libraries for the various INCONTROL products and references the sections in the INCONTROL for z/OS Installation Guide: Installing that describe these steps during a Customized Installation process.

Table 26d Steps for copying procedures to site libraries