Tracker, Data Store, and Output Collector considerations

When you migrate a tracker, it is not necessary for EQQEVDS to be empty. The migration enables you to use the subsystem with the new release and modifies the JCL trackers to point to the libraries used, for example EQQMLIB or STEPLIB.

The first time you start a tracker migrated to a new version, ensure that in the OPCOPTS statement you specified BUILDSSX(REBUILD) and SSCMNAME(EQQSSCMP,PERMANENT). However, this setting of OPCOPTS might cause the loss of some data set triggering events on the tracker; to prevent this from occurring, do not set BUILDSSX(REBUILD) and SSCMNAME(EQQSSCMP,PERMANENT) but set the INITRTN and INITPARM of the IEFSSNnn member in SYS1.PARMLIB as follows:

SUBSYS SUBNAME(subsysten name)
INITRTN(module name)
INITPARM('maxecsa,suffix')

In this way, after the IPL of the z/OS system, the tracker will be migrated without requiring any parameter change. Because the Z controller and trackers can communicate even if they are at different versions, you can migrate the trackers before or after migrating the Z controller.

When you migrate a Data Store, consider that:

In the Data Store, it is not necessary for EQQPKI01, EQQSKI01, EQQSDFnn, EQQUDFnn to be empty.
In the Z controller, it is not necessary for EQQPKI01, EQQSKI01, and EQQSDFnn to be empty.

The data store and controller tasks might be migrated at different times, provided that the maintenance level of the old and new release of IBM Z Workload Scheduler is the same. This means that you should apply any PTF which affects both controller and data store code to both releases of the product. If this level of concurrent PTF maintenance cannot be maintained, it is best to keep the data store and controller on the same release of IBM Z Workload Scheduler. If the migration is successfully performed, you should be able to use the Restart and Cleanup function on the new release for any operation which was on the error list on the old release of IBM Z Workload Scheduler

If you change a datastore connection type and you want to reflect the naming convention in the FLOPTS destination name, keep the former destination name in the FLOPTS parameter that corresponds to the connection type to be used (SNADEST, XCFDEST, or TCPDEST ). For example, suppose that you change the datastore connection from SNA to XCF and the former FLOPTS is SNADEST(OPCTRK1.DST). If you want to use XCFTRK1.DST as new destination name, specify the following FLOPTS parameter: XCFDEST(OPCTRK1.DST, XCFTRK1.DST). Omitting the former destination produces the messages EQQFL18E and EQQM643W in the controller message log, when retrieving any joblog stored with the former destination name.

Output collector is not to be migrated.