Writing Routines to Handle Special Installation Input The CMS Batch Facility can handle user-specified control language and
special installation batch facility /JOB control cards. These handling
mechanisms are built into the system in the form of user exits from
batch; you are responsible for generating two routines to make use of
them. These routines must be named BATEXITl and BATEXIT2, respectively,
and must have a filetype of TEXT and a filemode number of 2 if placed on the system disk or an extension of the system disk. (See the for information on how to write and use CMS Batch Facility
control The routines you write are responsible for saving
registers, including general register 12, which saves addressability for
the batch facility. These routines (if made available on the system
disk) are included with the eMS Batch Facility each time it is loaded. BATEXIT1: PROCESSING USER-SPECIFIED CONTROL LANGDAGE BATEXIT1 is an entry point provided so that users may write their own
routine to check non-CMS control statements. For example, a routine
could be written to scan for the OS job control language needed to
compile, link edit, and execute a FORTRAN job. BATEXITl receives
control after each read from the CMS Batch Facility virtual card reader
is issued. General register 1 contains the address of the batch
facility read buffer, which contains the card image to be executed by
the batch' facility. This enables BATEXITl to scan each card it receives
as input for the type of control information you specify.
If, after the card is processed by BATEXIT1, general register 15
contains a nonzero return code, the eMS Batch Facility flushes the card
and reads the next card. If a zero is returned in general register 15,
the batch facility continues processing by passing the card to CMS for
execution. BATEXIT2: PROCESSING THE BATCH FACILITY /JOB CONtROL CARD BATEXIT2 is an entry point provided so that users can code their own
routine to use the /JOB card for additional information. EATEXIT2 receives control before the VM/370 routine used to process the batch
facility /JOB card begins its processing, but after CMS has scanned the /JOB card and built the parameter list. When EATEXIT2 is processing,
general register 1 points to the CMS parameter list buffer. This buffer
is a series of 8-byte entries, one for each item on the /JOB card. If
the return code found in general register 15 resulting from EATEXIT2 processing of this card is nonzero, an error message is generated and
the job is flushed. If general register 15 contains a zero, normal
checking done for a valid userid and the existence of an account Finally, execution of this job begins.
Part 3. Conversational Monitor System (CMS) 317

EXEC Procedures for the Batch Facility Virtual Machine You can control the CMS Batch Facility virtual machine using EXEC procedures. For example, you can use an EXEC: • To produce the proper sequence of CP/CMS commands for users who do
not know CMS commands and controls. • To provide the sequence of commands needed to execute the most co.mon jobs (assemblies and compilations) in a particular installation.
For information on how to use the EXEC facility to control the batch
facility virtual machine, see the Data Security under the Batch Facility After each job, the CMS Batch Facility will load (via IPt) itself.
destroying all nucleus data and work areas. All disks to which links
were established during the previous job are detached.
At the beginning of each job, the batch facility work disk is
accessed and then immediately erased, preventing the current user job
from accessing files that might remain from the previous job. Because
of this, execution of the PROFILE EXEC is disabled for the CMS Batch
Facility machine. You may, however, create an EXEC procedure called BATPROF EXEC and store it on any system disk to be used instead of the
ordinary PROFILE EXEC. The batch facility will then execute this EXEC at each job initialization Improved IPL Performance Using a Saved System Since the CMS Batch processor goes through an IFL procedure after each
user j-ob, an installati-on may experience a -more efficient IPL procedure by using a saved CMS system when processing batch jobs.
This can be accomplished by passing the name of the saved system to
the CMS Batch Facility via the optional "sysname" operand in the
CMSBATCH command line.
The batch facility saves the name of the saved system until the end
of the first job, at which time it stores the name in the IPL command line both as the "device address" and as the PARM character string. The
latter entry informs the CMS initialization routine (DMSINS) that a
saved system has been loaded and that the name is to be saved fer
subsequent 1PL procedures. When using the CMS SET command, the BLIP operand is ignored when
issued from the CMS batch machine.
318 IBM VM/370 System Programmer's Guide