----------------------------------------<snip>---------------------------------
In the eighties I worked for a service bureau that provided primarily
on-line Wylbur and batch services. We acquired two 4341 processors.
While the customers didn't need it, I started working on TSO. On the
bare test system, I could log on and run; but once I added the SMF
exits, I got 0C4s and was unable to complete the logon process. Sounds
like an obvious error in the exits, but I tracked it down to the 4341,
which had an architecture based on 2K pages. Whenever the source or
destination of an MVCK crossed a 2K boundary that was not also a 4K
boundary, the instruction failed. It took quite a while to convince the
CE that this was not a software problem; some interminable (?) time
later he returned with a new floppy containing a firmware fix. We loaded
and tested it, and the logon failed again, on the same MVCK. The "fix"
worked when either the MVCK destination or source crossed the 2K
boundary, but not when both did. The problem was fixed eventually, and
also showed up on the 4381 we upgraded to some time later. Ever since,
in two states, I've has an MVCK license plate <g>
In the seventies we had a 360/65 (with non-IBM add-ons), that kept
failing on machine checks. The CE couldn't find anything, so brought in
others from the local office, then a few more from the area. The initial
diagnosis was a misbehaving MVC instruction, but they couldn't track the
problem. Finally IBM flew in a specialist from the West coast (San
Jose?), whose first action was to throw the Lamp Test switch, showing a
burned out bulb. Once that was replaced, and MVC determined to be
working fine, they finally found a ground loop in the console pedestal,
fixed with a one-foot square aluminum plate. Total downtime was three days!
And if you want to dredge up some really ancient history, in the
sixties I worked for ADR (ROSCOE and Librarian creator), and we
upgraded to a 360/50. This was a nifty upgrade for us (from a 360/40),
but at apparently random intervals the machine would crash on machine
checks, and the CE was unable to determine the cause. At the time,
Seymour/Shmuel Metz and I were maintaining the system, and one of his
mods chained a Bell CCW to the 1052 console write for a message with
routing and descriptor code of 1 (the operators had a habit of not
watching the console, and instead doing weird things like mounting
tapes, etc.). The CE insisted that it was a software problem, until one
maintenance session I had him power off the machine, bring it up, clear
storage, and I entered a simple I/O loop with the console switches to
ring the bell. It seems that with a plethora of diagnostics, at the time
there was nothing to verify proper working of the bell.
--------------------------------------<unsnip>-----------------------------------
ISTR a similar problem with the 360/67, when a BAL or its target were
split across a page boundary. The dialectric material in the ROS needed
replacement and the CE replaced it with three layers of SARAN Wrap and
the machine worked perfectly after that. Of course the capacitive ROS
had to be tightened to a different torque spec, but Burlington (or
whereever) came through with the right specs for that as well.
Consider chewing gum and bailing wire?? :-)
Rick
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
