Parallel testing

If you want to perform the migration and then continue immediately into parallel testing in a job-tracking environment,you can use the following procedure as a guide. However, you should carefully consider the applicability of this procedure in your own Tivoli Workload Scheduler for z/OS configuration.

1. Stop your production system.
2. Perform data set conversion and copying.
3. Start your production system.
4. |Start Tivoli Workload Scheduler for z/OS, Version 8.6.

You should also consider:

• If you start the JCC in both the production system and Tivoli Workload Scheduler for z/OS, the two JCCs cannot delete or requeue SYSOUT from the same SYSOUT class.
• Do not specify HOLDJOB(YES) or HOLDJOB(USER) for more than one of the two systems. If you do, one system might incorrectly release jobs that are held by the other system.
• When you convert the VSAM data sets, it is recommended that you run the conversion of the JS file to verify that conversion has been done correctly. Then, before running the parallel test, reallocate empty JS files. (Otherwise, the test system might find valid production JCL on the active JS file and submit it to the JES subsystem.)
• You should start with an empty JCL library data set (EQQJBLIB). Otherwise, the test system might submit production JCL incorrectly. To test that Tivoli Workload Scheduler for z/OS submits jobs correctly, you should create test applications with job names that are not known to the production system. JCL for those jobs could then safely be inserted into EQQJBLIB.
• On the test system you should specify TRACK(ALL) and SUBFAILACTION(R) on the JTOPTS initialization statement.
• TSO commands or subroutines that have a specific name for the subsystem parameter will not report events to the test system. You should update any procedures, which are dependent on TSO commands or subroutines, if events should also be reported to the test system.
• If you are migrating from a previous release of Tivoli Workload Scheduler for z/OS and you use NetView® or a similar product to intercept messages, make sure that WTO (write-to-operator) messages are not issued by the test system. Otherwise, the test system might trigger some processing that impacts the production system. You should not use alert WTOs, deadline WTOs, or WTO operations on the test system.
• If you want to use Restart and Cleanup when in the old subsystem is running a JCC task, you must specify the keyword DSTCLASS in the RCLOPTS statement of the new controller. The class specified in DSTCLASS must not be one of the classes specified in the JCC parameter CHKCLASS. This will prevent the JCC task from deleting the duplicate SYSOUT copy created for the Data Store before it has been successfully stored. Refer to Customization and Tuning for further details.

Using the preceding notes as a guide, you will be able to run one production system and one Tivoli Workload Scheduler for z/OS test system in parallel. The work with the database dialogs and the long-term-planning functions can be fully tested this way. The job-tracking functions of the test system will be incomplete because only the specially created test jobs will be submitted by the test system. However, the tracking of work, including the tracking of applications and jobs in the production area, will be done normally.