Introduction To eMS, The Conversational Monitor System (CMS), the major subsystem of VM/SP, pro­
vides a comprehensive set of conversational facilities to the user. Several copies of
CMS may run under CP, thus providing several users with their own time sharing
system. eMS is designed specifically for the VM/SP virtual machine environment.
Each copy of CMS supports a single user. This means that the storage area con­
tains only the data pertaining to that user. Likewise, each CMS user has his own
machine configuration and his own files. Debugging is simpler because the files
and storage area are protected from other users.
Programs can be debugged from the terminal. The terminal is used as a printer to
examine limited amounts of data. After examining program data, the terminal user
can enter commands on the terminal that will alter the program. This is the most
common method used to debug programs that runin CMS.
CMS, operating with the VM/SP Control Program, is a time sharing system suit­
able for problem solving, program development, and general work. It includes
several programming language processors, file manipulation commands, utilities,
and debugging aids. Additionally, CMS provides facilities to simplify the operation
of other operating systems in a virtual machine environment when controlled from
a remote terminal. For example, CMS capabilities are used to create and modify
job streams, and to analyze virtual printer output.
Part of the CMS environment is related to the virtual machine environment created
by CP. Each user is completely isolated from the activities of all other users, and
each machine in which CMS executes has virtual storage available to it and man­
aged for it. The CP commands are recognized by CMS. For example, the com­
mands allow messages to be sent to the operator or to other users, and virtual
devices to be dynamically detached from the virtual machine configuration.
The CMS Command Language
The File System
The CMS command language offers terminal users a wide range of functions. It
supports a variety of programming languages, service functions, file manipulation,
program execution control, and general system control. The CMS commands that
are useful in debugging are discussed in the "Debugging with CMS" section of
"Part 3. Debugging with VM/SP". For detailed information on all other CMS
commands, refer to the VM/SP CMS Command and Macro Reference.
Figure 35 describes CMS command processing.
The Conversational Monitor System interfaces with virtual disks, tapes, and unit
record equipment. The CMS residence device is kept as a read-only, shared, sys­
tem disk. Permanent user files may be accessed from up to 25 active disks. Log­
ical access to those virtual disks is controlled by CMS, while CP facilities manage
the device sharing and virtual-to-real mapping. User files in CMS are identified with three designators. The first is filename. The
second is a file type designator that may imply specific file characteristics to the
CMS file management routines. The third is a filemode designator that describes
the location and access mode of the file.
Introduction To eMS 303

User files can be created directly from the terminal with the System Product Editor
(XEDIT). XEDIT provides extensive context editing services. File characteristics
such as record length and format, tab locations, and serialization options can be
specified. The system includes standard definitions for certain filetypes. The size
of user files is determined by the BLKSIZE. When a BLKSIZE of 800 bytes is
specified, a single user file is limited to a maximum of 65533 records and must
reside on one virtual disk. The file management system limits the number of files
on the virtual disk to 3400. When a BLKSIZE of 1024,2048, or 4096 bytes is
specified, a single user file is limited to a maximum of 2
3
1- 1 CMS records and must
reside on one virtual disk. The maximum number of data blocks available in a vari­
able format file on a 512-byte blocksize minidisk is about 15 times less than 2
3
1-1. The file management system does not limit the number of files on the disk. The
number of files on a disk is limited by the capacity of the disk.
The compilers available under CMS default to particular input filetypes, such as
ASSEMBLE, but the file manipulation and listing commands do not. Files of a
particular filetype form a logical data library for a user; for example, the collection
of all COBOL source files, or of all object (TEXT) decks, or of all EXEC proce­
dures. This allows selective handling of specific groups of files with minimum input
by the user.
CMS automatically allocates compiler work files at the beginning of command exe­
cution on whichever active disk has the greatest amount of available space, and
deallocates them at completion. Compiler object decks and listing files are
normally allocated on the same disk as the input source file or on the primary
read/ write disk, and are identified by combining the input filename with the
filetypes TEXT and LISTING. These disk locations may be overridden by the
user.
Virtual disks may be shared by CMS users; the facility is provided by VM/SP to all
virtual machines, although a user interface is directly available in CMS commands.
Specific files may be spooled between virtual machines to accomplish file transfer
between users. Commands allow such file manipulations as writing from an entire
disk or from a specific disk file to a tape, printer, punch, or the terminal. Other commands write from a tape or virtual card reader to disk, rename files, copy files,
and erase files. Special macro libraries and text or program libraries are provided
by CMS, and special commands are provided to update and use them. CMS files
can be written onto and restored from unlabeled tapes via CMS commands.
Caution: Multiple write access under CMS can produce unpredictable results. Problem programs that execute in CMS can create files on unlabeled tape in any
record and block size; the record format can be fixed, variable, or undefined.
Migration from the 800-byte File System to the Extended File System
This section discusses the points to consider when migrating to the VM/SP file sys­
tem from VM/370 Release 6 or earlier versions of CMS. Note that the VM/SP file
system is directly compatible with the VM/370 System Extensions and the Basic
System Extensions, Release 2 file system. The VM/SP file system provides greater
file capacities, four disk blocksizes for minidisks, and improved performance over
most earlier versions of CMS.
The VM/SP file system contains support for the traditional CMS disk format and
for an enhanced format of CMS disk. It is with this enhanced or extended format
that additional functions and capacities are available. The VM/SP extended file 304 VM/SP System Programmer's Guide