If I remember correctly (since I started on DOS R26?) on a
S/360-30, we also had to use EXTENT cards (to define where a file
existed on a volume). So hazy memory recalls we had a Label
cylinder and an ALT Label cylinder. But maybe that came with
DOS/VS.... Too long ago now.
Then DOS got VTOCs and so if sharing with OS|MVS, the volume got
the "dirty" bit turned on if DOS did any work in the VTOC. (MVS
then had to RESERVE the volume and fix the VTOC to know where the
free extents were since DOS didn't have that feature).
The joys of migrating to OS/VS (MVS) and sharing of Volumes
between systems in a service Bureau.... oh, Cloud (sorry I forgot
the in-vogue term).
Steve Thompson
On 5/24/2024 6:02 AM, Lennie Bradshaw wrote:
When I started on IBM System/370 the shop I was at used DOS/VS. DOS/VS at that
time did not have VTOCs. We used //DLBL statements in JCL which specified the
exact locations of datasets on disk. This changed with the introduction of VSAM
on DOS/VS, but only for VSAM datasets.
Fortunately I soon moved to a company using OS/VS2 and got to use VTOCs and
CVOLs there.
As regards, why both VTOCs and Catalogs exist, what would be the alternative?
The more pertinent question is, I think,
Why do we have both VVDS datasets and VTOCs? Historically I understand, but it
could improve efficiency to merge these.
It would probably break too many existing interfaces though.
Lennie Dymoke-Bradshaw
https://rsclweb.com
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Joel C. Ewing
Sent: 24 May 2024 06:02
To: [email protected]
Subject: Re: VTOCs vs. catalogs
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?
...
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
[email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
