Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler 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: <1bed88y8na.fsf@pfeifferfamily.net> <87frsnwbd5.fsf@localhost> 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" 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