Saved System Restrictions for eMS There are several coding restrictions that must be imposed on CMS if it
is to run as a saved system. CMS may never modify, with a single machine instruction (except MYCL), a section of storage that crosses the boundary between two pages
with different storage keys. This restriction applies not only to SS instructions, such as MVC and ZAP, but also to as instructions, such as STM, and to RX instructions, such as ST and STD, which may have
nonaligned addresses on the System/370. It also applies to I/O instructions. If the key specified in the CCW is zero, then the data area for input may not cross the boundary between
two pages with different storage keys.
If you intend to modify a shared CMS system, be sure that all code
that 1S to be shared in the shared segment, CMS Nucleus (X'10000'-X'20000'). To make room for additional code in the eMS Nucleus, you may have to move some of the existing code. You can use the USERSECT area of DMSNUC to contain nonshared instructions. CP does not permit a user of a shared system to set storage keys via
the Set Storage Key (SSK) instruction. Thus, one user cannot prevent
other users from accessing shared storage. Part 3. Conversational Monitor System (eMS) 315

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