Use Considerations

If you are migrating your JCT data set in preparation for the installation of a higher release of JES3, see Migrating Using IATUTJCT for information performing this migration.
Allocate your new JCT data set and primary checkpoint data sets, and (optionally) your new alternate checkpoint data set. In doing this:
- Be certain to allocate these data sets in cylinders with only one extent.
- Be certain that your new JCT data set is large enough for your planned job number range, plus 64 spare JCT entries needed for write-error recovery. See Determining the size of the JCT data set for information on calculating the size of the JCT.
  Note:
  1. If you migrate the JCT data set from a "lower version" to a "higher version", you must allocate a larger JCT data set to accommodate the same number of jobs because the JCT entry size in the "higher version" is larger.
  2. Your new JCT data set can be smaller than your old JCT data set if the JCT contains sufficient job capacity for the job number range on the options initialization statement. If you discover later that you need more capacity, you will then have to allocate a larger JCT data set and run IATUTJCT again.
In JES3 installations where SYS1.PROCLIB is not shared, install the IATUTJCT procedure separately on any processor where IATUTJCT is to run.
Define the procedure to the security product.
- Define either a profile for the started task in the STARTED security class or an entry in the started task table (ICHRIN03).
- Provide the userid under which the procedure is to run with at least read access to the old JCT and checkpoint data sets and update access to the new JCT and primary checkpoint data set.
Note:
1. If your processors do not share the security product's data base and the STARTED security class is used to define IATUTJCT's security environment, define the STARTED class identically on any processor where IATUTJCT is to run.
2. If you use the started task table to define IATUTJCT's security environment, define the entry for the started task table identically on any processor where IATUTJCT is to run.
Either change the JES3 start-up procedure in SYS1.PROCLIB to allow names of your checkpoint data sets (and JCT data set, if not defined by the DYNALLOC initialization statement) to be specified as symbols, or install a new JES3 procedure in SYS1.PROCLIB to point to the new data sets.
For a new start-up procedure:
- Define an entry in the STARTED security class or an entry in the started task table (ICHRIN03)
- Create a new SYS1.PARMLIB(IEFSSNxx) member pointing to the new name of the procedure you are creating as a subsystem with the PRIMARY attribute.
If you use the DYNALLOC statement to define the JES3JCT DD name, create a new initialization stream member that points to the new JCT data set.
If you want to test IATUTJCT, you can start it with JES3 up or down.
Note: You might want to test IATUTJCT in order to make sure that the new data sets are acceptable and that the new JCT data set is large enough to contain all the jobs from the old JCT data set plus 64 spare JCT entries for error recovery.
See Testing IATUTJCT Processing for more testing information.
When you are ready to copy the checkpoint and JCT data sets to the new ones you intend to use, stop all CIFSS address spaces and bring JES3 down on the global processor and all local processors. If you have any other started tasks or jobs that refer to the JCT or checkpoint data sets, such as user-written spool browsers, bring them down also.
Start IATUTJCT with the SUB=MSTR parameter. If you are migrating from a "lower version" to a "higher version," use the P=MIGRATE parameter. If you are falling back from a higher JES3 release to a lower JES3 release, use the P=FALLBCK parameter. You need to run IATUTJCT only once in a JES3 complex, and you can run it on the global or any local processor.
Figure 1. IATUTJCT Utility Start Command
```
S IATUTJCT,SUB=MSTR
```
Figure 2. IATUTJCT Utility Migrating Start Command
```
S IATUTJCT,P=MIGRATE,SUB=MSTR
```
Figure 3. IATUTJCT Utility Fallback Start Command
```
S IATUTJCT,P=FALLBCK,SUB=MSTR
```
Note: No parameter value for P= other than MIGRATE or FALLBCK is allowed.
If IATUTJCT fails, or if you decide to not switch to the new data sets, you must restart JES3 with the old data sets. You can perform a hot start, hot start with refresh, or IPL with a warm start. If you have changed the initialization stream (the JES3JCT DYNALLOC statement to point to the new JCT data set) and you perform a hot start with refresh or a warm start, do not use the initialization stream member containing the change.
If you defined an alternate JES3 procedure as a primary subsystem on the global, IPL the global pointing to the new IEFSSNxx parameter.
If IATUTJCT is successful, restart JES3 on the global pointing to the new data sets. You must begin using the new checkpoint data sets and the new JCT data set at the same time. Do not mix old and new data sets.
- If your JCT data set is dynamically allocated and you are changing its cataloged status from cataloged to uncataloged or from uncataloged to cataloged, you must perform a hot start with refresh or warm start.
- If you perform a warm start or hot start with refresh and you define the JES3JCT DD using the DYNALLOC statement, you must use the initialization stream that you previously created, pointing to the new JCT data set.
All converter/interpreter (CIFSS) startup procedures must be updated to point to the new checkpoint data sets. Or, you could make new CIFSS procedures that point to the new checkpoint data sets and then use the *MODIFY,F command to change the FSS to use the new procedure. Because a CIFSS startup procedure cannot accept JCL symbolics, you must change the DD statements within the procedure before restarting the CIFSS address spaces.
If you defined an alternate JES3 procedure as a primary subsystem on the locals, IPL all locals pointing to the new IEFSSNxx member.
Restart JES3 on all locals pointing to the new data sets.
Start all CIFSS procedures pointing to the new checkpoint data sets.
If you have any other started tasks or jobs that refer to the JCT or checkpoint data sets, such as user-written spool browsers, change their data set references to the new JCT data set, and restart them at your convenience.
Rename or delete the old checkpoint and JCT data sets so that you do not accidentally use them again. When you have started using the new data sets, you must not revert to the old data sets. If you do, you risk corruption of the JES3 job queue possibly leading to conditions from which a cold start is required to recover.