Yes, Allocation did the cleanup for the DIRF bit. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Tom Brennan <[email protected]> Sent: Monday, May 27, 2024 4:48 PM To: [email protected] Subject: Re: VTOCs vs. catalogs I think I remember the DIRF bit. That happened when I would, for example, run a DFDSS full volume backup of a mod-3 and restore to a mod-9, and there was a warning message indicating I needed to allocate a dataset in order to force the processing that would determine the new free space on the mod-9. Does that sound anything like reality? It's been a while. On 5/27/2024 12:37 PM, Seymour J Metz wrote: > 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 <[email protected]> on behalf of > Charles Mills <[email protected]> > Sent: Monday, May 27, 2024 1:26 PM > To: [email protected] > 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 <[email protected]> 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 <[email protected]> on behalf of >> Steve Thompson <[email protected]> >> Sent: Friday, May 24, 2024 11:27 AM >> To: [email protected] >> 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 <[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 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 [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 >> >> >> >> ---------------------------------------------------------------------- >> 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 > ---------------------------------------------------------------------- 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
