Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lynn Wheeler <lynn@garlic.com>
Newsgroups: comp.arch
Subject: Re: Architectural implications of locate mode I/O
Date: Sat, 06 Jul 2024 07:34:43 -1000
Organization: Wheeler&Wheeler
Lines: 48
Message-ID: <878qyev2z0.fsf@localhost>
References: <v61jeh$k6d$1@gal.iecc.com> <1bed88y8na.fsf@pfeifferfamily.net>
	<v69jgf$1lg1$1@gal.iecc.com> <87frsnwbd5.fsf@localhost>
	<v6anes$3mvnv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sat, 06 Jul 2024 19:34:45 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e13bd93f2ce0ce0c86152ba447239d8c";
	logging-data="4101718"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/gRu6nQ0boTKmjKxVymeUoCE2Pgj6sDv4="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:qAg7L7W2XcppVp3TIq6IWmGHTfI=
	sha1:HlGCu219ud2DnzsF5gRzcdtSCys=
Bytes: 3729

"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
> As you posted below, the whole PDS search stuff could easily be a
> disaster.  Even with moremodest sized PDSs, it was inefficient has
> hell.  Doing a linear search, and worse yet, doing it on a device that
> was slower than main memory, and tying up the disk controller and
> channel to do it.  It wasn't even sort of addressed until the early
> 1990s with the "fast PDS search" feature in the 3990 controller.  The
> searches still took the same amount of elapsed time, but the key field
> comparison was done in the controller and it only returned status when
> it found a match (or end of the extent), which freed up the channel.
> Things would have been much better if they simply used some sort of
> "table of contents" or index at the start of the PDS, read it in, then
> did an in memory search.  Even on small memory machines, if you had a
> small sized index block and used something like a B-tree of them, it
> would have been faster.

trivia: I've also mentioned in 1980 using HYPERChannel to implement
channel extender ... as side-effect also reduced channel busy on the
"real" channels ... another side-effect would get calls from ibm
branches that had customers also doing stuff with HYPERChannel including
NCAR that did supercomputer "network access system" that as side-effect
eliminated channel busy for CKD DASD "search" operations in 1st half
of 80s (a decade before 3990)

for A510 channel emulator , the channel program was downloaded into the
A510 and executed from there. NCAR got a upgrade for A515 which also
allowed the search argument to be included in the download ...  so
mainframe real memory and channels weren't involved (although the dasd
controller was still involved). It also supported 3rd party transfer.

Supercomputer would send request over HYPERChannel to mainframe
server. The mainframe would download the channel program into a A515 and
return the A515 and channel program "handle" to the supercomputer. The
supercomputer would send a request to that A515 to execute the specified
channel program (and data would transfer directly between the disk and
the supercomputer w/o passing through the mainframe).

Then became involved with HIPPI (open cray channel standard pushed by
LANL) and FCS (open fibre channel pushed by LLNL) also being able to do
3rd party transfers ... along with have LLNL's LINCS/Unitree ported to
IBM's HA/CMP product we were doing. 

other trivia: as also mentioned System/R (original SQL/relational RDBMS
implementation) used cacheable indexes ... not linear searches.


-- 
virtualization experience starting Jan1968, online at home since Mar1970