Note: The ACCTON COpy file distributed with Ve/370 contains the basIc logic required to enhance system security based on the 3277 Operator Identification Card Rsadsr f€ature. Additional checking may be added to examine or validate the data read from the
identification card. ACCTOFF (account off) for action at logo!! time. Th1S section
contains the code that fills in the account card fields. It does
not reset any internal data. This file exists in both DMKICO and DMKCKP (checkpoint). If the ICCTOFF copy file is changed, both
modules should be reassembled.
2. CP has no provision for writing the accounting records to disk. 3. In addition to CP accounting, your installation can use the
accounting routines to supply virtual machine operating systea accounting records. This provides a means of job accounting and
operating system resource usage accounting.
4. If no punch is generated in the VM/370 system, accounting records
are not queued for punching. The ICCTON and lCCTOFF copy files are
still called, however. Part 2. Control program (CP) 131

Generating Saved Systems By taking advantage of the SAVESYS command, system resources are not
committed 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 initialized in the virtual = real
machine, via an IPL.
To generate a saved system: I • Assemble the NAMESYS macro instruction in module DMKSNT. I • Load a new control program nucleus. I • Load the system to be saved and then issue the SAVESYS command. When allocating DASD space for named systems, provide an extra page
for information purposes; do not overlay this area with subsequent named
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 specified, 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 Q.§1!.§gtig1! A DMKSNT ASSEMBLE module supplied with the system contains a dummy NAME TABLE. 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). The format of the NAMESYS macro is:
r I label I I I I I I NAMESYS n'U ,I "')..,. 1'\ ,;..,1./ ...JII V SYSSIZE=nnnnnK,SYSNAME=name,VSYSRES=ccccCC, VSYSADR={cuu },SYSVOL=cccccc,SYSCYL=nnn, SYSSTRT=(cc,p) ,SYSPGCT=pppp, SYSPGNM=(nn,nn,nn-nn, ••• ) , SYSHRSG=(s,s, ••• ),
PROTECT = {QJ! } OFF -- -- ,...,. -......,. -- ..•. -, .. - J:,L V'j,;.r.:tii.I.,;.eJ.. .;:, -.. , I I I I I I I