Re: VTOCs vs. catalogs

[Farley, Peter]

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>
 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

[Tony Harminc]

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

[Mike Schwab]

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

[rpinion865]

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

[Joel C. Ewing]

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: Syntax error using Unix cp command with "-W" parameters

[Paul Gilmartin]

On Fri, 24 May 2024 22:09:45 +, Farley, Peter wrote:

>Thanks Sri, that was the trick (as Dana also replied).
>
>From: IB Sri Hari Kolusu
>Sent: Friday, May 24, 2024 4:45 PM
>
>
>Try with single quotes before SPACE parm
>
>cp -W "seqparms='SPACE=(CYL,(5,5)),RECFM=VB,LRECL=259,BLKSIZE=0'"  
>$HOME/testfile.txt "//'TSOUSER.NEWFILE'"
>
>
It's careless documentation to introduce syntax rules only on examples.  I've
submitted a feedback to:


A sole example shows required apostrophes around seqparms:
 cp -W "seqparms='...'"

The apostrophes should also appear in the two instances
of "seqparms" in the Format a]section and the one in
the Description section.

-- 
Thanks,
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Syntax error using Unix cp command with "-W" parameters

[Farley, Peter]

Thanks Sri, that was the trick (as Dana also replied).

From: IBM Mainframe Discussion List  On Behalf Of Sri 
Hari Kolusu
Sent: Friday, May 24, 2024 4:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Syntax error using Unix cp command with "-W" parameters


Peter,



Try with single quotes before SPACE parm



cp -W "seqparms='SPACE=(CYL,(5,5)),RECFM=VB,LRECL=259,BLKSIZE=0'"  
$HOME/testfile.txt "//'TSOUSER.NEWFILE'"



Thanks,

--



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: Syntax error using Unix cp command with "-W" parameters

[Farley, Peter]

Thank you, that was the trick I needed.

From: IBM Mainframe Discussion List  On Behalf Of 
Dana Mitchell
Sent: Friday, May 24, 2024 4:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Syntax error using Unix cp command with "-W" parameters


at the example in the man pages, do you need another set of quotes?:



cp -W "seqparms='RECFM=U,space=(500,100)'" file "//'turbo.gammalib'"





On Fri, 24 May 2024 20:01:02 +, Farley, Peter  
wrote:



>What is wrong with this syntax for a cp command to copy a Unix file system 
>file to an MVS file:

>

>$ cp -W seqparms="SPACE=(CYL,(5,5)),RECFM=VB,LRECL=259,BLKSIZE=0"  
>$HOME/testfile.txt "//'TSOUSER.NEWFILE'"

>cp: FSUMF365 Syntax error on -W argument : Unknown keyword (5.

>

>I have read and re-read the Unix commands reference manual pages on the cp 
>command and the "-W seqparms=" parameter and I don't see what I am doing wrong 
>here.

>

>The "_UNIX03" environment variable in not set in this shell session.

>

>Peter

--



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: Syntax error using Unix cp command with "-W" parameters

[Sri Hari Kolusu]

Peter,

Try with single quotes before SPACE parm

cp -W "seqparms='SPACE=(CYL,(5,5)),RECFM=VB,LRECL=259,BLKSIZE=0'"  
$HOME/testfile.txt "//'TSOUSER.NEWFILE'"

Thanks,


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Syntax error using Unix cp command with "-W" parameters

[Dana Mitchell]

Looking at the example in the man pages, do you need another set of quotes?:

cp -W "seqparms='RECFM=U,space=(500,100)'" file "//'turbo.gammalib'"  


On Fri, 24 May 2024 20:01:02 +, Farley, Peter  
wrote:

>What is wrong with this syntax for a cp command to copy a Unix file system 
>file to an MVS file:
>
>$ cp -W seqparms="SPACE=(CYL,(5,5)),RECFM=VB,LRECL=259,BLKSIZE=0"  
>$HOME/testfile.txt "//'TSOUSER.NEWFILE'"
>cp: FSUMF365 Syntax error on -W argument : Unknown keyword (5.
>
>I have read and re-read the Unix commands reference manual pages on the cp 
>command and the "-W seqparms=" parameter and I don't see what I am doing wrong 
>here.
>
>The "_UNIX03" environment variable in not set in this shell session.
>
>Peter

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Syntax error using Unix cp command with "-W" parameters

[Farley, Peter]

What is wrong with this syntax for a cp command to copy a Unix file system file 
to an MVS file:

$ cp -W seqparms="SPACE=(CYL,(5,5)),RECFM=VB,LRECL=259,BLKSIZE=0"  
$HOME/testfile.txt "//'TSOUSER.NEWFILE'"
cp: FSUMF365 Syntax error on -W argument : Unknown keyword (5.

I have read and re-read the Unix commands reference manual pages on the cp 
command and the "-W seqparms=" parameter and I don't see what I am doing wrong 
here.

The "_UNIX03" environment variable in not set in this shell session.

Peter

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

[Farley, Peter]

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

[Seymour J Metz]

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. 
>
>
>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: IDz and RDz?

[Seymour J Metz]

In fact, it's now transcendental. As Aristophenes wrote in Cambridge, e**x dy 
dx, e**x dx.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Steve Horein <05b0b4f1358b-dmarc-requ...@listserv.ua.edu>
Sent: Friday, May 24, 2024 2:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IDz and RDz?

Is it now Irrational?


On Fri, May 24, 2024 at 7:08 AM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> RDz is the old name for IDz when it was still Rational.Current version
> of iDZ is 16.04.If all the hosts you connect to are current with
> regards to RSED task, then you should be able to ditch RDZ
>
> Dave Jousma
> Vice President | Director, Technology Engineering
>
>
>
>
>
> From: IBM Mainframe Discussion List  on behalf
> of Seymour J Metz 
> Date: Friday, May 24, 2024 at 8:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: IDz and RDz?
> I currently have both IDz and RDz installed. Do I lose any functionality
> if I uninstall RDz? -- Shmuel (Seymour J. ) Metz https: //urldefense.
> com/v3/__http: //mason. gmu.
> edu/*smetz3__;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$
>
>
> I currently have both IDz and RDz installed. Do I lose any functionality
> if I uninstall RDz?
>
>
>
> --
>
> Shmuel (Seymour J.) Metz
>
>
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$
> <
> https://urldefense.com/v3/__http:/mason.gmu.edu/*smetz3__;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$
> >
>
> עַם יִשְׂרָאֵל חַי
>
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> 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

Re: IDz and RDz?

[rpinion865]

LOL!




Sent with Proton Mail secure email.

On Friday, May 24th, 2024 at 2:33 PM, Steve Horein 
<05b0b4f1358b-dmarc-requ...@listserv.ua.edu> wrote:

> Is it now Irrational?
> 
> 
> On Fri, May 24, 2024 at 7:08 AM Jousma, David <
> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> > RDz is the old name for IDz when it was still Rational. Current version
> > of iDZ is 16.04. If all the hosts you connect to are current with
> > regards to RSED task, then you should be able to ditch RDZ
> > 
> > Dave Jousma
> > Vice President | Director, Technology Engineering
> > 
> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU on behalf
> > of Seymour J Metz sme...@gmu.edu
> > Date: Friday, May 24, 2024 at 8:03 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU IBM-MAIN@LISTSERV.UA.EDU
> > Subject: IDz and RDz?
> > I currently have both IDz and RDz installed. Do I lose any functionality
> > if I uninstall RDz? -- Shmuel (Seymour J. ) Metz https: //urldefense.
> > com/v3/http: //mason. gmu.
> > edu/*smetz3;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$
> > 
> > I currently have both IDz and RDz installed. Do I lose any functionality
> > if I uninstall RDz?
> > 
> > --
> > 
> > Shmuel (Seymour J.) Metz
> > 
> > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$
> > <
> > https://urldefense.com/v3/__http:/mason.gmu.edu/*smetz3__;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$
> > 
> > עַם יִשְׂרָאֵל חַי
> > 
> > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
> > 
> > --
> > 
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > 
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > 
> > This e-mail transmission contains information that is confidential and may
> > be privileged. It is intended only for the addressee(s) named above. If
> > you receive this e-mail in error, please do not read, copy or disseminate
> > it in any manner. If you are not the intended recipient, any disclosure,
> > copying, distribution or use of the contents of this information is
> > prohibited. Please reply to the message immediately by informing the sender
> > that the message was misdirected. After replying, please erase it from your
> > computer system. Your assistance in correcting this error is appreciated.
> > 
> > --
> > 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

Re: [EXTERNAL] Re: VTOCs vs. catalogs

[David Spiegel]

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: IDz and RDz?

[Steve Horein]

Is it now Irrational?


On Fri, May 24, 2024 at 7:08 AM Jousma, David <
01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:

> RDz is the old name for IDz when it was still Rational.Current version
> of iDZ is 16.04.If all the hosts you connect to are current with
> regards to RSED task, then you should be able to ditch RDZ
>
> Dave Jousma
> Vice President | Director, Technology Engineering
>
>
>
>
>
> From: IBM Mainframe Discussion List  on behalf
> of Seymour J Metz 
> Date: Friday, May 24, 2024 at 8:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU 
> Subject: IDz and RDz?
> I currently have both IDz and RDz installed. Do I lose any functionality
> if I uninstall RDz? -- Shmuel (Seymour J. ) Metz https: //urldefense.
> com/v3/__http: //mason. gmu.
> edu/*smetz3__;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$
>
>
> I currently have both IDz and RDz installed. Do I lose any functionality
> if I uninstall RDz?
>
>
>
> --
>
> Shmuel (Seymour J.) Metz
>
>
> https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$
> <
> https://urldefense.com/v3/__http:/mason.gmu.edu/*smetz3__;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$
> >
>
> עַם יִשְׂרָאֵל חַי
>
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> 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

[Tony Harminc]

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

[Tom Marchant]

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. 
>
>
>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

[Tom Marchant]

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

[Seymour J Metz]

Nope. 


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 


"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 D

Re: IBM LDAP 4.4 Weak Key Exchange Vulnerability Issue

[James McGinley]

Thanks David. The did the trick. Have a good weekend

--
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

[Lennie Bradshaw]

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
>> 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

Re: VTOCs vs. catalogs

[Lennie Bradshaw]

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 


"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

Re: VTOCs vs. catalogs

[Mike Schwab]

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: hints and tips and help for Git and GitHub for mainframers

[Mike Schwab]

DogeCICS is a live git project you can use.
(Linux on iOS or Android, Mocha 3270 lite),
Hercules, TK 4- or 5, KicksForTSO, 3270 emulator.

On Fri, May 24, 2024 at 8:05 AM Rick Troth
<058ff5c2d0a7-dmarc-requ...@listserv.ua.edu> wrote:
>
> howdy folks ...
>
> I was asked this week for help with Git. The target audience is
> mainframe people. (But I don't expect to be presenting.)
>
> I had previously helped this particular group get on-board using Git and
> GitHub, but that was several months ago. They're again looking at it, so
> their leader asked me for whatever material I might have.
> But I got nuthin. I don't see a PowerPoint deck in any of my stuff.
>
> Therefore, does anyone here have a PPT deck or a SHARE PDF for a
> Git/GitHub how-to for mainframers?
>
>
> thanks
>
>
> -- R; <><
>
> --
> 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

[David Spiegel]

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

-
- The information contained in this message is confident

Re: VTOCs vs. catalogs

[Steve Thompson]

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

--
For IBM-MAIN subscribe / signoff / archive 

Re: VTOCs vs. catalogs

[Seymour J Metz]

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 


--
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

[Pommier, Rex]

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
>>
>> -
>> - The information contained in this message is confidential, 
>> protected from disclosure 

Re: VTOCs vs. catalogs

[Paul Gilmartin]

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

[Seymour J Metz]

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 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 

Re: [EXTERNAL] Re: VTOCs vs. catalogs

[Seymour J Metz]

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, 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...@lists

Re: [EXTERNAL] Re: VTOCs vs. catalogs

[David Spiegel]

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 
tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN

Re: VTOCs vs. catalogs

[Paul Gilmartin]

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

[Joel C. Ewing]

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 hardware 
failures that might affect data availability tends to affects specif

Re: [EXTERNAL] Re: VTOCs vs. catalogs

[Pommier, Rex]

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 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

--
The information contained in this message is confidential, protected from 
disclosur

Re: VTOCs vs. catalogs

[Michael Watkins]

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 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 int

Re: VTOCs vs. catalogs

[David Spiegel]

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

[Pommier, Rex]

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

[billogden]

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: hints and tips and help for Git and GitHub for mainframers

[Lionel B. Dyck]

I might be able to help you with some that focus on using Git using ZIGI.

DM me on discord or direct email.


Lionel B. Dyck <>< 
Github: https://github.com/lbdyck
System Z Enthusiasts Discord: https://discord.gg/sze

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rick Troth
Sent: Friday, May 24, 2024 8:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: hints and tips and help for Git and GitHub for mainframers

howdy folks ...

I was asked this week for help with Git. The target audience is mainframe 
people. (But I don't expect to be presenting.)

I had previously helped this particular group get on-board using Git and 
GitHub, but that was several months ago. They're again looking at it, so their 
leader asked me for whatever material I might have.
But I got nuthin. I don't see a PowerPoint deck in any of my stuff.

Therefore, does anyone here have a PPT deck or a SHARE PDF for a Git/GitHub 
how-to for mainframers?


thanks


-- R; <><

--
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

hints and tips and help for Git and GitHub for mainframers

[Rick Troth]

howdy folks ...

I was asked this week for help with Git. The target audience is 
mainframe people. (But I don't expect to be presenting.)


I had previously helped this particular group get on-board using Git and 
GitHub, but that was several months ago. They're again looking at it, so 
their leader asked me for whatever material I might have.

But I got nuthin. I don't see a PowerPoint deck in any of my stuff.

Therefore, does anyone here have a PPT deck or a SHARE PDF for a 
Git/GitHub how-to for mainframers?



thanks


-- R; <><

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IDz and RDz?

[Jousma, David]

RDz is the old name for IDz when it was still Rational.Current version of 
iDZ is 16.04.If all the hosts you connect to are current with regards to 
RSED task, then you should be able to ditch RDZ

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Date: Friday, May 24, 2024 at 8:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: IDz and RDz?
I currently have both IDz and RDz installed. Do I lose any functionality if I 
uninstall RDz? -- Shmuel (Seymour J. ) Metz https: //urldefense. com/v3/__http: 
//mason. gmu. 
edu/*smetz3__;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$


I currently have both IDz and RDz installed. Do I lose any functionality if I 
uninstall RDz?



--

Shmuel (Seymour J.) Metz

https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!MwwqYLOC6b6whF7V!jujF6499mtUqS9VG2db9pmAWzXGy1n37HUvv-HgnEKimpCnxnG4O8RbMtx2nXE9aRKmQ-dyoCNqYyFVw$

עַם יִשְׂרָאֵל חַי

נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

IDz and RDz?

[Seymour J Metz]

I currently have both IDz and RDz installed. Do I lose any functionality if I 
uninstall RDz?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM LDAP 4.4 Weak Key Exchange Vulnerability Issue

[Jousma, David]

Yes.  In ds.conf set the FIPS state.  LDAP automagically sets the key sizes 
higher.


# sslFipsState 
#
# Default Value: Off
#
# Description:
#   The sslFipsState option specifies the FIPS state for the LDAP server.
#   When FIPS mode turned on, it is more restrictive with respect to
#   cryptographic algorithms, protocols and key sizes that can be supported.
#
# Examples:
#   sslFipsState Off
#   sslFipsState Level1
#   sslFipsState Level2
#   sslFipsState Level3
#
#--
sslFipsState Level3

Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List  on behalf of 
James McGinley 
Date: Friday, May 24, 2024 at 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: IBM LDAP 4.4 Weak Key Exchange Vulnerability Issue
GM, Has anyone had issues remediating IBM LDAP 4. 4 "Weak Key Exchange" 
vulnerability on their secure port? Attempting to provide Cipher combos in 
slapd. env with no success. sslCipherSpecs 
GSK_V3_CIPHER_SPECS_EXPANDED=00380039 or sslCipherSpecs


GM,

   Has anyone had issues remediating IBM LDAP 4.4 "Weak Key Exchange" 
vulnerability on their secure port?



Attempting to provide Cipher combos in slapd.env with no success.



sslCipherSpecs GSK_V3_CIPHER_SPECS_EXPANDED=00380039



or



sslCipherSpecs GSK_V3_CIPHER_SPECS_EXPANDED=C027C028



In CA LDAP by setting TLS key size to 2K the vulnerability is remediated. There 
are no such TLS statements in IBM LDAP:



TLSDhMinKeySize 2048

TLSDsaMinKeySize 2048

TLSEccMinKeySize 194

TLSRsaMinKeySize 2048



Regards,



Jamie McGinley - BNY Mainframe Support



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

IBM LDAP 4.4 Weak Key Exchange Vulnerability Issue

[James McGinley]

GM,
   Has anyone had issues remediating IBM LDAP 4.4 "Weak Key Exchange" 
vulnerability on their secure port?

Attempting to provide Cipher combos in slapd.env with no success.

sslCipherSpecs GSK_V3_CIPHER_SPECS_EXPANDED=00380039 

or

sslCipherSpecs GSK_V3_CIPHER_SPECS_EXPANDED=C027C028 

In CA LDAP by setting TLS key size to 2K the vulnerability is remediated. There 
are no such TLS statements in IBM LDAP:

TLSDhMinKeySize 2048
TLSDsaMinKeySize 2048
TLSEccMinKeySize 194
TLSRsaMinKeySize 2048

Regards,

Jamie McGinley - BNY Mainframe Support

--
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

[Seymour J Metz]

They say that the memory is the scond thing to go; I can't remember the first.

From DOS/VS Data Management Guide 


"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 old-timers can explain why we have both
> VTOCs and cata

Re: VTOCs vs. catalogs

[Lennie Bradshaw]

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

[Radoslaw Skorupka]

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