Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Stephen Fuld" 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: References: 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 schrieb: > > Stephen Fuld schrieb: > >> John Levine wrote: > > > > >>> According to Stephen Fuld : > >>> >> 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)