[email protected] (Edward Jaffe) writes: > You've described the old CUT-mode interface. Somewhere around the > early 1980s, DFT mode was introduced. It does not encode the data, use > a screen to send it, or any of that. It simply wraps the binary data > in a 3270 structured field envelope and sends it via the WSF > (write-structured-field) command. Any 3270 emulator that still uses > the CUT-mode interface for IND$FILE should be tossed on the trash heap > of history...
note that tcp/ip ftp ... typically does full-duplex pacing trying to maximize packets in flight (aka peer-to-peer networking). 3270 dumb terminal emulation tends to use half-duplex end-to-end serialization. tcp/ip "slow start" was introduced in the latter half of 80s as congestion control ... start with small number of packets in flight and slowly increase the number of packets in flight ... until get lost packet indication and then back-off number of packets. http://en.wikipedia.org/wiki/Slow-start in the mid-80s, there was adaptive rate-based pacing as part of my internal high-speed data transport project ... some past posts http://www.garlic.com/~lynn/subnetwork.html#hsdt old paper I did on adaptive rate-based pacing for XTP protocol (i was on xtp technical advisory board over extreme objections from communication group) http://www.garlic.com/~lynn/xtprate.html more recent there have been efforts with internet2 and next generation internet with rate-based pacing ... that shows significant increased throughput ... a subject I will periodically pontificate on. random rate-based pacing reference here https://lists.internet2.edu/sympa/arc/transport/2005-02/msg00004.html change from 3272/3277 to 3274/3278 move a lot of electronics from the terminal back into the shared control unit (to cut down manufactoring costs). as a result there was enormous increase in protocol chatter over the coax for 3274/3278 (as well as lots of increase in latency). later with 3277 emulation cards, they get three times the upload/download throughput of 3278 emulation cards. early 80s there was lots of work on showing human productivity for .2second response ... but 3274/3278 made that responsible ... past post with analysis of 3272/3277 and 3274/3278 from early 80s. http://www.garlic.com/~lynn/2001m.html#19 3270 protocol as referenced, none of the mvs/tso systems were even in the running with best possible of one second. somebody published a report that their internal interactive operation was best in the company with quarter-second response. I complained that I had operations on the west coast with .11 response (i eventually got back response that they could claim anything they wanted). 3272/3277 had hardware latency of .086 ... so to meet requirement of .2second required system response no more than .114sec. 3274/3278 best case hardware latency was .283sec ... but more typical was .530sec (making .2sec response impossible). we complained to the 3274/3278 product people ... and eventually they came back that 3274/3278 was for data entry and not intended for interactive computing, from recent discussion http://www.garlic.com/~lynn/2012m.html#15 cp76, vm370, etc from ibm jargon: bad response - n. A delay in the response time to a trivial request of a computer that is longer than two tenths of one second. In the 1970s, IBM 3277 display terminals attached to quite small System/360 machines could service up to 19 interruptions every second from a user I measured it myself. Today, this kind of response time is considered impossible or unachievable, even though work by Doherty, Thadhani, and others has shown that human productivity and satisfaction are almost linearly inversely proportional to computer response time. It is hoped (but not expected) that the definition of Bad Response will drop below one tenth of a second by 1990. ... 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: INFO IBM-MAIN
