Device and channel 361

note that the ficon description is nearly identical to the HYPERChannel remote device adapters (A51x) boxes starting around 1980 or so.

when a couple hundred people from the IMS group in STL-bldg90 were remoted to a bldg about 10miles away ... they looked at the performance of remote 3270s ... and decided to go with HYPERChannel and "local" 3270s instead. I got to write the device driver to download the CCWs into the memory of the A51x boxes ... which had loads of attach (local) 3270 controllers.

the configuration had HYPERChannel A220s on the local mainframe channels and then pairs of HYPERChannel A71x boxes with T1 (1.5mbit) link and finally some number of A51x boxes at the remote site.

The people that were remoted didn't see any observable 3270 response characteristics between real local 3270s and HYPERChannel local 3270s (over T1 link). However, there was a side benefit ... getting the local 3274s off the local mainframe channels and replacing them with HYPERChannel A22x adapters improved overall system thruput about 10-15%. It turns out that the HYPERChannel A22x had significantly lower channel busy time (for the same operation) than did real 3274 controllers directly attached to mainframe channels (getting the real 3274s directly off the mainframe channels significantly lowered channel busy time for doing 327x operations and improved overall system thruput).

There was a problem tho using A510 boxes for disk operations because of the timing dependeing nature of doing search-id-tic operations. Finally NSC came out with the HYPERChannel A515 channel adapter box that was used by NCAR for their cluster filesystems. They sort of used the IBM mainframe as a hierarchical filesystem controller. Various supercomputers on the HYPERChannel network could make a request for some data. The ibm mainframe would stage the data to disk (if no already) and then download the dasd channel program into the memory of an HYPERChannel A515 box ... and then return a pointer to the channel program. The supercomputer would address the specific A515 invoking the specified channel program ... resulting in the data read-writes being directly between the supercomputer memory and DASD (w-o having to pbutt thru the memory of the ibm mainframe).

numerous past posts on HYPERChannel, HSDT, etc.

for some topic drift ... the original mainframe tcp-ip support could consume a full 3090 cpu getting about 44kbytes-sec thruput. I added RFC1044 (NSC adapter) support to tcp-ip and in tuning at cray research was getting 1mbyte-sec sustained between a cray and a 4341-clone (using only a modest amount of the 4341).

misc rfc1044 posts

some other random HYPERChannel drift ... for original HYPERChannel driver i had done for STL-bld.90 ... if there was an error that could recover within the driver ... a channel check i-o interrupt was simulated. some years later ... something like a year after 3090 first customer ship ... some ras guy from pok tracked me down. turns out the industry erep reporting service was showing something like five times the expected number of channel checks for customer 3090 operation. It turned out they had tracked it down to some small number of HYPERChannel drivers simulating channel checks (for things like unrecoverable HYPERChannel channel extender over telco T1 links). The point in simulating channel check was to kick off various operating system retry operations. After some analysis, I determined that simulating IFCC (interface control check) instead of channel check would result in effectively the same retry operations.

--