Phil Payne wrote:
They had Memorex Double Density 3350s with IDI - "Intelligent Dual Interface".
Was ever
anything so inappropriately named? A status bus parity check - a common
occurence - caused
all IDI-linked controllers to forget all owed interrupts. Total system hang.
SVS had a MIH,
but its channel redrive was - IMO - incorrect. I can't remember after a
quarter of a century,
but it did a Clear IO when it should have done a Clear Channel or vice versa. I
zapped the
opcode
for other topic drift ... san jose had done a 3350 (prior to 3380) with twice
the number of cylinders ... but they couldn't get MVS to provide the device
support ... so they shipped it as two emulated regular 3350s ... which didn't
see a lot of uptake, partially because the two independent optimized seek
queues would be contending for single arm (resulting in relatively random arm
motion).
this was an ongoing problem. MVS also wouldn't do FBA
(fixed-block-architecture) device support. It was even offered to provide them
with the fully tested code ... and the reply was there would still be a twenty
some million change bill (documentation, training, etc). Needed to demonstrate
real incremental ROI for the (i.e. real additional new sales as opposed to
customers buying FBA in-lieu of CKD).
lots of past posts about hacking around in the disk engineering and test labs
(bldgs 14&15)
http://www.garlic.com/~lynn/subtopic.html#disk
From: wheeler
Date: 09/07/82 12:16:54
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 FBA/CKD topic drift ... recent post about heavy performance penalty
multi-track CKD extracted long after the memory/io trade-off had changed
http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction
and lots of past posts on the CKD performance trade-off subject ... using
excess I/O capacity in the 60s to compensate for scarce real-storage ... but by
the mid-70s, configurations were changing from real-storage constrained to I/O
constrained ... making the CKD trade-off totally the wrong thing.
http://www.garlic.com/~lynn/subtopic.html#dasd
other old email about early difficulty with MVS RAS for 3380 ... which got me
into loads of hot water with the MVS RAS manager ... not because of the tests
... but for having sent an email mentioning the results of the tests.
http://www.garlic.com/~lynn/2007.html#2 "The Elements of Programming Style"
when I had originally started playing around in the disk engineering labs ... the
"testcells" (i.e. development devices) were being scheduled for stand-alone testing on
dedicated processors. They had attempted to run under MVS in an operating system environment ...
but experienced 15 min MTBF for MVS (i.e. MVS was crashing or hanging because of errors and/or
incorrect operations of the devices under development). I undertook to completely redo the i/o
subsystem to make it bullet-proof ... allowing multiple concurrent testcells to be tested
"on-demand" ... rather than having to resort to dedicated, stand-alone scheduled testing
time.
----------------------------------------------------------------------
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
