Shared Segments
If one or more segments of a saved system are designated as being "shared," a sin­
gle copy of these segments in real storage can be used by any virtual machine that
loads the saved system by name. (In attached processor or multiprocessor mode,
there are two sets of pages, page tables, and swap tables maintained for each
shared segment.) A shared segment must be reenterable and the segment number
must be included in the SYSHRSG operand of the NAMESYS macro for the saved
system.
If, for example, you code the SYSHRSG= operand of the NAMESYS macro for
the system to be saved as SYSHRSG=(29,30,31) then segments 29, 30, and 31 of the system are to be shared. When CMS is saved,
via the SA VESYS command, the pages in segments 29, 30, and 31 are set up so
that any user loading the saved system by name shares the same set of these pages
in real storage. This results in a saving of both real and external page storage.
Also, the more virtual machines using the shared segment, the more likely it is that
these pages will be frequently referenced and, thereby, kept in real storage. As a
result, the number of page faults and the corresponding time and resources
expended in page swapping is reduced.
Special Considerations for Shared Segments
When a saved system containing one or more shared segments is again saved, a
problem can occur if the previous system has been loaded by name and is still in
use. If users of the "old" system continue to reference pages that have already
been brought into paging storage, no problems will occur. However, if after the
new system has been saved, users of the old system reference pages that had not
previously been referenced, they receive the new version of the referenced page.
Any users who IPL the newly saved system share only the new copy of the shared
segment.
Also, the entire segment is saved by the SA VESYS command, not just that portion
occupied by the program (for example, CMS), so that unwanted data may also be
contained in the segment.
The use of shared segments is not allowed in a virtual=real machine.
The maximum number of shared segments that may be defined is 78.
Discontiguous Saved Segments
With discontiguous saved segment support, you can attach and detach segments of
storage to and from your virtual machine. These segments contain reenterable
code that can be shared by many users. Thus, programs that are required some­
times, but not all the time, can be shared and only loaded when they are needed.
Segments that are to be shared in this manner must be loaded at an address beyond
the normal end of your virtual machine and then must be saved. The procedure for
loading and saving discontiguous segments is similar to the procedure that already
exists for loading and saving systems. Also, discontiguous saved segments can be
attached to your virtual machine in nonshared mode for testing and debugging. In
summary, a discontiguous saved segment is a segment that:
Generating Saved Systems 75

User Requirements
Has a name associated with it
Contains only reenterable code
Was previously loaded and saved
Can be shared by multiple virtual machines
Can be loaded by a particular virtual machine in nonshared mode for testing
and debugging
Note: A discontiguous saved segment must not 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 reenterable
and is named CMSDOS. The VM/SP starter system includes an EXEC procedure
that helps you load and then save this segment. CMS contains all the necessary
linkage to load the CMSDOS segment when it is needed.
In order to use discontiguous saved segments, you must:
Allocate permanent space on a CP-owned volume to contain the saved seg­
ment.
Assign a name to the segment and specify where it is to be stored on disk by
defining an entry in the system name table (DMKSNT) with the NAMESYS macro.
Load and save the segment. The VM/SP starter system has EXEC procedures
to help you load and save the discontiguous saved segments for CMS (one
EXEC procedure to load and save CMS/DOS, one for CMS/BAM, and one
for CMS/VSAM and AMSERV). Be sure that the proper linkage for attaching and detaching discontiguous saved
segments is in the operating system that needs the segment. CMS contains the
linkage necessary to attach and detach the discontiguous saved segments it
supports. I · Save a discontiguous saved system that is moved to a new DASD extent.
Usually, the direct access storage space is allocated and the system name table
entries are created during system generation. You allocate DASD space as perma­
nent (PERM) by executing the Format/Allocate program. This program is exe­
cuted 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 SYSOWN 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 par­
tial system generation and reassemble those files using the GENERATE EXEC
procedure. GENERATE is described in the VM/SP Installation Guide. You can
also load and save a discontiguous saved segment any time after system generation.
76 VM/SP System Programmer's Guide