Use the following checklist to migrate to the current z/OS Release with an existing service definition. You may or may not need to reallocate the WLM couple data set, depending on which release you are migrating from.
On OS/390 Release 10, you should be aware of new options available to help system administrators protect critical work, and how these options may affect other work. See Defining special protection options for critical work for more information.
Also, be aware that if you increase your service definition to LEVEL011, your service definition will be subject to a more rigorous verification. Errors may be flagged if you attempt to either save or install your service definition. The application will allow you to save the service definition, but will prevent you from installing it until the errors are corrected.
If you use the Release 10 application to modify a service definition below LEVEL011, these same conditions will instead appear as warnings when you save the service definition. In this case, it will not prevent you from installing the service definition.
For more information, see the discussion of LEVEL011 in Service definition functionality levels, CDS format levels, and WLM application levels.
If you plan on using the Intelligent Resource Director functions available on z/OS Release 1, you may need to define a specific coupling facility structure named SYSZWLM_xxxxyyyy in the CFRM policy. In addition, if you plan on using channel subsystem priority queuing, you'll need to turn on I/O priority management, as described in Specifying I/O priority management.
See The Intelligent Resource Director for more information on these and other steps you may need to take in order to make the Intelligent Resource Director work in your installation.
If you are running mixed MVS™ releases on a sysplex, you need to install the compatibility PTFs on all downlevel systems to enable different levels of workload management to coexist until you can upgrade the entire sysplex to the new release. Refer to z/OS Migration for further details.
The WLM service definition is stored in ISPF tables, or in XML format. When a new release adds certain specifications to the service definition, structural changes to the ISPF tables are required. When you open a service definition whose table structure is different (older) than the one currently used by the WLM application, the WLM application automatically updates the service definition structure. If this occurs, the service definition cannot be read by older levels of the WLM application.
Therefore, it is recommended to start updating a WLM policy with a higher level of administrative application (higher z/OS release) only when you are sure that you do not have to update that policy data set with a lower level of administrative application anymore.
If you ship the service definition PDS between systems (for example, via a TSO transmit, FTP, shared DASD), you need to verify that the sending and receiving systems are at compatible levels.
For more information, see Start the application and enter/edit the service definition. Please note the discussion of service definition functionality levels in Service definition functionality levels, CDS format levels, and WLM application levels. Once you choose to use a new functionality level, from that point on you must always use a level of the WLM application that is compatible with that functionality level. It is recommended that you do not use the new functions (which automatically updates the functionality level) until all those systems are upgraded to the new release.