Print class 60 has been reserved for writing JCL to the JES internal reader. By writing the JCL to class 60, a batch job is submitted to the MVS system. The following ADS command may be used:
WRITE PRINTER FROM workline LENGTH 80 CLASS 60.
Where 'workline' is an 80-character JCL or data statement.
After all the JCL records have been written, use the same comma to write one additional record:
/*EOF (followed by 75 spaces)
Many variables must be considered when attempting to determine which batch jobs can run simultaneously without one causing the other to wait or abort. Some of these considerations are discussed
below.
- CV execution.
- Update jobs are generally run under the CV. Since updates are journaled, the job will roll back to the last commit if the job abends. Since the CV manages record locks, more than one batch job may access a single area if their READY modes allow it.
- A large update job doing an area sweep with no COMMITs will probably lock out other jobs trying to access the area. Updated records remain locked until the next COMMIT or FINISH. Such a job can also eat up a lot (or ALL!) of the CV's storage, since the CV must get storage to hold lock tables covering all the records that are locked at one time. If you lock 500,000 records without doing a commit, you can imagine the large amount of storage used for the lock tables.
- To reduce contention within areas, programs should ready areas in the least restrictive mode required by the processing, i.e., if an area is not updated, it should be readied in retrieval mode.
- The CV handles only a fixed number of batch jobs at a time. At the moment, this number is 10, but can be changed. The more jobs running under a single CV, the more work the CV has to do on their behalf, and the slower the throughput will be.
- A SYSCTL DD card is used to run a batch job under a given CV. The dataset name indicates which CV the job is to run under (e.g., IDMS.CV20.SYSCTL, IDMS.CV30.SYSCTL, IDMS.CV40.SYSCTL). No DD cards are required for the areas used by the program because all areas are controlled directly by the CV.
- CV batch jobs require less region to run in than local jobs because the subschema and DMCL are loaded into CV storage instead of the job's own region.
- If you watch the batch job's progress under TSO SDSF, you might see it swapped out a good deal of the time. This is normal, because most of the I/O and CPU resources are being consumed by
the CV, not the batch job itself.
- Local execution.
- All retrieval-only programs (Culprit, reports, etc.) should be run in local mode. Since local jobs are not handled by the CV, they do not count toward the limit on the number of jobs the CV can handle at once. Retrieval-only programs do not require locks or journaling, and they will run faster by running locally.
The only possible danger is that another job might be updating the area that the retrieval job is reading. If an updated database page has not been written out from the CV buffer to the disk, the retrieval job may experience a broken-pointer situation. This rarely occurs, and the job will usually rerun successfully.
Note: A retrieval job is defined as one that actually readies its areas in retrieval mode, NOT one that readies them in update mode but only reads from the areas. There is a big difference
in the way these two types of programs are handled. The IDMS software assumes that if you ready an area in update mode, you intend to do some updating and that you need some protection from other update run units.
- Update jobs can also run in local mode. If they do, all the areas used by the job must first be varied offline from the CV. The areas must be backed up to tape. Since no journaling occurs while the job is executing, no rollbacks can occur if the program abends. In the case of an abend, the database areas must be restored from the backup tape. While the areas are offline to the CV, no jobs running under the CV can access those areas no local update jobs can access the areas however, local retrieval jobs can access
the areas.
- Reasons for running an update job in local mode include:
- To make a long-running job run much faster.
- To prevent a large update job with no COMMITs from either eating up all the CV's storage or filling up the journals.
Note: When a CV journal fills up, uncommitted updates must remain on the disk journal in case the entire run unit must be rolled back after an abend. If a single job fills up all 4 CV journals, the entire CV comes to a stop. Likewise, if all the CV's storage is used up by lock tables, the CV comes to a stop. The moral of the story is to always build COMMITs and restartability into a batch program.
- If an IDMS job step does not have a SYSCTL DD card in it, the step will run locally, not under the CV.
- In converting a CV job to a local job, more region is usually required because the local job must load the subschema and DMCL into its own region. The STEPLIB concatenation must contain not only the library containing the program, but also the libraries containing the Computer Associates system software.
- Shared retrieval.
- Any jobstep that readies all areas in shared retrieval should run local mode, not under the CV. No locks or journaling are needed. Rarely, a broken-chain condition might seem to occur if an update job is running simultaneously and one of the update pages is still in the output buffer. Some steps of a single job may run locally while others run under the CV.
- A local retrieval job can access areas regardless of what other jobs are updating or reading those areas. A CV retrieval job cannot access areas that have been varied offline to the CV however, it can access areas that have been varied retrieval-only.
- Shared update.
- Any jobstep that updates an area usually readies the area in shared update mode. This allows other retrieval and shared-update jobs to access the area at the same time. Record deadlock can occur if two jobs lock two records in reverse order. Timeout abends can occur if one job has to wait too long to get to a record that has been locked by the other job. Frequent commits (after every 1000 records or so) can prevent the latter problem, but a "deadly embrace" deadlock is often unavoidable both jobs' paths must
be nearly identical to avoid this situation from occurring.
- Protected update.
- An area readied in protected update mode is inaccessible to any other run units that wish to ready the area in shared or protected update however, other retrieval run units may access the area simultaneously. Since the CV knows that only this job is updating the area, the CV doesn't have to maintain lock tables to keep track of which records are locked by whom therefore, the job will not run the risk of grabbing all the CV's storage. The job should run faster than it would in shared retrieval mode because the CV does not have to inspect any gigantic lock tables before each update.
- Protected update mode is unsuitable for any batch job that might run during the day when the online system is active because the online user cannot update the area until the batch job finishes.
