April 1, 1981
The load address for the discontiguous saved segment should be just
beyond the largest virtual machine that uses it. If the load address is
unnecessarily high, real storage is wasted because CP must have segment
table entries for storage that is neVer used. For example, assume you have five CMS virtual machines in your
installation. Also assume that all five use the CMS support for DOS program development and testing which is in a 32K segment named CHSDOS. If each of your five CMS virtual machines has a machine size of 320K you
should load the CMSDOS segment just beyond 320K. If you load CMSDOS at
a much higher address, for example 512K, you are wasting real storage.
In this case, whenever one of your CMS virtual machines attaches the CMSDOS segment, CP creates segment table entries for a 544K (512K + 32K)
virtual machine. Although the virtual machine cannot refer to storage
addresses beyond 320K or below 512K, CP still must have segment table
entries in nonpageable real storage for those virtual addresses. Once the named segment is loaded at the correct address, you can save
it by issuing the CP SAVESYS command. To be sure that the CMS discontiguous saved segment has segment protection, set the storage key
for the seqment, via the CMS SETKEY command: to something other than X'F' before you save it.
The format of the eMS SETKEY command is: r ----------------------------------------------------------------------, SETKEY I key systemname [startadr] I key I is the storage protection key, specified in decimal. The
valid keys are 0-15. systemname is the name of the saved system or segment for which the
storage protection is being assigned.
startadr is the starting address (in hexadecimal) at which the keys
are to be assigned. The address must be within the address
range defined for the saved system or discontiguous saved
segments. Using the startadr operand, you can issue the SETKEY command several times and, thus, assign different
keys to various portions of the saved system or HOW THE INTERFACE WORKS The linkage to attach and detach discontiguous saved segments is
supported via several CP DIAGNOSE codes. Since the virtual machine is responsible for insuring that the
discontiguous saved seqment it is attaching does not overlay other
programming code, it must know how much virtual storage it has. By X'EO' during its initialization process, the 'virtual machine can determine its virtual machine storage size.
When the virtual machine needs to attach a discontiguous saved
segment, it must first ensure that the segment is available and that it
does not overlay existinq storage. By issuing the DIAGNOSE code X'64' Part 2. Control Proqram (CP) 139

April 1, 1981
with a subcode of X'OC', it can verify that a loadable copy of the
discontiguous shared segment exists on a CP-owned volume. This DIAGNOSE code is called the FINDSYS function. FINDSYS returns the starting
address of the segment. The virtual machine should compare the starting
address of the segment to its own ending address; if the segment does
not oveclay existing storage, it can be loaded.
A LOADSYS function is provided by the CP DIAGNOSE code X'64' and
subcodes X'OO' and X'04'. The section "Diagnose Instruction in a Virtual Machine" contains a complete description of the Diagnose codes
used in the discontiguous saved segment interface. If you want CMS to
load the named segment in nonshared mode, you may do -so by issuing the CMS command: SET NONSHARE segment name
before eMS attaches the named segment. If the segment is loaded in
nonshared mode you can test and debug it usinq the CP TRACE, STORE, and ADSTOP commands and the CMS DEBUG subcommands BREAK and STORE. When eMS loads a named segment in shared mode, it issues the CP DIAGNOSE code X'64' with subcode X'OO'. CMS also issues the same code
with subcode X'04' to load the named segment in nonshared mode. When a discontiguous saved segment is loaded (or attached) to a
virtual machine, CP expands its segment table entries for that virtual
machine to reflect the highest address of the virtual machine. When a named segment is successfully loaded, all of its storage is
addressable by the virtual machine. For example, when CMS attaches a
named segment, it can execute the routines contained in that segment.
All of the commands that are executable for CMS are also executable for
the attached named segment, with the following exceptions: • The response for the CP QUERY VIRTUAL STORAGE command does not
reflect the storage occupied by the named segment. • If you execute a command that alters storage (such as STORE), you are
given a nonshared copy of the named segment. When the named segment is no longer needed, it can be detached. The CP DIAGNOSE code X'64' subcode X'08', is called the PURGESYS function;
it detaches named segments. When a named segment is detached, its
storage is no longer addressable by the virtual machine and CP updates
its segment tables. The entries for segments beyond the original
virtual machine size are deleted and the associated real storage is
released. Shared Segment Protection
Installations may optionally protect or not protect shared segments. When segments are protected, CP ensures that a virtual machine does not
access a shared segment that another virtual machine has modified. When segments are not protected, CP does not provide this capability.
If a victual machine modifies an unprotected shared segment, other
virtual machines sharing the segment may be affected by the
modification. Therefore, before running without shared segment pcotection, ensure that none of the virtual machines modify shared
segments. 140 IBM VM/370 System Programmer's Guida