Saving the eMS System Only named systems can be saved. The NAMESYS macro must be used to name a
system. A discussion on creating a named system is found under "Generating Saved Systems" in "Part 1: Control Program (CP)." The DMKSNT module must have been configured (by coding the NAMESYS mac­
ro) when CP was generated. The DMKSNT module contains the system name, size
of the system, and its real disk location. The CMS system may be saved by entering
the command "SA VESYS name" as the first command after the IPL command
(that is, after the CMS version identification is displayed), where "name" is the
name to be assigned to the saved system.
The CMS Sand Y -disks (if the Y -disk is defined) must be mounted and attached to
the virtual machine, creating the saved system before the SA VESYS command is
issued. This ensures that CMS file directories are saved correctly.
Any updates to the CMS S-disk or Y -disk requires resaving the CMS system.
The IPLing of the saved CMS system is similar to IPLing by device except that the
directories for the Sand Y -disk are part of the nucleus instead of being built in DMSFREE storage.
In VM/SP, the CMS system is designed to be used as a saved system. Its location
may be modified by an installation for its particular requirements, but should be
shared among CMS users.
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.
If the key specified in the CAW for a SIO instruction 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 is to be
shared resides in the shared segments of the CMS Nucleus (suggested location: X'lDOOOO' to X'200000'). 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.
Saving the eMS System 417

The eMS Batch Facility
The CMS Batch Facility is a VM/SP programming facility that runs under the CMS subsystcm. It allows VM/SP uscrs to run their jobs in batch mode by send­
ing 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/SP 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 sta­
tion.
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 CMS 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 facil­
ity IPLs itself, thereby providing a continuously processing batch machine. The
batch processor IPLs itself by using the P ARM option of the CP IPL 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 read­
er 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 VM / SP Operator's Guide for more information about controlling
the batch machine.
The CMS Batch Facility is particularly useful for compute-bound jobs such as
assemblies and compilations and for execution of large user programs, since inter­
active users can continue working at their terminals while their time-consuming
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 proce­
dures that make the CMS Batch Facility facility easier to use. the eMS Batch Machine
Before using the CMS Batch Facility, an entry must exist in the users directory.
This entry specifies the userid of the CMS Batch machine.
Following is an example of a user directory entry granting authorization to use the
CMS Batch Facility.
418 VM/SP System Programmer's Guide