DOS had VTOCs for as far back as I can remember, but when was the transition from DLAB and TLAB to DLBL and TLBL?
When did IBM introduce the DIRF bit in the VTOC? It was definitely in OS/360, but which release? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Steve Thompson <ste...@wkyr.net> Sent: Friday, May 24, 2024 11:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs 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://secure-web.cisco.com/1odBw3GEOl-eQtgejAefr15bp7Yjgq1VZ1WvUgBCrG9juGErPDn2ToWA1oEov1iWq1nP1bJw6eaKuPky8YmEAI6ROQImouPPYsKMCoGQ4ib8muwTwBtsgmaaEwwZlZiehgecLz8PbPsMQwcG6tJsnJ1A5dooWER-nlc8e4YktroinRIxWFzwwcwSbdSWcHH74KJSQEkXZ7HjEmlD-rondxM3-dfiCUg6WdtAfaSZIdRnWb-s0WXRcSwWWn6opjI-Xq_Mm4rZPflgd3uyNxmzRYFO3upfE079gkz4LE7Pyt_Bs2kE4cKOlzz3x2G9xSmKy9YDk5ssM6f8Ixw7X9JwxwfoEmYhlKrybn9x-ZmPbEvXi4Bs6_XiPY2ZhFGYLeUDT9UAkXR_oj8hxsaGAyq44-tIbzxarxzELtlv1VpBXhbY/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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
