They say that the memory is the scond thing to go; I can't remember the first.
From DOS/VS Data Management Guide <http://bitsavers.org/pdf/ibm/370/DOS_VS/Rel_29_Nov73/GC33-5372-2_DOS_VS_Data_Management_Guide_Rel_29_Nov73.pdf> "In order to locate any particular file, there is a table on each volume called the Volume Table Of Contents (VTOC). " -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Lennie Bradshaw <lennie-brads...@outlook.com> Sent: Friday, May 24, 2024 6:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs 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://secure-web.cisco.com/1jXOAuzSz0mv5GshkE1m6vpNy3z4inQP9fZF6gnNsJSY42PIfiBYGmb_A9RIk2F8r0zrdY9m-tXDCObPpPQJbFFA49s_4oPzqGSovgu__dpsDB6GiJsJBT4Bm_Kjc74_e7KrkXTwR20Pe5u7YkJ8SehvC1vtMqc7kRnpebp6JRLjiaJDPXbx7g2gS3uKVq25lKkR3lcUeonNoJWpe0mn97J1-r0s7gPympMvlrWBt_ooDSshYxLp8dPDY9c9XjNuqtHS4J_fRnbF4zo_VVQxzayg5CcjlH87GcCTae0sPDGlq7m-ZUerCdazNepePJV-lzd_RrjM6ba6JXNJzcVWKRpEioQq8LKF80EumL7Me5BJm9RMmOn2ZKQwgyFkGJ7JO2Zue4KBVcXF3gOxqRAFV2cslZbytPRp2x_aEDPAadPU/https%3A%2F%2Frsclweb.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Joel C. Ewing Sent: 24 May 2024 06:02 To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
