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
Discontiguous Saved Segments Assign a name to segment and specify where it is to be stored on
disk. To do this, define an entry in the system name table (DMKSNTBL) with the NAMESYS macro.. See "Coding the NAMESYS Macro" in "Part 2. Defining Your VM/370 System." Or you can use the entries in
the DMKSNT module supplied with the starter system. Load and save the segment, using the appropriate EXEC procedure (CMSXGEN, DOSGEN, or VSAMGEN). Be sure that the proper linkage for attaching and detaching
di-scontiguous saved segments is in the operating s-ystemthat needs
the segment. CMS contains the linkage necessary to attach and detach
the discontiguous saved segments it supports.
Usually, the direct access storage space is allocated and the system
name table entries are created during system generation. You allocate DASD space as permanent (PERM) by executing the Format/Allocate program.
This program is executed during system generation, but it is a
standalone program that can be executed at any time. During system
generation, you designate the Cp-owned volumes by coding the SISOWN macro of the DMKSYS file. The system name table (DMKSNT) is also
created during system generation. If, at some time after system
generation, you wish to change the DMKSYS or DMKSNT files, you can do a
partial system generation and reassemble those files using the GENERATE EXEC procedure. GENERATE is described in "Part 5. Updating VM/370." You can load and save a discontiguous saved segment any time after
system generation. £Q1!§ideratiQ1!§.!Q!: Using ,ihe and By the time you complete the VM/370 system generation procedure, the CMS editor, EXEC, and OS simulation load modules exist on the CMS S-disk. Also, if you have followed VK/370 recommendations, you have created a
discontiguous saved segment, called CMSSEG, that contains the CMS editor, EXEC, and OS simulation routines (you save in Step 24). During virtual machine execution, CMS handles a call to the editor or EXEC processor as follows: CMS first searches for editor or EXEC load modules on all accessed CMS disks, except the S-disk. If you wanted to test changes made to the editor or EXEC processor, you could place the load modules on a disk other than the S-disk (that is available only to your virtual machine) and test
those changes. CMS next attempts to attach the shared segment. If you have not
reset the name of the shared segment by issuing a SET SYSNAME command, CMS attempts to attach the CMSSEG segment. If you wish to
use an alternate segment, indicate the alternate segment on a SET SYSNAME command and issue that command before the segment is
attached. If you do not want CMS to attach a shared segment when
editor, EXEC, or OS simulation routines are needed; issue a SET SISNAME command specifying as the segment name any name that does not
correspond to a named saved segment. Last, CMS attempts to load the appropriate modules from the CMS S-disk. Part 1. Planning for System Generation 83
Previous Page Next Page