[email protected] (Joel C. Ewing) writes: > Having a few devices that supported dual case didn't necessarily make > it economically reasonable to adopt dual case. There was considerable > (more than a decade) overlap between use of card equipment and the > deployment of 3270 devices, and as already remarked, card punches > didn't support dual case, nor did the original 3277 model of 3270 in > 1971. It took another 8 or 9 years after introduction of the 3277 > before the first 3278 terminals with full dual case support became > available and much longer before all 3277's were phased out. There > was a strong economic motivation for the lowest common capability to > determine local standards. Our data center didn't totally phase out > the use of cards until sometime after 1985, after conversion to MVS, > and line printers with higher dual-case costs persisted for decades > after that. > > I'm not sure how early one could get dual case support for line > printers, but the most common high-speed production print technology > pretty much through the end of the 20th century were line printers > with print bands or print trains, and using dual-case bands or trains > reduced the number of repeated patterns and effectively cut print > speed in half, doubling the hardware cost of printing dual case. Laser > printers like the IBM 3800 which didn't have this problem were > available from the late 1970's, but they were very expensive and > supported the print volume of 5-10 line printers -- you had to have an > incredibly high print volume or an application that absolutely > demanded that print flexibility to cost justify two of them (so you > could continue production when one was down for extended maintenance). > > Now that relatively cheap slower laser printers with multi-font > support are ubiquitous, print band line printers are on the decline, > application development and data entry are no longer tied to punched > cards, and mono-case display terminals are long gone, dual-case > support is almost no-cost. That was not the case for decades, and > corporate culture (in the companies that are still in business) did > tend to frown on expenditures that were deemed avoidable and which > could not be cost justified. > > Existence of millions of lines of program source written with > mono-case conventions may continue to influence local coding > standards, but at least the hardware cost penalty of dual case is no > longer an overriding factor.
re: http://www.garlic.com/~lynn/2013b.html#52 Article for the boss: COBOL will outlive us all 1403 printer with TN ... had upper/lower case ... some of the principles of operation can be seen as 1403TN from cms script ... where the vertical bars on box diagrams don't quite connect. lots of cp67/cms documents were all from 1403 TN. as previously mentioned there was big difference between os/360 batch genre with punch cards and upper case only ... and the online interactive systems using terminals. The paradigm difference between online interacive and batch with punch cards ... also significantly cut the requirement for bulk print (mitigating the issue that TN with upper/lower only had half the lines/min of uppercase only). we had some hardware tweaks to 3277s that improved their human factors operation for interactive computing. when 3278s came out ... they had moved a lot of the electronics back into the (shared) controller (reducing the manufacturing costs) ... eliminating the ability to improve 3278 for interactive computer. we complained to the 3278 product admininstrator about the issues ... and eventually the response was that 3278s design point was but for "data entry" (aka basically online keypunching) ... not interactive computing. side-effect of moving electronics back into shared controller was it greatly increased protocol chatter over the coax (could be seen later in terminal emulation, 3277-emulation had three times the upload/download speed of 3278-emulation) and eliminated the ability to have quarter second (human interactive) response (this wasn't an issue for data entry and/or TSO ... which also wasn't designed for human interactive) past post with old data regarding 3277/3272 comparison with 3278/3274 for better than quarter second response for interactive computing http://www.garlic.com/~lynn/2001m.html#19 the comparisons were done in period when there was lots of activity showing the productivity improvement and cost/effectiveness of interactive computing and good response. The numbers are for direct channel attach controllers, SNA & other issues could further significantly degrade the human factor characteristics. 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 ... other posts in the thread: http://www.garlic.com/~lynn/2013b.html#43 Article for the boss: COBOL will outlive us all http://www.garlic.com/~lynn/2013b.html#45 Article for the boss: COBOL will outlive us all http://www.garlic.com/~lynn/2013b.html#51 Article for the boss: COBOL will outlive us all for other topic drift ... 1980, the Santa Teresa Lab (now silicon valley lab) was bursting at its seams and 300 people from the IMS group were being moved too offsite building. They were accustomed to local channel attached 3270s with vm370/cms ... and were being told that they would have remote 3270s (back to STL datacenter, remote 3270 controllers operated over 19.2 telco links) at the offsite building ... and in testing they found remote 3270s human factors totally intolerable. I got roped into writing the channel extender support to put local channel attached 3270s at the offsite building (using HYPERChannel for channel extenders). Part of the software was downloading the 3270 channel programs to the remote HYPERChannel "device adapter" (simulating mainframe channel). Preloading the channel programs to the remote box and executing them remotely with the controller significantly cut the latency ... and the users would see no difference between remote terminal and local terminal at STL. There was side-effect of the change that improved the throughput of the mainframes by 10-15%. The common strategy was to spread mixture of 3270 controllers and disk controllers across 16 available channels. Replacing the 3270 controllers with HYPERChannel adapter directly on real IBM channels ... significantly cut channel busy for doing 3270 operations (reducing channel busy contention with disk controlleres) ... aka the HYPERChannle box had significantly lower real channel busy than 3270 controllers for the same operation. recent posts mentioning FICON and HYPERChannel ... FICON is a layer that enormously cuts the throughput of the underlying FCS. Recently FICON had enhancements to download CCWs to the remote end (analogous to what I had done for HYPERChannel in 1980) that mitigates a little of the enormous reduction in FCS throughput that the FICON layer imposes. http://www.garlic.com/~lynn/2011b.html#58 Other early NSFNET backbone http://www.garlic.com/~lynn/2011n.html#34 Last Word on Dennis Ritchie http://www.garlic.com/~lynn/2012e.html#27 NASA unplugs their last mainframe http://www.garlic.com/~lynn/2012m.html#43 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012o.html#22 Assembler vs. COBOL--processing time, space needed http://www.garlic.com/~lynn/2012o.html#27 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012o.html#46 Random thoughts: Low power, High performance http://www.garlic.com/~lynn/2012p.html#1 3270 response & channel throughput http://www.garlic.com/~lynn/2012p.html#5 What is a Mainframe? -- 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
