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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Charles
Mills <charl...@mcn.org>
Sent: Monday, May 27, 2024 1:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs
I started my first professional programming job in January of 1969, working with DOS/360.
DLBL, EXTENT and TLBL cards existed but they were new -- the "old timers" still
used DLAB, XTENT and TLAB. So that gives you an approximate timeframe.
As @Shmeel has said, DOS definitely supported VTOCs. VTOCs were in fact
partially portable between DOS and OS/360. What DOS lacked was OS-controlled
free space management and support for the free space records of a VTOC. Free
space management on volumes was controlled by a chart on the sysprog's wall and
data set expiration dates.
Charles
On Mon, 27 May 2024 12:32:16 +0000, Seymour J Metz <sme...@gmu.edu> wrote:
DOS had VTOCs for as far back as I can remember, but when was the transition
from DLAB and TLAB to DLBL and TLBL?
When did IBM introduce the DIRF bit in the VTOC? It was definitely in OS/360,
but which release?
--
Shmeel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר
________________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Steve
Thompson <ste...@wkyr.net>
Sent: Friday, May 24, 2024 11:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs
If I remember correctly (since I started on DOS R26?) on a
S/360-30, we also had to use EXTENT cards (to define where a file
existed on a volume). So hazy memory recalls we had a Label
cylinder and an ALT Label cylinder. But maybe that came with
DOS/VS.... Too long ago now.
Then DOS got VTOCs and so if sharing with OS|MVS, the volume got
the "dirty" bit turned on if DOS did any work in the VTOC. (MVS
then had to RESERVE the volume and fix the VTOC to know where the
free extents were since DOS didn't have that feature).
The joys of migrating to OS/VS (MVS) and sharing of Volumes
between systems in a service Bureau.... oh, Cloud (sorry I forgot
the in-vogue term).
Steve Thompson
On 5/24/2024 6:02 AM, Lennie Bradshaw wrote:
When sstarted on IBM System/370 the shop I was at used DOS/VS. DOS/VS at that
time did not have VTOCs. We used //DLBL statements in JCL which specified the
exact locations of datasets on disk. This changed with the introduction of VSAM
on DOS/VS, but only for VSAM datasets.
Fortunately I soon moved to a company using OS/VS2 and got to use VTOCs and
CVOLs there.
As regards, why both VTOCs and Calalogs exist, what would be the alternative?
The more pertinent question is, I think,
Why do we have both VVDS datasets and VTOCs? Historically I understand, but it
could improve efficiency to merge these.
It would probably break too many existing interfaces though.
Lennie Dymoke-Bradshaw
https://secure-web.cisco.com/1odBw3GEOl-eQtgejAefr15bp7Yjgq1VZ1WvUgBCrG9juGErPDn2ToWA1oEov1iWq1nP1bJw6eaKuPky8YmEAI6ROQImouPPYsKMCoGQ4ib8muwTwBtsgmaaEwwZlZiehgecLz8PbPsMQwcG6tJsnJ1A5dooWER-nlc8e4YktroinRIxWFzwwcwSbdSWcHH74KJSQEkXZ7HjEmlD-rondxM3-dfiCUg6WdtAfaSZIdRnWb-s0WXRcSwWWn6opjI-Xq_Mm4rZPflgd3uyNxmzRYFO3upfE079gkz4LE7Pyt_Bs2kE4cKOlzz3x2G9xSmKy9YDk5ssM6f8Ixw7X9JwxwfoEmYhlKrybn9x-ZmPbEvXi4Bs6_XiPY2ZhFGYLeUDT9UAkXR_oj8hxsaGAyq44-tIbzxarxzELtlv1VpBXhbY/https%3A%2F%2Frsclweb.com
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Joel C. Ewing
Sent: 24 May 2024 06:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: VTOCs vs. catalogs
VTOCs did come first. The original DOS/360 Operating System did not have catalogs.
VTOCs contain not only information about physical location and organization of datasets
on the volume but also (for OS/360 and its MVS and z/OS descendants) contains a list of
all the free extents on the volume to support automated allocation of new extents for
datasets. It makes sense to still keep that level of information at the volume level
and not in some centralized "catalog", because an individual volume can be
varied online or offline, added to or deleted from the system, and also any hardware
failures that might affect data availability tends to affects specific volumes, so it
simplifies many things to keep volume-level descriptive information on the related volume.
As the total number number of DASD volumes on a system increases, having that
VTOC-level information distributed across all volumes vs putting all that
info in a centralized location improves performance by distributing read/write
activity for that data across all the volumes, and prevents a single point of
failure that could cause loss of all datasets.
Without a catalog to map data set names to volumes, it was necessary to
manually record and maintain a record of what volume(s) contain each dataset.
That was practical for a few volumes and a small number of datasets, but
obviously impractical when talking about 100's of volumes and 1000's of
datasets. OS/360 was designed to support very large systems; Hence it included
a catalog; but its use was optional for application datasets. These days the
recommended practice is that all z/OS application DASD datasets should be under
SMS, and SMS datasets must be cataloged.
The original CVOL catalog evolved into multi-level ICF catalogs, and an
eventual need to save additional dataset attributes to support SMS and VSAM
datasets resulted in an additional VVDS dataset to store that info on each
volume.
As the capacity and maximum number of datasets on a volume increased, a serial
search through a VTOC became a performance bottleneck, and an optional VTOCIX
(VTOC Index) was added to each volume for more efficient access.
There is some redundancy with having VTOCs, VVDSs, and Catalogs, but that aids
in error detection and recovery by allowing cross-checking between VTOCs, VVDSs
and Catalogs to look for and resolve inconsistencies.
On z/OS it is typical to use multi-level catalogs for security and availability
reasons and to keep application and personal datasets in catalogs distinct from
those containing system-level datasets essential to the operating system.
To reduce I/O and improve catalog performance, z/OS accesses catalogs via a
system Catalog address space that provides additional in-memory caching for all
open ICF catalogs.
JC Ewing
On 5/23/24 21:32, Phil Smith I I wrote:
I'm curious whether any of you old-timers can explain why we have both
VTOCs and catalogs. I'm guessing it comes down to (a) VTOCs came first
and catalogs were added to solve some problem (what?) and/or (b) catalogs were
added to save some I/O and/or memory, back when a bit of those mattered. But
I'd like to understand. Anyone?
...
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
