TOD clock discussion

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: Thou shalt have no