[email protected] (Anne & Lynn Wheeler) writes: > old '89 email with copy of the spring '85 announcement > http://www.garlic.com/~lynn/2011c.html#890731
re: http://www.garlic.com/~lynn/2011g.html#73 We list every company in the world that has a mainframe computer http://www.garlic.com/~lynn/2011g.html#74 We list every company in the world that has a mainframe computer oops, correction, URL should be http://www.garlic.com/~lynn/2011c.html#email890731 the post: http://www.garlic.com/~lynn/2011c.html#40 Other early NSFNET backbone also has communication group related email from the following day http://www.garlic.com/~lynn/2011c.html#email890801 and a 2nd one from the following day ... i had gotten on the xtp technical advisory board (which the communication group strongly objected to): http://www.garlic.com/~lynn/2011c.html#email890801b where part of XTP specification included reliable multicast which was being used in some environments that might experience an enormous amount of damage but the signals still need to get through. recent post doing channel extender support in 1980 for 300 people/terminals from IMS group that were being moved out of STL to remote bldg (they had tried "remote 3270" and found human factors intolerable) http://www.garlic.com/~lynn/2011g.html#43 My first mainframe experience In 60s, 2701 supported T1 data rates ... and lots of gov. institutions were still using them in the 80s (since the communication group didn't have products w/T1 support). Many customers were moving to products from other vendors (like HYPERChannel) to get T1 and higher speed support. Special T1 RPQ Series/1 Zirpel card was product for gov. accounts where their 2701 were starting to completely fail. Now part of the VTAM problem was that it handled latency on higher speed links, very poorly (even when terrestrial). Part of 3737 was to have a mini-VTAM ... get the transmission from mainframe ... look inside the RU and if possible, immediately tell the host VTAM that it had already arrived at the other end ... and then use (effectively) non-SNA for 3737 to 3737 transmission (lots of VTAM spoofing to effectively compensate for poor VTAM latency handling). from long ago and far away Date: Mon, 6 Jun 88 12:46:05 est From: wheeler Subject: 3737 3737 is the product version of zebra. zebra has a mini-vtam buried in its guts and will only handle connections with a vtam system. 3737 looks like a ctc connection to host vtam. In zebra/3737, it is doing a lot of SNA session management ... it transparently forwards all control RUs to the host vtam at the remote end ... but it does early ACKs for all data RUs (i.e. tells the local host vtam that the data has completed transmission before it has even been sent). The logic/design is somewhat similar to the PVM/S1 support ... but in this case it can only be used with host VTAM system. ... snip ... Date: Wed, 5 Oct 88 15:30:42 EST From: wheeler Subject: 3737 note don't confuse the 3737 with a standard T1 inteface box. 3737 is specifically VTAM only. The 3737 contains a mini-embedded VTAM and can only be directly channel attached to an IBM mainframe and can only be driven by IBM mainframe VTAM system. It is also slow, and what SNA performance it does get is via SNA protocol spoofing (it does early "ACKS" to the local mainframe, as a result packets can be lost w/o any way of notifying higher level protocol layers). ... snip ... -- 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: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
