[email protected] (Carmen Vitullo) writes: > Brings back some good memories - I enjoy reading your post, I seem to > have forgotten more about my life at Boeing than I remember, short > time, 11 years in Philly but I do recall the 4341 trail connected to > some new state of the art 3390 controllers running MVS 4.3 ? or 5 > strictly for an electronic mock up system for the V-22, I had a great > pleasure working with some AI engineers and Wind Tunnel engineers on > some off the wall projects. > > I remember the data center running microwave sender/receiver from one > building to another to support CATIA workstations, not an IBM approved > method to extend a channel but back them there were less options. so > many other projects I can't even remember any longer :( > > BCS then morphed into Boeing Shared Services group. I have some fond > memories of those time and the GREAT folks I worked with. thanks > again for the trip back in time. sorry to stray from the topic folks > > Carmen
re: http://www.garlic.com/~lynn/2016h.html#47 Why Can't You Buy z Mainframe Services from Amazon Cloud Services? http://www.garlic.com/~lynn/2016h.html#48 Why Can't You Buy z Mainframe Services from Amazon Cloud Services? 1980, I was con'ed into doing channel-extension support (over microwave) for STL (even tho the lab was only a couple years old, it was already bursting at the seams), they were moving 300 people from the IMS group to offsite bldg ... but with dataprocessing support back into the STL datacenter. They had tried "remote" 3270 support but found the human factors totally unacceptable (use to vm370/cms local channel attached 3270 controllers). It turns out that the support downloaded channel programs to a channel emulator at the remote site for execution which radically reduced the latency and channel protocol chatter overhead on the real channels. A combination of factors resulted in them not seeing any degradation and because lots of channel protocol chatter was moved off the real IBM channels, total system throughput increased 10-15% (reduced channel busy for the 3270 operations). some past posts http://www.garlic.com/~lynn/submisc.html#channel.extender Then the FE IMS support group in Boulder was being moved acrossed the road with infrared optical modem between the roofs of the two bldgs. with same support. There was concern that optical modems would be subject to weather outages. Turns out in a white-out snow storm when nobody could get into work, we recorded only a modest number of transmission bit-errors. There was a problem with poles with the modems on the roofs ... it turns out sun during the day, unevenly heated the sides of the bldgs causing them to slightly lean ... causing the modems to get out of alignment (took some careful engineering). The vendor wanted to get IBM to let them release my support ... but there was a group in POK working on some serial stuff that got it blocked, because they felt if it was released, it would make it harder to get their stuff released. In any case, the vendor eventually managed to reimplement my support from scratch and sell it in the market. A year after 3090s had been in the field, the 3090 product administrator tracked me down. There is an industry publication that gathered customer EREP reports and generated summary reports ... able to compare different models as well as IBM processors against clone makers. 3090 had been design to have less than 3-5 total channel check errors over period of year ... and it turned out something like 15 were reported. It turns out that nearly all of them was because I had chosen to reflect "channel check" error for channel-extender unrecoverable errors ... setting up standard system error retry. After doing some research, I figured that reflecting IFCC (interface control check) would result in same system error recovery (as CC, channel check). I then got the vendor to make the change (to IFCC) in their support ... to improve the 3090 EREP statistics. In 1988, I was asked to help LLNL (national lab) standardize some serial channel stuff they had, which quickly becomes fibre channel standard ... including the support for downloading I/O programs to minimize latency and protocol chatter overhead. In 1990, the POK people get their serial stuff released as ESCON with ES/9000, when it was already obsolete. Later, some POK channel engineers get involved with fibre channel standard and define an extremely heavyweight protocol (that drastically reduces the throughput of the native standard), that is eventually released as FICON ... some past posts http://www.garlic.com/~lynn/submisc.html#ficon Relatively recently, IBM published peak I/O benchmark that used 104 FICON getting 2M IOPS on z196 (I haven't been able to find anything similar published since then) ... at about the same time, a native fibre channel was announced for e5-2600 blade claiming over million IOPS (two such fiber channel with higher throughput than 104 FICON running over 104 fibre channel). About the same time there was specification for enhanced FICON protocol using TCWs ... a little like what I had done originally in 1980 ... but it claimed only about 30% improvement compared to the base FICON heavyweight protocol. -- 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
