[email protected] (Norman.Hollander) writes: > 3088 Multi-System Channel-to-Channel I/O Control Unit. Bus and Tag, > connecting 4 CPUs (IIRC). We used these (had to have 2 for > redundancy) for JES2, VTAM, and CA-MIM connectivity. Also used to > connect to VM systems (PVM, RSCS, and CA-MIM). Obsoleted by ESCON and > Directors. May have a picture somewhere with a 3088 and 9032 (ESCON > director). Without the 3088, you needed many dedicated channels on > each processor.
3088/trouter could have up to eight arms. my wife had been con'ed into going to POK to be in charge of loosely-coupled architecture ... she wanted to have several enhancements for 3088/trouter (before announced) and was unable to get the enhancements to make it much more efficient. One of the reasons to her leaving ... along with frequent battles with the communication group trying to force her into using SNA/VTAM for loosely coupled operation ... and little uptake of her full "peer-coupled shared data architecture" (except for IMS hot-standby, until sysplex). some past posts http://www.garlic.com/~lynn/subnetwork.html#shareddata an example was an internal vm370 4341 8-way cluster effort ... that did a tweak and used full-duplex cluster coordination protocol with 3088/trouter. The communication group forced them to SNA/VTAM before release for customers, cluster coordination operations that had run in subsecond elapsed time was then taking upwards of 30seconds elapsed time over SNA/VTAM. I've periodically mentioned in 1980, getting con'ed into doing channel extender support. The STL lab. was bursting at the seams and they were moving 300 people from the IMS group to offsite bldg ... with remote access back to the STL datacenter. The group had been offerred remote 3270s ... but found the human factors intolerable (compared to what they had been use to with local 3270 direct channel attached controllers). The channel extended box allowed downloading channel programs to the remote site channel emulator ... enormously reducing the channel protocol chatter latency. this included using multiple subchannel addresses for full-duplex operations (asynchronous, continuous incoming and outgoing). some past posts http://www.garlic.com/~lynn/submisc.html#channel.extender The hardware vendor tried to get IBM to let them release my support to customers ... but there was a group in POK playing with some serial stuff and they were afraid if it was in the market, it would make it harder to get their stuff released. A little later in the early 80s, NCAR http://ncar.ucar.edu/ did a supercomputer filesystem using the same vendor hardware. They had IBM 370 as NAS (network attached storage) controller with IBM DASD ... DASD controllers connected to the vendors emulated channel. Supercomputers would use the hardware as network interface to talk to IBM mainframe to request data. The IBM mainframe would download the channel program to the channel emulator box and then return the "handle" for the channel program to the requesting supercomputer. The supercomputers would then directly execute the channel program (data flowed directly between supercomputer and IBM DASD, with only IBM mainframe being involved in the control operation, the same hardware operates as both CTCA, processor-to-processor as well as processor-to-controller and included family of boxes interfacing to different kinds of processors, not just ibm mainframes). I would be periodically be contacted by Boulder branch because I was considered the IBM expert on the vendor hardware. I was being asked IBM DASD questions because bldg. 14 disk engineering lab had also con'ed me into periodically playing disk engineer ... some past posts http://www.garlic.com/~lynn/subtopic.html#disk Later in 1988, I was asked to help LLNL https://www.llnl.gov/ standardize some serial stuff they were working with ... which quickly becomes fibre channel standard ... it included sending i/o programs to remote end for execution and continuous, asynchronous incoming and outgoing (significantly reducing protocol overhead latency). The NCAR NAS stuff was also standardized as "3rd party transfers". By the time the POK serial stuff was released in 1990 with ES/9000 as ESCON, it was already obsolete. Then some of the POK channel engineers get involved with fibre channel standard ... and define an enormously heavyweight protocol that reduces native FCS throughput that is eventually released as FICON ... some past posts http://www.garlic.com/~lynn/submisc.html#ficon trivia ... in the 80s, concern about US competitiveness in the world motivated congress to passed legislation (including changing some anti-trust provisions) making it easier for gov. agencies and national labs. to work with companies to commercialize gov. technology (including several things from LLNL). I've mentioned before in the late 80s, a senior disk engineer gets a talk scheduled at annual, world-wide, internal communication group conference supposedly on 3174 performance ... but opens the talk with statement that the communication group was going to be responsible for the demise of the disk division. The issue was that the communication group had stanglehold on datacenters with corporate responsibility for everything that crossed datacenter walls and were fighting off client/server and distributed computing trying to preserve their dumb (emulated) terminal paradigm and install base. The disk division was seeing data fleeing to more distributed computing friendly platforms with drop in disk sales. The disk division tried to come out with several products to address the problem, but they were constantly being vetoed by the communication group. some past posts http://www.garlic.com/~lynn/subnetwork.html#terminal As a work around to internal politics, the disk division was then investing in anything that might use IBM DASD ... including "Mesa Archival" ... the NCAR NAS spinoff, part of the push to commercialize gov. tech & improve US competitiveness ... and disk division executive would periodically asked us to go by and try and help them. "Mesa Archiveal" was working on moving from IBM mainframe to IBM RS/6000 and "3rd party" FCS operation (still using IBM disks). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
