April 1, 1981
The CMS/DOS shared segment contains the B-transients that are
simulated for DOS support in CMS. Three B-transients that pertain only
to VSAM are included in the VSAM saved segment: $$BOMSG1, $$BOKSG2, and
$$BENDQB. The $$BENDQB transient is called by the ENQB macro and
released by the DEQB macro. Storage Requirements
The VSAM and Access Method Services support in CMS requires both DASD
space and virtual storage.
The VSAM and Access Method Services support adds approximately 2K to
the size of the CMS nucleus. In addition, this support uses free
storaqe to execute the DOS/VS logical transients and for buffers and
work areas. VSAM issues a GETVIS macro to request free If the CMS/DOS environment is invoked with the VSAM option
SET DOS ON (VSAM part of the CMS/DOS virtual storage is set aside for VSAM use.
Disk storage requirements vary depending upon device type:
Number of cylinders Required
Device Usg OS User 2314- 10 --20- 2319 10 20 3330 Model 1 6 12 3330 Model 11 6 12 3340 15 30 3344 15 30 3350 3 6
Data Set Compatibility Considerations CMS can read and update VSAM data sets that were created under DOS/VS or OS/VS. In addition, VSAM data sets created under CMS can be read and
updated by DOS/VS or OS/VS. However, if you perform allocation on a minidisk in you cannot
use that minidisk in an OS virtual machine in any manner that causes
further allocation. DOS/VS VSAM (and, thus, CMS) ignores the format-5,
free space, DSCB, on VSAM disks when it allocates extents. If
allocation later occurs in an OS machine, OS attempts to create a
format-5 DSCB. However, the format-5 DSCB created by OS does not
correctly reflect the free space on the minidisk. In eMS, allocation
occurs whenever data spaces or unique data sets are defined. Space is
released whenever data spaces, catalogs, and unique data spaces are
deleted. ISAM Interface Program (liP) CMS does not support the VSAM ISAM Interface Proqram (lIP). Thus, any
program that creates and accesses ISAM (indexed sequential access
method) data sets cannot be used to access VSAM key sequential data
sets. There is one exception to this restriction. If you have (1) OS PL/I programs that have files declared as ENV(INDEXED) and (2) if the library routines detect that the data set being accessed is a VSAM data
set, your programs will execute VSAM I/O requests.
312 IBM VM/370 System Proqrammer's Guide

Page of GC20-1807-7 As Updated April 1, 1981 by TNL GN25-0829
Saving the eMS System Only named systems can be saved. The NAMESYS macro must be used to name
a system. A discussion on creating a named system is found under
"Generatinq Named System" in "Part 2: Control Program (CP)". The DMKSNT module must have been configured (by coding the NAMESYS macro) when CP was qenerated. The DMKSNT module contains the system
name, size of the system, and its real disk location. The CMS system
may be saved by entering the command "SAVESYS name" as the first command
after the IPL command (that is, after the CMS version identification is
displayed), where "name" is the name to be assigned to the saved system.
The CMS S- , D-, and Y disks (and, optionally, the A-disk) should be
mounted and attached to the virtual machine, creating the saved system
before the SAVESYS command is issued. This ensures that the CMS file
directory is saved correctly. The status of this saved system, when activated by a subsequent IPL, is changed as though an IPL of a specific device had occurred. The one
exception to this procedure is the file directory for the system disk,
which is part of the nucleus. When a user IPLs CMS, CP loads the
directory for the CMS residence device from disk into virtual storage. Subsequent crpdates to this directory modify the copy that is in virtual
storage but not the copy that is on disk. To modify the copy that is on
disk, save the CMS system after updating the directory.
The CMSSEG Discontiguous Saved Segment
The CMSSEG discontiguous saved segment contains the CMS modules that
perform the CMS Editor, EXEC, or as simulation functions. These same
modules are also loaded on the S-disk of a CMS virtual machine. When CMSSEG has been generated and is in use during execution of the CMS virtual machine, CMS handles a call to the Editor or EXEC processors
by first searching for the requested Editor or EXEC load modules on all
accessed CMS disks, except the S-disk. CMS next attempts to attach the CMSSEG segment; CMSSEG may not be available, depending upon how the CMS virtual machine was generated. If this is the case, CMS attempts to
load the appropriate modules from the CMS S-disk. To handle as simulation routines, CMS first attempts to attach the CMSSEG segment. If the segment is not available, CMS searches all
accessed disks for the as simulation load modules and loads them into
hiqh user storage if they are found. The as simulation modules are then
kept in storage until CMS is reloaded or until a SET SYSNAMES command is
issued for a valid CMSSEG saved segment.
There is overhead associated with controlling discontiguolls saved
segments and with ensuring their integrity. In small systems, the
overhead associated with the use of the CMSSEG saved segment may not be
offset by the benefits of sharing storage among users. Therefore, the
us-e of CMSS-EGmust be deteI"mined-by the user for- his own- ell1l-LrOnlll-ent. Part 3. Conversational Monitor System (CMS) 313