ps2...@yahoo.com (Ed Gould) writes: > Back in the 70's & 80's the place I worked had 1500 (or so) local 3270's off > of > a 168MP. > We were truly at the UCB # limit for MVS. We were forever having to do > sysgens > as our VP was a hungry for drives. The conversion to 3350's did save us a bit. > But what truly helped us was the 3274L's (1 UCB and 32 address's) (SNA local > controller). > Our monitoring of channel's we did not tend to see much busies on the byte > channel's even with the 3705 we rarely saw anything that concerned us (say > more > than 10 percent busy). BTW the online CICS application was a really big > fullscreen transfer user. > I am not sure where the chatty part you were talking about but we never saw > it > and the people that were entering the data were no slouches for entering > lot's > of data.
re: http://www.garlic.com/~lynn/2011g.html#41 & unnrelated old CICS reference: http://www.garlic.com/~lynn/2011g.html#42 interactive computing tended to have a lot more interactions that pure data entry. 3270s in general were half-duplex ... so from the time enter was hit until it was safe to type again ... increased with 3274 ... because so much electronics had been moved out of the terminal and back to the controller. the half-duplex problem also showed up if the system as doing something asynchronously while typing ... if system went to write to the screen while key was being hit, the keyboard would lock and then person would need to stop and hit reset (again horrible human factors). the reference http://www.garlic.com/~lynn/2001m.html#19 3270 protocol gave comparison timing between 3272/3277 and 3274/3278 for just internal hardware part of the controller ... base 3272/3277 hardware processing was .086 seconds ... with 90percentile trivial interactive CMS response of .11sec ... that gave effective human perceived response of .196 seconds. base 3274/3278 hardware processing was .530 seconds. The corporation had started doing a lot in the area programmer productivity and human factors ... establishing quarter second response time as a goal. The reference numbers were from a internal ibm study that showed that it was impossible to meet the objectives with direct channel attached 3274 controllers. going to SNA made the latencies and delays much worse ... and going to any kind of remote made human interactive intolerable. That was what initially prompted the HYPERChannel channel extender for the STL development lab. STL was bursting at the seams and 300 people from the IMS group were being moved to off-site building. They had done some experiments with remote 3270 and found the human factors totally unacceptable. The channel extender from the offsite building back to STL datacenter, allowed the local channel attached 3270 controllers to be placed at the remote building and human response and interactive characteristics appeared as if they werer still in the STL bldg. As it turned out, getting the direct channel 3270 controllers off the real channels had a side-benefit of increasing overall system throughput by 10-15% with the electronics in the head of 3277 it was possible to further improve the human factors ... including eliminating the half-duplex keyboard locking ... when there is normal interactive operation going on concurrently between system and user (user potentially constantly typing while the system might do something that would asynchronously update part of the screen). Open the 3277 keyboard and little soldering ... and could adjust the key repeat delay and the key repeat rate ... to a much more human acceptable rate. Also got a vendor to build a small fifo box ... unplug the keyboard from the 3277 head, plug the box into the 3277 head and plug the 3277 keyboard into the fifo box. This provided a keystroke buffer to eliminate keyboard getting locked if key was being pressed same time screen was getting something written. in the 3274/3278 ... with all the electronics moved back into the controller, it was no longer possible to perform these human factor hacks. also with much of the electronics back in the controller ... there was enormous increase in protocol chatter over coax cable between what was going on in the 3278 terminal head and the electronics back in the controller. later with terminal emulation ... is was possible to program the PC for human factors ... compensating for the 3270 human factor characteristics. However, the enormous increase in protocal chatter over coax cable drastically reduced upload/download throughput for 3274/3278 terminal emulation ... compared to what could get from 3272/3277 terminal emulation (since 3274/3278 had both lot more extranous protocol chatter as well as significantly more handshaking operation latencies doing any data movement between controller and head). the terminal emulation paradigm shows up later with the controllers supporting token-ring and PCs with T/R adapters. The PC/RT workstation (with AT ISA bus) had done its own 4mbit T/R adapters for distributed computing. For the RS/6000 workstation (with 32bit microchannel bus), the group had been told that they could not do their own adapters and had to use standard corporate 16mbit (microchannel) T/R adapters. The problem was that the 16mbit (microchannel) T/R adapters had been designed for terminal emulation paradigm with possibly 300 or more stations all sharing the same T/R bandwidth. As a result, the standard corporate individual (32bit microchannel) 16mbit T/R adapters had lower per adapter thruput than the PC/RT (16bit AT bus) 4mbit T/R adapter. The new Almaden research bldg was coming online about that time and had been heavily provisioned with CAT5 for T/R ... however, they eventually had nearly all (other vendor) ethernet adapters (running over CAT5) since it had much higher thruput (10mbit enet delivered higher sustained aggregate thruput than 16mbit T/R), lower latency, as well as higher per adapter thruput. misc. past references terminal emulation http://www.garlic.com/~lynn/submain.html#terminal in the early 80s, the corporations attention on development productivity had been somewhat spiked by Jim's "MIP Envy" tome as he was leaving for research http://www.garlic.com/~lynn/2007d.html#email800920 in this post http://www.garlic.com/~lynn/2007d.html#17 which also has URL for slightly later version at microsoft research http://research.microsoft.com/~gray/papers/CritiqueOfIBM%27sCSResearch.doc as Jim was leaving, he was palming some amount of stuff on me ... like DBMS consulting for the IMS group (unrelated to work I did for the IMS group supporting channel extender), RDBMS consulting, and misc. other stuff ... misc. old references http://www.garlic.com/~lynn/2007.html#email801006 http://www.garlic.com/~lynn/2007.html#email801016 in this old post: http://www.garlic.com/~lynn/2007.html#1 from IBM jargon: MIP envy - n. The term, coined by Jim Gray in 1980, that began the Tandem Memos (q.v.). MIP envy is the coveting of other's facilities - not just the CPU power available to them, but also the languages, editors, debuggers, mail systems and networks. MIP envy is a term every programmer will understand, being another expression of the proverb The grass is always greener on the other side of the fence. ... snip ... Note that "MIP envy" wasn't directly start of "Tandem Memos". I had gotten blamed for online computer conferencing on the internal network in the late 70s and early 80s (folklore is that when executive committee was told about online computer conferencing and internal network, 5of6 wanted to fire me). "Tandem Memos" was more kicked-off by a trip report I wrote after visiting Jim at Tandem (this was after Jim had left IBM and had joined Tandem). from IBM Jargon: Tandem Memos - n. Something constructive but hard to control; a fresh of breath air (sic). That's another Tandem Memos. A phrase to worry middle management. It refers to the computer-based conference (widely distributed in 1981) in which many technical personnel expressed dissatisfaction with the tools available to them at that time, and also constructively criticised the way products were are developed. The memos are required reading for anyone with a serious interest in quality products. ... snip ... -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
