Migration strategies

You need to consider these points when deciding the appropriate migration strategy for your enterprise:

JES and SMF exits

JES and SMF exits supplied with Tivoli Workload Scheduler for z/OS can also track work for previous releases. The exits are always downward compatible.

Consider installing JES and SMF exits in your current production environment at least a week before you plan to migrate any of the address spaces to Tivoli Workload Scheduler for z/OS.

Migrating to existing subsystem definitions

You can migrate from or fall back to your current subsystems without having to IPL the z/OS system.

By continuing to use your current subsystem names, you do not need to consider the effect of migration on these users of Tivoli Workload Scheduler for z/OS services:

Keeping the same subsystem names reduces the installation effort of a new level of Tivoli Workload Scheduler for z/OS.

Migrating to new subsystem definitions

If you want to parallel-test the new level of Tivoli Workload Scheduler for z/OS with your current level, you must create new subsystems for the Tivoli Workload Scheduler for z/OS address space.

Getting the right software parts

The Tivoli Workload Scheduler for z/OS load modules, panels, messages, and other software parts have the same name as they had in previous Tivoli Workload Scheduler for z/OS releases. You must ensure that the users of Tivoli Workload Scheduler for z/OS services run the same level of software as the subsystem address space.

Load modules

You can decide if you want to use the same data set name for the Tivoli Workload Scheduler for z/OS load modules as your previous environment. However, consider the additional effort required on your part to coordinate the JCL changes required for callers of Tivoli Workload Scheduler for z/OS services such as:

If the Tivoli Workload Scheduler for z/OS load library is not referenced in the STEPLIB DD statement, ensure that the Tivoli Workload Scheduler for z/OS library is listed first in the LNKLST concatenation and that the library remains empty until you are ready to cut over to Tivoli Workload Scheduler for z/OS on the production system. Then you should copy the load modules into the library and perform an LLA refresh.

Two Tivoli Workload Scheduler for z/OS load modules must always be in a LNKLST library:

EQQINITn
The subsystem initialization module
EQQSSCMn
The subsystem communication module.

However, this does not mean that you must reinitialize the subsystem to cut over Tivoli Workload Scheduler for z/OS to production. The module names defined for EQQINIT and EQQSSCM in the SYS1.PARMLIB subsystem name table (IEFSSNnn) can be overridden when a Tivoli Workload Scheduler for z/OS address space is created.

The EQQMINOx load module requires special attention. EQQMINOx is the scheduler's dialog interface module, is invoked by TSO SERVICES, and passes dialog requests and data to the controller. EQQMINOx must run APF authorized, therefore it must reside in an authorized library. By this token, keep in mind that any unauthorized library in a STEPLIB or LIBDEF concatenation makes the entire concatenation unauthorized. So remember to identify the library where EQQMINOx resides.

The BUILDSSX keyword of the OPCOPTS initialization statement can be used to rebuild the environment created during subsystem initialization at the new software level. When the address space is terminated, the previous environment is reinstated, thereby ensuring fallback to a previous release of Tivoli Workload Scheduler for z/OS.

SSCMNAME keyword of the OPCOPTS initialization statement can be used to permanently, or temporarily, replace the EQQSSCMn module that was loaded into common storage at IPL. When the TEMPORARY value is defined, the named module is loaded into private storage of the Tivoli Workload Scheduler for z/OS address space, therefore events created while the address space is not active will use the EQQSSCMn from the previous IPL. When PERMANENT is specified, the old EQQSSCMn in common storage is replaced.

Permanent replacement of the EQQSSCMn module effects the SSX and prevents reinstatement of the subsystem to a previous release or version.

Notes:
  1. Do not specify PERMANENT in the SSCMNAME keyword and BUILDSSX(REBUILD) until you are certain that you will not need to fall back to a previous version or release.
  2. Create backup copies of the old load module library before you replace the objects.
The ISPF environment

Tivoli Workload Scheduler for z/OS ISPF dialog users must run software parts that are at the same level as the controller address space. Again, using the same data set names for software parts libraries, such as messages and panels, negates the requirement to change TSO logon procedures.

If you use the same data set names, instruct dialog users to return to the TSO READY prompt after you have replaced the software parts and before they try to communicate with a Tivoli Workload Scheduler for z/OS controller.

The Tivoli Workload Scheduler for z/OS ISPF profile is automatically reinitialized when the EQQOPCAP panel (the Tivoli Workload Scheduler for z/OS main menu) is first displayed for a new release. Dialog users must enter the Tivoli Workload Scheduler for z/OS options dialog and redefine required values, such as the subsystem name.

Be sure to create backup copies of the old libraries before you replace the objects.

When migrating from one release of Tivoli Workload Scheduler for z/OS to the next, the LOADLIB, PANELLIB, MSGLIB, CLIB, and SKELLIB for the right Tivoli Workload Scheduler for z/OS release must be invoked from the TSO ISPF dialogs. Remember to identify the library where EQQMINOx resides.