IMSplex migration considerations

Migrating an IMSplex from one version of IMS to another is a complex process because many factors are involved and many different configurations are possible.

Note: The discussions in this topic aim at version-to-version migrations, therefore the considerations and examples are the same for all IMS 15 releases.

The following considerations apply when planning to migrate an IMSplex:

Multiple Resource Managers (RMs) and Operations Managers (OMs) can run simultaneously in an IMSplex.
Only one Structured Call Interface (SCI) can run at any given time in an IMSplex on a single logical partition (LPAR).
All Common Queue Server (CQS) clients connected to a CQS address space must be stopped before shutting down that CQS.
CQS clients are limited as to which version of CQS they can connect to. For more information about these rules, see Common Queue Server coexistence considerations.
Install all appropriate coexistence service onto IMSplexes before attempting to migrate.
If you are running multiple IMS systems on one logical partition (LPAR), migrate one IMS at a time.
If you are running multiple LPARs, migrate one LPAR at a time.
If you activate the automatic RECON loss notification and parallel RECON access functions within the same IMSplex, you must use the CHANGE.RECON IMSPLEX command to ensure that all DBRCs in the IMSplex are using the same IMSplex name that is specified in the RECON data set. If you use the DBRC SCI Registration exit routine (DSPSCIX0) or the IMSPLEX EXEC parameter before issuing the CHANGE.RECON IMSPLEX command, message DSP1136A is issued and subsequent jobs fail due to an unavailable RECON data set.
Open Database Manager (ODBM) can only connect to the IMS systems that are of the same version as ODBM itself. In a mixed-version IMSplex, to limit ODBM connection to the IMS systems of the same version, list the eligible IMS systems as data stores in the CSLDCxxx member of the IMS PROCLIB data set.

Example 1: Migrating IMS systems on a single LPAR

The following IMSplex migration example assumes:

Continuous availability is a high priority.
All coexistence APARs have been installed.
All IMS systems in the IMSplex are running on one LPAR (LPAR1).
One IMS Version 13 (V13) CQS that is using a resource structure.
One RM and one OM running on the LPAR.
Two V13 IMS systems (named IMSA and IMSB) that are running on LPAR1 and participating in data sharing and shared queues.

To migrate the IMS systems in this example IMSplex to IMS 15 (V15):

Prepare the IMSA libraries and data sets for IMS 15 (for example, perform a system definition, set up JCL, and so on).
Stop the V13 SCI.
Start the V15 SCI.
Start the V15 OM.
Because there is only one LPAR in this example, and one OM must be running at all times to provide OM services, the higher-level OM is started before shutting down the lower-level OM.
Stop the V13 OM.
Shut down IMSA.
Shut down IMSB.
Stop the V13 RM.
Stop the V13 CQS.
Start the V15 CQS.
Start the V15 RM.
Cold start IMSA.
Restart IMSB.
Test IMSA.
After IMSA (V15) has tested successfully, proceed to the next step. If IMSA does not pass this testing step, consider whether IMSA needs to fall back to IMS Version 13 and repeat this process after any problems are fixed.
Stop the V13 OM.
Take IMSB offline and migrate it to IMS 15.

Example 2: Migrating IMS systems on multiple LPARs

The operational environment for this example consists of two LPARs and a total of three IMS systems that are participating in shared queues and data sharing.

The following IMSplex migration example assumes:

Continuous availability is a high priority.
All coexistence APARs have been installed.
An example IMSplex consisting of:
LPAR1
- One V13 CQS
- One Common Service Layer (CSL), consisting of an OM, RM, and SCI
- One V13 IMS system named IMSC
LPAR2
- One V13 CQS
- One Common Service Layer (CSL), consisting of an OM, RM, and SCI
- Two V13 systems (named IMSD and IMSE)

Recommendation: Migrate less complex LPARs before migrating more complex LPARs.

To migrate the IMS systems in this example IMSplex to IMS 15 (V15):

Migrate the subsystems on LPAR1 first by performing the following actions:
1. Prepare the IMSC libraries and data sets for IMS 15 (for example, perform a system definition, set up JCL, and so on).
2. Stop the V13 SCI.
3. Start the V15 SCI.
4. Stop the V13 OM (assuming the same OM name is used before and after the migration).
5. Start the V15 OM.
6. Shut down IMSC.
7. Stop the V13 RM.
8. Shut down the V13 CQS.
9. Start the V15 CQS.
10. Start the V15 RM.
11. Coldstart IMSC.
12. Test IMSC. If IMSC does not pass this testing step, consider whether IMSC needs to fall back to IMS Version 13 and repeat this process after any problems are fixed.
After validating that the migration of IMSC on LPAR1 is successful, start migrating the IMS subsystems on LPAR2 with the following steps:
1. Prepare the IMSD libraries and data sets for IMS 15 (for example, perform a system definition, set up JCL, and so on).
2. Stop the V13 SCI.
3. Start the V15 SCI.
4. Stop the V13 OM.
5. Start the V15 OM.
6. Shut down IMSD.
7. Shut down IMSE.
8. Stop the V13 RM.
9. Stop the V13 CQS.
10. Start the V15 CQS.
11. Start the V15 RM.
12. Cold start IMSD.
13. Restart IMSE.
14. Test IMSD. If IMSD does not pass this testing step, consider whether IMSD needs to fall back to V13 and repeat this process after any problems are fixed.
15. After IMSD (V15) has tested successfully, proceed to the next step.
16. Stop the V13 OM.
17. Take IMSE offline and migrate it to IMS 15.

Example 3: Migrating IMS systems on multiple LPARs (with IMS Connect involved)

The operational environment for this example consists of two LPARs and a total of three IMS systems that are participating in shared queues and data sharing.

The following IMSplex migration example assumes:

Continuous availability is a high priority.
All coexistence APARs have been installed.
An example IMSplex consisting of:
LPAR1
- One V13 CQS
- One Common Service Layer (CSL), consisting of an OM, RM, and SCI
- One V13 IMS system named IMSF
- One IMS Connect that is communicating with IMSF, IMSG, and IMSH
LPAR2
- One V13 CQS
- One Common Service Layer (CSL), consisting of an OM, RM, and SCI
- Two V13 IMS systems named IMSG and IMSH

Recommendation: Migrate less complex LPARs before migrating more complex LPARs.

To migrate the IMS systems in this example IMSplex to IMS 15 (V15):

Migrate the subsystems on LPAR1 first by performing the following actions:
1. Prepare the IMSF libraries and data sets for IMS 15 (for example, perform a system definition, set up JCL, and so on).
2. Stop the V13 SCI.
3. Start the V15 SCI.
4. Stop the V13 OM (assuming the same OM name is used before and after the migration).
5. Start the V15 OM.
6. Shut down IMS Connect.
7. Shut down IMSF.
8. Stop the V13 RM.
9. Shut down the V13 CQS.
10. Start the V15 CQS.
11. Start the V15 RM.
12. Coldstart IMSF.
13. Start IMS Connect. If you start IMS Connect before IMSF, IMS Connect issues a datastore unavailable message.
14. Test IMSF. If IMSF does not pass this testing step, consider whether IMSF needs to fall back to V13 and repeat this process after any problems are fixed.
After validating that the migration of IMSF on LPAR1 is successful, start migrating the IMS subsystems on LPAR2 with the following steps:
1. Prepare the IMSG libraries and data sets for IMS 15 (for example, perform a system definition, set up JCL, and so on).
2. Stop the V13 SCI.
3. Start the V15 SCI.
4. Start the V15 OM.
5. Stop the V13 OM.
6. Shut down IMSG.
7. Shut down IMSH.
8. Stop the V13 RM.
9. Stop the V13 CQS.
10. Start the V15 CQS.
11. Start the V15 RM.
12. Cold start IMSG.
13. Restart IMSH.
14. Test IMSG. If IMSG does not pass this testing step, consider whether IMSG needs to fall back to IMS Version 13 and repeat this process after any problems are fixed.
15. After IMSG (V15) has tested successfully, proceed to the next step.
16. Stop the V13 OM.
17. Take IMSH offline and migrate it to IMS 15.