Re: VTOCs vs. catalogs
Sorry for the late reply. The problem was that it wanted to use a RACF function that wasn't available in RAKF (the MVS user developed equivalent). So I reassembled the code and found where the problem was and zapped it. It will be available in the next Hercules TK5 update, I believe. I do think we used to avoid IEHMOVE with MFT and MVT because it was a quite slow. However, it seems to fly under Hercules and MVS 3.8, and has advantages that it will allocate the output data set, and automatically adjust the size allocation depending on the DASD device it is going to. There is quite a lot of code devoted to it. Probably not much use for it these days, I suspect However, IEHMOVE automatically allocates the output Data Set or PDS and that does make life much easier. Also, I have been developing some procedures that use standard programs so you can delete or copy members, or data sets. This way, newcomers don't have to learn which utilities do what. They just have to know COPYxxx copies, or MOVE xxx etc. For example: // EXEC MOVEMEM,DSN='MY.CNTL',TO='OTHER.CNTL',MEM=MYMEMBER or // EXEC DELMEM,DSN='MY.CNTL',MEM=MYMEMBER or // EXEC ALLOCPDS, DSN='MyNew.PDS',Vol=WORK01,PRIM=10,SEC=3,MEMS=10 or // EXEC ALLOCKS,DSN='VSAM.DS',VOL=WORK01,PRIM=20 They use my old utility PARMCNTL to create the control cards for the utility programs. If they are useful, the ZOS JCL facilities can be used, of course. Clem Michael Stein wrote: On Wed, May 29, 2024 at 10:22:43PM +1000, Clement Clarke wrote: That is my recollection, too. MVS is when SVC99 appeared. Recently, I was looking at the source code for IEHMOVE to allow IEHMOVE to run under Hercules, and it uses DAIR. Is that under some MVS system under Hercules? Why won't it just work? Also IEHMOVE used the allocate svc directly in MVS 3.8. An example: TITLE 'IEHMVSSX-BUILD DCB AND GO TO DADSM' * 05838532 * TURN ON HIGH ORDER BIT OF REGISTER 0 TO INFORM DADSM @G32DSFS 05838632 * ALLOCATE THAT ENTRY WAS FROM A UTILITY PROGRAM @G32DSFS 05838732 * 05838832 LAACCE,2048 MAKE SIGN NEGATIVE @G32DSFS 05838932 SLL ACCE,20 SHIFT TO HI ORDER BYTE @G32DSFS 05839032 ORR0,ACCE SET BIT IN REG 0@G32DSFS 05839132 ALLO2B EQU * NO RACF ACTION @G32DSFS 05839232 SVC 32 ALLOCATION SVC @G32DSFS 05839332 LARETURN,4 05839532 SRLINK,RETURN 0584 BZDUPNAME PS: There are zaps/mods to IEHMOVE on the cbttape from UCLA which allow running IEHMOVE non-authorized with some restrictions. And with VIO work files. -- 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
Re: VTOCs vs. catalogs
On Wed, May 29, 2024 at 10:22:43PM +1000, Clement Clarke wrote: > That is my recollection, too. MVS is when SVC99 appeared. > > Recently, I was looking at the source code for IEHMOVE to allow IEHMOVE to > run under Hercules, and it uses DAIR. Is that under some MVS system under Hercules? Why won't it just work? Also IEHMOVE used the allocate svc directly in MVS 3.8. An example: TITLE 'IEHMVSSX-BUILD DCB AND GO TO DADSM' * 05838532 * TURN ON HIGH ORDER BIT OF REGISTER 0 TO INFORM DADSM @G32DSFS 05838632 * ALLOCATE THAT ENTRY WAS FROM A UTILITY PROGRAM @G32DSFS 05838732 * 05838832 LAACCE,2048 MAKE SIGN NEGATIVE @G32DSFS 05838932 SLL ACCE,20 SHIFT TO HI ORDER BYTE @G32DSFS 05839032 ORR0,ACCE SET BIT IN REG 0@G32DSFS 05839132 ALLO2B EQU * NO RACF ACTION @G32DSFS 05839232 SVC 32 ALLOCATION SVC @G32DSFS 05839332 LARETURN,4 05839532 SRLINK,RETURN 0584 BZDUPNAME PS: There are zaps/mods to IEHMOVE on the cbttape from UCLA which allow running IEHMOVE non-authorized with some restrictions. And with VIO work files. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
No, MVS is when the interface changed and became supported. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Clement Clarke <05cb6e944c87-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, May 29, 2024 8:22 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs That is my recollection, too. MVS is when SVC99 appeared. Recently, I was looking at the source code for IEHMOVE to allow IEHMOVE to run under Hercules, and it uses DAIR. I think RESTORE was mentioned too, but I am not 100%. I didn't attempt to find out any more. Clem Clarke On Tue, May 28, 2024 at 10:44 AM Tony Harminc wrote: > On Mon, 27 May 2024 at 19:50, Paul Gilmartin < > 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > > > On Mon, 27 May 2024 23:21:43 +, Seymour J Metz wrote: > > > > >Restore? > > > > > >My recollection is that DIRF came before TSO. Besides, SVC 99 *IS* > > Allocation. > > > > > I k ow SVC 99 *IS* Allocation. That's why I thought of it. > > TSO? > > > > Dynamic allocation arrived with TSO, and on MVT was supported in TSO only, > iirc. I'm pretty sure there was no batch TSO in MVT, but not sure if that > came with SVS or (more likely) with MVS. > > I am also reasonably sure that SVC 99 was not a supported interface on MVT. > Rather, the Dynamic Allocation Interface Routine (IKJDAIR) was the > documented interface, and under the covers it used a quite different > version of SVC 99 to do most of the work. > > But I digress... > > Tony H. > > -- > 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
Auto: Re: VTOCs vs. catalogs
Je suis absent le 29 mai 2024 après-midi. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
That is my recollection, too. MVS is when SVC99 appeared. Recently, I was looking at the source code for IEHMOVE to allow IEHMOVE to run under Hercules, and it uses DAIR. I think RESTORE was mentioned too, but I am not 100%. I didn't attempt to find out any more. Clem Clarke On Tue, May 28, 2024 at 10:44 AM Tony Harminc wrote: > On Mon, 27 May 2024 at 19:50, Paul Gilmartin < > 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > > > On Mon, 27 May 2024 23:21:43 +, Seymour J Metz wrote: > > > > >Restore? > > > > > >My recollection is that DIRF came before TSO. Besides, SVC 99 *IS* > > Allocation. > > > > > I k ow SVC 99 *IS* Allocation. That's why I thought of it. > > TSO? > > > > Dynamic allocation arrived with TSO, and on MVT was supported in TSO only, > iirc. I'm pretty sure there was no batch TSO in MVT, but not sure if that > came with SVS or (more likely) with MVS. > > I am also reasonably sure that SVC 99 was not a supported interface on MVT. > Rather, the Dynamic Allocation Interface Routine (IKJDAIR) was the > documented interface, and under the covers it used a quite different > version of SVC 99 to do most of the work. > > But I digress... > > Tony H. > > -- > 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
Re: VTOCs vs. catalogs
Well, thanks. This has been interesting, with at least the typical amount of thread drift! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
SVC 99 came in with TSO (R20.1?). What is Restore? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Monday, May 27, 2024 7:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs On Mon, 27 May 2024 23:21:43 +, Seymour J Metz wrote: >Restore? > >My recollection is that DIRF came before TSO. Besides, SVC 99 *IS* Allocation. > I k ow SVC 99 *IS* Allocation. That's why I thought of it. TSO? >IAC, all it took wasalllocating a new dataset to get the cleanup: > >//IEFREER DD UNIT=SYSDA,SPACE=(TRK,1) > >in a simple proc woul let the operator select a volume for cleanup select a >volume for cleanup on a START command. > Couldn't that have been done via MGCR by Restore? Obviating the need in Tom's "I needed". > >From: IBM Paul Gilmartin >Sent: Monday, May 27, 2024 6:46 PM > >On Mon, 27 May 2024 21:34:31 +, Syymour J Metz wrote: > >>Yes, Allocation did the cleanup for the DIRF bit. >> >Why didn't Restore just SVC 99 to automate the process? > >_ >>From: Tom Brennan >>Sent: Monday, May 27, 2024 4:48 PM >> >>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. -- gil -- 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
Re: VTOCs vs. catalogs
Batch TMP came in with TSO/E. SVC 99 was a supported interface in MVS, but the parameter list was very different from that in OS/360 and SVS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Tony Harminc Sent: Monday, May 27, 2024 8:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs On Mon, 27 May 2024 at 19:50, Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 27 May 2024 23:21:43 +, Seymour J Metz wrote: > > >Restore? > > > >My recollection is that DIRF came before TSO. Besides, SVC 99 *IS* > Allocation. > > > I k ow SVC 99 *IS* Allocation. That's why I thought of it. > TSO? > Dynamic allocation arrived with TSO, and on MVT was supported in TSO only, iirc. I'm pretty sure there was no batch TSO in MVT, but not sure if that came with SVS or (more likely) with MVS. I am also reasonably sure that SVC 99 was not a supported interface on MVT. Rather, the Dynamic Allocation Interface Routine (IKJDAIR) was the documented interface, and under the covers it used a quite different version of SVC 99 to do most of the work. But I digress... Tony H. -- 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
Re: VTOCs vs. catalogs
On Mon, 27 May 2024 at 19:50, Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 27 May 2024 23:21:43 +, Seymour J Metz wrote: > > >Restore? > > > >My recollection is that DIRF came before TSO. Besides, SVC 99 *IS* > Allocation. > > > I k ow SVC 99 *IS* Allocation. That's why I thought of it. > TSO? > Dynamic allocation arrived with TSO, and on MVT was supported in TSO only, iirc. I'm pretty sure there was no batch TSO in MVT, but not sure if that came with SVS or (more likely) with MVS. I am also reasonably sure that SVC 99 was not a supported interface on MVT. Rather, the Dynamic Allocation Interface Routine (IKJDAIR) was the documented interface, and under the covers it used a quite different version of SVC 99 to do most of the work. But I digress... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
On Mon, 27 May 2024 23:21:43 +, Seymour J Metz wrote: >Restore? > >My recollection is that DIRF came before TSO. Besides, SVC 99 *IS* Allocation. > I k ow SVC 99 *IS* Allocation. That's why I thought of it. TSO? >IAC, all it took wasalllocating a new dataset to get the cleanup: > >//IEFREER DD UNIT=SYSDA,SPACE=(TRK,1) > >in a simple proc woul let the operator select a volume for cleanup select a >volume for cleanup on a START command. > Couldn't that have been done via MGCR by Restore? Obviating the need in Tom's "I needed". > >From: IBM Paul Gilmartin >Sent: Monday, May 27, 2024 6:46 PM > >On Mon, 27 May 2024 21:34:31 +, Syymour J Metz wrote: > >>Yes, Allocation did the cleanup for the DIRF bit. >> >Why didn't Restore just SVC 99 to automate the process? > >_ >>From: Tom Brennan >>Sent: Monday, May 27, 2024 4:48 PM >> >>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. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
Restore? My recollection is that DIRF came before TSO. Besides, SVC 99 *IS* Allocation. IAC, all it took was allocating a new dataset to get the cleanup: //IEFRDER DD UNIT=SYSDA,SPACE=(TRK,1) in a simple proc would let the operator select a volume for cleanup select a volume for cleanup on a START command. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Monday, May 27, 2024 6:46 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs On Mon, 27 May 2024 21:34:31 +, Seymour J Metz wrote: >Yes, Allocation did the cleanup for the DIRF bit. > Why didn't Restore just SVC 99 to automate the process? _ >From: Tom Brennan >Sent: Monday, May 27, 2024 4:48 PM > >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. -- gil -- 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
Re: VTOCs vs. catalogs
On Mon, 27 May 2024 21:34:31 +, Seymour J Metz wrote: >Yes, Allocation did the cleanup for the DIRF bit. > Why didn't Restore just SVC 99 to automate the process? _ >From: Tom Brennan >Sent: Monday, May 27, 2024 4:48 PM > >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. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
Yes, Allocation did the cleanup for the DIRF bit. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Tom Brennan Sent: Monday, May 27, 2024 4:48 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 on behalf of > Charles Mills > 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 +, Seymour J Metz 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 on behalf of >> Steve Thompson >> 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_XiPY2Zh
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 on behalf of Charles Mills 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 +, Seymour J Metz 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 on behalf of Steve Thompson 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 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.
Re: VTOCs vs. catalogs
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 on behalf of Charles Mills 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 +, Seymour J Metz 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 on behalf of >Steve Thompson >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 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 in
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 +, Seymour J Metz 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 on behalf of >Steve Thompson >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 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. >&
Re: VTOCs vs. catalogs
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 on behalf of Steve Thompson 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 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 > ser
Re: VTOCs vs. catalogs
One of the things that made KSDS viable was the CI, which let existing programs continue to run after moving off of ISAM; I considered it to be a blunder that MVS failed to do so for ESDS. I was also unhappy that VSAM did not include the functionality of VAM in TSS, especially VIPAM. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Joel C. Ewing Sent: Friday, May 24, 2024 8:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs VSAM KSDS datasets were a clear win as a replacement for Indexed Sequental (ISAM) datasets when adding large numbers of keyed records. I saw cases where a KSDS implementation literally ran two orders of magnitude faster than ISAM and also took less DASD space, because ISAM required that unblocked overflow records be serially searched when there was no remaining space in a block to insert a record with a given key. In theory an ESDS dataset could be used to replace a sequential dataset and BSAM/QSAM, but of course the application interfaces were considerably different, and VSAM constraints on block size meant you could take substantial hits on track efficiency and performance for certain logical record sizes. An RRDS could be used as a functional replacement for direct access files, but again the restriction on block sizes caused compatibility issues, and tuning RRDS dataset access to get performance comparable to a well-tuned BDAM application was difficult to impossible. You could probably have designed a functional replacement for PDS datasets with either a KSDS or RRDS organization, or a combination of KSDS and ESDS, but it wouldn't have been practical. Many decades later PDSEs are almost a tranparent replacement for a PDS, but there are still some things possible with a PDS that are not supported for a PDSE. If VSAM's goal was to replace all other file organizations, it failed. The only old dataset organization to be made totally obsolete by VSAM was ISAM. JC Ewing On 5/24/24 10:02, Paul Gilmartin wrote: > On Thu, 23 May 2024 22:24:06 -0500, Mike Schwab wrote: >> VSAM came from the Future Systems development as a complete >> replacement, Lynn Wheeler has posts about that. >> It was cut back to be an addition to MVS, then combined with CVOL >> catalogs to ICF. >> > "complete replacement" of what, specifically? I have heard the > assertion that VSAM was intended to replace all other access > methods: QSAM, BSAM, BPAM, ... > > ... -- 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
Re: VTOCs vs. catalogs
I remember a lecturer at IBM in London 1975 when I was taking a PL/I course. He asked, "Why is VSAM like a cow in a meadow". Answer : "Because they are both outstanding in their field". Our company was still using ISAM and continued well past 1978. I first encountered VSAM at IBM when I went to work there in 1978. I wasn't sure what all the fuss was about. On Sat, May 25, 2024 at 11:46 PM billogden wrote: > > What you described about VSAM is what I heard too, a replacement of the > then dominant access methods. > > > Wow -- I distinctly remember that goal. It really scared many of us > (customers and IBMers) and made some of us aware of the gaps between > "developers" and "users". > > KSDS worked well to replace ISAM (and ISAM is another bad memory!) The > other > VSAM types mostly vanished, although there is a newer one for LINEAR data. > > Some participants here are roughly as old as I am -- with notes about 2311s > and 2314s (and we should probably skip our potential comments about 650s, > 1620s, 1400s, and 709xs)! > > Bill Ogden > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Extended Attributes (was: VTOCs vs. catalogs)
On Sat, 25 May 2024 09:45:57 -0400, billogden wrote: >> What you described about VSAM is what I heard too, a replacement of the >then dominant access methods. >> >Wow -- I distinctly remember that goal. It really scared many of us >(customers and IBMers) and made some of us aware of the gaps between >"developers" and "users". > It is IBM's culture, when confronting a requirement, to provide an alternative but not to generalize. For example, DSORG=PS/PO did not meet the needs of JES so the Spool was invented, but no access method simply treats PS/PO/Spool alike. OMVS did slightly better: z/FS files can be allocated as if PS, and directories read (but not written) by BPAM. And they are not supported as SYSEXEC or as STEPLIB. And IEBGENER can't copy load modules. Not general. TRANSMIT/RECEIVE handle PS/PO nicely, but not zFS. This thread discussed attributes in VTOCs vs. catalogs vs. VVDS. And OMVS, MacOS, and Linux all support some version of "Extended Attributes". An example from Linux: 523 $ 523 $ xattr -l * example.com: user.mime_type: text/html; charset=UTF-8 example.com: user.xdg.origin.url: https://example.com/ 524 $ But they're not portable and not supported by common transport utilities such as zip. Where should extended attributes (sometimes called metadata) reside? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
> What you described about VSAM is what I heard too, a replacement of the then dominant access methods. > Wow -- I distinctly remember that goal. It really scared many of us (customers and IBMers) and made some of us aware of the gaps between "developers" and "users". KSDS worked well to replace ISAM (and ISAM is another bad memory!) The other VSAM types mostly vanished, although there is a newer one for LINEAR data. Some participants here are roughly as old as I am -- with notes about 2311s and 2314s (and we should probably skip our potential comments about 650s, 1620s, 1400s, and 709xs)! Bill Ogden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
Thank you for a better memory than mine. Yes, those were the terms the instructor used when I heard the story – AM1 (Access Method 1) for the original grand design, and AM0 for what we got instead. Peter From: IBM Mainframe Discussion List On Behalf Of Tony Harminc Sent: Saturday, May 25, 2024 1:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs On Fri, 24 May 2024 at 15:59, Farley, Peter < 031df298a9da-dmarc-requ...@listserv.ua.edu<mailto:031df298a9da-dmarc-requ...@listserv.ua.edu>> wrote: > In the mid-1970’s (or it may have been the early 1980’s, the memory is > fainter now) I took an operating systems overview class at a technical > college nearby, and the instructor was an IBM Fellow whose name I have long > since forgotten, but in one class he told us a story about how VSAM came to > be as we know it today. The following is my (perhaps faulty) memory of the > story he told us. > > The original Virtual Storage Access Method design was created by a group > of people within IBM as a complete replacement for ALL then-existing access > methods. When it was presented to the IBM powers, one of the > marketing/sales honchos screamed loudly that the conversion costs for > existing customers would clobber sales (and therefore profits) and that > this could not be tolerated as the way forward. When the group that > invented the idea refused to reduce the scope of the project, he took home > the design paper and took out all the parts that would require IBM > customers to convert existing code and processes, and the resulting design > document became known as VSAM0 (VSAM zero) and this is the VSAM design that > was implemented. > I too heard a similar story from an IBMer at a course in the 1980s. The terminology he used was AM0 (what we got) vs a proposed much grander AM1. I think the story of the original VSAM catalogue design must be related. If anyone set out to design a VSAM catalogue they would surely produce roughly the ICF catalogues we know today. But the original VSAM catalogues were Just Weird, were hard to use, performed poorly, were missing basic function, and so on and so on - things we have mostly forgotten about now. There must surely have been some reason for such a design, and perhaps that is also a relic of AM1. Tony H. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
On Fri, 24 May 2024 at 15:59, Farley, Peter < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > In the mid-1970’s (or it may have been the early 1980’s, the memory is > fainter now) I took an operating systems overview class at a technical > college nearby, and the instructor was an IBM Fellow whose name I have long > since forgotten, but in one class he told us a story about how VSAM came to > be as we know it today. The following is my (perhaps faulty) memory of the > story he told us. > > The original Virtual Storage Access Method design was created by a group > of people within IBM as a complete replacement for ALL then-existing access > methods. When it was presented to the IBM powers, one of the > marketing/sales honchos screamed loudly that the conversion costs for > existing customers would clobber sales (and therefore profits) and that > this could not be tolerated as the way forward. When the group that > invented the idea refused to reduce the scope of the project, he took home > the design paper and took out all the parts that would require IBM > customers to convert existing code and processes, and the resulting design > document became known as VSAM0 (VSAM zero) and this is the VSAM design that > was implemented. > I too heard a similar story from an IBMer at a course in the 1980s. The terminology he used was AM0 (what we got) vs a proposed much grander AM1. I think the story of the original VSAM catalogue design must be related. If anyone set out to design a VSAM catalogue they would surely produce roughly the ICF catalogues we know today. But the original VSAM catalogues were Just Weird, were hard to use, performed poorly, were missing basic function, and so on and so on - things we have mostly forgotten about now. There must surely have been some reason for such a design, and perhaps that is also a relic of AM1. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
I didn't see where Lynn mentioned VSAM development, but several Future Systems posts leading to https://en.wikipedia.org/wiki/IBM_Future_Systems_project , where it became S38, AS/400, IBM i. https://www.garlic.com/~lynn/index.html#archpost is his posts. On Fri, May 24, 2024 at 7:36 PM rpinion865 <042a019916dd-dmarc-requ...@listserv.ua.edu> wrote: > > What you described about VSAM is what I heard too, a replacement of the then > dominant access methods. > > Sent from Proton Mail Android > > > Original Message > On 5/24/24 8:18 PM, Joel C. Ewing wrote: > > > VSAM KSDS datasets were a clear win as a replacement for Indexed > > Sequental (ISAM) datasets when adding large numbers of keyed records. I > > saw cases where a KSDS implementation literally ran two orders of > > magnitude faster than ISAM and also took less DASD space, because ISAM > > required that unblocked overflow records be serially searched when > > there was no remaining space in a block to insert a record with a given > > key. > > > > In theory an ESDS dataset could be used to replace a sequential dataset > > and BSAM/QSAM, but of course the application interfaces were > > considerably different, and VSAM constraints on block size meant you > > could take substantial hits on track efficiency and performance for > > certain logical record sizes. > > > > An RRDS could be used as a functional replacement for direct access > > files, but again the restriction on block sizes caused compatibility > > issues, and tuning RRDS dataset access to get performance comparable to > > a well-tuned BDAM application was difficult to impossible. > > > > You could probably have designed a functional replacement for PDS > > datasets with either a KSDS or RRDS organization, or a combination of > > KSDS and ESDS, but it wouldn't have been practical. Many decades later > > PDSEs are almost a tranparent replacement for a PDS, but there are still > > some things possible with a PDS that are not supported for a PDSE. > > > > If VSAM's goal was to replace all other file organizations, it failed. > > The only old dataset organization to be made totally obsolete by VSAM > > was ISAM. > > > > JC Ewing > > > > On 5/24/24 10:02, Paul Gilmartin wrote: > > > On Thu, 23 May 2024 22:24:06 -0500, Mike Schwab wrote: > > >> VSAM came from the Future Systems development as a complete > > >> replacement, Lynn Wheeler has posts about that. > > >> It was cut back to be an addition to MVS, then combined with CVOL > > >> catalogs to ICF. > > >> > > > "complete replacement" of what, specifically? I have heard the > > > assertion that VSAM was intended to replace all other access > > > methods: QSAM, BSAM, BPAM, ... > > > > > > ... > > > > -- > > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
What you described about VSAM is what I heard too, a replacement of the then dominant access methods. Sent from Proton Mail Android Original Message On 5/24/24 8:18 PM, Joel C. Ewing wrote: > VSAM KSDS datasets were a clear win as a replacement for Indexed > Sequental (ISAM) datasets when adding large numbers of keyed records. I > saw cases where a KSDS implementation literally ran two orders of > magnitude faster than ISAM and also took less DASD space, because ISAM > required that unblocked overflow records be serially searched when > there was no remaining space in a block to insert a record with a given key. > > In theory an ESDS dataset could be used to replace a sequential dataset > and BSAM/QSAM, but of course the application interfaces were > considerably different, and VSAM constraints on block size meant you > could take substantial hits on track efficiency and performance for > certain logical record sizes. > > An RRDS could be used as a functional replacement for direct access > files, but again the restriction on block sizes caused compatibility > issues, and tuning RRDS dataset access to get performance comparable to > a well-tuned BDAM application was difficult to impossible. > > You could probably have designed a functional replacement for PDS > datasets with either a KSDS or RRDS organization, or a combination of > KSDS and ESDS, but it wouldn't have been practical. Many decades later > PDSEs are almost a tranparent replacement for a PDS, but there are still > some things possible with a PDS that are not supported for a PDSE. > > If VSAM's goal was to replace all other file organizations, it failed. > The only old dataset organization to be made totally obsolete by VSAM > was ISAM. > > JC Ewing > > On 5/24/24 10:02, Paul Gilmartin wrote: > > On Thu, 23 May 2024 22:24:06 -0500, Mike Schwab wrote: > >> VSAM came from the Future Systems development as a complete > >> replacement, Lynn Wheeler has posts about that. > >> It was cut back to be an addition to MVS, then combined with CVOL > >> catalogs to ICF. > >> > > "complete replacement" of what, specifically? I have heard the > > assertion that VSAM was intended to replace all other access > > methods: QSAM, BSAM, BPAM, ... > > > > ... > > -- > 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
Re: VTOCs vs. catalogs
VSAM KSDS datasets were a clear win as a replacement for Indexed Sequental (ISAM) datasets when adding large numbers of keyed records. I saw cases where a KSDS implementation literally ran two orders of magnitude faster than ISAM and also took less DASD space, because ISAM required that unblocked overflow records be serially searched when there was no remaining space in a block to insert a record with a given key. In theory an ESDS dataset could be used to replace a sequential dataset and BSAM/QSAM, but of course the application interfaces were considerably different, and VSAM constraints on block size meant you could take substantial hits on track efficiency and performance for certain logical record sizes. An RRDS could be used as a functional replacement for direct access files, but again the restriction on block sizes caused compatibility issues, and tuning RRDS dataset access to get performance comparable to a well-tuned BDAM application was difficult to impossible. You could probably have designed a functional replacement for PDS datasets with either a KSDS or RRDS organization, or a combination of KSDS and ESDS, but it wouldn't have been practical. Many decades later PDSEs are almost a tranparent replacement for a PDS, but there are still some things possible with a PDS that are not supported for a PDSE. If VSAM's goal was to replace all other file organizations, it failed. The only old dataset organization to be made totally obsolete by VSAM was ISAM. JC Ewing On 5/24/24 10:02, Paul Gilmartin wrote: On Thu, 23 May 2024 22:24:06 -0500, Mike Schwab wrote: VSAM came from the Future Systems development as a complete replacement, Lynn Wheeler has posts about that. It was cut back to be an addition to MVS, then combined with CVOL catalogs to ICF. "complete replacement" of what, specifically? I have heard the assertion that VSAM was intended to replace all other access methods: QSAM, BSAM, BPAM, ... ... -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
In the mid-1970’s (or it may have been the early 1980’s, the memory is fainter now) I took an operating systems overview class at a technical college nearby, and the instructor was an IBM Fellow whose name I have long since forgotten, but in one class he told us a story about how VSAM came to be as we know it today. The following is my (perhaps faulty) memory of the story he told us. The original Virtual Storage Access Method design was created by a group of people within IBM as a complete replacement for ALL then-existing access methods. When it was presented to the IBM powers, one of the marketing/sales honchos screamed loudly that the conversion costs for existing customers would clobber sales (and therefore profits) and that this could not be tolerated as the way forward. When the group that invented the idea refused to reduce the scope of the project, he took home the design paper and took out all the parts that would require IBM customers to convert existing code and processes, and the resulting design document became known as VSAM0 (VSAM zero) and this is the VSAM design that was implemented. I have never seen any actual history that describes the events around the creation of VSAM as he related them, but that instructor seemed quite believable at the time, and he was an IBM Fellow so you would think he knew whereof he spoke. Peter From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Friday, May 24, 2024 11:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs On Thu, 23 May 2024 22:24:06 -0500, Mike Schwab wrote: > >VSAM came from the Future Systems development as a complete >replacement, Lynn Wheeler has posts about that. >It was cut back to be an addition to MVS, then combined with CVOL >catalogs to ICF. > "complete replacement" of what, specifically? I have heard the assertion that VSAM was intended to replace all other access methods: QSAM, BSAM, BPAM, ... -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
I just grabbed the first one I found at bitsavers. AFAIK, everything from BOS up supported a VTOC on DASD from day one, other than the card and tape only software. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Friday, May 24, 2024 1:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs Even earlier, in November, 1966, https://bitsavers.org/pdf/ibm/360/dos/C24-5036-1_DOS_System_Control_and_System_Service_Programs_Nov1966.pdf Bottom of page 53 references VTOCs -- Tom Marchant On Fri, 24 May 2024 17:21:43 +, Seymour J Metz wrote: >Nope. ><http://bitsavers.org/pdf/ibm/360/dos/C24-3427-3_Disk_Operating_System_Data_Management_Concepts_Feb68.pdf> > >The fact had DLAB and DLBL statements does not mean that the was no VTOC. > >-- >Shmuel (Seymour J.) Metz >http://msoon.gmu.edu/~smetz3 >עַם יִשְׂרָאֵל חַי >נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > >From: IBM Mainframe Discussion List on behalf of >Lennie Bradshaw >Sent: Friday, May 24, 2024 12:53 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: VTOCs vs. catalogs > >VTOCs were introduced in a release of DOS/VS after the one we were using. We >definitely used //DLBL statement to specify disk extents. >Lennie -- 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
Re: [EXTERNAL] Re: VTOCs vs. catalogs
Hi Tony, I meant that the (DEFINE) SPACE would be similar to a PDS and the SUBALLOCATED Clusters would be similar to members in that PDS (SPACE). Regards, David On 2024-05-24 14:26, Tony Harminc wrote: On Fri, 24 May 2024 at 11:31, David Spiegel < 0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: Hi Rex, VVDSs came with ICF. Before that, VSAM Clusters were ALLOCATED as either SUBALLOCATION or UNIQUE. SUBALLOCATION meant that the user ALLOCATED a "cloud" (i.e. DEFINE SPACE) to hold 1 or more VSAM suballocated Dataset. Yes, I was about to mention this. All the information for a non-UNIQUE VSAM dataset was kept in the VSAM catalogue. One advantage in those distant days of mountable disk drives was that one could allocate or delete a VSAM dataset with all its details while the disk pack was sitting on the shelf. This could be seriously useful for production jobs where the packs were mounted only when the job ran. But of course the down side - as mentioned here in a slightly different context - was that the disk volume and the catalogue could get out of sync if the disk failed, and with potentially much worse results than just some datasets not being catalogued. It was conceptually similar to a PDS and Members. I'm not quite seeing that analogy... Have you ever met a PDS with members on different volumes? Regards, David Tony H. -- 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
Re: [EXTERNAL] Re: VTOCs vs. catalogs
On Fri, 24 May 2024 at 11:31, David Spiegel < 0468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > Hi Rex, > VVDSs came with ICF. Before that, VSAM Clusters were ALLOCATED as either > SUBALLOCATION or UNIQUE. > SUBALLOCATION meant that the user ALLOCATED a "cloud" (i.e. DEFINE > SPACE) to hold 1 or more VSAM suballocated Dataset. > Yes, I was about to mention this. All the information for a non-UNIQUE VSAM dataset was kept in the VSAM catalogue. One advantage in those distant days of mountable disk drives was that one could allocate or delete a VSAM dataset with all its details while the disk pack was sitting on the shelf. This could be seriously useful for production jobs where the packs were mounted only when the job ran. But of course the down side - as mentioned here in a slightly different context - was that the disk volume and the catalogue could get out of sync if the disk failed, and with potentially much worse results than just some datasets not being catalogued. It was conceptually similar to a PDS and Members. > I'm not quite seeing that analogy... Have you ever met a PDS with members on different volumes? Regards, > David > Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
Even earlier, in November, 1966, https://bitsavers.org/pdf/ibm/360/dos/C24-5036-1_DOS_System_Control_and_System_Service_Programs_Nov1966.pdf Bottom of page 53 references VTOCs -- Tom Marchant On Fri, 24 May 2024 17:21:43 +, Seymour J Metz wrote: >Nope. ><http://bitsavers.org/pdf/ibm/360/dos/C24-3427-3_Disk_Operating_System_Data_Management_Concepts_Feb68.pdf> > >The fact had DLAB and DLBL statements does not mean that the was no VTOC. > >-- >Shmuel (Seymour J.) Metz >http://msoon.gmu.edu/~smetz3 >עַם יִשְׂרָאֵל חַי >נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > >From: IBM Mainframe Discussion List on behalf of >Lennie Bradshaw >Sent: Friday, May 24, 2024 12:53 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: VTOCs vs. catalogs > >VTOCs were introduced in a release of DOS/VS after the one we were using. We >definitely used //DLBL statement to specify disk extents. >Lennie -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
Having the information about the contents of a volume on the volume itself allows the volume to be used on more than one system. If that information was stored in the catalog, that would not be practical. DASD devices were not nearly as reliable as they are today, even without RAID. When a volume is restored to a new volume, all of the information about the contents of the restored volume is included on the volume itself. Catalogs relieve the need to specify which volume contains a data set in the JCL. A volume can be DASD or tape. Some early DASD devices for system/360, like the 2311 and 2314 could be dismounted and a different volume mounted in its place. It was not uncommon to have many more volumes than drives. -- Tom Marchant On Thu, 23 May 2024 22:32:28 -0400, 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? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
Nope. <http://bitsavers.org/pdf/ibm/360/dos/C24-3427-3_Disk_Operating_System_Data_Management_Concepts_Feb68.pdf> The fact had DLAB and DLBL statements does not mean that the was no VTOC. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Lennie Bradshaw Sent: Friday, May 24, 2024 12:53 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs VTOCs were introduced in a release of DOS/VS after the one we were using. We definitely used //DLBL statement to specify disk extents. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 24 May 2024 11:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs They say that the memory is the scond thing to go; I can't remember the first. From DOS/VS Data Management Guide <http://secure-web.cisco.com/1kqVQ2hs9Fb_zzATH_oEjvYwjDvDLD6XsrqlFvq6h15M37OrnZ469g3uM1tMQJz3IrXfuOOXGyz6FXZ1N_lDC400eVbUdfAPl_A19egzBWXltRrT2RlhjMSC5bES9k5t4oHYO0FRqrKHfbZNyGwMzN5o2uAbnxWME0eUfuA-UovOSJGNz1O6ShLcK7gZD_vevLN0sGOjL-mYBMwddPiyezg2MLZMC7xYd_5B64IwD1mTgCEQUysEqGH-ElmU-tTaTym2WRSJTJuwiUldZOPH1Y52ZYuX8gYFbnGKUyACcWeKEXnlfMAv_evOkmfJCG4WKeWkIGPZ70iORIgjr5wq1FqSRvS9zAn3dzLv1L1v6gCgK9aiDef3Hue9f1bWecLaTFn4qn4eBxxoIWtkYvoXvEleIrXWJe2CqXDy4dEJbuSM/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F370%2FDOS_VS%2FRel_29_Nov73%2FGC33-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 on behalf of Lennie Bradshaw 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 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 re
Re: VTOCs vs. catalogs
When using a VSAM catalog, all of the VSAM datasets on a given volume needed to be catalogued in the same VSAM catalog. This restriction was removed when ICF catalogs and VVDS datasets were introduced with DF/EF, which was a package available as an add-on to MVS/SP3, I think. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Michael Watkins Sent: 24 May 2024 15:00 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs Yes, absolutely. MVS systems were becoming larger and creating backups was becoming an issue. Backing up to physical tape was the only real option then. Not only were there more volumes, but there were more datasets that spanned volumes. Before ICF catalogs, catalog records contained VSAM time stamps. When restoring from a backup, getting the timestamps in the catalog to match up with the dataset on a volume where the catalog did not reside became an issue (unless all other processing was halted while creating the backups) because the tape backups themselves took a considerable amount of time. This problem was compounded when datasets spanned volumes. The solution was to move the volatile fields (e.g. timestamps) from the catalog and place them onto the DASD volume where the data was; then they would be backed up at the same time that the data was backed up. This was the origin of, and reason for, the VVDS. The volatile catalog fields describing the datasets were moved to where the dataset was so they could be backed up with the data. An IBM SSR told me at the time that the VVDS would eventually replace the VTOC, but this, obviously, never came to pass. -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, May 24, 2024 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. Hi Rex, "...Followed by SMS and VVDS for non-VSAM datasets ..." This was meant (AFAIK) to state that VVDS for Non-VSAMs came into use with SMS-Controlled DASD Volumes. It is also true that VVDSs were introduced with ICF Catalogs (circa 1981, recalled and re-released in 1982). Regards, David On 2024-05-24 09:44, Pommier, Rex wrote: > Didn't the VVDS come along with the ICF catalog structure? > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Thursday, May 23, 2024 10:32 PM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: VTOCs vs. catalogs > > All speculation on my part. One system with no DASD, you need neither. > On a system with only one, of just a few DASD volumes, a VTOC is required to > say where on the volume a dataset is and the basic attributes of PS and PDS > datasets. > > Once you get to several always mounted DASSD volumes, it becomes a pain to > need to remember and specify VOLSER in the JCL. > > CVOLs where an early attempt to solve this problem. Then came VSAM > (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. > Followed by SMS and VVDS for non-VSAM datasets > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Mike Schwab >> Sent: Thursday, May 23, 2024 8:24 PM >> To:IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: VTOCs vs. catalogs >> >> [EXTERNAL EMAIL] >> >> For the most part the catalog lets you locate your dataset no matter >> which volume you put it on. >> For non-vsam, that is about all that is stored, dataset >> characteristics are in the VTOC. >> And with non-SMS volumes you can have uncataloged datasets on DASD or >> tape. >> >> VSAM came from the Future Systems development as a complete >> replacement, Lynn Wheeler has posts about that. >> It was cut back to be an addition to MVS, then combined with CVOL >> catalogs to ICF. >> >> On Thu, May 23, 2024 at 9:32 PM 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? >>> >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email tolists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >> >> >> -- >> Mike A Schwab, Springfield IL USA >> W
Re: VTOCs vs. catalogs
VTOCs were introduced in a release of DOS/VS after the one we were using. We definitely used //DLBL statement to specify disk extents. Lennie -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: 24 May 2024 11:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs 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 on behalf of Lennie Bradshaw 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 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-
Re: VTOCs vs. catalogs
Or one dataset on 59 DASD volumes. Get one out of order you might have problems. On Fri, May 24, 2024 at 8:21 AM billogden wrote: > > Subject: Re: VTOCs vs. catalogs > > I'm curious whether any of you old-timers can explain why we have both > VTOCs and catalogs. > > Please note that you can have datasets with exactly the same name on > different volumes, but only one can be cataloged. This was (and might still > be) a common practice for sysprogs who try to maintain a system. (I still do > it when it is convenient.) > > Also, it is easy to move a non-VSAM non-SMS volume to a completely different > z/OS system and simply recatalog the datasets (or some of them) on that > volume. > > Bill Ogden > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: VTOCs vs. catalogs
Hi Rex, VVDSs came with ICF. Before that, VSAM Clusters were ALLOCATED as either SUBALLOCATION or UNIQUE. SUBALLOCATION meant that the user ALLOCATED a "cloud" (i.e. DEFINE SPACE) to hold 1 or more VSAM suballocated Dataset. It was conceptually similar to a PDS and Members. Regards, David On 2024-05-24 11:10, Pommier, Rex wrote: David, Since you are obviously my elder in the field, please enlighten me as to what the VVDS was before the ICF catalog came along. When I started, VSAM catalogs were still a thing (as were CVOLs I think) but we never had them at my shop. I was taught that the VVDS and BCS structures were the 2 components of an ICF catalog, created to overcome shortcomings of the VSAM catalog. Did VVDS's exist before the ICF catalog or were they introduced with ICF? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, May 24, 2024 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: VTOCs vs. catalogs Hi Rex, You said: "...I never worked with either CVOLs or VSAM catalogs ..." If I may take the Bible out of context, please see: DE 32:7 זְקֵנֶ֖יךָ וְיֹ֥אמְרוּ לָֽךְ "... Remember the days of old, Consider the years of ages past; Ask your parent, who will inform you, Your elders, who will tell you: ..." Regards,. David On 2024-05-24 10:12, Pommier, Rex wrote: Hi David, This is the part I was commenting on. " Then came VSAM (and VVDS?) and VSAM Catalogs,...". I took that comment as being Dave guessing that possibly the VVDS came along with VSAM catalogs which I believe were a stepping stone between CVOLs and ICF catalogs. I never worked with either CVOLs or VSAM catalogs but I was pretty sure the VVDS came along with the ICF. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, May 24, 2024 8:55 AM To:IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: VTOCs vs. catalogs Hi Rex, "...Followed by SMS and VVDS for non-VSAM datasets ..." This was meant (AFAIK) to state that VVDS for Non-VSAMs came into use with SMS-Controlled DASD Volumes. It is also true that VVDSs were introduced with ICF Catalogs (circa 1981, recalled and re-released in 1982). Regards, David On 2024-05-24 09:44, Pommier, Rex wrote: Didn't the VVDS come along with the ICF catalog structure? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Thursday, May 23, 2024 10:32 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: VTOCs vs. catalogs All speculation on my part. One system with no DASD, you need neither. On a system with only one, of just a few DASD volumes, a VTOC is required to say where on the volume a dataset is and the basic attributes of PS and PDS datasets. Once you get to several always mounted DASSD volumes, it becomes a pain to need to remember and specify VOLSER in the JCL. CVOLs where an early attempt to solve this problem. Then came VSAM (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. Followed by SMS and VVDS for non-VSAM datasets -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Thursday, May 23, 2024 8:24 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs [EXTERNAL EMAIL] For the most part the catalog lets you locate your dataset no matter which volume you put it on. For non-vsam, that is about all that is stored, dataset characteristics are in the VTOC. And with non-SMS volumes you can have uncataloged datasets on DASD or tape. VSAM came from the Future Systems development as a complete replacement, Lynn Wheeler has posts about that. It was cut back to be an addition to MVS, then combined with CVOL catalogs to ICF. On Thu, May 23, 2024 at 9:32 PM 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? --- - -- For IBM-MAIN subscribe / signoff / archive access instructions, send emailtolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? - - For IBM-MAIN subscribe / signoff / archive access instructions, send emailtolists...@listserv.ua.edu with the message: INFO IBM-MAIN - - For IBM-MAIN subscribe / signoff / archive access instructions, send emailtolists...@listserv.ua.edu with the message: INFO IBM-MAIN -
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://rsclweb.com -Original Message- From: IBM Mainframe Discussion List 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 ---
Re: VTOCs vs. catalogs
VSAM certainly didn't replace PDS. Too bad they didn't port VAM from TSS. In Eunix there is no catalog of file systems that you can mount. "Every OS Sucks", Three Dead Trolls in a Baggie <https://genius.com/Three-dead-trolls-in-a-baggie-every-os-sucks-lyrics> -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu> Sent: Friday, May 24, 2024 11:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs On Thu, 23 May 2024 22:24:06 -0500, Mike Schwab wrote: > >VSAM came from the Future Systems development as a complete >replacement, Lynn Wheeler has posts about that. >It was cut back to be an addition to MVS, then combined with CVOL >catalogs to ICF. > "complete replacement" of what, specifically? I have heard the assertion that VSAM was intended to replace all other access methods: QSAM, BSAM, BPAM, ... I have known an OS partisan to rant hereabouts: The MVS catalog tells the OS exactly where a data set resides, whereas with UNIX the programmer must supply such information to access any file. I believe he was referring to pathnames. I have never felt that hardship. UNIX provides alternative facilities: o Mounted filesystems o Symbolic links o Directory hierarchy o The current working directory o Logical filesystems comprising multiple physical volumes, a technique MVS never mastered, partly because of compatibility constraints with BBCCHHR. It was desigh shortsightedness to expose low-level DASD characteristics to high-level programmers. Beyond that, the MVS namespace is woefully small; another archaic and insuperable compatibility constraint. -- gil -- 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
Re: [EXTERNAL] Re: VTOCs vs. catalogs
David, Since you are obviously my elder in the field, please enlighten me as to what the VVDS was before the ICF catalog came along. When I started, VSAM catalogs were still a thing (as were CVOLs I think) but we never had them at my shop. I was taught that the VVDS and BCS structures were the 2 components of an ICF catalog, created to overcome shortcomings of the VSAM catalog. Did VVDS's exist before the ICF catalog or were they introduced with ICF? Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, May 24, 2024 9:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: VTOCs vs. catalogs Hi Rex, You said: "...I never worked with either CVOLs or VSAM catalogs ..." If I may take the Bible out of context, please see: DE 32:7 זְקֵנֶ֖יךָ וְיֹ֥אמְרוּ לָֽךְ "... Remember the days of old, Consider the years of ages past; Ask your parent, who will inform you, Your elders, who will tell you: ..." Regards,. David On 2024-05-24 10:12, Pommier, Rex wrote: > Hi David, > > This is the part I was commenting on. " Then came VSAM (and VVDS?) and > VSAM Catalogs,...". I took that comment as being Dave guessing that possibly > the VVDS came along with VSAM catalogs which I believe were a stepping stone > between CVOLs and ICF catalogs. I never worked with either CVOLs or VSAM > catalogs but I was pretty sure the VVDS came along with the ICF. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of David Spiegel > Sent: Friday, May 24, 2024 8:55 AM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: VTOCs vs. catalogs > > Hi Rex, > "...Followed by SMS and VVDS for non-VSAM datasets ..." > This was meant (AFAIK) to state that VVDS for Non-VSAMs came into use with > SMS-Controlled DASD Volumes. > It is also true that VVDSs were introduced with ICF Catalogs (circa 1981, > recalled and re-released in 1982). > > Regards, > David > > On 2024-05-24 09:44, Pommier, Rex wrote: >> Didn't the VVDS come along with the ICF catalog structure? >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Gibney, Dave >> Sent: Thursday, May 23, 2024 10:32 PM To:IBM-MAIN@LISTSERV.UA.EDU >> Subject: [EXTERNAL] Re: VTOCs vs. catalogs >> >> All speculation on my part. One system with no DASD, you need neither. >> On a system with only one, of just a few DASD volumes, a VTOC is required to >> say where on the volume a dataset is and the basic attributes of PS and PDS >> datasets. >> >> Once you get to several always mounted DASSD volumes, it becomes a pain to >> need to remember and specify VOLSER in the JCL. >> >> CVOLs where an early attempt to solve this problem. Then came VSAM >> (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. >> Followed by SMS and VVDS for non-VSAM datasets >> >>> -Original Message- >>> From: IBM Mainframe Discussion List On >>> Behalf Of Mike Schwab >>> Sent: Thursday, May 23, 2024 8:24 PM To:IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: VTOCs vs. catalogs >>> >>> [EXTERNAL EMAIL] >>> >>> For the most part the catalog lets you locate your dataset no matter >>> which volume you put it on. >>> For non-vsam, that is about all that is stored, dataset >>> characteristics are in the VTOC. >>> And with non-SMS volumes you can have uncataloged datasets on DASD >>> or tape. >>> >>> VSAM came from the Future Systems development as a complete >>> replacement, Lynn Wheeler has posts about that. >>> It was cut back to be an addition to MVS, then combined with CVOL >>> catalogs to ICF. >>> >>> On Thu, May 23, 2024 at 9:32 PM 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? >>>> --- >>>> - >>>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send emailtolists...@listserv.ua.edu with the message: INFO >>>> IBM-MAIN >>> >>> -- >>> Mike A Schwab, Springfield IL USA >>> Where do Forest Rangers go to get away from it all? &
Re: VTOCs vs. catalogs
On Thu, 23 May 2024 22:24:06 -0500, Mike Schwab wrote: > >VSAM came from the Future Systems development as a complete >replacement, Lynn Wheeler has posts about that. >It was cut back to be an addition to MVS, then combined with CVOL >catalogs to ICF. > "complete replacement" of what, specifically? I have heard the assertion that VSAM was intended to replace all other access methods: QSAM, BSAM, BPAM, ... I have known an OS partisan to rant hereabouts: The MVS catalog tells the OS exactly where a data set resides, whereas with UNIX the programmer must supply such information to access any file. I believe he was referring to pathnames. I have never felt that hardship. UNIX provides alternative facilities: o Mounted filesystems o Symbolic links o Directory hierarchy o The current working directory o Logical filesystems comprising multiple physical volumes, a technique MVS never mastered, partly because of compatibility constraints with BBCCHHR. It was desigh shortsightedness to expose low-level DASD characteristics to high-level programmers. Beyond that, the MVS namespace is woefully small; another archaic and insuperable compatibility constraint. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: VTOCs vs. catalogs
Correction: VTOC index came with DFDS but VVDS came with ICF in DF/EF. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Seymour J Metz Sent: Friday, May 24, 2024 10:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: VTOCs vs. catalogs VVDS came with DFDS. ICF and קריעת תחת came with DF/EF. Things got better with DFP and DFSMS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Pommier, Rex Sent: Friday, May 24, 2024 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: VTOCs vs. catalogs Hi David, This is the part I was commenting on. " Then came VSAM (and VVDS?) and VSAM Catalogs,...". I took that comment as being Dave guessing that possibly the VVDS came along with VSAM catalogs which I believe were a stepping stone between CVOLs and ICF catalogs. I never worked with either CVOLs or VSAM catalogs but I was pretty sure the VVDS came along with the ICF. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, May 24, 2024 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: VTOCs vs. catalogs Hi Rex, "...Followed by SMS and VVDS for non-VSAM datasets ..." This was meant (AFAIK) to state that VVDS for Non-VSAMs came into use with SMS-Controlled DASD Volumes. It is also true that VVDSs were introduced with ICF Catalogs (circa 1981, recalled and re-released in 1982). Regards, David On 2024-05-24 09:44, Pommier, Rex wrote: > Didn't the VVDS come along with the ICF catalog structure? > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Thursday, May 23, 2024 10:32 PM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: VTOCs vs. catalogs > > All speculation on my part. One system with no DASD, you need neither. > On a system with only one, of just a few DASD volumes, a VTOC is required to > say where on the volume a dataset is and the basic attributes of PS and PDS > datasets. > > Once you get to several always mounted DASSD volumes, it becomes a pain to > need to remember and specify VOLSER in the JCL. > > CVOLs where an early attempt to solve this problem. Then came VSAM > (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. > Followed by SMS and VVDS for non-VSAM datasets > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Mike Schwab >> Sent: Thursday, May 23, 2024 8:24 PM >> To:IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: VTOCs vs. catalogs >> >> [EXTERNAL EMAIL] >> >> For the most part the catalog lets you locate your dataset no matter >> which volume you put it on. >> For non-vsam, that is about all that is stored, dataset >> characteristics are in the VTOC. >> And with non-SMS volumes you can have uncataloged datasets on DASD or >> tape. >> >> VSAM came from the Future Systems development as a complete >> replacement, Lynn Wheeler has posts about that. >> It was cut back to be an addition to MVS, then combined with CVOL >> catalogs to ICF. >> >> On Thu, May 23, 2024 at 9:32 PM 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? >>> >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email tolists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >> >> >> -- >> Mike A Schwab, Springfield IL USA >> Where do Forest Rangers go to get away from it all? >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email tolists...@listserv.ua.edu with the message: INFO >> IBM-MAIN > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > The information contain
Re: [EXTERNAL] Re: VTOCs vs. catalogs
VVDS came with DFDS. ICF and קריעת תחת came with DF/EF. Things got better with DFP and DFSMS. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 עַם יִשְׂרָאֵל חַי נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר From: IBM Mainframe Discussion List on behalf of Pommier, Rex Sent: Friday, May 24, 2024 10:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [EXTERNAL] Re: VTOCs vs. catalogs Hi David, This is the part I was commenting on. " Then came VSAM (and VVDS?) and VSAM Catalogs,...". I took that comment as being Dave guessing that possibly the VVDS came along with VSAM catalogs which I believe were a stepping stone between CVOLs and ICF catalogs. I never worked with either CVOLs or VSAM catalogs but I was pretty sure the VVDS came along with the ICF. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, May 24, 2024 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: VTOCs vs. catalogs Hi Rex, "...Followed by SMS and VVDS for non-VSAM datasets ..." This was meant (AFAIK) to state that VVDS for Non-VSAMs came into use with SMS-Controlled DASD Volumes. It is also true that VVDSs were introduced with ICF Catalogs (circa 1981, recalled and re-released in 1982). Regards, David On 2024-05-24 09:44, Pommier, Rex wrote: > Didn't the VVDS come along with the ICF catalog structure? > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Thursday, May 23, 2024 10:32 PM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: VTOCs vs. catalogs > > All speculation on my part. One system with no DASD, you need neither. > On a system with only one, of just a few DASD volumes, a VTOC is required to > say where on the volume a dataset is and the basic attributes of PS and PDS > datasets. > > Once you get to several always mounted DASSD volumes, it becomes a pain to > need to remember and specify VOLSER in the JCL. > > CVOLs where an early attempt to solve this problem. Then came VSAM > (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. > Followed by SMS and VVDS for non-VSAM datasets > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Mike Schwab >> Sent: Thursday, May 23, 2024 8:24 PM >> To:IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: VTOCs vs. catalogs >> >> [EXTERNAL EMAIL] >> >> For the most part the catalog lets you locate your dataset no matter >> which volume you put it on. >> For non-vsam, that is about all that is stored, dataset >> characteristics are in the VTOC. >> And with non-SMS volumes you can have uncataloged datasets on DASD or >> tape. >> >> VSAM came from the Future Systems development as a complete >> replacement, Lynn Wheeler has posts about that. >> It was cut back to be an addition to MVS, then combined with CVOL >> catalogs to ICF. >> >> On Thu, May 23, 2024 at 9:32 PM 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? >>> >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email tolists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >> >> >> -- >> Mike A Schwab, Springfield IL USA >> Where do Forest Rangers go to get away from it all? >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email tolists...@listserv.ua.edu with the message: INFO >> IBM-MAIN > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it
Re: [EXTERNAL] Re: VTOCs vs. catalogs
Hi Rex, You said: "...I never worked with either CVOLs or VSAM catalogs ..." If I may take the Bible out of context, please see: DE 32:7 זְקֵנֶ֖יךָ וְיֹ֥אמְרוּ לָֽךְ "... Remember the days of old, Consider the years of ages past; Ask your parent, who will inform you, Your elders, who will tell you: ..." Regards,. David On 2024-05-24 10:12, Pommier, Rex wrote: Hi David, This is the part I was commenting on. " Then came VSAM (and VVDS?) and VSAM Catalogs,...". I took that comment as being Dave guessing that possibly the VVDS came along with VSAM catalogs which I believe were a stepping stone between CVOLs and ICF catalogs. I never worked with either CVOLs or VSAM catalogs but I was pretty sure the VVDS came along with the ICF. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, May 24, 2024 8:55 AM To:IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: VTOCs vs. catalogs Hi Rex, "...Followed by SMS and VVDS for non-VSAM datasets ..." This was meant (AFAIK) to state that VVDS for Non-VSAMs came into use with SMS-Controlled DASD Volumes. It is also true that VVDSs were introduced with ICF Catalogs (circa 1981, recalled and re-released in 1982). Regards, David On 2024-05-24 09:44, Pommier, Rex wrote: Didn't the VVDS come along with the ICF catalog structure? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Thursday, May 23, 2024 10:32 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: VTOCs vs. catalogs All speculation on my part. One system with no DASD, you need neither. On a system with only one, of just a few DASD volumes, a VTOC is required to say where on the volume a dataset is and the basic attributes of PS and PDS datasets. Once you get to several always mounted DASSD volumes, it becomes a pain to need to remember and specify VOLSER in the JCL. CVOLs where an early attempt to solve this problem. Then came VSAM (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. Followed by SMS and VVDS for non-VSAM datasets -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Thursday, May 23, 2024 8:24 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs [EXTERNAL EMAIL] For the most part the catalog lets you locate your dataset no matter which volume you put it on. For non-vsam, that is about all that is stored, dataset characteristics are in the VTOC. And with non-SMS volumes you can have uncataloged datasets on DASD or tape. VSAM came from the Future Systems development as a complete replacement, Lynn Wheeler has posts about that. It was cut back to be an addition to MVS, then combined with CVOL catalogs to ICF. On Thu, May 23, 2024 at 9:32 PM 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? -- For IBM-MAIN subscribe / signoff / archive access instructions, send emailtolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? - - For IBM-MAIN subscribe / signoff / archive access instructions, send emailtolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send emailtolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send emailtolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email
Re: VTOCs vs. catalogs
On Fri, 24 May 2024 09:21:30 -0400, billogden wrote: > >Please note that you can have datasets with exactly the same name on >different volumes, but only one can be cataloged. This was (and might still >be) a common practice for sysprogs who try to maintain a system. (I still do >it when it is convenient.) > Isn't it possible to have multiple catalogs in which similarly named data sets can reside? But that "common practice for sysprogs" too often runs afoul of ENQ conflicts. There has never been an adequate resolution for this. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
DOS/VS did indeed have VTOCs on each volume with entries for all datasets allocated on the volume. MVS could see and potentially read compatible DASD datasets created by DOS/VS, but you didn't want to share drives between DOS/VS and MVS because DOS/VS didn't track changes to free space and would corrupt the free space info required by MVS. The DOS/VS DLBL explicit track information in JCL was used to manually allocate or extend space for datasets, because DOS did not have the smarts to track volume free space and do automatic allocation based on space requirements. While the dataset was physically allocated on a volume, it had a VTOC entry. Typically an application area had their own disk volumes or disk packs and were responsible for keeping a manual record of the tracks allocated to each of their datasets, and possibly moving everything around if some dataset in the middle of a volume needed to be bigger. A common practice in environments where disk space was scarce was to have "work" drives associated with a batch job partition, restore application files to the work drive, run a processing cycle, then stage the modified application files back to tape, so there might be no permanent datasets on the work drive. There were also some system-level DLBL definitions that were globally defined so important installation datasets could be referenced without the JCL for individual jobs being aware of their physical location. PC file systems are an example of alternatives. Each physical disk or logical disk (partition) contains a File Allocation Table that contains an entry for each allocatable unit of space on the disk -- originally that allocatable unit was 1 sector, but expanded to multiple contiguous sectors (FAT16, FAT32) to keep the FAT size manageable as disk capacity increased. The FAT indicates whether that unit of disk is free space, or for files or directories that require additional space, where the next part is located. There is a fixed first directory block (root), where files or sub directories can be "cataloged". Some descriptive information about each file is saved -- minimal on PCs, which puts the onus of understanding data organization onto the accessing application, not the Operating System, but there's no logical reason why you couldn't design a directory structure that contained the level of detail contained in z/OS Catalogs, VTOC, and VVDS. The high-level qualifier of a multi-level z/OS dataset name could be implemented as a sub-directory name, with the lowest-level qualifier as the file name, and all the intermediate levels of the name giving the directory path to find where the actual file data can be found. So things could have evolved that way, but they didn't; and the z/OS super-power of upward compatibility pretty well says it's not going to change, and there are some good performance and availability arguments for the current z/OS design. There will always be limits on the maximum size of a physical or logical disk, and one of the things PC file system structures can't handle is the creation of files that exceed the size of one disk volume. z/OS catalog structures, VTOC and VVDS support multi-volume datasets in ways that are transparent to applications by allowing the catalog entry to point to an ordered list of volumes. JC Ewing On 5/24/24 05:02, 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 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 hardwa
Re: [EXTERNAL] Re: VTOCs vs. catalogs
Hi David, This is the part I was commenting on. " Then came VSAM (and VVDS?) and VSAM Catalogs,...". I took that comment as being Dave guessing that possibly the VVDS came along with VSAM catalogs which I believe were a stepping stone between CVOLs and ICF catalogs. I never worked with either CVOLs or VSAM catalogs but I was pretty sure the VVDS came along with the ICF. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, May 24, 2024 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: VTOCs vs. catalogs Hi Rex, "...Followed by SMS and VVDS for non-VSAM datasets ..." This was meant (AFAIK) to state that VVDS for Non-VSAMs came into use with SMS-Controlled DASD Volumes. It is also true that VVDSs were introduced with ICF Catalogs (circa 1981, recalled and re-released in 1982). Regards, David On 2024-05-24 09:44, Pommier, Rex wrote: > Didn't the VVDS come along with the ICF catalog structure? > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Thursday, May 23, 2024 10:32 PM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: VTOCs vs. catalogs > > All speculation on my part. One system with no DASD, you need neither. > On a system with only one, of just a few DASD volumes, a VTOC is required to > say where on the volume a dataset is and the basic attributes of PS and PDS > datasets. > > Once you get to several always mounted DASSD volumes, it becomes a pain to > need to remember and specify VOLSER in the JCL. > > CVOLs where an early attempt to solve this problem. Then came VSAM > (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. > Followed by SMS and VVDS for non-VSAM datasets > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Mike Schwab >> Sent: Thursday, May 23, 2024 8:24 PM >> To:IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: VTOCs vs. catalogs >> >> [EXTERNAL EMAIL] >> >> For the most part the catalog lets you locate your dataset no matter >> which volume you put it on. >> For non-vsam, that is about all that is stored, dataset >> characteristics are in the VTOC. >> And with non-SMS volumes you can have uncataloged datasets on DASD or >> tape. >> >> VSAM came from the Future Systems development as a complete >> replacement, Lynn Wheeler has posts about that. >> It was cut back to be an addition to MVS, then combined with CVOL >> catalogs to ICF. >> >> On Thu, May 23, 2024 at 9:32 PM 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? >>> >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email tolists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >> >> >> -- >> Mike A Schwab, Springfield IL USA >> Where do Forest Rangers go to get away from it all? >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email tolists...@listserv.ua.edu with the message: INFO >> IBM-MAIN > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for delivering > this message to the intended recipient, you are hereby notified that any > disclosure, distribution, copying, or any action taken or action omitted in > reliance on it, is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to this message and destroy the material in its entirety, whether in > electronic or hard copy format. Thank you. > > > -- > For IBM-MAIN subscribe / signoff / archive access
Re: VTOCs vs. catalogs
Yes, absolutely. MVS systems were becoming larger and creating backups was becoming an issue. Backing up to physical tape was the only real option then. Not only were there more volumes, but there were more datasets that spanned volumes. Before ICF catalogs, catalog records contained VSAM time stamps. When restoring from a backup, getting the timestamps in the catalog to match up with the dataset on a volume where the catalog did not reside became an issue (unless all other processing was halted while creating the backups) because the tape backups themselves took a considerable amount of time. This problem was compounded when datasets spanned volumes. The solution was to move the volatile fields (e.g. timestamps) from the catalog and place them onto the DASD volume where the data was; then they would be backed up at the same time that the data was backed up. This was the origin of, and reason for, the VVDS. The volatile catalog fields describing the datasets were moved to where the dataset was so they could be backed up with the data. An IBM SSR told me at the time that the VVDS would eventually replace the VTOC, but this, obviously, never came to pass. -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Friday, May 24, 2024 8:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs CAUTION: This email originated from outside of the Texas Comptroller's email system. DO NOT click links or open attachments unless you expect them from the sender and know the content is safe. Hi Rex, "...Followed by SMS and VVDS for non-VSAM datasets ..." This was meant (AFAIK) to state that VVDS for Non-VSAMs came into use with SMS-Controlled DASD Volumes. It is also true that VVDSs were introduced with ICF Catalogs (circa 1981, recalled and re-released in 1982). Regards, David On 2024-05-24 09:44, Pommier, Rex wrote: > Didn't the VVDS come along with the ICF catalog structure? > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gibney, Dave > Sent: Thursday, May 23, 2024 10:32 PM > To:IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: VTOCs vs. catalogs > > All speculation on my part. One system with no DASD, you need neither. > On a system with only one, of just a few DASD volumes, a VTOC is required to > say where on the volume a dataset is and the basic attributes of PS and PDS > datasets. > > Once you get to several always mounted DASSD volumes, it becomes a pain to > need to remember and specify VOLSER in the JCL. > > CVOLs where an early attempt to solve this problem. Then came VSAM > (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. > Followed by SMS and VVDS for non-VSAM datasets > >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Mike Schwab >> Sent: Thursday, May 23, 2024 8:24 PM >> To:IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: VTOCs vs. catalogs >> >> [EXTERNAL EMAIL] >> >> For the most part the catalog lets you locate your dataset no matter >> which volume you put it on. >> For non-vsam, that is about all that is stored, dataset >> characteristics are in the VTOC. >> And with non-SMS volumes you can have uncataloged datasets on DASD or >> tape. >> >> VSAM came from the Future Systems development as a complete >> replacement, Lynn Wheeler has posts about that. >> It was cut back to be an addition to MVS, then combined with CVOL >> catalogs to ICF. >> >> On Thu, May 23, 2024 at 9:32 PM 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? >>> >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email tolists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >> >> >> -- >> Mike A Schwab, Springfield IL USA >> Where do Forest Rangers go to get away from it all? >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email tolists...@listserv.ua.edu with the message: INFO >> IBM-MAIN > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email
Re: VTOCs vs. catalogs
Hi Rex, "...Followed by SMS and VVDS for non-VSAM datasets ..." This was meant (AFAIK) to state that VVDS for Non-VSAMs came into use with SMS-Controlled DASD Volumes. It is also true that VVDSs were introduced with ICF Catalogs (circa 1981, recalled and re-released in 1982). Regards, David On 2024-05-24 09:44, Pommier, Rex wrote: Didn't the VVDS come along with the ICF catalog structure? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Thursday, May 23, 2024 10:32 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: VTOCs vs. catalogs All speculation on my part. One system with no DASD, you need neither. On a system with only one, of just a few DASD volumes, a VTOC is required to say where on the volume a dataset is and the basic attributes of PS and PDS datasets. Once you get to several always mounted DASSD volumes, it becomes a pain to need to remember and specify VOLSER in the JCL. CVOLs where an early attempt to solve this problem. Then came VSAM (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. Followed by SMS and VVDS for non-VSAM datasets -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Thursday, May 23, 2024 8:24 PM To:IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VTOCs vs. catalogs [EXTERNAL EMAIL] For the most part the catalog lets you locate your dataset no matter which volume you put it on. For non-vsam, that is about all that is stored, dataset characteristics are in the VTOC. And with non-SMS volumes you can have uncataloged datasets on DASD or tape. VSAM came from the Future Systems development as a complete replacement, Lynn Wheeler has posts about that. It was cut back to be an addition to MVS, then combined with CVOL catalogs to ICF. On Thu, May 23, 2024 at 9:32 PM 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? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email tolists...@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
Re: VTOCs vs. catalogs
Didn't the VVDS come along with the ICF catalog structure? -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gibney, Dave Sent: Thursday, May 23, 2024 10:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: VTOCs vs. catalogs All speculation on my part. One system with no DASD, you need neither. On a system with only one, of just a few DASD volumes, a VTOC is required to say where on the volume a dataset is and the basic attributes of PS and PDS datasets. Once you get to several always mounted DASSD volumes, it becomes a pain to need to remember and specify VOLSER in the JCL. CVOLs where an early attempt to solve this problem. Then came VSAM (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. Followed by SMS and VVDS for non-VSAM datasets > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Mike Schwab > Sent: Thursday, May 23, 2024 8:24 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: VTOCs vs. catalogs > > [EXTERNAL EMAIL] > > For the most part the catalog lets you locate your dataset no matter > which volume you put it on. > For non-vsam, that is about all that is stored, dataset > characteristics are in the VTOC. > And with non-SMS volumes you can have uncataloged datasets on DASD or > tape. > > VSAM came from the Future Systems development as a complete > replacement, Lynn Wheeler has posts about that. > It was cut back to be an addition to MVS, then combined with CVOL > catalogs to ICF. > > On Thu, May 23, 2024 at 9:32 PM 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? > > > > > > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO > > IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > 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 -- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
Subject: Re: VTOCs vs. catalogs > I'm curious whether any of you old-timers can explain why we have both VTOCs and catalogs. Please note that you can have datasets with exactly the same name on different volumes, but only one can be cataloged. This was (and might still be) a common practice for sysprogs who try to maintain a system. (I still do it when it is convenient.) Also, it is easy to move a non-VSAM non-SMS volume to a completely different z/OS system and simply recatalog the datasets (or some of them) on that volume. Bill Ogden -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
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 on behalf of Lennie Bradshaw 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 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 ol
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://rsclweb.com -Original Message- From: IBM Mainframe Discussion List 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
Re: VTOCs vs. catalogs
W dniu 24.05.2024 o 04:32, Phil Smith III pisze: 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? Yes, your guess is correct - it is matter of timeline and *compatibility*. However it is not like "catalogs replaced VTOC". IMHO the crucial information kept in VTOC is disk map, physical location of extents. For compatibility reasons the VTOC also keeps parameters of nonVSAM datasets, like RECFM, LRECL, BLKSIZE, etc. However new thing like VSAM had parameters which could not be kept in old existing VTOC fields. Change VTOC could mean incompatibility, so they decided to use another structure called VVDS. Note - VVDS is "per volume", so it is more like VTOC extension. The "catalog" usually understood as BCS is not tied 1:1 to volume, it is kind of database linking dsname withe the volume *and* further information residing in VTOC/VVDS. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
Thanks! You answered my questions. I always figured there was a time before catalogs, when I assume you had to code VOL=SER= on everything, but that was before my time. And I was trying to remember the CVOL method. I started with ICFCAT's but come to think of it, there may have been one or two in the shop when I started in 1983. Or they may have been converting and I was too new to understand what was going on. On 5/23/2024 10:01 PM, Joel C. Ewing wrote: 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? ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOCs vs. catalogs
VSAM catalog was released in 1974 in OS/VS2 R2, prior to that the catalog was CVOL (dsname SYSCTLG with BLKSIZE=256 and KEYLEN=8). The SYSRES volume was the primary SYSCTLG but could be linked to CVOL on other volumes. The "new" VSAM catalog in 1974 was a big improvement. On Fri, May 24, 2024 at 12:32 PM 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? > > > -- > 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
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
Re: VTOCs vs. catalogs
All speculation on my part. One system with no DASD, you need neither. On a system with only one, of just a few DASD volumes, a VTOC is required to say where on the volume a dataset is and the basic attributes of PS and PDS datasets. Once you get to several always mounted DASSD volumes, it becomes a pain to need to remember and specify VOLSER in the JCL. CVOLs where an early attempt to solve this problem. Then came VSAM (and VVDS?) and VSAM Catalogs, and somewhile later ECf/Catalogs. Followed by SMS and VVDS for non-VSAM datasets > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Mike Schwab > Sent: Thursday, May 23, 2024 8:24 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: VTOCs vs. catalogs > > [EXTERNAL EMAIL] > > For the most part the catalog lets you locate your dataset no matter which > volume you put it on. > For non-vsam, that is about all that is stored, dataset characteristics are > in the > VTOC. > And with non-SMS volumes you can have uncataloged datasets on DASD or > tape. > > VSAM came from the Future Systems development as a complete > replacement, Lynn Wheeler has posts about that. > It was cut back to be an addition to MVS, then combined with CVOL catalogs > to ICF. > > On Thu, May 23, 2024 at 9:32 PM 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? > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > 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
Re: VTOCs vs. catalogs
For the most part the catalog lets you locate your dataset no matter which volume you put it on. For non-vsam, that is about all that is stored, dataset characteristics are in the VTOC. And with non-SMS volumes you can have uncataloged datasets on DASD or tape. VSAM came from the Future Systems development as a complete replacement, Lynn Wheeler has posts about that. It was cut back to be an addition to MVS, then combined with CVOL catalogs to ICF. On Thu, May 23, 2024 at 9:32 PM 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? > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VTOCs vs. catalogs
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? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
