Tracker, Data Store, and Output Collector considerations
When you migrate a tracker, it is not necessary for EQQEVDS and EQQSUDS 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.
- In the Data Store, it is not necessary for EQQPKI01, EQQSKI01, EQQSDFnn, EQQUDFnn to be empty.
- In the controller:
- If the CP files are kept, it is not necessary for EQQPKI01, EQQSKI01, EQQSDFnn to be empty.
- If the CP files are deleted, EQQPKI01, EQQSKI01, EQQSDFnn must 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 HCL Workload Automation for Z 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 HCL Workload Automation for Z. 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 HCL Workload Automation for Z
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.