[EMAIL PROTECTED] wrote:
Some other "users" (aka Fortune 100 companies) are used to reliability,
availability, and serviceability of such magnitude that an unscheduled reIPL
(also pronounced "reboot") on their mainframes happens perhaps twice a year.
Memory leaks are not a valid reason for restarting these systems, but amazingly
enough these users are intolerant enough to demand that the memory leaks be
fixed. And, even more amazingly, the software vendors involved even fix the
leaks.
circa 1980, STL wanted to relocate something like 300 of the IMS people
to an offsite building about 10 miles away. They looked at remote 3270
support into the STL datacenter but found it totally unacceptable.
NSC had HYPERChannel with A22x channel adapters (looked like control
unit and directly attached to channels), A7xx telco adapters, and A51x
remote device adapters (emulated ibm mainframe channel and allowed
connection of control units). These could be configured to effectively
provide channel extension over telco links. This was used to provide
remote service for the 300 relocated people from the IMS group. Turned
out as a side-effect of getting the local 3274 controllers directly off
the IBM channels ... things actually improved about 10-15 percent
compared to the direct attached operation (which more than compensated
for the slight increase in latency over T1-telco link in the channel path).
So I tried to make the software generally available ... but both the
communication group and the fiber group in pok non-concurred (what
eventually was released as escon had been laying around pok since the
late 70s). However, the vendor took my design ... and re-implemented it
from scratch.
so we roll forward, the 3090 had been in customer shops for a year ...
and the product manager for the 3090 tracks me down. a lot of customers
provide erep data to an industry operation that collected and provided
report summaries about different vendor RAS (reliability, availability,
serviceability). the 3090 product manager was very concerned about the
3090 data.
the 3090 channels had been designed to have 3-5 channel errors per year
(all channels for all customers, aka not 3-5 channel errors per channel
per customer per year ... but 3-5 channel errors aggregate per year
across all channels and all customers). the industry source reported
that there had been something like a total of 16 reported channel errors
for the year. they were deeply concerned about the additional 11
reported channel errors.
well, it turned out to be a number of customers using HYPERChannel for
channel extension. in the original design, if I had got an unrecoverable
i/o error from the telco transmission or the remote end ... i would
eventually simulate a channel check error on the operation ... which got
it into the standard operating system erep retry, recovery, and
recording processing. this accounted for the additional 11 reported 3090
reported channel errors for the year.
so i went back and looked at stuff in detail and decided that for all
intent and purposes ... simulated IFCC (interface control check)
resulted in nearly identical operating system retry and recovery. I got
the vendor to change the channel check simulation to IFCC simulation.
can you imagine any other market segment where they would even know if
the total aggregate i/o bus errors across all machines installed at all
customers totaled 15 errors for the whole year.
can you imagine any other market segment where there was an industry
service that collected all such information across the installed
customer base and provided regular industry reports?
can you imagine any other market segment where the customers would
reguarly buy and read such industry reports.
misc. past posts mentioning the 3090 channel incident:
http://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
http://www.garlic.com/~lynn/96.html#27 Mainframes & Unix
http://www.garlic.com/~lynn/2004j.html#19 Wars against bad things
http://www.garlic.com/~lynn/2004q.html#51 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005d.html#28 Adversarial Testing, was Re:
Thou shalt have no
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005u.html#22 Channel Distances
http://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor
----------------------------------------------------------------------
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
