Pg. of GC20-1819-2 Rev March 30, 1979 by Supp. SD23-9024-1 for 5148-IX8 Under CMS, it is possible to have the master catalog disk read-only.
A bit in the ACB indicates to VSE/VSAM that it is running under CMS. If
this bit is on, VSAM will not write to the master catalog for either of the two cases described above. This allows one or more CMS virtual
machines to share the VSAM master catalog. This assumes either no other
virtual machine has the master catalog disk in write status or only one
virtual machine (DOS, OS, or CMS) has it. Multiple CMS users may have the VSAM master catalog disk in read-only
status but only one virtual machine may have the same in write status. with respect to dataset sharing, there is only read-sharing for the user.
DISK COMPATIBILITY Since the CMS VSAM support writes VSAM datasets to DOS disks, the
question of disk compatibility is not one between CMS and DOS nor
between CMS or OS but rather between DOS and OS disks. In other words,
because CMS actually uses VSE/VSAM for processing VSAM datasets, all
disks used by CMS VSAM are DOS disks. For this reason, we need only
discuss how DOS and OS disks are compatible and, because they are
compatible, we can conclude that CMS and OS are also compatible.
In the format-4 DSCB, there is a bit in the VTOC Indicators (byte 59,
bit 0) defined by OS/VS to indicate (when OFF) that a format-5 label is
included in the VTOC. This bit is always On under DOS/VSE because Des
does not maintain the format-5 label. This technique allows OS/VS to
realize when the format-5 is invalid and that it must recompute free
space and rewrite the format-5 so that device integrity is maintained.
Thus, if a disk originally was used (allocated) under OS/VS and,
subsequently, with DOS/VSE, further allocation could occur under DOS/VSE but with the format-5 ignored and, therefore, no longer valid. If the
disk was then used under OS/VS and still further allocation performed, OS/VS would recognize the fact that the format-5 was not valid
(contamination bit turned ON by DOS/VSE) and would rewrite the format-5,
turning the bit OFF. This shows that DOS and OS disks are compatible in that they are
portable between the two systems, but one of the systems (OS/VS) must
perform some extra processing (rewriting format-5) prior to using the
disk if it intends to reallocate using the format-5. DOS and OS disks containing VSAM datasets are no exception to this. OS and DOS disks containing VSAM datasets that are used (allocated)
under CMS are portable among all three systems. Since CMS uses VSE/VSAM code, all disks used under CMS to process VSAM datasets become DOS/VSE disks in that the contamination bit is turned ON as it is when using DOS/VSE. The term "minidisk" may be interchanged with the word "disk" in the above explanation if we are dealing with "virtual" DOS/VSE and OS/VS systems. However, real systems are not aware of, and do not support,
minidisks.
It is necessary to distinguish between two types of allocation under VSAM. The first refers to actual space allocation on the disk, and the
second is that within the dataset itself.
Space for VSAM components must be allocated cn the DASD device using
the DEFINE commands. The only component for which the user is able to
186 IBM VM/370 eMS User's Guide

Pg. of GC20-1819-2 Rev March 30, 1979 by Supp. SD23-9024-1 for 5748-XX8 allocate space is for the master catalog, a data space, and a UNIQUE cluster. In defining the actual DASD space for components, there are
parameters for the DEFINE SPACE command which allows the user to include a "secondary allocation" specification. These parameters (CYLINDERS, RECORDS, TRACKS) have this secondary facility only as a syntactic
compatibility with the OS/VS access method services commands. That is, nOS/iSE (and, therefore, CMS) does not perform secondary space
allocation on a DASD. The facility does exist under DOS/iSE (and CMS) to extend data or
index components through already allocated data space, catalog extents,
or UNIQUE cluster extents. Thus, the CYLINDERS, TRACKS, and RECORDS parameters of the DEFINE commands for alternate indexes, clusters, and
catalogs do not dynamically allocate DASD space but only extend a
component through eXisting space. USING VM/370 MINIDISKS If you have a VM/370 minidisk in your virtual machine configuration, you
can use it to contain VSAM files. Before you can use it, it must be
formatted with the IBCDASDI program or other appropriate operating system utility program. When you request that a disk be added to your virtual machine configuration for use with VSAM files under CKS, you
should indicate that it be formatted for use with as or DOS. Or you can
format it yourself using the IBCDASDI program. A brief example of how to
do this is given under the following "Using Temporary Disks." The IECDASDI control statements are fully described in the If you are an as user, you should be careful about allocating
space for VSAM on minidisks. Once you have used CMS AMSERV to allocate VSAM data space on a minidisk, you should not attempt to allocate
additional space on that minidisk using an OS/VS system. as does not
recognize minidisks, and would attempt to format the entire disk pack
and thus erase any data on it. To allocate additional space for VSAM, you should use CMS again. If you use the IBCDASDI program to format the
disk, and use the CYLNC parameter, the entire disk is flagged as full# so that as cannot allocate additional space. Minidisk space allocation
is fully described in the USING THE LISTDS COMMAND For as or DOS disks or minidisks, you can use the LISTDS command to
determine the extents of free space available for use by VSAM. You can
also determine what space is already in use. You can use this
information to supply the extent information when you define VSAM files.
The options used with VSAM disks are: • EXTENT, to find out what extents are in use, and • FREE, to find out what extents are available.
For example, if you have an as disk accessed as a G-disk, and you enter:
listds 9 (extent Section 10. Using Access Method Services and VSAM 187