[EMAIL PROTECTED] wrote:
Yeah, we had both on a 4361. I don't remember all the details since it was
under the purview of the VM group. Think they went out of their way to avoid
3330's and 3350's. One of the very sharp MVSer's dad worked at Santa Teresa and
we usually got excellent support for all geometries. The one exception was
the 3380 w/ speed matching buffer. The JES3 folks just wouldn't admit that it
existed or even take it into account. So we'd ZAP in support only to find it
SUP'd with next batch of PTFs.
whole e-ckd stuff somewhat came out of trying to get 3380 speed matching buffer
stuff working.
3380/3880 introduced "data streaming" and 3mbyte channels raising the max channel
distance (daisy-chain) from 200ft to 400ft. previously bus&tag had synchronous end-to-end
handshake
on every byte transferred. "data streaming" relaxed that requirement ...
doubling both the
typical max. data transfer from 1.5mbyte to 3mbyte and also max channel distance from 200ft to
400ft. "speed matching" attempted to retrofit 3880/3380 to 168 and 303x machines with channel running at 1.5mbyte max (w/o 3mbyte data streaming support)
part of the FBA rant was the significant pain/cost of trying to get e-ckd &
speed matching working could have been totally eliminated by directly supporting
FBA (at a drastically lower cost/effort).
lots of posts about doing operating system for disk development and product test labs (bldgs. 14&15) was debugging 3880 and 3380 problems.
http://www.garlic.com/~lynn/subtopic.html#disk
and in part because I was around trying to figure out what was going on to
compensate for hardware incorrect/error operations in the software ... i would
also periodically get pulled into playing hardware for the engineers. the
excuse given roping me into playing hardware engineer was that so many of the
senior engineers had departed (for one reason or another).
old posts mentioning the period:
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2003e.html#7 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003e.html#9 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2004l.html#14 Xah Lee's Unixism
http://www.garlic.com/~lynn/2006l.html#4 Google Architecture
http://www.garlic.com/~lynn/2006q.html#50 Was FORTRAN buggy?
http://www.garlic.com/~lynn/2007b.html#28 What is "command reject" trying to
tell me?
including this old email reference in the above post
http://www.garlic.com/~lynn/2007b.html#email800402
The previous post that started the "FBA rant" topic drift
http://www.garlic.com/~lynn/2007e.html#33 IBM S/360 series operating systems
history
had email that had first paragraph on speed-matching buffer edited out
http://www.garlic.com/~lynn/email820907
From: wheeler
Date: 09/07/82 12:16:54
STL cannot even handle what they currently have. Calypso (3880 speed
matching buffer using "ECKD") is currently in the field and not
working correctly. Several severity one situations. Engineers are on
site at some locations trying to solve some hardware problems ... but
they have commented that the software support for ECKD appears to be
in even worse shape ... didn't even look like it had been tested.
IBM double density (double the number of tracks) are here also. The
engineers have been fighting with the OS people (completely
unsuccessfully) to support the box in native mode .. i.e. one device
with twice the number of cylinders as a 3350. OS data management
people would have nothing of it. Several engineers who had MVT
experience said that they could go in and do it easily just by
defining a new device type and updating a couple of tables (almost as
trivial as what it takes for VM). OS data management replied that
things have completely changed since then, implying that they might
not even know all the routines that may have tables now. Result is
that the engineers have been forced into simulating two 3350 drives on
a single double density 3350 because the OS crowd is completely
incapable of getting their act together. As a result any performance
optimization techniques are going to be blown almost completely out of
the window (in some ways worse than effect of multi-track search). Not
only is two device simulation going to completely lay to waste any
ordered seek queueing algorithms (as bad as what happens in a multiple
CPU, shared DASD situation) ... but VM is stuck with the design also.
Based on the current record so far ... any investigation into MVS
support of FBA is going to be little more than another throw-away task
force report w/o any productive results.
... snip ...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
