Using IBM Health Checker for z/OS for migration checking

Beginning with z/OS V1R10, the IBM® Health Checker for z/OS® infrastructure is being exploited for migration purposes. Checks are being added to help you determine the applicability of various migration actions. Before you migrate to your new z/OS release, you should use these new checks to assist with migration planning. After you migrate, you should rerun them to verify that the migration actions were successfully performed. As with any IBM Health Checker for z/OS check, no updates are made to the system. These new migration checks only report 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 information, see Accommodate new address spaces and Convert your existing IBM Health Checker for z/OS setup for automatic start-up.

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

The names of migration checks follow the convention ZOSMIGVvvRrr_component_program_name (or, for ICSF, ICSFMIGnnnn_component_program_name). Notice the "MIG" characters followed immediately by the release identifier. This convention tells you that the check helps with migration and it tells you the release in which the migration action was introduced. If the release in which the migration action was introduced is not known, the name will be ZOSMIGREC.
By default, migration checks are inactive.

System REXX health check considerations:

All exploiters of the System REXX support in z/OS require that the System REXX customization be performed. Using the IBM Health Checker for z/OS health checks is one example of possible System REXX exploitation. In particular, any compiled REXX execs must have the proper runtime support available from the Alternate Library for REXX (available in z/OS since V1R9) or from the IBM Library for REXX on zSeries (5695-014). Several IBM Health Checker for z/OS migration health checks have been written in compiled System REXX. These health checks rely upon the System REXX customization and runtime activities being completed. If System REXX (and the security environment that System REXX requires) have not been properly customized, then System REXX health checks will not execute successfully.

For System REXX customization activities, see "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 to product documentation accompanying the IBM Alternate Library for REXX.

Remember that migration checks are intended to be used on your current z/OS release and then again after you have migrated to your new z/OS release. The steps you might follow in each of these two scenarios are listed.

On your current z/OS release:

Install the latest migration checks. Review all the latest health checks (for both best practices and migration) by using the functional PSP bucket HCHECKER (which is SMP/E FIXCAT IBM.Function.HealthChecker).
You might want to install the PTFs during a regular service window so that an IPL is scheduled afterwards. 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. Additional migration checks can be added at different times, so having all the latest ones installed before making your migration plans is recommended.
Activate the migration checks appropriate to your migration path. Because the naming convention for migration checks indicates which release introduced the corresponding migration actions, you can activate just the checks 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 V1R12 to z/OS V2R1 you need to activate the migration checks for changes that occurred in both z/OS V1R13 and z/OS V2R1. If you are migrating from z/OS V1R13 to z/OS V2R1, you only need to activate the migration checks for changes that occurred in z/OS V2R1. There are many ways to make a check active, as well as many ways of using 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*,ZOSMIGV2R1)
Remember that for z/OS, two naming conventions are used: one for ICSF (that starts with ICSFMIGnnnn) and one for the rest of z/OS (that starts with ZOSMIGVvvRrr). Use a wildcard filter that includes the intended migration checks.
Review the migration check output and rerun checks as appropriate. Any exceptions should be addressed in your migration plan. If you can complete the migration action before moving to the new z/OS release, you can rerun the check to verify that it was completed correctly on your current system.
Deactivate the migration checks if you desire. 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*,ZOSMIGV2R1)

After you have migrated to the new z/OS version and release, the steps are similar:

Install the latest migration checks. New migration checks might be available for your new z/OS system since you installed it. Therefore, review all the latest health checks (for both best practices and migration) by using the functional PSP bucket HCHECKER (which is SMP/E FIXCAT IBM.Function.HealthChecker).
Activate the migration checks appropriate to your migration path. For migration verification, activate the checks appropriate on the release you are migrating from, migrating through, and migrating to. For example, if you are migrating from z/OS V1R12 to z/OSV2R1, you need to activate the migration checks for changes that occurred in both z/OS V1R13 and z/OS V2R1. If you are migrating fromz/OS V1R13 to z/OS V2R1, you only need to activate the migration checks for changes that occurred in z/OS V2R1. Here are some examples of using the MODIFY command to make checks active. (These are the same activation commands shown previously.)
- F HZSPROC,ACTIVATE,CHECK=(IBM*,*MIG*)
- F HZSPROC,ACTIVATE,CHECK=(IBM*,ICSFMIG*)
- F HZSPROC,ACTIVATE,CHECK=(IBM*,ZOSMIGV2R1)
Review the migration check output and rerun checks as appropriate. Any exceptions, which could indicate that a migration action was not performed correctly, should be addressed. Rerun the check after the corrections have been made.
Deactivate the migration checks. Once your migration verification is complete, deactivate the migration checks similar to the way you activated them. For example (using the same deactivation commands shown previously):
- F HZSPROC,DEACTIVATE,CHECK=(IBM*,*MIG*)
- F HZSPROC,DEACTIVATE,CHECK=(IBM*,ICSFMIG*)
- F HZSPROC,DEACTIVATE,CHECK=(IBM*,ZOSMIGV2R1)

Within this document, the migration actions that have checks are clearly identified within the migration actions. All of the checks are made by IBM Health Checker for z/OS but, as stated earlier, some of the checks are the new migration checks (identified by names that start with ZOSMIGVvvRrr or ICSFMIGnnnn) and others are regular health checks.

Note that 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 solely on checks.