Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: ancient disks, Architectural implications of locate mode I/O
Date: Sun, 7 Jul 2024 14:11:49 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <v6e7n5$c57i$1@dont-email.me>
References: <v61jeh$k6d$1@gal.iecc.com> <v6anes$3mvnv$1@dont-email.me> <v6bm29$2ev1$1@gal.iecc.com> <v6c56i$3u9qe$1@dont-email.me> <v6cctp$2k8r$1@gal.iecc.com> <v6dc8r$7ra8$1@dont-email.me> <v6dcvs$7shp$1@dont-email.me> <v6djnh$8tj9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 07 Jul 2024 16:11:50 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ba103472410feb2a17b6a16ee1809f64";
	logging-data="398578"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+MiLIQZ9E+PsiUUB4KaAYkgoaMtDlaIcY="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:e+RX77J3GKPUH2TdoqdStQlxwMs=
Bytes: 3643

Thomas Koenig wrote:

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


Ahhh!  That (and your previous post) is the answer.  This all happened
long after I was not involved,

Thank You Thomas.



-- 
 - Stephen Fuld 
(e-mail address disguised to prevent spam)