Using IBM Health Checker for z/OS for migration checking

Before you migrate to a new z/OS release, you can use IBM® Health Checker for z/OS® to assist with migration planning. Migration checks can help you determine the applicability of various migration actions to your current system. As with other checks provided by IBM Health Checker for z/OS, no updates are made to the system. Migration checks report only on the applicability of specific migration actions on a system, and only on the currently active system.

Note: As of z/OS V2R1, the IBM Health Checker for z/OS is started automatically at initialization. For more information, see Accommodate new address spaces and Convert your existing IBM Health Checker for z/OS setup for automatic start-up.

Migration checks are similar to the other checks provided by IBM Health Checker for z/OS. The only differences are:

Migration checks are inactive by default.
The names of migration checks begin with the characters ZOSMIG. Following this prefix is a value to help you plan the timing of the migration action, as follows:
ZOSMIGVvRr_NEXT

Migration action is recommended, but will become a required migration action in the release after VvRr.

ZOSMIGVvRr_NEXT2

Migration action is recommended, but will become a required migration action two releases after VvRr.

ZOSMIGVvRr

Migration action is required in the release indicated by VvRr.

ZOSMIGREC

Migration action is recommended for the foreseeable future. The migration action might never be required.

ZOSMIGREQ

Migration action that is recommended now, but will be required in a future release.

Note: In previous releases, the names of migration checks followed a different set of naming conventions: one for ICSF, which used the convention ICSFMIGnnnn_component_program_name, and one for the rest of z/OS, which used the convention ZOSMIGVvvRrr_component_program_name.

On your current z/OS release, follow these steps:

Install the latest migration checks. Review all the latest health checks for both best practices and migration by using the SMP/E FIXCAT IBM.Function.HealthChecker.
You might want to install the PTFs during a regular service window, so that an IPL is scheduled afterward. Checks are often added by a function when it is started or restarted, so you might find that installing the PTFs before a scheduled IPL works best for you. More migration checks can be added at different times, so having all the latest checks installed before making your migration plans is recommended.
Activate the migration checks that are appropriate to your migration path. Because the naming convention for migration checks indicates which release introduced the corresponding migration actions, you can activate only the checks that are appropriate for your migration path. Using SDSF (or another method for viewing checks, such as filters), you can view ahead of time which migration checks you have available on your system. For example, if you are migrating from z/OS V1R13 to z/OS V2R2, you must activate the migration checks for changes that occurred in both z/OS V2R1 and z/OS V2R2. If you are migrating from z/OS V2R1 to z/OS V2R2, you need to activate only the migration checks for changes that occurred in z/OS V2R2. There are many ways to make a check active, and many ways to use wildcards to include specific checks.
Here are some examples of using the MODIFY command to make checks active:
- F HZSPROC,ACTIVATE,CHECK=(IBM*,*MIG*)
- F HZSPROC,ACTIVATE,CHECK=(IBM*,ICSFMIG*)
- F HZSPROC,ACTIVATE,CHECK=(IBM*,ZOSMIG*)
Review the migration check output and rerun checks. Any exceptions should be addressed in your migration plan. If you can complete the migration action before you move to the new z/OS release, you can rerun the check to verify that it was completed correctly on your current system. In some cases, the check might be available for running on the new z/OS release for verification after that release is IPLed.
Deactivate the migration checks if you want. If you no longer desire to have the migration checks active, you can deactivate them similar to the way you activated them. For example:
- F HZSPROC,DEACTIVATE,CHECK=(IBM*,*MIG*)
- F HZSPROC,DEACTIVATE,CHECK=(IBM*,ICSFMIG*)
- F HZSPROC,DEACTIVATE,CHECK=(IBM*,ZOSMIG*)

Within this document, the migration actions that have checks are clearly identified within the migration actions.

Not all migration actions in this document are addressed by checks; many migration actions do not lend themselves to programmatic checking. Therefore, use this document to prepare your migration plan and do not rely on checks only.

System REXX considerations

Several IBM Health Checker for z/OS migration health checks are written in compiled System REXX. These health checks rely on System REXX customization and runtime activities being completed. If System REXX and the security environment that System REXX requires has not been properly customized, the System REXX health checks will not run successfully. Also, the compiled REXX execs must have the proper runtime support from the Alternate Library for REXX (available in z/OS since V1R9) or from IBM Library for REXX on zSeries (5695-014).

Note: To allow System REXX to use JES services, the AXRnn address spaces are started under the primary subsystem. Therefore, you must end the AXRnn address spaces before you shut down JES2. You do not have to stop the AXR address space; this action only affects the secondary AXRnn address spaces.

More information is available in the following references:

For information about System REXX customization, see the topic on System REXX in z/OS MVS Programming: Authorized Assembler Services Guide.
For compiled REXX exec runtime availability, see "Alternate Library for REXX Customization Considerations" in the z/OS Program Directory, or see the product documentation that accompanies IBM Alternate Library for REXX.