Discontiguous Saved Segments
Discontiguous Saved Segments VM/370 supports discontiguous shared segments and provides shared
segment protection.
With discontiguous saved segment support, you can attach and detach
segments of storage to and from your virtual machine. These segments
may contain reenterable code that can be shared by many users. Thus,
programs that are required sometimes, but not all the time, can be saved
and only loaded when they are needed. Also, discontiguous saved
segments can be attached to your virtual machine in nonshared mode for
testing and debugging. When in attached processor mode, all shared segments are duplicated.
Sufficient storage is obtained to construct duplicate page and swap
tables in contiguous storage. This additional storage space should be
planned for, when running in attached processor mode.
The SHRTABLE SHRPAGE pointer points to the page and swap tables for
the main processor, and the page and swap tables for the attached
processor will be at a fixed offset from the page and swap tables for
the main processor. DMKCFG initializes both sets of page and swap
tables. At first, the swap tables for the main processor and attached
processor will point at the DASD locations specified in DMKSNT. However, as the pages are read into storage and then stolen, each shared
page is allocated its own DASD slot and pointed to by only one swap
table entry. The last user to purge a shared system causes both sets of
page and swap tables to be freed. See the !M/31Q for a description of shared segments.
Segments that are to be saved in this manner must be loaded at an
address within your virtual machine and then must be saved. To do this
in CMS (following eMS conventions) you must define your virtual machine
size large enough to contain the discontiguous segments, loader tables,
and CMS control block storage at the end of virtual storage; load the
segments; save the segments; then reduce the virtual storage to its normal size. When you attach these segments, they are attached beyond the end of your virtual machine. The procedures for loading and saving
discontiguous segments are similar to the procedure that already exists
for loading and saving systems. CMS has three EXEC procedures to help you place portions of CMS in
discontiguous saved segments: • DOSGEN, which loads and saves CMS/DOS support • VSAMGEN, which loads and saves CMS/VSAM and Access Method Services
support • CMSXGEN, which loads and saves the CMS Editor, EXEC processor, and OS simulation routines See the section "Loading and Saving Discontiguous Saved Segments" in "Part 3. Generating VM/310 (CP, CMS, RSCS, and IPCS) " for descriptions
of how the DOSGEN and VSAMGEN EXEC procedures are used. The CMSXGEN procedure is described in Step 24 of the system generation procedure in Part 3. Part 1. Planning for System Generation 81

Discontiguous Saved Segments CP checks to see whether a virtual machine has altered any shared
segments before it dispatches the next virtual machine. When a shared
segment is found to have been modified as a result of a CP STORE, ADSTOP, or TRACE command, CP issues a message to indicate that the
shared copy has been replaced by a nonshared copy. Execution continues
in the virtual machine with the nonshared copy. However, if a protected
shared segment is found to be altered by any other means and segment
protection is on, CP sends a message to the current virtual machine to
identify the altered page. The altered page is made inaccessible and the
virtual machine's execution is stopped by placing it into console
function mode. Saved systems must be named and may be shared. The discontiguous
saved segment support is similar to saved system support. Therefore,
you should understand saved systems before you read this section; see
the VMLJ70 Guide for a description of saved systems.
A discontiguous saved segment is a segment that: • Has a name associated with it • Was previously loaded and saved • Mayor may not be shared by multiple virtual machines • Can be loaded by a particular virtual machine in nonshared mode for
testing and debugging
A discontiguous saved segment can be logically attached to a virtual
machine when it is needed and detached when it is not needed. The
attaching and detaching is done by the name associated with the segment.
The virtual machine attaching and detaching discontiguous saved segments
must issue CP DIAGNOSE instructions to perform the proper linkage.
Discontiguous saved segments are loaded at the same address at which
they were saved: this address must be higher than the highest address of
the virtual machine that is attaching it. A discontiguous saved segment
cannot be attached by a virtual machine executing in the virtual=real
area.
An example of a discontiguous saved segment is the segment of CMS that supports DOS program development and testing under CMS. This
segment is reentrant and is named CMSDOS. The starter system includes
an EXEC procedure, DOSGEN, that helps you load and then save this
segment. CMS contains all the necessary linkage to load the CKSDOS segment when it is needed.
The main advantage of placing the CMS support for DOS in a
discontiguous saved segment is that it conserves real storage. Not all CMS users need the DOS support, and those who do need it probably do not
need it all the time. CP keeps the segment tables in real nonpageable
storage. These segment tables have an entry for each segment (whether
it is saved or nonsaved) of virtual storage available to each active
virtual machine. By putting the DOS support in a discontiguous saved
segment (called CKSDOS), real nonpageable storage is conserved. Your segment table has entries for the CMSDOS segment (and all segments up to
it) only when the CKSDOS segment is attached to your virtual machine.
Using Discontiguous Saved Segments
To use discontiguous saved segments you must: • Allocate permanent space on a CP-owned volume to contain the saved
segment.
82 IBM VM/370 Planning and System Generation Guide