Thanks! You answered my questions. I always figured there was a time
before catalogs, when I assume you had to code VOL=SER= on everything,
but that was before my time. And I was trying to remember the CVOL
method. I started with ICFCAT's but come to think of it, there may have
been one or two in the shop when I started in 1983. Or they may have
been converting and I was too new to understand what was going on.
On 5/23/2024 10:01 PM, Joel C. Ewing wrote:
VTOCs did come first. The original DOS/360 Operating System did not
have catalogs. VTOCs contain not only information about physical
location and organization of datasets on the volume but also (for OS/360
and its MVS and z/OS descendants) contains a list of all the free
extents on the volume to support automated allocation of new extents for
datasets. It makes sense to still keep that level of information at
the volume level and not in some centralized "catalog", because an
individual volume can be varied online or offline, added to or deleted
from the system, and also any hardware failures that might affect data
availability tends to affects specific volumes, so it simplifies many
things to keep volume-level descriptive information on the related volume.
As the total number number of DASD volumes on a system increases, having
that VTOC-level information distributed across all volumes vs putting
all that info in a centralized location improves performance by
distributing read/write activity for that data across all the volumes,
and prevents a single point of failure that could cause loss of all
datasets.
Without a catalog to map data set names to volumes, it was necessary to
manually record and maintain a record of what volume(s) contain each
dataset. That was practical for a few volumes and a small number of
datasets, but obviously impractical when talking about 100's of volumes
and 1000's of datasets. OS/360 was designed to support very large
systems; Hence it included a catalog; but its use was optional for
application datasets. These days the recommended practice is that all
z/OS application DASD datasets should be under SMS, and SMS datasets
must be cataloged.
The original CVOL catalog evolved into multi-level ICF catalogs, and an
eventual need to save additional dataset attributes to support SMS and
VSAM datasets resulted in an additional VVDS dataset to store that info
on each volume.
As the capacity and maximum number of datasets on a volume increased, a
serial search through a VTOC became a performance bottleneck, and an
optional VTOCIX (VTOC Index) was added to each volume for more efficient
access.
There is some redundancy with having VTOCs, VVDSs, and Catalogs, but
that aids in error detection and recovery by allowing cross-checking
between VTOCs, VVDSs and Catalogs to look for and resolve inconsistencies.
On z/OS it is typical to use multi-level catalogs for security and
availability reasons and to keep application and personal datasets in
catalogs distinct from those containing system-level datasets essential
to the operating system.
To reduce I/O and improve catalog performance, z/OS accesses catalogs
via a system Catalog address space that provides additional in-memory
caching for all open ICF catalogs.
JC Ewing
On 5/23/24 21:32, Phil Smith III wrote:
I'm curious whether any of you old-timers can explain why we have both
VTOCs and catalogs. I'm guessing it comes down to (a) VTOCs
came first and catalogs were added to solve some problem (what?)
and/or (b) catalogs were added to save some I/O and/or memory, back
when a bit of those mattered. But I'd like to understand. Anyone?
...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
