Also, was the name "DOS contaminated" for the DIRF bit ever official? And when did IBM finally give an equate for X'80' in DS4VTOCI?
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Charles Mills <charl...@mcn.org> Sent: Monday, May 27, 2024 1:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs I started my first professional programming job in January of 1969, working with DOS/360. DLBL, EXTENT and TLBL cards existed but they were new -- the "old timers" still used DLAB, XTENT and TLAB. So that gives you an approximate timeframe. As @Shmeel has said, DOS definitely supported VTOCs. VTOCs were in fact partially portable between DOS and OS/360. What DOS lacked was OS-controlled free space management and support for the free space records of a VTOC. Free space management on volumes was controlled by a chart on the sysprog's wall and data set expiration dates. Charles On Mon, 27 May 2024 12:32:16 +0000, Seymour J Metz <sme...@gmu.edu> wrote: >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? > >-- >Shmeel (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 sstarted 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 Calalogs 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 I I 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 ---------------------------------------------------------------------- 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
