Generating Saved Systems
By taking advantage of the SA VESYS command, system resources are not commit­
ted to perform an IPL each time a system is loaded. Instead, the saved system is
located and page tables are initialized according to its system name table entry.
The saved system is not automatically loaded at IPL time; however, its pages are
brought into storage on demand as the virtual machine operating system executes.
In addition to saving time by avoiding an IPL, a saved system can share segments
of reenterable code, thus making more efficient use of real storage. This technique
is especially valuable when using CMS. However, a shared segment cannot be ini­
tialized in the virtual=real machine, by an IPL. To generate a saved system:
Add the appropriate NAMESYS or NAMENCP macro and operands to the DMKSNT file
Assemble this new version of DMKSNT Create and load a new control program nucleus IPL the new CP system
Load the system to be saved and then issue the SA VESYS command.
When allocating DASD space for named systems, provide an extra page for infor­
mation purposes; do not overlay this area with subsequent named systems. See the
VM / SP Planning Guide and Reference and the VM / SP Installation Guide for fur­
ther information on generating and saving saved systems.
The NAMESYS Macro for Saved Systems
The NAMESYS macro is assembled by the installation system programmer and is
used to describe the location of the saved system. Shared segments may be speci­
fied, but they must consist of reenterable code.
When making additions, changes, or deletions to the system name table, the DMKSNT module must be reassembled. The GENERATE EXEC procedure has
the facility to reassemble only the DMKSNT module. See the description of the
GENERATE EXEC procedure in the VM/SP Installation Guide.
A DMKSNT ASSEMBLE sample supplied with the system contains workable CMS segments. Either edit or update this module to include the NAMESYS macros
describing your installation's named systems. Note that this module may contain a PUNCH SPB card, which is used by the loader to force this module to a 4K
boundary when the CP system is built (a 12-2-9 multipunch must be specified in
column 1 of an SPB). Coding the NAMESYS Macro
The NAMESYS macro describes the name and location of the saved system or dis­
contiguous saved segment. Shared segments may be specified, but they must con­
sist of reenterable code, with no alteration of its storage space permitted. See the
VM / SP Planning Guide and Reference for the format of the NAMESYS macro.
Example 0/ a DMI(SNT Entry I A DMKSNT entry to create a named CMS system could be coded as follows:
Generating Saved Systems 73

DMKSNTBL CSECT FSTNAME NAMESYS SYSNAME=CMS,SYSVOL=VMSRES,SYSSTRT=(001,1), X SYSPGNM=(O-4,14-33,400-511) ,SYSPGCT=137, X SYSHRSG=(25,26,27,28,29,30,31),SYSSIZE=256K, X VSYSADR=190,SYSCYL=98,VSYSRES=VMSRES X
END
In the above example, VMSRES is a count-key-data volume (IBM 3330 Disk Stor­ age).
A similar example in which the device is a fixed-block volume follows:
DMKSNTBL CSECT FSTNAME NAMESYS SYSNAME=CMS,SYSVOL=VMSRES,SYSSTRT=(2), X SYSPGNM=(O-4,14-33,400-511) ,SYSPGCT=137, X SYSHRSG=(25,26,27,28,29,30,31),SYSSIZE=256K, X VSYSADR=190,SYSBLOK=46912,VSYSRES=VMSRES X
END
If the segment resides on one volume and the virtual 190 minidisk resides on a dif­
ferent volume, it is possible for one of the devices to be fixed-block and the other
to be count-key-data. In that case, the parameters pertaining to each device are
selected based on the type of that particular device. Using the SA VESYS Command
The system to be saved must first be loaded by device address in the traditional
manner. Before its page-format image can be saved, the system to be saved must
have its execution stopped. The point at which the operating system is stopped
should be determined by the installation system programmer. The SA VESYS command must then be issued; its format is: I SAVESYS systemname
where:
systemname corresponds to the identification of the saved system. This is iden­
tical to the SYSNAME entry in the NAMESYS macro.
The user must have a CP privilege class of E to issue the SA VESYS command.
Next, he should IPL the saved system. The virtual machine will attempt to resume
execution and immediately encounter a page fault. The required page is brought
into storage and execution continues. As execution continues, subsequent page
faults bring the required pages into storage.
A system should be saved as soon after IPL as possible. All pages to be saved must
be resident at the time the SAVESYS command is issued. Also, before issuing the SA VESYS command, be sure that the system is stopped. CMS was designed to run under CP and it was also designed so that it could easily
be saved by CPo See "Saving the CMS System" in "Part 2. Conversational Moni­
tor System (CMS)" of this publication.
Note: The system being saved should not exceed X'79COOO' bytes. Unpredictable
results may occur if you save a larger system.
74 VM/SP System Programmer's Guide