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
>

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