Step 43. Migrate the IOA component

1. If the IOA LOAD library of the version you are migrating from is in the MVS Linklist, remove it. To remove it permanently, edit the LNKLSTxx member in the SYS1.PARMLIB library and delete the reference to the library.
   • You may need an IPL to make the change effective. However, if you use a product that can dynamically modify the MVS Linklist, such as CA‑LOOK, you can skip the IPL.
   • You can decide to add the new IOA LOAD library to the Linklist. If so, refresh the LLA and update the facilities that access the LOAD libraries.
2. If the IOA LOAD library of the version you are migrating from is not in the MVS LINKLIST, verify that it is not being used by any address space in the GRS complex by reviewing the output of the following operator command:

   D GRS,RES=(SYSDSN,ioa.prev.load)

   In this command, ioa.prev.load is the name of the previous version of the IOA LOAD library. The name will usually have the form of ilprefa.LOAD, where ilprefa is the IOA Installation prefix of the version you are upgrading from.

   The following is a sample output for this command indicating that no address spaces are using that environment:

   ISG343I 15.40.50 GRS STATUS 678

   NO REQUESTORS FOR RESOURCE SYSDSN IOAP.V900.INST.LOAD

   As an alternative to the D GRS operator command, you can rename the IOA LOAD library of the version you are migrating from, and then rename it back. A successful rename indicates that no one is allocating that library. Note that renaming the library back is necessary, as it may still be used by some of the migration steps described in this chapter.

   If any address spaces in the GRS complex are identified as allocating the library, resolve the situation by stopping them.

3. Replace IOA procedures

   If you used IOA procedures in your jobs, you can use JCLLIB statement or you can copy these procedures to the procedure library at your site.

   Note: If IOA JCL procedure prefixes are not the same as prefixes of the previous version, modify the JCL of production jobs to refer to the new IOA JCL procedure names.

   Rename the started tasks to those of the version you are migrating from.

4. Migrate the IOA Core

   Rename or delete the current release LOG, LOGI, CND, NRS, NSN, and (optionally) ALTCND files that were used while testing the current release.

   To migrate the IOA Core, do the following:

   1. Edit the FORMIOA member in the IOA INSTWORK library. Check that the JCL is correct and submit the job. The job allocates and formats the IOA Core.
   2. If you changed some parameters, you can tailor the FORMIOA job again by using the "Tailor Job" option in the INCONTROL Installation and Customization Engine (ICE), available by selecting Maintain your Environment => ICE refresh.
   3. Copy the conditions from the IOA Conditions file and Synchronization file in the version you are upgrading from by using the IOACCND sample job in the IOA JCL library. For more information, see the INCONTROL for z/OS Utilities Guide.
   4. IOA Log file

      If you want to copy the previous IOA Log file to the current release IOA Log file, use the IOACPLOG utility from the new version. Before you copy the file, apply optional Wish WI0357.

      Example:

      //          JCLLIB ORDER=IOA.PROCLIB 

      //          INCLUDE MEMBER=IOASETnn 

      //COPYLOG   EXEC IOACPLOG

      //DALOGCUR  DD   DISP=SHR,DSN=previous log file

      //DALOG     DD   DISP=SHR,DSN=new log file

      //SYSIN     DD   *

        COPYTOLOG

   5. Update the IOA Manual Conditions file.

      It is not necessary to update the IOA Manual Conditions file (NRS) during the migration of the IOA Core files. The IOA Manual Conditions file can be updated with data from your current release system by executing the IOALDNRS utility, after the migration of the Control-M Repository and the Control-D Repository (described in Step 44. Migrate Control-M and in Step 46. Migrate Control-D) have been completed.

      See the INCONTROL for z/OS Utilities Guide for details on executing the IOALDNRS utility.

5. Migrate the AutoEdit Variable databases

   If you used the AutoEdit Variable database facility in the version you are migrating from, you must copy your databases to the current release, as described below:

   1. Back up the AutoEdit Variable databases from the version you are migrating from.
   2. Unload the databases to flat files in the version you are migrating from by submitting the IOADBSUL, IOACOLUL, and IOAVARUL jobs from the IOAprefix.JCL library of the earlier version.

      This creates three sequential files named IOAprefix.FLAT.DBSD, IOAprefix.FLAT.COLD, and IOAprefix.FLAT.VARD respectively.

   3. Rename the IOAprefix.FLAT.* files from the version you are migrating from to IOAprefix.FLAT.* using the IOA prefix of your current release installation.
   4. Format the current version databases using the IOADBSBF, IOACOLBF, and IOAVARBF jobs from the IOAprefix.JCL library of the current version installation.
   5. Load the current version databases using the IOADBSLD, IOACOLLD, and IOAVARLD jobs from the IOAprefix.JCL library of the current version installation.
   6. Build the indexes for the current version databases with the IOADBSBI, IOACOLBI, and IOAVARBI jobs from the IOAprefix.JCL library of the current version installation.
   7. Start either Control-O or Control-M/Event Manager (CMEM).
   8. Enter Screen IV from the current version IOA Main Menu, and verify that the databases contain the same data as the version you are migrating from.
   9. Stop the application that you started in Step g.
6. Copy the destination definitions from the IOADEST, MAILDEST, or SNMPDEST members of the IOA...PARM library from the old to the new environment.
7. Migrate INCONTROL security definitions

   For IOA and each INCONTROL product, if necessary, activate the security definitions that you prepared in Step 36. Prepare security definitions.

8. Put the new IOA Online interface, CLISTs, and panels into effect for all IOA users.
9. Migrate CMEM

   Adjust the CMEM IOACMEML.

   —Ensure that the IOACMEML member in the current release Parameters library references the correct rule definitions in the correct Rules libraries.

   —Verify that the CMEM monitor procedure uses the correct names of the IOA GLOBAL database files.

   Note: For environments that use CMEM and do not use Control-O, the CTMCMEM monitor can be restarted at this point. After CMEM has been initialized, you can restart any other INCONTROL products as soon as you complete their migration steps.

   For environments that do not use either CMEM or Control-O, any other INCONTROL products can be started as soon as you complete their migration steps.