eMS Batch Facility The CMS Batch Facility is a VM/370 programming facility that runs under
the CMS subsystem. It allows VM/370 users to run their jobs in batch
mode by sending jobs either from their virtual machines or through the
real (system) card reader to a virtual machine dedicated to running
batch jobs. The CMS Batch Facility then executes these jobs, freeing
user machines for other uses.
If both CMS Batch Facility and the Remote spooling Communications Subsystem (RSCS) are being executed under the same VM/370 system, job
input streams can be transmitted to the batch facility from remote
stations via communication lines. Also, the output of the batch
processing can be transmitted back to the remote station. For additional
information, see "Remote Job Entry to CMS Batch" in the The CMS Batch Facility virtual machine is generated and controlled on
a userid dedicated to execution of jobs in batch mode. The system
operator generates the "batch machine" by loading (via IPL) the C"S subsystem, and then issuing the CMSBATCH command. The CMSBATCH module
loads the DMSBTP TEXT S2 file, which is the actual batch processor.
After each job is executed, the batch facility will IPL itself, thereby
providing a ccntinuously processing batch machine. The batch processor
will IPL itself by using the PARM option of the CP 1PL command, followed
by a character string that CMS recognizes as peculiar to a batch virtual
machine performing its IPL. Jobs are sent to the batch machine's
virtual card reader from users' terminals and executed sequentially. When there are no jobs waiting for execution, the CMS Batch Facility
remains in a wait state ready to execute a user job. See the for more information about controlling the batch
machine.
The eMS Batch Facility is particularly useful for compute-bound jobs
such as assemblies and compilations and for execution of large user
programs, since interactive users can continue working at their
terminals while their time--consulling jobs are run in another virtual
machine.
The system programmer controls the batch facility virtual machine
environment by resetting the CMS Batch Facility machine's system limits,
by writing routines that handle special installation input to the batch
facility, and by writing EXEC procedures that make the CMS Batch
Facility facility easier to use.
Resetting the eMS Batch Facility System Limits
Each job running under the CMS Batch Facility is limited by default to
the maximum value of 32,767 seconds of virtual processor time, 32,767
punched cards output, and 32,767 printed lines of output. You can reset
these limits by modifying the BATLIMIT MACRO file, which is found in the CMSLIB macro library, and by reassembling DMSBTP. 316 IBM VM/370 System programmer's Guide

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