USER CMSBATCH BATCH 1M 2M BG ACCOUNT 13 SYSTEM OPTION ACCT
IPL CMS CONSOLE 009 3215 SPOOL OOC 2540 READER * SPOOL OOD 2540 PUNCH A SPOOL OOE 1403 A
LINK MAINT 190 190 RR MDISK 195 3330 xxx 010 I paswrd I W 'rdpswd' 'wrtpswd'
'allpswd
'
Consult VM I SP Planning Guide and Reference the proper coding of the directory
macro parameters.
Note: There is no 191 MDISK for the CMS Batch Machine.
In order to have the CMS Batch Machine autologed, you should have the following
entry in the autolog virtual machine's PROFILE EXEC: AUTOLOG CMSBATCH BATCH CMSBATCH
Otherwise, the operator logs on to the CMS Batch Machine and enters
"CMSBATCH" followed by "DISCONNECT" (if the CMS Batch Machine is to
run in DISCONNECT status).
Note: Refer to VM I SP CP Command Reference for General User's for more
information on the AUTOLOG command.
Resetting the eMS Batch Facility System Limits
Each job running under the CMS Batch Facility is limited by default to the maxi­
mum value of 32,767 seconds of virtual processor time, 32,767 punched cards out­
put, 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.
Writing Routines To Handle Special Installation Input
The CMS Batch Facility can handle user-specified control language and special
installation batch facility 110B control cards. These handling mechanisms are built
into the system in the form of user exits from batch; you are responsible for gener­
ating two routines to make use of them. These routines must be named
BATEXIT1 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 VM I SP CMS User's Guide for information on how to write and use CMS Batch Facility control cards.) The routines you write are responsible for sav­
ing registers, including general register 12, which saves address ability for the batch
facility. These routines (if made available on the system disk) are included with the CMS Batch Facility each time it is loaded.
BATEXITl: Processing User-Specified Control Language
BATEXIT 1 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. BATEXIT1 receives control after each read from the CMS Batch
Facility virtual card reader is issued. General register 1 contains the address of the
The CMS Batch Facility 419

batch facility read buffer, which contains the card image to be executed by the
batch facility. This enables BATEXITI to scan each card it receives as input for
the type of control information you specify.
If, after the card is processed by BA TEXIT 1, general register 15 contains a nonze­
ro return code, the CMS 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
BA TEXIT2 is an entry point provided so that users can code their own routine to
use the 110B card for additional information. BATEXIT2 receives control before
the VM/SP routine used to process the batch facility 110B card begins its process­
ing, but after CMS has scanned the 110B card and built the parameter list. When
BATEXIT2 is processing, general register 1 points to the CMS parameter list buff­
er. This buffer is a series of 8-byte entries, one for each item on the 110B card. If
the return code found in general register 15 resulting from BATEXIT2 processing
of this card is nonzero, an error message is generated and the job is flushed. If gen­
eral register 15 contains a zero, normal checking is done for a valid userid and the
existence of an account number. Finally, execution of this job begins.
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 I CMS commands for users who do not
know CMS commands and controls.
To provide the sequence of commands needed to execute the most common
jobs (assemblies and compilations) in a particular installation.
For information on how to use the EXEC facility to control the batch facility virtu­
al machine, see the VMjSP eMS User's Guide.
Data Security under the Batch Facility
After each job, the CMS Batch Facility loads (via IPL) 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 then executes
this EXEC at each job initialization time.
Improved IPL Performance Using a Saved System
Since the CMS Batch processor goes through an IPL procedure after each user job,
an installation may experience a more efficient IPL procedure by using a saved
CMS system when processing batch jobs. 420 VM!SP System Programmer's Guide