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

Auxiliary Directories When a disk is accessed, each module that fits the description specified
on the ACCESS command is included in the resident directory. An
auxiliary directory is an extension of the resident directory and
contains the name and location of certain CMS modules that are not
included in the resident directory. These modules, if added to the
resident directory, would significantly increase its size, thus
increasing the search time and storage requirements. An auxiliary
directory can reference modules that reside on the system (S) disk; or,
if the proper linkage is provided, reference modules that reside on any
other read-only CMS disk. To take advantage of the saving in search
time and storage, modules that are referenced via an auxiliary directory
should never be in the resident directory. The disk on which these
modules reside should be accessed in a way that excludes these mOdules.
How to Add an Auxiliary Directory
To add an auxiliary directory to eMS, the system programmer must
generate the directory, initialize it, and establish the proper linkage. Only when all three tasks are completed, can a module described in an
auxiliary directory be properly located.
GENERATION OF THE AUXILIARY DIRECTORY An auxiliary directory TEXT deck is generated by assembling a set cf DMSFST macros, one for each module name. The format of the DMSFST macro
is: DMSFST L filename ( (filename r , ; , filetype I) I L .J ![,aliaSnalle1 filename,filetype is the name of the module whose File Status Table
(FST) information is to be copied.
aliasnalle is another name by which the module is to be known.
INITIALIZING THE AUXILIARY DIRECTORY After the auxiliary directory is generated via the DMSFST macro, it must be initialized. The CMS GENDIRT command initializes the auxiliary
directory with the name and location of the modules to reside in an
Part 3. Conversational Monitor System (CMS) 319