Skip to content

Migration Strategy

This section:

  • Lists factors that limit how you can migrate to ChangeMan ZMF 8.3.

  • Outlines measures you can take to reduce risk in your migration to the new version.

  • Discusses the advantages of release libraries.

  • Outlines a strategy you can use to convert P (production) instances before you migrate your ChangeMan ZMF D (development) or DP (development-production) instance.

Constraints

All package and component functions begun under pre-8.3 ChangeMan ZMF releases can be continued under version 8.3, including promotion/demotion and install/backout.

However, there are constraints on the migration to ChangeMan ZMF 8.3:

  • There is no process to deconvert from ChangeMan ZMF 8.3 back to a pre-8.3 instance.

    • Because of the changes to the structure of ChangeMan ZMF files, there is no process to deconvert data stores that are processed through conversion programs that prepare them for version 8.3.

    • Installation jobs that are file tailored under ChangeMan ZMF 8.3 will not run successfully under pre-8.3 versions.

  • Only one type of phased migration to version 8.3 is supported: Convert P instances to version 8.3 before you convert D and DP instances.

    You cannot convert DP instances before P instances because installation jobs that are file tailored under ChangeMan ZMF 8.3 will not run successfully under pre-8.3 versions.

  • If you back out a conversion to ChangeMan ZMF 8.3, you must restore all converted ZMF master files to their pre-conversion state. If you back out the conversion after developers have performed work under ZMF 8.3, you will have these problems:

    • There will be no record of the changes that developers made to components between the conversion and the conversion backout. Such changes remain in staging libraries, but these changes are unknown to ChangeMan ZMF, so they will cause audit errors.

    • Staging versions recorded between conversion and conversion backout are lost.

    • Packages and staging libraries that were created between conversion and conversion backout are unknown to ChangeMan ZMF. However, staging libraries created during that time will remain on DASD and in the catalog, and they will interfere with the allocation of staging libraries as developers try to recreate packages that they created under 8.3.

    • Installation jobs that are file tailored between conversion and conversion backout will not run.

Installation JCL Issues

Installation jobs that are file tailored on a pre-8.3 instance can run on a version 8.3 instance. When ChangeMan ZMF 8.3 installation programs process an installation Package data set created under a pre-8.3 version, the Package records are converted to version 8.3 before they are inserted into the ZMF 8.3 Package Master.

The challenge is that the installation JCL created on a pre-8.3 ChangeMan ZMF instance must execute with version 8.3 libraries to install on a version 8.3 instance.

Customers may have devised a solution to this issue when they upgraded ChangeMan ZMF to their current release. Here are two solutions, one solution for customers with a simple ZMF environment, and one solution for customers with a more complex environment:

  • If all of your ChangeMan ZMF instances use the same production load library, you can convert all ZMF instances at the same time, replacing pre-8.3 components in the LOAD library with version 8.3 components.

  • If you have a complex environment and use release libraries (libraries with a unique DSN for each ChangeMan ZMF release), you can use INCLUDE groups for JOBLIB and STEPLIB statements in installation skeletons. By changing the libraries in the INCLUDE group stored in a PROCLIB, you effectively change the JOBLIB libraries in the installation jobs at run time.

Strategies to Reduce Risk

Use these strategies to reduce risk in the process of migrating a pre-8.3 ChangeMan ZMF instance to version 8.3.

  • Segregate delivered vendor versions of components from custom components; store them in separate libraries. Preserve the vendor version of all ChangeMan ZMF 8.3 components so you can revert to the original versions if your modifications do not work as expected.

  • Create new physical libraries for ChangeMan ZMF 8.3 custom and vendor components. Do not update libraries containing pre-8.3 components with version 8.3 components. Not all pre-8.3 components are brought forward into version 8.3.

  • Analyze the ChangeMan ZMF 8.3 components that you can customize, and customize these components as appropriate for your installation and your ChangeMan ZMF version 8.3 instance.

  • Use the ChangeMan ZMF M+R Option to locate and analyze modifications you made to pre-8.3 components. If you do this, keep in mind that customizations you made to components for an earlier ZMF release may no longer apply to components in the new ZMF release distribution libraries. The M+R Option is included in ChangeMan ZMF distribution libraries. Any version of the M+R Option is suitable for this task. If you do not already license the M+R Option, contact your Micro Focus account representative.

  • Preserve ISPF statistics on vendor versions of ChangeMan ZMF components. Micro Focus Customer Care may need the USER and the CHANGED date from the delivered version of a component to help you diagnose problems.

  • Create two sets of change packages for your customized ChangeMan ZMF 8.3 components:

    • Packages with components that are installed into ChangeMan ZMF 8.3 libraries in production, such as exit programs, ISPF messages, panels, and skeletons.

    • Packages with components that are installed into system libraries in production, such as JCL, cataloged procedures, and CLISTs.

    ChangeMan ZMF 8.3 libraries can be populated before the actual conversion. Unless you make the name of your started procedures and log-on CLISTS version specific, you cannot update system libraries until the day a pre-8.3 instance is converted to version 8.3.

  • Test all data conversions in the migration process with copies of your pre-8.3 production data to determine how much DASD is required for intermediate and final files and to determine how long each process will run on conversion day.

  • Create a conversion plan, write a test plan, and build a detailed script for the day of conversion. Build a script for reversing the upgrade in case there are serious problems after conversion that cannot be fixed.

  • Execute a dry-run conversion before you execute the actual conversion. If you have problems, correct the problems and execute the dry-run conversion again until it runs smoothly.

  • Ensure that your conversion scripts contain file backups that create a pre-conversion snapshot that you can reload if you must back out the upgrade of a ChangeMan ZMF instance. Also verify that your backups can be restored. Ensure that your conversion scripts contain post-conversion backups that create a snapshot that is included in your standard disaster recovery backups.

  • Keep all job logs in their entirety from your final conversion activities.

Libraries By Release

There are significant benefits to creating a new set of uniquely named vendor and custom production libraries for each release of ChangeMan ZMF. Unique production libraries allow:

  • Phased migration where there are multiple ChangeMan ZMF instances. Two ZMF releases can coexist in the production environment.

  • A simpler conversion-day process, because most components in the new release can be installed into production before conversion without interfering with the old release.

When you manage custom ChangeMan ZMF components with a ChangeMan ZMF instance, implement unique production libraries for a release by creating a new application for each new ZMF release.

Strategies for Sites with Multiple ChangeMan ZMF Instances

If you have many ChangeMan ZMF instances, you may not be able to upgrade all of those instances to version 8.3 at the same time. If you have uniquely named vendor and custom production libraries for each release of ZMF, you may be able to convert instances individually or in groups:

  • You can convert A (ALL) instances one at a time or in groups.

  • You can convert P instances before you convert the D or DP instances that communicate with them.

  • You can convert a D or DP instance and all of the P instances it communicates with.

You cannot convert a D or DP instance before you convert the P instances that they communicate with. Convert P instances first.

A Release Format Version Field has been Added to the Package Master

A format version field (vvpp, for example, 8300 for ZMF version 8.3) has been added to the global 0 record of the Package Master file. If there is a mismatch between the actual file version format and the file version format that the startup program CMNSTART expects, the Sernet started task will incur a U320 abend with a message in the log that indicates which of the following three master files has the error:

  • Package Master

  • Component Master

  • Long Name Component Master

This abend will happen if you have not run a conversion program on that file to update the format to the correct level for the release that you are installing. To resolve the problem, run the correct conversion JCL, and restart the task. The CMN990 report will show the current versions. The enhancement is intended to prevent you from running a ChangeMan ZMF version with a Package, Component, or Long Name Component Master file that is incompatible with the ChangeMan ZMF version that is being installed.

Prevention of multiple versions of ZMF running in a single ISPF session (U0044)

Different versions of ChangeMan ZMF are incompatible in ISPF split screen mode. User abend 44 blocks users from opening a second session with a different version and can also signify that incomplete SEREX006 exit information has been supplied when it occurs within the ZMF Server started task.