Re: ancient disks, Architectural implications of locate mode I/O

Thomas Koenig <tkoenig@netcologne.de> schrieb:

Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:

John Levine wrote:
>

According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:

I believe that's what they did with VSAM.

 
Agreed in the sense that VSAM replaced ISAM, but, and I am getting
beyond my depth here, I wasn't aware that PDSs used ISAM.  I had
thought they were a thing unto themselves.  Please correct me if I
am wrong.  In any event, PDSs in their original form lasted beyond
the introduction of VSAM, or the PDS search assist functionality
wouldn't have been needed.

 
A PDS had a directory at the front followed by the members. The
directory had an entry per member with the name, the starting
location, and optional other stuff. The entries were in order by
member name, and packed into 256 byte records each of which had a
hardware key with the name of the last entry in the block. It searched
the PDS directory with the same kind of channel key search it did for
ISAM, leading to the performance issues Lynn described.

>
>
Yes, I don't disagree with any of that.  But I got the impression from
your previous posts that IBM had replaced the search key fields of a
PDS with some kind of VSAM (i.e. b-tree or such) varient, as they did
with ISAM.  If that is true I had never heard about it.

>
They introduced PDSE, see
https://www.ibm.com/docs/en/zos-basic-skills?topic=sets-what-is-pdse
It appears they fixed many of the problems with the original
design, but not all (why is the number of extents still imited?)
It also seems that RECFM=U for load modules is no longer supported,
you have to do something different.

Reading
https://share.confex.com/share/121/webprogram/Handout/Session14147/SHARE%20PDSE%20What%27s%20new%20in%202.1.pdf
it seems IBM really messed up PDSE the first time around,
introducing size limits on members which were not present in the
original PDS.  Seems somebody didn't take backwards compatibility
too seriously, after all...