Re: VTOCs vs. catalogs

[Tony Harminc]

On Mon, 27 May 2024 at 19:50, Paul Gilmartin <
042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 27 May 2024 23:21:43 +, Seymour J Metz wrote:
>
> >Restore?
> >
> >My recollection is that DIRF came before TSO.  Besides, SVC 99 *IS*
> Allocation.
> >
> I k ow SVC 99 *IS* Allocation.  That's why I thought of it.
> TSO?
>

Dynamic allocation arrived with TSO, and on MVT was supported in TSO only,
iirc. I'm pretty sure there was no batch TSO in MVT, but not sure if that
came with SVS or (more likely) with MVS.

I am also reasonably sure that SVC 99 was not a supported interface on MVT.
Rather, the Dynamic Allocation Interface Routine (IKJDAIR) was the
documented interface, and under the covers it used a quite different
version of SVC 99 to do most of the work.

But I digress...

Tony H.

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

Re: VTOCs vs. catalogs

[Paul Gilmartin]

On Mon, 27 May 2024 23:21:43 +, Seymour J Metz wrote:

>Restore?
>
>My recollection is that DIRF came before TSO.  Besides, SVC 99 *IS* Allocation.
>
I k ow SVC 99 *IS* Allocation.  That's why I thought of it.
TSO?

>IAC, all it took wasalllocating a new dataset to get the cleanup:
>
>//IEFREER   DD  UNIT=SYSDA,SPACE=(TRK,1)
>
>in a simple proc woul  let the operator select a volume for cleanup select a 
>volume for cleanup on a START command.
>
Couldn't that have been done via MGCR by Restore? Obviating the
need in Tom's "I needed".


>
>From: IBM Paul Gilmartin
>Sent: Monday, May 27, 2024 6:46 PM
>
>On Mon, 27 May 2024 21:34:31 +, Syymour J Metz wrote:
>
>>Yes, Allocation did the cleanup for the DIRF bit.
>>
>Why didn't Restore just SVC 99 to automate the process?
>
>_
>>From:  Tom Brennan
>>Sent: Monday, May 27, 2024 4:48 PM
>>
>>I think I remember the DIRF bit.  That happened when I would, for
>>example, run a DFDSS full volume backup of a mod-3 and restore to a
>>mod-9, and there was a warning message indicating I needed to allocate a
>>dataset in order to force the processing that would determine the new
>>free space on the mod-9.

-- gil

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

Re: VTOCs vs. catalogs

[Seymour J Metz]

Restore?

My recollection is that DIRF came before TSO.  Besides, SVC 99 *IS* Allocation.

IAC, all it took was allocating a new dataset to get the cleanup:

//IEFRDER   DD  UNIT=SYSDA,SPACE=(TRK,1)

in a simple proc would let the operator select a volume for cleanup select a 
volume for cleanup on a START command.

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


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Monday, May 27, 2024 6:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs

On Mon, 27 May 2024 21:34:31 +, Seymour J Metz wrote:

>Yes, Allocation did the cleanup for the DIRF bit.
>
Why didn't Restore just SVC 99 to automate the process?

_
>From:  Tom Brennan
>Sent: Monday, May 27, 2024 4:48 PM
>
>I think I remember the DIRF bit.  That happened when I would, for
>example, run a DFDSS full volume backup of a mod-3 and restore to a
>mod-9, and there was a warning message indicating I needed to allocate a
>dataset in order to force the processing that would determine the new
>free space on the mod-9.
>
>Does that sound anything like reality?  It's been a while.

-- gil

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


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

Re: VTOCs vs. catalogs

[Paul Gilmartin]

On Mon, 27 May 2024 21:34:31 +, Seymour J Metz wrote:

>Yes, Allocation did the cleanup for the DIRF bit.
> 
Why didn't Restore just SVC 99 to automate the process?

_
>From:  Tom Brennan 
>Sent: Monday, May 27, 2024 4:48 PM
>
>I think I remember the DIRF bit.  That happened when I would, for
>example, run a DFDSS full volume backup of a mod-3 and restore to a
>mod-9, and there was a warning message indicating I needed to allocate a
>dataset in order to force the processing that would determine the new
>free space on the mod-9.
>
>Does that sound anything like reality?  It's been a while.

-- gil

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

Re: VTOCs vs. catalogs

[Seymour J Metz]

Yes, Allocation did the cleanup for the DIRF bit.

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


From: IBM Mainframe Discussion List  on behalf of Tom 
Brennan 
Sent: Monday, May 27, 2024 4:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs

I think I remember the DIRF bit.  That happened when I would, for
example, run a DFDSS full volume backup of a mod-3 and restore to a
mod-9, and there was a warning message indicating I needed to allocate a
dataset in order to force the processing that would determine the new
free space on the mod-9.

Does that sound anything like reality?  It's been a while.

On 5/27/2024 12:37 PM, Seymour J Metz wrote:
> Also, was the name "DOS contaminated" for the DIRF bit ever official? And 
> when did IBM finally give an equate for X'80' in DS4VTOCI?
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> עַם יִשְׂרָאֵל חַי
> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
> 
> From: IBM Mainframe Discussion List  on behalf of 
> Charles Mills 
> Sent: Monday, May 27, 2024 1:26 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VTOCs vs. catalogs
>
> I started my first professional programming job in January of 1969, working 
> with DOS/360. DLBL, EXTENT and TLBL cards existed but they were new -- the 
> "old timers" still used DLAB, XTENT and TLAB. So that gives you an 
> approximate timeframe.
>
> As @Shmeel has said, DOS definitely supported VTOCs. VTOCs were in fact 
> partially portable between DOS and OS/360. What DOS lacked was OS-controlled 
> free space management and support for the free space records of a VTOC. Free 
> space management on volumes was controlled by a chart on the sysprog's wall 
> and data set expiration dates.
>
> Charles
>
>
> On Mon, 27 May 2024 12:32:16 +, Seymour J Metz  wrote:
>
>> DOS had VTOCs for as far back as I can remember, but when was the transition 
>> from DLAB and TLAB to  DLBL and TLBL?
>>
>> When did IBM introduce the DIRF bit in the VTOC? It was definitely in 
>> OS/360, but which release?
>>
>> --
>> Shmeel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>> עַם יִשְׂרָאֵל חַי
>> נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>>
>> 
>> From: IBM Mainframe Discussion List  on behalf of 
>> Steve Thompson 
>> Sent: Friday, May 24, 2024 11:27 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: VTOCs vs. catalogs
>>
>> If I remember correctly (since I started on DOS R26?) on a
>> S/360-30, we also had to use EXTENT cards (to define where a file
>> existed on a volume). So hazy memory recalls we had a Label
>> cylinder and an ALT Label cylinder. But maybe that came with
>> DOS/VS Too long ago now.
>>
>> Then DOS got VTOCs and so if sharing with OS|MVS, the volume got
>> the "dirty" bit turned on if DOS did any work in the VTOC. (MVS
>> then had to RESERVE the volume and fix the VTOC to know where the
>> free extents were since DOS didn't have that feature).
>>
>> The joys of migrating to OS/VS (MVS) and sharing of Volumes
>> between systems in a service Bureau oh, Cloud (sorry I forgot
>> the in-vogue term).
>>
>> Steve Thompson
>>
>>
>> On 5/24/2024 6:02 AM, Lennie Bradshaw wrote:
>>> When  sstarted on IBM System/370 the shop I was at used DOS/VS. DOS/VS at 
>>> that time did not have VTOCs. We used //DLBL statements in JCL which 
>>> specified the exact locations of datasets on disk. This changed with the 
>>> introduction of VSAM on DOS/VS, but only for VSAM datasets.
>>> Fortunately I soon moved to a company using OS/VS2 and got to use VTOCs and 
>>> CVOLs there.
>>>
>>> As regards, why both VTOCs and Calalogs exist, what would be the 
>>> alternative?
>>> The more pertinent question is, I think,
>>> Why do we have both VVDS datasets and VTOCs? Historically I understand, but 
>>> it could improve efficiency to merge these.
>>> It would probably break too many existing interfaces though.
>>>
>>> Lennie Dymoke-Bradshaw
>>> https://secure-web.cisco.com/1odBw3GEOl-eQtgejAefr15bp7Yjgq1VZ1WvUgBCrG9juGErPDn2ToWA1oEov1iWq1nP1bJw6eaKuPky8YmEAI6ROQImouPPYsKMCoGQ4ib8muwTwBtsgmaaEwwZlZiehgecLz8PbPsMQwcG6tJsnJ1A5dooWER-nlc8e4YktroinRIxWFzwwcwSbdSWcHH74KJSQEkXZ7HjEmlD-rondxM3-dfiCUg6WdtAfaSZIdRnWb-s0WXRcSwWWn6opjI-Xq_Mm4rZPflgd3uyNxmzRYFO3upfE079gkz4LE7Pyt_Bs2kE4cKOlzz3x2G9xSmKy9YDk5ssM6f8Ixw7X9JwxwfoEmYhlKrybn9x-ZmPbEvXi4Bs6_XiPY2ZhFGYLeUDT9UAkXR_oj8hxsaGAyq44-tIbzxarxzELtlv1VpBXhbY/https%3A%2F%2Frsclweb.com
>>>
>>>
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On Behalf Of 
>>> Joel C. Ewing
>>> Sent: 24 May 2024 06:02
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: VTOCs vs. catalogs
>>>
>>> VTOCs did come first.   The  original DOS/360 Operating System did not have 
>>> catalogs.   VTOCs contain not only information about physical location and 
>>> organization of datasets on the volume but also (for OS/360 and its MVS

Re: VTOCs vs. catalogs

[Tom Brennan]

I think I remember the DIRF bit.  That happened when I would, for 
example, run a DFDSS full volume backup of a mod-3 and restore to a 
mod-9, and there was a warning message indicating I needed to allocate a 
dataset in order to force the processing that would determine the new 
free space on the mod-9.


Does that sound anything like reality?  It's been a while.

On 5/27/2024 12:37 PM, Seymour J Metz wrote:

Also, was the name "DOS contaminated" for the DIRF bit ever official? And when 
did IBM finally give an equate for X'80' in DS4VTOCI?

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


From: IBM Mainframe Discussion List  on behalf of Charles 
Mills 
Sent: Monday, May 27, 2024 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs

I started my first professional programming job in January of 1969, working with DOS/360. 
DLBL, EXTENT and TLBL cards existed but they were new -- the "old timers" still 
used DLAB, XTENT and TLAB. So that gives you an approximate timeframe.

As @Shmeel has said, DOS definitely supported VTOCs. VTOCs were in fact 
partially portable between DOS and OS/360. What DOS lacked was OS-controlled 
free space management and support for the free space records of a VTOC. Free 
space management on volumes was controlled by a chart on the sysprog's wall and 
data set expiration dates.

Charles


On Mon, 27 May 2024 12:32:16 +, Seymour J Metz  wrote:


DOS had VTOCs for as far back as I can remember, but when was the transition 
from DLAB and TLAB to  DLBL and TLBL?

When did IBM introduce the DIRF bit in the VTOC? It was definitely in OS/360, 
but which release?

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


From: IBM Mainframe Discussion List  on behalf of Steve 
Thompson 
Sent: Friday, May 24, 2024 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs

If I remember correctly (since I started on DOS R26?) on a
S/360-30, we also had to use EXTENT cards (to define where a file
existed on a volume). So hazy memory recalls we had a Label
cylinder and an ALT Label cylinder. But maybe that came with
DOS/VS Too long ago now.

Then DOS got VTOCs and so if sharing with OS|MVS, the volume got
the "dirty" bit turned on if DOS did any work in the VTOC. (MVS
then had to RESERVE the volume and fix the VTOC to know where the
free extents were since DOS didn't have that feature).

The joys of migrating to OS/VS (MVS) and sharing of Volumes
between systems in a service Bureau oh, Cloud (sorry I forgot
the in-vogue term).

Steve Thompson


On 5/24/2024 6:02 AM, Lennie Bradshaw wrote:

When  sstarted on IBM System/370 the shop I was at used DOS/VS. DOS/VS at that 
time did not have VTOCs. We used //DLBL statements in JCL which specified the 
exact locations of datasets on disk. This changed with the introduction of VSAM 
on DOS/VS, but only for VSAM datasets.
Fortunately I soon moved to a company using OS/VS2 and got to use VTOCs and 
CVOLs there.

As regards, why both VTOCs and Calalogs exist, what would be the alternative?
The more pertinent question is, I think,
Why do we have both VVDS datasets and VTOCs? Historically I understand, but it 
could improve efficiency to merge these.
It would probably break too many existing interfaces though.

Lennie Dymoke-Bradshaw
https://secure-web.cisco.com/1odBw3GEOl-eQtgejAefr15bp7Yjgq1VZ1WvUgBCrG9juGErPDn2ToWA1oEov1iWq1nP1bJw6eaKuPky8YmEAI6ROQImouPPYsKMCoGQ4ib8muwTwBtsgmaaEwwZlZiehgecLz8PbPsMQwcG6tJsnJ1A5dooWER-nlc8e4YktroinRIxWFzwwcwSbdSWcHH74KJSQEkXZ7HjEmlD-rondxM3-dfiCUg6WdtAfaSZIdRnWb-s0WXRcSwWWn6opjI-Xq_Mm4rZPflgd3uyNxmzRYFO3upfE079gkz4LE7Pyt_Bs2kE4cKOlzz3x2G9xSmKy9YDk5ssM6f8Ixw7X9JwxwfoEmYhlKrybn9x-ZmPbEvXi4Bs6_XiPY2ZhFGYLeUDT9UAkXR_oj8hxsaGAyq44-tIbzxarxzELtlv1VpBXhbY/https%3A%2F%2Frsclweb.com


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joel C. Ewing
Sent: 24 May 2024 06:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs

VTOCs did come first.   The  original DOS/360 Operating System did not have catalogs.   
VTOCs contain not only information about physical location and organization of datasets 
on the volume but also (for OS/360 and its MVS and z/OS descendants) contains a list of 
all the free extents on the volume to support automated allocation of new extents for 
datasets.   It makes sense to still keep that level of information at the volume level 
and not in some centralized "catalog", because an individual volume can be 
varied online or offline, added to or deleted from the system, and also any hardware 
failures that might affect data availability tends to affects specific  volumes, so it 
simplifies many things to keep volume-level descriptive information on the related volume.

As the total number number of DASD volumes on a system increases, h

Re: VTOCs vs. catalogs

[Seymour J Metz]

Also, was the name "DOS contaminated" for the DIRF bit ever official? And when 
did IBM finally give an equate for X'80' in DS4VTOCI?

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


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Monday, May 27, 2024 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs

I started my first professional programming job in January of 1969, working 
with DOS/360. DLBL, EXTENT and TLBL cards existed but they were new -- the "old 
timers" still used DLAB, XTENT and TLAB. So that gives you an approximate 
timeframe.

As @Shmeel has said, DOS definitely supported VTOCs. VTOCs were in fact 
partially portable between DOS and OS/360. What DOS lacked was OS-controlled 
free space management and support for the free space records of a VTOC. Free 
space management on volumes was controlled by a chart on the sysprog's wall and 
data set expiration dates.

Charles


On Mon, 27 May 2024 12:32:16 +, Seymour J Metz  wrote:

>DOS had VTOCs for as far back as I can remember, but when was the transition 
>from DLAB and TLAB to  DLBL and TLBL?
>
>When did IBM introduce the DIRF bit in the VTOC? It was definitely in OS/360, 
>but which release?
>
>--
>Shmeel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>עַם יִשְׂרָאֵל חַי
>נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Steve Thompson 
>Sent: Friday, May 24, 2024 11:27 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: VTOCs vs. catalogs
>
>If I remember correctly (since I started on DOS R26?) on a
>S/360-30, we also had to use EXTENT cards (to define where a file
>existed on a volume). So hazy memory recalls we had a Label
>cylinder and an ALT Label cylinder. But maybe that came with
>DOS/VS Too long ago now.
>
>Then DOS got VTOCs and so if sharing with OS|MVS, the volume got
>the "dirty" bit turned on if DOS did any work in the VTOC. (MVS
>then had to RESERVE the volume and fix the VTOC to know where the
>free extents were since DOS didn't have that feature).
>
>The joys of migrating to OS/VS (MVS) and sharing of Volumes
>between systems in a service Bureau oh, Cloud (sorry I forgot
>the in-vogue term).
>
>Steve Thompson
>
>
>On 5/24/2024 6:02 AM, Lennie Bradshaw wrote:
>> When  sstarted on IBM System/370 the shop I was at used DOS/VS. DOS/VS at 
>> that time did not have VTOCs. We used //DLBL statements in JCL which 
>> specified the exact locations of datasets on disk. This changed with the 
>> introduction of VSAM on DOS/VS, but only for VSAM datasets.
>> Fortunately I soon moved to a company using OS/VS2 and got to use VTOCs and 
>> CVOLs there.
>>
>> As regards, why both VTOCs and Calalogs exist, what would be the alternative?
>> The more pertinent question is, I think,
>> Why do we have both VVDS datasets and VTOCs? Historically I understand, but 
>> it could improve efficiency to merge these.
>> It would probably break too many existing interfaces though.
>>
>> Lennie Dymoke-Bradshaw
>> https://secure-web.cisco.com/1odBw3GEOl-eQtgejAefr15bp7Yjgq1VZ1WvUgBCrG9juGErPDn2ToWA1oEov1iWq1nP1bJw6eaKuPky8YmEAI6ROQImouPPYsKMCoGQ4ib8muwTwBtsgmaaEwwZlZiehgecLz8PbPsMQwcG6tJsnJ1A5dooWER-nlc8e4YktroinRIxWFzwwcwSbdSWcHH74KJSQEkXZ7HjEmlD-rondxM3-dfiCUg6WdtAfaSZIdRnWb-s0WXRcSwWWn6opjI-Xq_Mm4rZPflgd3uyNxmzRYFO3upfE079gkz4LE7Pyt_Bs2kE4cKOlzz3x2G9xSmKy9YDk5ssM6f8Ixw7X9JwxwfoEmYhlKrybn9x-ZmPbEvXi4Bs6_XiPY2ZhFGYLeUDT9UAkXR_oj8hxsaGAyq44-tIbzxarxzELtlv1VpBXhbY/https%3A%2F%2Frsclweb.com
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Joel C. Ewing
>> Sent: 24 May 2024 06:02
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: VTOCs vs. catalogs
>>
>> VTOCs did come first.   The  original DOS/360 Operating System did not have 
>> catalogs.   VTOCs contain not only information about physical location and 
>> organization of datasets on the volume but also (for OS/360 and its MVS and 
>> z/OS descendants) contains a list of all the free extents on the volume to 
>> support automated allocation of new extents for datasets.   It makes sense 
>> to still keep that level of information at the volume level and not in some 
>> centralized "catalog", because an individual volume can be varied online or 
>> offline, added to or deleted from the system, and also any hardware failures 
>> that might affect data availability tends to affects specific  volumes, so 
>> it simplifies many things to keep volume-level descriptive information on 
>> the related volume.
>>
>> 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 t

Re: VTOCs vs. catalogs

[Charles Mills]

I started my first professional programming job in January of 1969, working 
with DOS/360. DLBL, EXTENT and TLBL cards existed but they were new -- the "old 
timers" still used DLAB, XTENT and TLAB. So that gives you an approximate 
timeframe.

As @Shmeel has said, DOS definitely supported VTOCs. VTOCs were in fact 
partially portable between DOS and OS/360. What DOS lacked was OS-controlled 
free space management and support for the free space records of a VTOC. Free 
space management on volumes was controlled by a chart on the sysprog's wall and 
data set expiration dates.

Charles


On Mon, 27 May 2024 12:32:16 +, Seymour J Metz  wrote:

>DOS had VTOCs for as far back as I can remember, but when was the transition 
>from DLAB and TLAB to  DLBL and TLBL? 
>
>When did IBM introduce the DIRF bit in the VTOC? It was definitely in OS/360, 
>but which release?
>
>--
>Shmeel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>עַם יִשְׂרָאֵל חַי
>נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
>
>
>From: IBM Mainframe Discussion List  on behalf of 
>Steve Thompson 
>Sent: Friday, May 24, 2024 11:27 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: VTOCs vs. catalogs
>
>If I remember correctly (since I started on DOS R26?) on a
>S/360-30, we also had to use EXTENT cards (to define where a file
>existed on a volume). So hazy memory recalls we had a Label
>cylinder and an ALT Label cylinder. But maybe that came with
>DOS/VS Too long ago now.
>
>Then DOS got VTOCs and so if sharing with OS|MVS, the volume got
>the "dirty" bit turned on if DOS did any work in the VTOC. (MVS
>then had to RESERVE the volume and fix the VTOC to know where the
>free extents were since DOS didn't have that feature).
>
>The joys of migrating to OS/VS (MVS) and sharing of Volumes
>between systems in a service Bureau oh, Cloud (sorry I forgot
>the in-vogue term).
>
>Steve Thompson
>
>
>On 5/24/2024 6:02 AM, Lennie Bradshaw wrote:
>> When  sstarted on IBM System/370 the shop I was at used DOS/VS. DOS/VS at 
>> that time did not have VTOCs. We used //DLBL statements in JCL which 
>> specified the exact locations of datasets on disk. This changed with the 
>> introduction of VSAM on DOS/VS, but only for VSAM datasets.
>> Fortunately I soon moved to a company using OS/VS2 and got to use VTOCs and 
>> CVOLs there.
>>
>> As regards, why both VTOCs and Calalogs exist, what would be the alternative?
>> The more pertinent question is, I think,
>> Why do we have both VVDS datasets and VTOCs? Historically I understand, but 
>> it could improve efficiency to merge these.
>> It would probably break too many existing interfaces though.
>>
>> Lennie Dymoke-Bradshaw
>> https://secure-web.cisco.com/1odBw3GEOl-eQtgejAefr15bp7Yjgq1VZ1WvUgBCrG9juGErPDn2ToWA1oEov1iWq1nP1bJw6eaKuPky8YmEAI6ROQImouPPYsKMCoGQ4ib8muwTwBtsgmaaEwwZlZiehgecLz8PbPsMQwcG6tJsnJ1A5dooWER-nlc8e4YktroinRIxWFzwwcwSbdSWcHH74KJSQEkXZ7HjEmlD-rondxM3-dfiCUg6WdtAfaSZIdRnWb-s0WXRcSwWWn6opjI-Xq_Mm4rZPflgd3uyNxmzRYFO3upfE079gkz4LE7Pyt_Bs2kE4cKOlzz3x2G9xSmKy9YDk5ssM6f8Ixw7X9JwxwfoEmYhlKrybn9x-ZmPbEvXi4Bs6_XiPY2ZhFGYLeUDT9UAkXR_oj8hxsaGAyq44-tIbzxarxzELtlv1VpBXhbY/https%3A%2F%2Frsclweb.com
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Joel C. Ewing
>> Sent: 24 May 2024 06:02
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: VTOCs vs. catalogs
>>
>> VTOCs did come first.   The  original DOS/360 Operating System did not have 
>> catalogs.   VTOCs contain not only information about physical location and 
>> organization of datasets on the volume but also (for OS/360 and its MVS and 
>> z/OS descendants) contains a list of all the free extents on the volume to 
>> support automated allocation of new extents for datasets.   It makes sense 
>> to still keep that level of information at the volume level and not in some 
>> centralized "catalog", because an individual volume can be varied online or 
>> offline, added to or deleted from the system, and also any hardware failures 
>> that might affect data availability tends to affects specific  volumes, so 
>> it simplifies many things to keep volume-level descriptive information on 
>> the related volume.
>>
>> As the total number number of DASD volumes on a system increases, having 
>> that VTOC-level information  distributed across all  volumes vs putting all 
>> that info in a centralized location improves  performance by distributing 
>> read/write activity for that data across all the volumes, and prevents a 
>> single point of failure that could cause loss of all datasets.
>>
>> 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 catalo

Re: VTOCs vs. catalogs

[Seymour J Metz]

DOS had VTOCs for as far back as I can remember, but when was the transition 
from DLAB and TLAB to  DLBL and TLBL? 

When did IBM introduce the DIRF bit in the VTOC? It was definitely in OS/360, 
but which release?

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


From: IBM Mainframe Discussion List  on behalf of 
Steve Thompson 
Sent: Friday, May 24, 2024 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs

If I remember correctly (since I started on DOS R26?) on a
S/360-30, we also had to use EXTENT cards (to define where a file
existed on a volume). So hazy memory recalls we had a Label
cylinder and an ALT Label cylinder. But maybe that came with
DOS/VS Too long ago now.

Then DOS got VTOCs and so if sharing with OS|MVS, the volume got
the "dirty" bit turned on if DOS did any work in the VTOC. (MVS
then had to RESERVE the volume and fix the VTOC to know where the
free extents were since DOS didn't have that feature).

The joys of migrating to OS/VS (MVS) and sharing of Volumes
between systems in a service Bureau oh, Cloud (sorry I forgot
the in-vogue term).

Steve Thompson


On 5/24/2024 6:02 AM, Lennie Bradshaw wrote:
> When I started on IBM System/370 the shop I was at used DOS/VS. DOS/VS at 
> that time did not have VTOCs. We used //DLBL statements in JCL which 
> specified the exact locations of datasets on disk. This changed with the 
> introduction of VSAM on DOS/VS, but only for VSAM datasets.
> Fortunately I soon moved to a company using OS/VS2 and got to use VTOCs and 
> CVOLs there.
>
> As regards, why both VTOCs and Catalogs exist, what would be the alternative?
> The more pertinent question is, I think,
> Why do we have both VVDS datasets and VTOCs? Historically I understand, but 
> it could improve efficiency to merge these.
> It would probably break too many existing interfaces though.
>
> Lennie Dymoke-Bradshaw
> https://secure-web.cisco.com/1odBw3GEOl-eQtgejAefr15bp7Yjgq1VZ1WvUgBCrG9juGErPDn2ToWA1oEov1iWq1nP1bJw6eaKuPky8YmEAI6ROQImouPPYsKMCoGQ4ib8muwTwBtsgmaaEwwZlZiehgecLz8PbPsMQwcG6tJsnJ1A5dooWER-nlc8e4YktroinRIxWFzwwcwSbdSWcHH74KJSQEkXZ7HjEmlD-rondxM3-dfiCUg6WdtAfaSZIdRnWb-s0WXRcSwWWn6opjI-Xq_Mm4rZPflgd3uyNxmzRYFO3upfE079gkz4LE7Pyt_Bs2kE4cKOlzz3x2G9xSmKy9YDk5ssM6f8Ixw7X9JwxwfoEmYhlKrybn9x-ZmPbEvXi4Bs6_XiPY2ZhFGYLeUDT9UAkXR_oj8hxsaGAyq44-tIbzxarxzELtlv1VpBXhbY/https%3A%2F%2Frsclweb.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Joel C. Ewing
> Sent: 24 May 2024 06:02
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: VTOCs vs. catalogs
>
> VTOCs did come first.   The  original DOS/360 Operating System did not have 
> catalogs.   VTOCs contain not only information about physical location and 
> organization of datasets on the volume but also (for OS/360 and its MVS and 
> z/OS descendants) contains a list of all the free extents on the volume to 
> support automated allocation of new extents for datasets.   It makes sense to 
> still keep that level of information at the volume level and not in some 
> centralized "catalog", because an individual volume can be varied online or 
> offline, added to or deleted from the system, and also any hardware failures 
> that might affect data availability tends to affects specific  volumes, so it 
> simplifies many things to keep volume-level descriptive information on the 
> related volume.
>
> As the total number number of DASD volumes on a system increases, having that 
> VTOC-level information  distributed across all  volumes vs putting all that 
> info in a centralized location improves  performance by distributing 
> read/write activity for that data across all the volumes, and prevents a 
> single point of failure that could cause loss of all datasets.
>
> Without  a catalog to map data set names to volumes, it was necessary to 
> manually record and maintain a record of what volume(s) contain each dataset. 
>   That was practical for a few volumes and a small number of datasets, but 
> obviously impractical when talking about 100's of volumes and 1000's of 
> datasets. OS/360 was designed to support very large systems;  Hence it 
> included a catalog; but its use was optional for application datasets.   
> These days the recommended practice is that all z/OS application DASD 
> datasets should be under SMS, and SMS datasets must be cataloged.
>
> The original CVOL catalog evolved into multi-level ICF catalogs, and an 
> eventual need to save additional dataset attributes  to support SMS and VSAM 
> datasets resulted in an additional VVDS dataset to store that info on each 
> volume.
>
> As the capacity and maximum number of datasets on a volume increased, a 
> 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 Cata

Re: VTOCs vs. catalogs

[Seymour J Metz]

One of the things that made KSDS viable was the CI, which let existing programs 
continue to run after moving off of ISAM; I considered it to be a blunder that 
MVS failed to do so for ESDS. I was also unhappy that VSAM did not include the 
functionality of VAM in TSS, especially VIPAM.

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


From: IBM Mainframe Discussion List  on behalf of 
Joel C. Ewing 
Sent: Friday, May 24, 2024 8:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs

VSAM KSDS datasets were a clear win as a replacement for Indexed
Sequental (ISAM) datasets when adding large numbers of keyed records.  I
saw cases where a KSDS implementation literally ran two orders of
magnitude faster  than ISAM and also took less DASD space, because ISAM
required  that unblocked overflow records be serially searched when
there was no remaining space in a block to insert a record with a given key.

In theory an ESDS dataset could be used to  replace a sequential dataset
and BSAM/QSAM, but of course the application interfaces were
considerably different, and VSAM constraints on block size meant you
could take substantial hits on track efficiency and performance for
certain logical record sizes.

An RRDS could be used as a functional replacement for direct access
files, but again the restriction on block sizes caused compatibility
issues, and tuning RRDS dataset access to get performance comparable to
a well-tuned BDAM application was difficult to impossible.

You could probably have designed a functional replacement for PDS
datasets with either a KSDS or RRDS organization, or a combination of
KSDS and ESDS, but it wouldn't have been practical.  Many decades later
PDSEs are almost a tranparent replacement for a PDS, but there are still
some things possible with a PDS that are not supported for a PDSE.

If VSAM's goal was to replace all other file organizations, it failed.
The only old dataset organization to be made totally obsolete by VSAM
was ISAM.

 JC Ewing

On 5/24/24 10:02, Paul Gilmartin wrote:
> On Thu, 23 May 2024 22:24:06 -0500, Mike Schwab wrote:
>> VSAM came from the Future Systems development as a complete
>> replacement, Lynn Wheeler has posts about that.
>> It was cut back to be an addition to MVS, then combined with CVOL
>> catalogs to ICF.
>>
> "complete replacement" of what, specifically?  I have heard the
> assertion that VSAM was intended to replace all other access
> methods:  QSAM, BSAM, BPAM, ...
>
> ...

--
Joel C. Ewing

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


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

Re: Nodejs20 error installation

[Jake Anderson]

Hi

This is the step prior to env
I ran ./setup.sh and got this message

So the set up itself has verified the PTF availability

On Mon, May 27, 2024, 2:39 PM Michael Babcock <
05ad4e2d7232-dmarc-requ...@listserv.ua.edu> wrote:

> Make sure these are on:
>
>
>- z/OS 2.4 with all the following PTFs installed:
>   - UI80106 
>   - UI81096 
>   - UI78103 
>   - UI80155 
>   - UI83490
>
>
> Did you run the .env command?   Use
>
> $ . /.env
>
> Issue echo $PATH and ensure nodejs has been added to your path.
>
>
>
> On Mon, May 27, 2024 at 1:39 AM Jake Anderson <
> 0655e880aa7d-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Hello
> >
> > I am trying to install nodejs 20 on z/OS 2.4 but I end up with below
> error.
> > All the prerequisites PTF are available but not sure why the nodule is
> not
> > found
> >
> >
> >
> > Setting up IBM Open Enterprise SDK for Node.js
> > 20.0
> >
> > Checking for supported platform...SUCCESS
> >
> >
> > Checking for supported
> > hardware...SUCCESS
> >
> > Checking for supported OS
> > version...SUCCESS
> >
> > Checking that /usr/bin/env
> > exists...SUCCESS
> >
> > Checking that system prerequisite PTFs are installed (CHECK
> > 1)...SUCCESS
> >
> > Checking that system prerequisite PTFs are installed (CHECK
> > 2)...SUCCESS
> >
> > Checking that system prerequisite PTFs are installed (CHECK
> > 3)...SUCCESS
> >
> > Checking that Integrated Cryptographic Service Facility is
> > active...SUCCESS
> >
> > Checking for sufficient above the bar
> > memory...SUCCESS
> >
> > Checking for sufficient address
> > space...SUCCESS
> >
> > Checking that Python 3.9.14+
> > exists...SUCCESS
> >
> > Checking that Make 4.1+
> > exists...SUCCESS
> >
> > Checking that IBM C/C++ for Open Enterprise Languages on z/OS
> > exists...SUCCESS
> >
> > Checking that Node.js is
> > installed...FAILED
> >
> > ***ERROR: CEE3501S The module CRTEQCXS was not
> > found.
> >
> >  The traceback information could not be
> > determined.
> >
> > ***ERROR: Node.js ("node --version") failed to run. Refer to the
> > instructions in
> >
> > Checking that npm is installed...FAILED
> >
> >
> > ***ERROR: CEE3501S The module CRTEQCXS was not
> > found.
> >
> >  The traceback information could not be
> > determined.
> >
> > ***ERROR: npm ("npm --version") failed to run. Refer to the instructions
> in
> > READ
> >
> > --
> > 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: Nodejs20 error installation

[Michael Babcock]

Make sure these are on:


   - z/OS 2.4 with all the following PTFs installed:
  - UI80106 
  - UI81096 
  - UI78103 
  - UI80155 
  - UI83490


Did you run the .env command?   Use

$ . /.env

Issue echo $PATH and ensure nodejs has been added to your path.



On Mon, May 27, 2024 at 1:39 AM Jake Anderson <
0655e880aa7d-dmarc-requ...@listserv.ua.edu> wrote:

> Hello
>
> I am trying to install nodejs 20 on z/OS 2.4 but I end up with below error.
> All the prerequisites PTF are available but not sure why the nodule is not
> found
>
>
>
> Setting up IBM Open Enterprise SDK for Node.js
> 20.0
>
> Checking for supported platform...SUCCESS
>
>
> Checking for supported
> hardware...SUCCESS
>
> Checking for supported OS
> version...SUCCESS
>
> Checking that /usr/bin/env
> exists...SUCCESS
>
> Checking that system prerequisite PTFs are installed (CHECK
> 1)...SUCCESS
>
> Checking that system prerequisite PTFs are installed (CHECK
> 2)...SUCCESS
>
> Checking that system prerequisite PTFs are installed (CHECK
> 3)...SUCCESS
>
> Checking that Integrated Cryptographic Service Facility is
> active...SUCCESS
>
> Checking for sufficient above the bar
> memory...SUCCESS
>
> Checking for sufficient address
> space...SUCCESS
>
> Checking that Python 3.9.14+
> exists...SUCCESS
>
> Checking that Make 4.1+
> exists...SUCCESS
>
> Checking that IBM C/C++ for Open Enterprise Languages on z/OS
> exists...SUCCESS
>
> Checking that Node.js is
> installed...FAILED
>
> ***ERROR: CEE3501S The module CRTEQCXS was not
> found.
>
>  The traceback information could not be
> determined.
>
> ***ERROR: Node.js ("node --version") failed to run. Refer to the
> instructions in
>
> Checking that npm is installed...FAILED
>
>
> ***ERROR: CEE3501S The module CRTEQCXS was not
> found.
>
>  The traceback information could not be
> determined.
>
> ***ERROR: npm ("npm --version") failed to run. Refer to the instructions in
> READ
>
> --
> 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