mitchd...@gmail.com (Dana Mitchell) writes: > 4331 had integrated disk and communication adapters built in, no 3274, > 3705, 3880 controllers required. Later machines just had parallel > channels just sort of built in, not really on cards. 3090 was first > with ESCON
minor nit, ESCON announced with ES/9000 in 1990 ... https://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_FS9000.html Enterprise Systems Connection (ESCON) Architecture implementing fiber optic channels, which provide significantly higher data rates than traditional parallel channels and which permit input/output equipment to be located at distances up to nine kilometers (5.6 miles) from the processor; ... snip ... from Computerworld, 20Jan1992, volXXVI, #3, pg. 29 article, "No stampeded to IBM's Escon" IBM's Escon architecture, introduced in September 1990, is a fiber-optic-based method of connecting processors, storage devices and peripherals. ... snip ... 1980, STL cons me into doing channel extender support. They are moving 300 people from the IMS group to an offsite bldg with remote access back to STL datacenter. The victim group had tried remote 3270 support and found the human factors totally unacceptable. The channel extender support puts 3270 channel attached controllers at the offsite bldg. The channel extender support ... downloads channel programs to channel simulator at the remote site ... significantly offsetting the latency and overhead of the intensive channel protocol chatter over the extended distance. Instead streams data & channel programs simultaneously over full-duplex connection (side-by-side 3270 demos with real local channel attached and channel-extender running loop-back to offsite bldg and back ... it is not possible to tell difference). Vendor then tries to get IBM to allow release of my support. However there is a group in POK that is playing with some fibre stuff that gets it blocked because they are concerned that if it was in the market, it would make it harder to get their stuff released. some past posts http://www.garlic.com/~lynn/submisc.html#channel.extender STL does a special 3270 logon screen for the IMS people at the offsite bldg (standard login for all of STL is VM370, even for people working on IMS, DB2, MVS, etc). This was also in the days of increasing focus on productivity from subsecond response. Standard TSO at best was second, and most of the time much worse. Lots of internal VM370 systems were .2sec ... but I did "SJR/VM" systems that lots of internal datacenters ran that would get .1sec using same hardware with identical load (when I was at science center, it was CSC/VM that lots of internal datacenters ran, before I transfered to san jose research) http://www.garlic.com/~lynn/vmhyper.jpg In 1988, I'm asked to help LLNL standardize some serial technology they are working with ... which quickly becomes Fibre Channel Standard ... including concurrent streaming in both directions of data & downloaded I/O programs (minimizing latency of I/O program protocol chatter). Then ESCON is announced 1990 with ES/9000 when it is already obsolete. Then some POK engineers became involved with fibre channel standard and defined an extremely heavy-weight protocol that drastically cuts the native throughput, which is eventually announced as FICON. Most recent "peak I/O" benchmark I can find is z196 getting 2M IOPS using 104 FICON. About the same time there was native FCS announced for E5-2600 blade claiming over million IOPS (for single FCS, two such FCS having higher throughput than 104 FICON running over 104 FCS). There is some mention of zHPF/TCW that is a little like what I had done originally in 1980 ... but claims only 30% improvement over standard FICON (possibly 2M IOPS with only 70 FICON?) some past posts http://www.garlic.com/~lynn/submisc.html#ficon 3090 trivia: engineers were really upset being directed to use slow, vertical microcoded JIB-prime for 3880 disk controller. It had special hardware bypass for 3mbyte/sec data transfer ... but the controller was really slow at processing channel programs and rest of the channel protocol chatter, signicantly increasing channel busy (much, much slower than the previous horizontal microcode 3830 disk controller). 3090 had designed balanced configuration throughput assuming that channel protocol overhead busy would be similar to 3830 (with improvement that data transferred at 3mbyte/sec). When they found how bad 3880 channel busy was going to be, they had to significantly increase the number of channels ... which required an additional TCM, which increased manufacturing cost. There were semi-facetious references that the 3090 group was going to bill the 3880 controller organization for the additional TCM. Then marketing spins all the additional channels as how much it increases the 3090 I/O throughput (obfuscating the fact that the additional channels were required for the significant increase in channel busy overhead). past posts getting to play disk engineer in bldgs14&15 http://www.garlic.com/~lynn/subtopic.html#disk recent posts in this thread: http://www.garlic.com/~lynn/2017c.html#80 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#81 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#82 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#83 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#84 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#85 Great mainframe history(?) http://www.garlic.com/~lynn/2017c.html#86 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#87 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#88 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#89 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#94 GREAT presentation on the history of the mainframe http://www.garlic.com/~lynn/2017c.html#95 GREAT presentation on the history of the mainframe -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
