From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 3 Jan 1999 19:32:38 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <76ogkm$7kl$1@teabag.demon.co.uk> References: <74kun5$mmq@netaxs.com> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915393652 nnrp-01:8570 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 20 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!newsfeed.uk.ibm.net!ibm.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <74kun5$mmq@netaxs.com>, hancock4@bbs.cpcn.com (Lisa or Jeff) writes: > I would be awfully surprised if anyone has a S/360 up and > running, unless they've invested an awful lot of time and > money. Just as an aside, I know this isn't a "home computing" anecdote, but a manufacturing company I worked for in my time off while studying used a S/360 to do all their invoicing, inventory, accounting and so on as late as about '87. They replaced the thing with an HP minicomputer and the transition was just awful. The new system was *so* much slower than the '360, the response time was horrible, it took about three times as long to do month-end stuff, and as far as the end-user was concerned the screen presentation was just hideous compared to the nice 3270 (or whatever it was that the '360 used for terminal I/O) forms. ISTR that the '360 CPU (can't remember which model) looked a lot like a large chest freezer. Chris. ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 4 Jan 1999 01:32:52 GMT Organization: Net Access BBS Lines: 6 Message-ID: <76p5o4$l8u@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newspump.monmouth.com!newspeer.monmouth.com!news-xfer.newsread.com!netaxs.com!newsread.com!netaxs.newsread.com!bbs.cpcn.com!root > ISTR that the '360 CPU (can't remember which model) looked a lot like > a large chest freezer. That sounds like a System/370, not S/360. Besides, mechanically a S/360 would be worn out by 1987 and cost a great deal to replace circuit cards. ###### From: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 4 Jan 1999 02:40:45 GMT Organization: The National Capital FreeNet Lines: 10 Message-ID: <76p9nd$rk@freenet-news.carleton.ca> References: <76p5o4$l8u@netaxs.com> Reply-To: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) NNTP-Posting-Host: freenet5.carleton.ca X-Given-Sender: ab528@freenet5.carleton.ca (Heinz W. Wiggeshoff) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!212.63.192.161.MISMATCH!newshub.bart.net!news.tele2.nl!newsfeed1.swip.net!swipnet!newshub.northeast.verio.net!newsserver.jvnc.net!xcski.com!freenet-news.carleton.ca!FreeNet.Carleton.CA!ab528 Lisa or Jeff (hancock4@bbs.cpcn.com) writes: >> ISTR that the '360 CPU (can't remember which model) looked a lot like >> a large chest freezer. > > That sounds like a System/370, not S/360. Besides, mechanically a > S/360 would be worn out by 1987 and cost a great deal to replace circuit > cards. Probably a 4331. The 4381 stood upright. ###### From: p.h.s.3@watdcs.uwaterloo.ca (phs3) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Mon, 04 Jan 1999 02:59:25 GMT Lines: 18 Message-ID: <76paqd$d92$1@winter.news.rcn.net> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> X-Trace: V9gJv7XUeBWGvPWRAPvJyETHnUvqaQChkVAwUU7B1/c= X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 4 Jan 1999 02:59:25 GMT X-Newsreader: News Xpress 2.01 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!howland.erols.net!master.news.rcn.net!the-smith-pc In article <76p9nd$rk@freenet-news.carleton.ca>, ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) wrote: > >Lisa or Jeff (hancock4@bbs.cpcn.com) writes: >>> ISTR that the '360 CPU (can't remember which model) looked a lot like >>> a large chest freezer. >> >> That sounds like a System/370, not S/360. Besides, mechanically a >> S/360 would be worn out by 1987 and cost a great deal to replace circuit >> cards. > > Probably a 4331. The 4381 stood upright. Or 4341 w/o CTCA, or 4321, no? ..phsiii Remove dots from userid portion of From: to reply. root@localhost ###### From: bbreynolds@aol.com (BBReynolds) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Lines: 15 NNTP-Posting-Host: ladder03.news.aol.com X-Admin: news@aol.com Date: 04 Jan 1999 03:34:00 GMT References: <76ogkm$7kl$1@teabag.demon.co.uk> Organization: AOL http://www.aol.com X-Newsreader: AOL Offline Reader Message-ID: <19990103223400.17693.00002015@ngol05.aol.com> Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!news.gtei.net!portc02.blue.aol.com!audrey03.news.aol.com!not-for-mail In article <76ogkm$7kl$1@teabag.demon.co.uk>, cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) writes: >ISTR that the '360 CPU (can't remember which model) looked a lot like >a large chest freezer. Probably a 4331 or 4361, not a true S/360...were there winken-blinken lights and a Selectric console??? -- Bruce B. Reynolds, Systems Consultant: Founder of Trailing Edge Technologies, Glenside PA and Niles IL: Sweeping Up Behind Data Processing Dinosaurs ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 4 Jan 1999 17:40:13 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <76qudt$67g$1@teabag.demon.co.uk> References: <76ogkm$7kl$1@teabag.demon.co.uk> <19990103223400.17693.00002015@ngol05.aol.com> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915472858 nnrp-12:3165 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 26 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!howland.erols.net!woodstock.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <19990103223400.17693.00002015@ngol05.aol.com>, bbreynolds@aol.com (BBReynolds) writes: > Probably a 4331 or 4361, not a true S/360...were there winken-blinken lights > and a Selectric console??? Blimey, that's pushing my memory! I wasn't actually in the computing department (it's a small company, there were only two people there) so I can't really remember much about the CPU installation other than it was a small one. I can remember the terminals better, if that helps; they were big buggers that weighed in at about 12 stone and looked a bit like a DEC VT100. The keyboard was also a hefty thing that made a loud "clunk" every time a key was pressed. The screen itself was forms based, and input field characters were separated with narrow vertical bars. To the right of the screen an extra column provided four or five "status lights" which were either block characters or minuses, with the legends "wait" etc etched onto the terminal. It used a twinax connection and was daisychained to the other devices. I don't know if remembering the details of the terminal might shed any light on the heart of the system. All I remember is that it didn't look like MVS or VM! (Oh, and occasionally between transactions, a funny status line appeared at the bottom of the screen where various fixed field, comma separated words would flicker on and off; this wasn't a normal 3270-style status line that I'm used to seeing with its "TIME X" and lightning-strike legends) Chris. ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 4 Jan 1999 17:57:13 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <76qvdp$67g$2@teabag.demon.co.uk> References: <76p5o4$l8u@netaxs.com> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915472859 nnrp-12:3165 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 37 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!news.idt.net!news.maxwell.syr.edu!woodstock.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <76p5o4$l8u@netaxs.com>, hancock4@bbs.cpcn.com (Lisa or Jeff) writes: > That sounds like a System/370, not S/360. Besides, mechanically a > S/360 would be worn out by 1987 and cost a great deal to replace circuit > cards. Could've been, although it's a small company and would have had a limited budget even for 2nd hand equipment. I assumed it wasn't a /370 as the only ones I've actually seen up close were water-cooled 3090 installations, which looked entirely different but I guess looks don't count for much (I should know better, being more familiar with DEC stuff, I know a VAX can be anything from a small desktop to a behemoth) My other assumption is that (as I said in another post) it didn't appear to be running VM or MVS, which I know aren't the only /370 OS', but I'd assumed that the others would have a similar "feel" to them; perhaps that may also be a mistake on my part since I was talking directly to the application using what I now suspect wasn't a 3270 connection afterall. My interest has really been piqued now, I'd be interested if anyone could shed any light on what I have so little information about! (I suppose I could always 'phone up the company and ask them, if anyone there remembers...) Going off on a slightly different tack, I have unrelated question to /360s which has been discussed to some extent in the NG in the past, but a comprehensive answer still seems to be missing (unless I just missed it!) That is, since I mentioned the VAX, "why isn't a VAX classed as a mainframe?" (Although people often refer to them as such, they're often quickly corrected on the matter in NGs such as this) I'd assumed it was something to do with physical size, but the CPU and overall installation of a VAX system can be larger than the a /360 or /370 site; I'd thought it was perhaps design concepts, but both beasts (the larger models anyway) both offer enormous I/O throughput in comparison with their CPU speeds, both have virtual memory, advanced batch-processing and time sharing. The only other things I can think of is that either it was a deliberate marketing decision on DEC's part, or that "only EBCDIC systems are mainframes." :) Any comments, anyone? Chris. ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 4 Jan 1999 17:58:57 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <76qvh1$67g$3@teabag.demon.co.uk> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <76paqd$d92$1@winter.news.rcn.net> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915472859 nnrp-12:3165 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 11 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!128.230.129.106!news.maxwell.syr.edu!woodstock.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <76paqd$d92$1@winter.news.rcn.net>, p.h.s.3@watdcs.uwaterloo.ca (phs3) writes: > In article <76p9nd$rk@freenet-news.carleton.ca>, ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) wrote: >> Probably a 4331. The 4381 stood upright. > > Or 4341 w/o CTCA, or 4321, no? Could someone expand on the details of the 4xxx series for this IBM ignoramus, please? :) (Will they run Linux? Even as a guest? :) Chris. ###### From: Bob Shair (courtesy) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 4 Jan 1999 18:46:17 GMT Organization: University of Illinois at Urbana-Champaign Lines: 33 Message-ID: <76r29p$18v$2@vixen.cso.uiuc.edu> References: <76ogkm$7kl$1@teabag.demon.co.uk> <19990103223400.17693.00002015@ngol05.aol.com> <76qudt$67g$1@teabag.demon.co.uk> NNTP-Posting-Host: delphi.itg.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Newsreader: TIN [UNIX 1.3 unoff BETA 970217; 000047148900 AIX 2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!128.174.5.49!vixen.cso.uiuc.edu!delphi.itg.uiuc.edu!not-for-mail Chris Hedley wrote: > In article <19990103223400.17693.00002015@ngol05.aol.com>, > bbreynolds@aol.com (BBReynolds) writes: > > Probably a 4331 or 4361, not a true S/360...were there winken-blinken lights > > and a Selectric console??? > Blimey, that's pushing my memory! I wasn't actually in the computing department > (it's a small company, there were only two people there) so I can't really > remember much about the CPU installation other than it was a small one. > I can remember the terminals better, if that helps; they were big buggers that > weighed in at about 12 stone and looked a bit like a DEC VT100. The keyboard > was also a hefty thing that made a loud "clunk" every time a key was pressed. > The screen itself was forms based, and input field characters were separated > with narrow vertical bars. To the right of the screen an extra column provided > four or five "status lights" which were either block characters or minuses, > with the legends "wait" etc etched onto the terminal. It used a twinax > connection and was daisychained to the other devices. > I don't know if remembering the details of the terminal might shed any light > on the heart of the system. All I remember is that it didn't look like MVS > or VM! (Oh, and occasionally between transactions, a funny status line appeared > at the bottom of the screen where various fixed field, comma separated words > would flicker on and off; this wasn't a normal 3270-style status line that > I'm used to seeing with its "TIME X" and lightning-strike legends) This sounds like an IBM System/38 (or perhaps its replacement, the AS/400) rather than a member of the S/360, S/370, S/390 series. -- Bob Shair rmshair@delphi.itg.uiuc.edu Open Systems Specialist Champaign, Illinois /* Opinions expressed are mine... go get your own! */ ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 5 Jan 1999 02:42:17 GMT Organization: Net Access BBS Lines: 25 Message-ID: <76ru69$6jc@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!news.maxwell.syr.edu!news-xfer.newsread.com!news-toy.newsread.com!netaxs.com!newsread.com!newshog.newsread.com!netaxs.newsread.com!bbs.cpcn.com!root > Could've been, although it's a small company and would have had a limited > budget even for 2nd hand equipment. I assumed it wasn't a /370 as the only > ones I've actually seen up close were water-cooled 3090 installations, which > looked entirely different but I guess looks don't count for much (I should S/370, like S/360, came in a lot of different sizes. The 4300 series were smaller computers, as someone described, one model was the size of a freezer. The 3090 were much bigger machines. > from a small desktop to a behemoth) My other assumption is that (as I said > in another post) it didn't appear to be running VM or MVS, which I know aren't > the only /370 OS', but I'd assumed that the others would have a similar "feel" > to them; perhaps that may also be a mistake on my part since I was talking > directly to the application using what I now suspect wasn't a 3270 connection > afterall. It was likely it was running DOS/VSE, which was the smaller scale operating system. As to whether the DEC was a mainframe, there really isn't any hard and fast definition of a "mainframe". Actually, originally all computers were "mainframes". The split came when DEC (and others) developed "mini" computers. ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 5 Jan 1999 02:53:22 GMT Organization: Net Access BBS Lines: 9 Message-ID: <76rur2$8ii@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!212.63.192.161.MISMATCH!newshub.bart.net!news.tele2.nl!newsfeed1.swip.net!swipnet!newshub.northeast.verio.net!news-xfer.newsread.com!netaxs.com!newsread.com!netaxs.newsread.com!bbs.cpcn.com!root > Could someone expand on the details of the 4xxx series for this IBM > ignoramus, please? :) (Will they run Linux? Even as a guest? :) All were part of the IBM S/370 family. The S/370 was the next generation of S/360, which were a universal series of computers intended to use a common architecture for both low and high end machines, and scientific and commercial. The 4xxx series were lower end machines. ###### From: jeffreyb@gwis2.circ.gwu.edu Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Organization: The George Washington University Lines: 56 Message-ID: <76uod9$9im@gwis2.circ.gwu.edu> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <76paqd$d92$1@winter.news.rcn.net> <76qvh1$67g$3@teabag.demon.co.uk> Date: 5 Jan 1999 23:22:01 -0500 NNTP-Posting-Host: 128.164.127.141 X-Trace: fozzy.nit.gwu.edu 915596359 128.164.127.141 (Tue, 05 Jan 1999 23:19:19 EDT) NNTP-Posting-Date: Tue, 05 Jan 1999 23:19:19 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!chippy.visi.com!news-out.visi.com!cam-news-hub1.bbnplanet.com!washdc3-snh1!cpk-news-feed3.bbnplanet.com!news.gtei.net!fozzy.nit.gwu.edu!not-for-mail In article <76qvh1$67g$3@teabag.demon.co.uk>, Chris Hedley wrote: > >Could someone expand on the details of the 4xxx series for this IBM >ignoramus, please? :) (Will they run Linux? Even as a guest? :) The 43xx series was a series of low-cost mainframes [for very high values of "low"] intended for small to medium sized institutions. Their design and architecture was quite different from the mainstream 308X and 3090 series. The original design of the 4341 was done with DOS/VSE in mind, but I think by the time IBM came out with the 4381, they included special assists for VM. All 43xx were air-cooled systems. The 4341 was sort of a desk height system, while the 4381 was full-height, taller and wider than a refrigerator. The most powerful 4381s were dual-processor systems, with up to 32 megabytes of memory (or possibly 64 - most of my information is before the introduction of the very last model of 4381, which could support the ESA architecture). Unix-wise, the 43xx series could run as guests under VM the IX/370 operating system, and possibly also UTS. I think they were too far out of the mainstream to be able to run any Unix variant native. Lifted from IBM's "A Guide to the 4381 Processor", Sep 1985: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Performance of a 4341 Model Group 12: Up to 1.15 times 4331 Model Group 2 for commercial Up to 1.07 times 4331 Model Group 2 for scientific. Performance of a 4381 Model Group 1,2,3: (model group 3 was dual-processor) 1.4 and 1.6 times the 4341 Model Group 2 for commercial and up to 1.7 times the 4341 Model Group 2 for scientific for the 4381 Model Group 1 for System/370 mode. 1.7 to 2.3 times the 4341 Model Group 2 for commercial and 2.4 to 3 times the 4341 Model Group 2 for scientific for the 4381 Model Group 2 for System/370 mode. 1.7 times the 4381 Model Group 2 for commercial and up to 1.9 times the 4381 Model Group 2 for scientific. Memory: 4341 Model Group 12 could have up to 16M virtual storage. 4381 could have up to 2GB virtual storage. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- We got rid of our 4381 just over a year ago. I talked to one of the IBM CEs during the de-installation, and he mentioned that there was a nearby site in Maryland still using a 4341. Had I but known, I'd have offered them an upgrade. Thanks, that was a fun trip down memory lane! --Jeffrey Boulier ###### From: jeffreyb@gwis2.circ.gwu.edu Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Organization: The George Washington University Lines: 30 Message-ID: <76upvv$aar@gwis2.circ.gwu.edu> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36918a48.0@news.destek.net> Date: 5 Jan 1999 23:49:03 -0500 NNTP-Posting-Host: 128.164.127.141 X-Trace: fozzy.nit.gwu.edu 915597982 128.164.127.141 (Tue, 05 Jan 1999 23:46:22 EDT) NNTP-Posting-Date: Tue, 05 Jan 1999 23:46:22 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!4.1.16.34!cpk-news-hub1.bbnplanet.com!cpk-news-feed3.bbnplanet.com!news.gtei.net!fozzy.nit.gwu.edu!not-for-mail In article <36918a48.0@news.destek.net>, Dave Cherkus wrote: > [about developing mainframe unix under VM] >Alas, most of this work has gone the way of the dodo birds. But I >wonder if some day someone doesn't try to revive mainframe UNIX. Some >of the recent mainframe-class hardware is pretty impressive by any >standard, excepting of course cost, but all you need to do is >sell one or two big mainframes and you can cover the cost of the >whole shooting match. As far as I know, the only Unix still being actively developed and sold for mainframe platforms is Fujitsu's Amdahl division's UTS. I believe it's also the only "foreign" operating system that IBM officially acknowledges as running on mainframes. Right now the trend is for Unix vendors to get their boxes to look more like mainframes. Sun has something called "Dynamic System Domains" for its Ultra Enterprise 10000 ("Starfire") systems. These are vaguely like LPARs, except that everything is hardware dependent and only atomic to the system board level. Compaq/Digital is working something called "Wildfire" which will allow running multiple, clustered instances of Digital Unix on a single system. They're a bit behind, though, and it seems the major goal is to do an end-run around Digital Unix's troubles coping on systems with large numbers of processors. --Jeffrey Boulier -- Senior Systems Programmer George Washington University / SCT Corp. ###### From: cherkus@unimaster.com (Dave Cherkus) Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <76paqd$d92$1@winter.news.rcn.net> <76qvh1$67g$3@teabag.demon.co.uk> <76uod9$9im@gwis2.circ.gwu.edu> Lines: 16 X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] NNTP-Posting-Host: homerun.unimaster.com Message-ID: <36944954.0@news.destek.net> Date: 7 Jan 1999 00:42:44 -0500 X-Trace: 7 Jan 1999 00:42:44 -0500, homerun.unimaster.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!192.156.97.247!news.destek.net!not-for-mail As you mention, the last 4381 supported ESA, so it could run AIX/ESA, which IBM marketed for a few years before tossing in the towel. It was based on OSF/1 and could run native or as a guest of VM and was SMP capable. Before this, IBM marketed AIX/370, which ran only as a guest of VM but it ran on most anything that was a 370 system. Before this came IX/370 and before this was AT&T's use of UNIX (I think this code was the predecessor to the first UTS - IBM wasn't interested in UNIX then, so AT&T moved to Amdahl) ObFolklore: AIX/370 on a 3090 was used by Intel to lay out the 486 design onto silicon. I also know Hitachi ported OSF/1 to their S/390 mainframe clone. I don't know if it is still being marketed, but I kinda doubt it. -- Dave Cherkus ------- UniMaster, Inc. ------ Contract Software Development Specialties: UNIX Internals/Kernel TCP/IP Alpha Clusters Performance ISDN Email: cherkus@UniMaster.COM When the music's over, turn out the lights! ###### From: cherkus@unimaster.com (Dave Cherkus) Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36918a48.0@news.destek.net> <76upvv$aar@gwis2.circ.gwu.edu> Lines: 29 X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] NNTP-Posting-Host: homerun.unimaster.com Message-ID: <36944cdd.0@news.destek.net> Date: 7 Jan 1999 00:57:49 -0500 X-Trace: 7 Jan 1999 00:57:49 -0500, homerun.unimaster.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!192.156.97.247!news.destek.net!not-for-mail jeffreyb@gwis2.circ.gwu.edu wrote: : Compaq/Digital is working something called "Wildfire" which : will allow running multiple, clustered instances of Digital Unix on a : single system. They're a bit behind, though, and it seems the major goal : is to do an end-run around Digital Unix's troubles coping on systems with : large numbers of processors. Cough. Digital UNIX has no problem dealing with large number of processors. Right now, it's running on hardware that's a step or so behind most of the gang on the high end. When this hardware came out, it set world records. Unfortunately for CPQ/DEC/whatever, the competition stole a day's march on them. I'm not sure how you could make this statement anyhow. There really isn't a lot of data out there to make such a statement. Companies with large SMPs publish the absolute numbers of the full-blown system, but don't tend to publish curves showing the incremental game of adding each CPU, so you don't know much about anyone's ability to deal with a large number of processors. I'd even settle for seeing the curve showing the gain for each 2 or 4 CPUs. When you do see such numbers, they tend to be for scientific workloads, which sit in the cache so they don't stress the backplane, instead of commercial workoads that don't benefit from CPU caches. -- Dave Cherkus ------- UniMaster, Inc. ------ Contract Software Development Specialties: UNIX Internals/Kernel TCP/IP Alpha Clusters Performance ISDN Email: cherkus@UniMaster.COM When the music's over, turn out the lights! ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 7 Jan 1999 04:28:28 GMT Organization: Net Access BBS Lines: 39 Message-ID: <771d5c$bu5@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!newspeer1.nac.net!news-xfer.newsread.com!netaxs.com!newsread.com!netaxs.newsread.com!bbs.cpcn.com!root > The 43xx series was a series of low-cost mainframes [for very high values > of "low"] intended for small to medium sized institutions. Their design > and architecture was quite different from the mainstream 308X and 3090 > series. The _physical_ design and architecture was different, but it is important to remember that the _logical_ design was uniform. We take it for granted today--a program written for one model of PC can run on a higher level model. Before S/360, small computers had different logical organizations than large ones. A customer who outgrew his small machine had to convert all his programming to run on a big machine. Manufacturers had different lines of periperhals all custom built for various models. S/360 made everything uniform. The CPUs varied internally, low end ones were slower and cheaper, but all could run the same programs, and that was a major advantage. The same peripherals could be used on the whole line of machines. Remember in the early PC days how a separate chip was required for optimum floating point (scientific) calculations? In the early days computers were physically different depending on the intended application. S/360 supported both scientific and commercial oriented instruction sets, again eliminating the need for separate machines. Again, we take the genius of S/360 design since hardware is so damn cheap and memory is measured in megabytes. But in the original S/360 memory was still meaures in kilobytes, and not many at that. Low end machines did not have a lot of excess room for address space. The S/360 address can accomodate up to 16 Meg. If every memory instruction had to carry that long address space, it would be very wasteful. But they developed the register+displacement scheme that worked out well on machines of all sizes. (Someone probably can explain how this worked and saved space better than I can.) ###### From: "Gareth Alun Evans" Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Thu, 7 Jan 1999 15:07:21 -0000 Message-ID: <915721923.28388.0.nnrp-07.9e98250c@news.demon.co.uk> References: <771d5c$bu5@netaxs.com> NNTP-Posting-Host: cemetery.demon.co.uk X-NNTP-Posting-Host: cemetery.demon.co.uk:158.152.37.12 X-Trace: news.demon.co.uk 915721923 nnrp-07:28388 NO-IDENT cemetery.demon.co.uk:158.152.37.12 X-Complaints-To: abuse@demon.net X-Newsreader: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Lines: 43 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!howland.erols.net!woodstock.news.demon.net!demon!news.demon.co.uk!demon!cemetery.demon.co.uk!not-for-mail Mark Forsyth wrote in message ... >In the early to mid '70s I worked with Honeywell gear (H8200,H800/1800,H200,etc) The >8200 was a big sod with as muich as 64k of memory. You usually kept memory usage >as low as possible because of cost. About $1,000,000 /meg. Yes a million bucks a >megabyte. My first job in 1973 involved assembly language on a 16K Byte PDP11/10. My salary was £1300 pa. An 8k increment of memory cost, ISTR, about £1500. So, in those days based upon the relative cost considerations, it was considered to be an advantage to be able to code your programs so as to shave off a byte here and there. One thing I remember doing was having a dual entry subroutine, where the second word of the first instruction was the second entry point!...... SUBR : MOV #5046, -(SP) SUBR2 = SUBR + 2 so JSR PC,SUBR pushed the value 5046 (octal and non-zero) onto the stack. and JSR PC,SUBR2 pushed the value 0 onto the stack, because 5046 is the op code for CLR -(SP). Unless you're in the realms of restricted embedded processors, such techniques should be banned upon pain of death today where the bulk of software cost is in maintenance! Gareth Evans, Out And About Systems Ltd Software contractors for Real-time, Telecommunications and ATE ###### From: dcurry@silo.csci.unt.edu (David Mason Curry) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 7 Jan 1999 15:52:41 GMT Organization: University of North Texas Lines: 37 Message-ID: <772l89$9aq@hermes.acs.unt.edu> References: <771d5c$bu5@netaxs.com> <915721923.28388.0.nnrp-07.9e98250c@news.demon.co.uk> NNTP-Posting-Host: silo.csci.unt.edu X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!4.1.16.34!cpk-news-hub1.bbnplanet.com!news.gtei.net!cs.utexas.edu!news.unt.edu!silo.csci.unt.edu!dcurry Gareth Alun Evans (gareth@cemetery.demon.co.uk) wrote: : One thing I remember doing was having a dual entry subroutine, where the : second word of the first instruction was the second entry point!...... : SUBR : MOV #5046, -(SP) : SUBR2 = SUBR + 2 : so JSR PC,SUBR pushed the value 5046 (octal and non-zero) : onto the stack. and JSR PC,SUBR2 pushed the value 0 onto : the stack, because 5046 is the op code for CLR -(SP). : Unless you're in the realms of restricted embedded processors, : such techniques should be banned upon pain of death today where : the bulk of software cost is in maintenance! Unfortunately, this view is best for business... but it sure does make computing boring! Embedded systems are about the only thing left, but at least in my field, legacy systems are the only ones needing any savvy. For newer systems, the average CPU/memory load is usually only 5%-25% with sloppy programming and all. BTW, my field is avionics software. I long for the old days :-( : Gareth Evans, : Out And About Systems Ltd : Software contractors for Real-time, Telecommunications and ATE Cheers, David Curry ###### From: mforsyth@bigpond.com (Mark Forsyth) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 References: <771d5c$bu5@netaxs.com> Reply-To: mforsyth@bigpond.com Message-ID: X-Newsreader: slrn (0.9.4.3 UNIX) Date: Thu, 7 Jan 1999 17:13:58 +1059 NNTP-Posting-Host: 203.40.56.106 X-Trace: 7 Jan 1999 16:12:15 +1000, 203.40.56.106 Lines: 24 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.idt.net!logbridge.uoregon.edu!newsfeed.dacom.co.kr!intgwlon.nntp.telstra.net!nsw.nntp.telstra.net!139.134.5.33!mforsyth On 7 Jan 1999 04:28:28 GMT, Lisa or Jeff wrote: > [deletia] > > >Again, we take the genius of S/360 design since hardware is so damn >cheap and memory is measured in megabytes. But in the original S/360 >memory was still meaures in kilobytes, and not many at that. Low >end machines did not have a lot of excess room for address space. The >S/360 address can accomodate up to 16 Meg. If every memory instruction In the early to mid '70s I worked with Honeywell gear (H8200,H800/1800,H200,etc) The 8200 was a big sod with as muich as 64k of memory. You usually kept memory usage as low as possible because of cost. About $1,000,000 /meg. Yes a million bucks a megabyte. Mark F... >had to carry that long address space, it would be very wasteful. But >they developed the register+displacement scheme that worked out well >on machines of all sizes. (Someone probably can explain how this worked >and saved space better than I can.) ###### From: jnickelsen@acm.org (Juergen Nickelsen) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Thu, 7 Jan 1999 20:17:12 +0100 Organization: [Posted via] Interactive Networx Lines: 12 Message-ID: <1dl8e9h.1p52sfa13fdvnkN@n35-14.berlin.snafu.de> References: <74kun5$mmq@netaxs.com> <76ogkm$7kl$1@teabag.demon.co.uk> <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <76paqd$d92$1@winter.news.rcn.net> <76qvh1$67g$3@teabag.demon.co.uk> <76uod9$9im@gwis2.circ.gwu.edu> NNTP-Posting-Host: n35-14.berlin.snafu.de User-Agent: MacSOUP/2.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!howland.erols.net!newsfeed.nacamar.de!news-hh.maz.net!unlisys!news.snafu.de!jnickelsen wrote: > We got rid of our 4381 just over a year ago. The CS department of the Technical University of Berlin, Germany, still has a 4381 running (tubvm.cs.tu-berlin.de, also DB0TUI11.BITNET). When I just looked, I still got a logon screen, but my account seems to have expired. On the other hand, a mailing list I am on that was hosted by this machine has already been moved elsewhere. -- Juergen Nickelsen ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 08 Jan 1999 08:55:26 -0800 Organization: Wheeler&Wheeler Message-ID: References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <76paqd$d92$1@winter.news.rcn.net> <76qvh1$67g$3@teabag.demon.co.uk> <76uod9$9im@gwis2.circ.gwu.edu> <36944954.0@news.destek.net> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-19.garlic.com X-Newsreader: Gnus v5.6.45/Emacs 20.3 Lines: 20 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news-feed.inet.tele.dk!bofh.vszbr.cz!dispose.news.demon.net!demon!rill.news.pipex.net!pipex!ams.news.uu.net!uunet!in4.uu.net!bulb.garlic.com!not-for-mail I think it was somebody at Princeton that did a port of Unix to 370. There were two people in IBM that tried to hire him when he graduated ... but were not able to get authorization. Amdahl hired him and produced gold (aka Au, amdahl unix) which became UTS. AT&T & IBM had an effort that had unix running on top a modified TSS/370 kernel. I believe that the AT&T and Amdhal efforts were pretty much unrelated. AIX/370 was a Locus port that included AIX/PS2 in the package. About 85/86, at one of the science centers, IBM had a project to port BSD to 370 ... but part way thru the activity ... the effort got redirected to porting BSD to the IBM PC/RT. -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ###### From: Dennis Ritchie Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Sat, 09 Jan 1999 04:15:16 +0000 Organization: Bell Labs, Lucent Technologies Lines: 26 Message-ID: <3696D7D3.3E9A@bell-labs.com> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <76paqd$d92$1@winter.news.rcn.net> <76qvh1$67g$3@teabag.demon.co.uk> <76uod9$9im@gwis2.circ.gwu.edu> <36944954.0@news.destek.net> Reply-To: dmr@bell-labs.com NNTP-Posting-Host: cebu.cs.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.shore.net!uunet!in4.uu.net!nntphub.cb.lucent.com!news Anne & Lynn Wheeler wrote: > > I think it was somebody at Princeton that did a port of Unix to > 370. There were two people in IBM that tried to hire him when he > graduated ... but were not able to get authorization. Amdahl hired him > and produced gold (aka Au, amdahl unix) which became UTS. > Your're thinking of Tom Lyon, I imagine. The Princeton work was demonstrable, though incomplete, yet quite fascinating. Our group hired Tom over the summer during which much of our work on the Interdata 8/32 was made real. > AT&T & IBM had an effort that had unix running on top a modified > TSS/370 kernel. It was more than "an effort," it was the standard development environment for the 5ESS CO switch for quite a few years starting around 1982. Quoting from a 1984 paper, Typical operational parameters of an IBM 3033AP are 150 simultaneous users (upwards of 200 have been observed) 600 active processes, 90% CPU usage on both processors, and 10-20% usage of the I/O channels. Dennis ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 9 Jan 1999 10:37:18 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <777bgu$vtu$1@teabag.demon.co.uk> References: <76ogkm$7kl$1@teabag.demon.co.uk> <19990103223400.17693.00002015@ngol05.aol.com> <76qudt$67g$1@teabag.demon.co.uk> <76r29p$18v$2@vixen.cso.uiuc.edu> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915879661 nnrp-06:1017 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 9 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!btnet-peer!btnet!dispose.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <76r29p$18v$2@vixen.cso.uiuc.edu>, Bob Shair (courtesy) writes: > This sounds like an IBM System/38 (or perhaps its replacement, the AS/400) > rather than a member of the S/360, S/370, S/390 series. I suppose it could've been, I'd never really considered that. I must try to find someone who might be able to remember! Chris. ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 9 Jan 1999 10:42:20 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <777bqc$vtu$2@teabag.demon.co.uk> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <76paqd$d92$1@winter.news.rcn.net> <76qvh1$67g$3@teabag.demon.co.uk> <76uod9$9im@gwis2.circ.gwu.edu> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915879661 nnrp-06:1017 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 31 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!btnet-peer!btnet!dispose.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <76uod9$9im@gwis2.circ.gwu.edu>, jeffreyb@gwis2.circ.gwu.edu writes: > The 43xx series was a series of low-cost mainframes [for very high values > of "low"] intended for small to medium sized institutions. Their design > and architecture was quite different from the mainstream 308X and 3090 > series. The original design of the 4341 was done with DOS/VSE in mind, but > I think by the time IBM came out with the 4381, they included special > assists for VM. All 43xx were air-cooled systems. The 4341 was sort of a > desk height system, while the 4381 was full-height, taller and wider than > a refrigerator. The most powerful 4381s were dual-processor systems, with > up to 32 megabytes of memory (or possibly 64 - most of my information is > before the introduction of the very last model of 4381, which could > support the ESA architecture). Thanks, this all makes interesting reading. Talking of memory, ISTR that the "biggest" 3090s of one of my previous employers had 32MB of core, except for the VM-based development/test system which had an additional 32MB (I can't remember the term for this extra memory, but it wasn't accessible in the same way that the main core was, for some reason) > Unix-wise, the 43xx series could run as guests under VM the IX/370 > operating system, and possibly also UTS. I think they were too far out of > the mainstream to be able to run any Unix variant native. I was only kidding about the Linux bit, although this also seems to have spawned an interesting subthread. I'd always assumed that Unix on IBM mainframes would've been an awkward pairing since Unix likes to use data-streams and, from what I understand, the hardware is more into block-transfers. Chris. ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 9 Jan 1999 11:07:08 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <777d8s$vtu$3@teabag.demon.co.uk> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36918a48.0@news.destek.net> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915883304 nnrp-04:24048 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 109 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!btnet-peer!btnet!dispose.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <36918a48.0@news.destek.net>, cherkus@unimaster.com (Dave Cherkus) writes: > In theory it can be done. Various UNIXes other than linux have run on > IBM mainframes and some still do. AT&T System V, various now-retired > IBM products and Hitachi with an OSF/1 variant come to mind. So, with > sufficient interest there is no reason it can't happen. > > I saw a passing rumour that some IBM employee was working on Linux on > S/3xx systems after hours as a hobby but never saw a confirmation of it. There're always rumours going around, but I guess that there's often some degree of truth to them; that's one hell of a "spare time project" for one person, though! > GCC has support for S/3xx, but I was told a few years ago that it had > some issues. The various UNIXes I worked with had commercial > compilers. So this might need work. Then, you'd have the usual > machine-dependent things to work on (like paging, fault handling, > interrupt handlers, etc.) then the whole world of writing device > support for mainframe disks, terminals, etc. I can imagine doing the interrupts and stuff would be a major headache, but I was under the impression that as far as device-drivers went, the nature of the data-channels and intelligent controllers tended to "hide" the dynamics of the remote hardware to a large extent. One analogy I've read a few times, which I've no doubt is very superficial and probably not at all accurate, is that IBM channels are similar in operation to how SCSI works. Sorry if I'm sounding a complete newby here, but since using IBM "big iron" as an end-user many years ago, I've been intrigued by "what makes it tick," although finding a comprehensive answer in one place (ie reading up in books, asking colleagues etc) seems to be difficult. Perhaps I'm just setting my sights too high, since there's obviously a lot to take in! My colleagues gave me vague inklings about how parts of the system worked, although I was surprised that, culturally, people tended not to get at all involved with the mechanics of what was going on outside of their own "domain." > Suffice it to say you'd > want to think a lot about which devices were worth the effort of > supporting, since many of them are culturally incompatible with the > UNIX way of doing things. Is this the data-stream vs. block-mode way of doing things that I mentioned in another post? > To bootstrap, you could build a linux kernel and its ramdisk image, get > it loaded into the mainframe's memory and let it rip. Based on what I > remember from working on mainframe UNIX, you'd want to build an image > using a cross-development environment (in our case it was an earlier > version of mainframe UNIX but in your case it'd be a standard linux > environment), then use VM/CMS with TCP/IP to pull the image from UNIX > into the VM world. At this point, you'd have an image formatted as a > set of 80 column virtual cards in this VM/CMS account. Then, you'd > send the image from this account to the virtual card reader of second > account. Then, you'd log into that second account, and type a command > that meant "please boot my virtual card reader". This would load the > image into memory, and then it's off to the races. I'd always wondered how one got VM to boot another image, so this info is also welcome. I know it sounds quite nasty having to use a "virtual card reader" and so forth to shift data around, although I know it works quite well in practice (this is how we transferred data and ran jobs [in both directions] between our 3090s and Unix minis, the latter of which were fitted with SDLC cards; the mail interface between Uniplex/UUCP on Unix and VISTA on MVS was quite an interesting one!) > From what I recall, this wasn't a bad development environment. The > image had a built-in debugger fairly early on in the development cycle > that was quite good. Before this was ready, the native facilities were > good enough to figure out where your virtual machine crashed or where > it was hung. It was a lot nicer than trying to debug UNIX on bare > metal (i.e. what Linus got to do a lot of very early in his career). > It was also kinda fun to see one machine (a 3090 mainframe) running > over a hundred different UNIX kernels in various states of being > debugged. Using virtual channels and the channel-to-channel driver, > you could hook them together in countless network topologies. It made > for fairly simple ways to do things that are costly to do with real > hardware, such as testing routing protocols. I'd love to have been involved in this sort of environment, it sounds a wonderful way of working! Sadly, these days, hardware is so cheap (at the PC-server end of things, anyway) that to test a new environment I tend to just hook-up an unused PC to the network and use that. Nowhere near as elegant or as easy to debug. It's a shame that none of the Unices out there have a VM-style capability, as (on the face of it) there's enough already lurking in the kernel to make this comparatively straightforward (no I'm not volunteering to do it! I'm sure that it'd immediately turn out to be nowhere near as "comparatively straightforward" as I assume at the moment. :) > Alas, most of this work has gone the way of the dodo birds. But I > wonder if some day someone doesn't try to revive mainframe UNIX. Some > of the recent mainframe-class hardware is pretty impressive by any > standard, excepting of course cost, but all you need to do is > sell one or two big mainframes and you can cover the cost of the > whole shooting match. It's a shame really, although I understand that Amdahl are still pushing UTS. Just as an aside, I'd wondered what Unix would look like from a 3270 session, so I x3270'd to a VM system and telnetted back to the originating Unix one. It was certainly quite "different," although by no means as unusable as I'd have expected. That's probably just showing how out-of-date I am, though, as I understand that IBM have supported graphics terminals for their mainframe hardware for years now (although someone once claimed that they still used 3270 as the underlying protocol!) Chris. ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 9 Jan 1999 11:08:40 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <777dbo$vtu$4@teabag.demon.co.uk> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36918a48.0@news.destek.net> <76upvv$aar@gwis2.circ.gwu.edu> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915883304 nnrp-04:24048 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 12 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.maxwell.syr.edu!woodstock.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <76upvv$aar@gwis2.circ.gwu.edu>, jeffreyb@gwis2.circ.gwu.edu writes: > board level. Compaq/Digital is working something called "Wildfire" which > will allow running multiple, clustered instances of Digital Unix on a > single system. Didn't Digital work on something similar for the Vax platform in the early to mid '80s? I'm sure I heard about an attempted enhancement to the CPU to allow it to run a mixture of VMS and Ultrix sessions on the same box. Chris. ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 9 Jan 1999 11:33:54 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <777er2$vtu$6@teabag.demon.co.uk> References: <76ru69$6jc@netaxs.com> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915883305 nnrp-04:24048 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 28 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!woodstock.news.demon.net!demon!dispose.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <76ru69$6jc@netaxs.com>, hancock4@bbs.cpcn.com (Lisa or Jeff) writes: > S/370, like S/360, came in a lot of different sizes. The 4300 series were > smaller computers, as someone described, one model was the size of a > freezer. Something a person could fit in their garage if they so wanted, then. :) > The 3090 were much bigger machines. I've encountered some face-to-face, so I know what you mean. There were various facetious comments about engineers "getting lost" inside them and never being seen again! > It was likely it was running DOS/VSE, which was the smaller scale operating > system. That's one that I know *absolutely nothing* about, as opposed to MVS and VM, where I just know very little! > As to whether the DEC was a mainframe, there really isn't any hard > and fast definition of a "mainframe". Actually, originally all > computers were "mainframes". The split came when DEC (and others) > developed "mini" computers. Probably DEC Marketing's last jab at doing something useful, I suppose... Chris. ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 9 Jan 1999 11:35:04 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <777et8$vtu$7@teabag.demon.co.uk> References: <76rur2$8ii@netaxs.com> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 915883306 nnrp-04:24048 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 13 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.maxwell.syr.edu!diablo.theplanet.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <76rur2$8ii@netaxs.com>, hancock4@bbs.cpcn.com (Lisa or Jeff) writes: > All were part of the IBM S/370 family. The S/370 was the next generation > of S/360, which were a universal series of computers intended to use a > common architecture for both low and high end machines, and scientific > and commercial. > > The 4xxx series were lower end machines. Thanks for pointing that out. I understand that the S/370 is an entirely different animal to the S/360 when it comes to design concepts etc. Chris. ###### From: cherkus@unimaster.com (Dave Cherkus) Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> Lines: 235 X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] NNTP-Posting-Host: homerun.unimaster.com Message-ID: <36978ea0.0@news.destek.net> Date: 9 Jan 1999 12:15:12 -0500 X-Trace: 9 Jan 1999 12:15:12 -0500, homerun.unimaster.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newspump.monmouth.com!newspeer.monmouth.com!newsfeed.cwix.com!192.156.97.247!news.destek.net!not-for-mail Keep in mind this is pipe dreaming. I'm not proposing anyone go out and bring up Linux on a S/3xx, but it doesn't hurt to talk about it - this is alt.folklore.computers after all! Chris Hedley (cbh@REMOVE_THIS.teabag.demon.co.uk) wrote: > cherkus@unimaster.com (Dave Cherkus) writes: > > I saw a passing rumour that some IBM employee was working on Linux on > > S/3xx systems after hours as a hobby but never saw a confirmation of it. > > There're always rumours going around, but I guess that there's often > some degree of truth to them; that's one hell of a "spare time project" > for one person, though! As was Linux itself, in the early days! Linus acknowledges the benefits gained from being able to leverage the AT&T design by use of Maury Bach's textbook, as well as the ability to use the GNU tools, but in essence it was a one-man show early on. A S/3xx hacker would have the benefit of Linus's efforts, and by use of S/3xx he'd have the benefit of a system with an extremely complete documentation set and a solid set of builtin tools (i.e. CP and CMS). I've done 'bare iron' Intel hacking in the past, and it's no fun. One disadvantage of an attempt to bring up the current Linux would be that the user-mode programs tend to use a lot of the full system call set, so you'd have to have a fair amount of the kernel running before you could use many of the programs. Things like signal handling and the mmap()/shm*() calls need machine dependent code and get in the way of early bootstrap efforts. > > GCC has support for S/3xx, but I was told a few years ago that it had > > some issues. The various UNIXes I worked with had commercial > > compilers. So this might need work. Then, you'd have the usual > > machine-dependent things to work on (like paging, fault handling, > > interrupt handlers, etc.) then the whole world of writing device > > support for mainframe disks, terminals, etc. > > I can imagine doing the interrupts and stuff would be a major headache, > but I was under the impression that as far as device-drivers went, the > nature of the data-channels and intelligent controllers tended to "hide" > the dynamics of the remote hardware to a large extent. One analogy I've > read a few times, which I've no doubt is very superficial and probably > not at all accurate, is that IBM channels are similar in operation to > how SCSI works. Sorry, but this too big a stretch. In particular, the programming model presented to the operating system programmer is totally different and inreconcilable (but read on)... > Sorry if I'm sounding a complete newby here, but since using IBM "big > iron" as an end-user many years ago, I've been intrigued by "what makes > it tick," although finding a comprehensive answer in one place (ie reading > up in books, asking colleagues etc) seems to be difficult. Perhaps I'm > just setting my sights too high, since there's obviously a lot to take > in! My colleagues gave me vague inklings about how parts of the system > worked, although I was surprised that, culturally, people tended not to > get at all involved with the mechanics of what was going on outside of > their own "domain." My knowledge has faded, but here's how I'd describe what is involved. It's also overly simplified but hey, I haven't looked at the details of this in 8 years or so. Corrections are invited. To do I/O on a S/3xx, one codes a short list of instructions known as channel control words (CCWs). Then, one uses the SIO instruction (Start IO) that points at the list of CCWs. The SIO instruction also has the address of the device that will perform the IO. It is these things (the SIO instruction and the CCWs) that are standardized and hide the details of how the device will actually perform the IO. Because they are standardized, the operating system can trap whenever it sees a SIO instruction and rewrite the CCWs to do IO to/from different main memory addresses and IO device addresses. This is more or less how VM virtualizes IO access. Also, because of standard formats, the CPU can offload the processing of these CCWs to outboard processors. This is one of the main reasons why mainframe types say their systems are better at doing IO, and why they say you can get by with less powerful CPUs on a mainframe class system. One of the things that I've forgotten the details of is that the IO 'program' (i.e. list of CCWs) can be run in a non-blocking way so the main CPU can go off and do other things while the IO processor(s) execute the IO program. The CPU can then determine the result of the IO later, presumably by polling (reading a main memory address) or by receiving an interrupt. Again, I forget how this works. But this is how the mainframe can do a lot of IO per unit time. Contrast this to the current Intel environment. The code that does IO uses the same read and write instructions as does any other code segment, and these instructions read and write to/from addresses that that happen to be mapped to IO device registers and memories. This makes it hard to virtualize IO. The operating system can trap on any IO space read or write, but since the devices themselves aren't standardized (either in terms of their control registers or the operations they can perform) there's not much it can do to remap the IO to a different place. Also, there's no way to determine which set of instructions really are an IO subroutine so there's no way to bundle them up and hand them off to an IO processor. Finally, since accessing IO devices is much slower than accessing cached main memory (consider 33 MHZ PCI versus a 400 MHz Xeon with full speed cache), each access to IO space consumes the same amount of time that could be used for tens/hundreds/thousands of CPU instructions depending on how busy the IO bus and device is. Intel has recognized this problem and has come up with their solution: i2o. If you search for i2o at www.intel.com or read www.i2o.org you will see that Intel is trying to get industry support for adoption of the mainframe approch to doing IO. I recall seeing a picture of an IBM mainframe buried in one of their presentations, and this slide says that the approch i2o uses is based on mainframe ideas. > > Suffice it to say you'd > > want to think a lot about which devices were worth the effort of > > supporting, since many of them are culturally incompatible with the > > UNIX way of doing things. > > Is this the data-stream vs. block-mode way of doing things that I mentioned > in another post? Yes, in particular the terminal devices in both environments are very quirky and hard to reconcile. Also there is a lot of effort needed if you want good IO performance. I recall the idea was to try to batch up IO requests and issue them as one long IO program instead of lots of little IO programs, since there is a cost associated with starting up the IO processors. > > To bootstrap, you could build a linux kernel and its ramdisk image, get > > it loaded into the mainframe's memory and let it rip. Based on what I > > remember from working on mainframe UNIX, you'd want to build an image > > using a cross-development environment (in our case it was an earlier > > version of mainframe UNIX but in your case it'd be a standard linux > > environment), then use VM/CMS with TCP/IP to pull the image from UNIX > > into the VM world. At this point, you'd have an image formatted as a > > set of 80 column virtual cards in this VM/CMS account. Then, you'd > > send the image from this account to the virtual card reader of second > > account. Then, you'd log into that second account, and type a command > > that meant "please boot my virtual card reader". This would load the > > image into memory, and then it's off to the races. > > I'd always wondered how one got VM to boot another image, so this info > is also welcome. I know it sounds quite nasty having to use a "virtual > card reader" and so forth to shift data around, although I know it works > quite well in practice (this is how we transferred data and ran jobs [in > both directions] between our 3090s and Unix minis, the latter of which > were fitted with SDLC cards; the mail interface between Uniplex/UUCP on > Unix and VISTA on MVS was quite an interesting one!) After booting countless virtual card decks, I really wanted to find a way to get my virtual UNIX card deck punched onto real cards, and find a real card reader, and boot the mother. I'm sure the place I worked had all the required facilities, but in my own mind I could never justify the expense. Sigh, a big opportunity lost forever... > > From what I recall, this wasn't a bad development environment. The > > image had a built-in debugger fairly early on in the development cycle > > that was quite good. Before this was ready, the native facilities were > > good enough to figure out where your virtual machine crashed or where > > it was hung. It was a lot nicer than trying to debug UNIX on bare > > metal (i.e. what Linus got to do a lot of very early in his career). > > It was also kinda fun to see one machine (a 3090 mainframe) running > > over a hundred different UNIX kernels in various states of being > > debugged. Using virtual channels and the channel-to-channel driver, > > you could hook them together in countless network topologies. It made > > for fairly simple ways to do things that are costly to do with real > > hardware, such as testing routing protocols. > > I'd love to have been involved in this sort of environment, it sounds > a wonderful way of working! Sadly, these days, hardware is so cheap (at > the PC-server end of things, anyway) that to test a new environment I > tend to just hook-up an unused PC to the network and use that. Nowhere > near as elegant or as easy to debug. It's a shame that none of the Unices > out there have a VM-style capability, as (on the face of it) there's > enough already lurking in the kernel to make this comparatively > straightforward (no I'm not volunteering to do it! I'm sure that it'd > immediately turn out to be nowhere near as "comparatively straightforward" > as I assume at the moment. :) From the above, you can see why it's next to impossible to virtualize the way most mini/micros do IO. It's kind of a shame. But as you note, most all of the UNIX system vendors are moving towards cloning the PR/SM approch of partitioning a large computer system so it can run different images in each partition. > > Alas, most of this work has gone the way of the dodo birds. But I > > wonder if some day someone doesn't try to revive mainframe UNIX. Some > > of the recent mainframe-class hardware is pretty impressive by any > > standard, excepting of course cost, but all you need to do is > > sell one or two big mainframes and you can cover the cost of the > > whole shooting match. > > It's a shame really, although I understand that Amdahl are still pushing > UTS. Acutally, there's a good page at http://www.amdahl.com/uts/uts390home.html and in particular http://www.amdahl.com/uts/utshist.html has their version of the history of UTS. They say the first UTS was a port of Version 6 done in 1978 and was used in-house to host their CPU design efforts because they preferred UNIX to TSO or CMS! > Just as an aside, I'd wondered what Unix would look like from a > 3270 session, so I x3270'd to a VM system and telnetted back to the > originating Unix one. It was certainly quite "different," although by > no means as unusable as I'd have expected. Yep. We tended to use the console only for booting the image and simple command-line tests. Otherwise, we'd telnet into the image. Packets would be routed from ethernet to a tcp/ip virtual machine, then fan out via virtual channel to each test image. From that point, you couldn't tell it apart from any other UNIX server (except that it was really fast after hours!). You could also use rsh to start X Windows programs on the mainframe that would display back on your workstation. > That's probably just showing > how out-of-date I am, though, as I understand that IBM have supported > graphics terminals for their mainframe hardware for years now (although > someone once claimed that they still used 3270 as the underlying protocol!) Well, this can be misleading. Mainframe graphics exist, but they are really only used for graphics (such as for computer-aided design), and not for graphical user interfaces (GUIs). The main reason is that they are programmed using display lists (indeed transferred using a mechanism similar to 3270) instead of being bitmapped devices. This is natural given my description of S/3xx IO above (it would be un-natural to have access to a memory-mapped framebuffer on a S/3xx). The display list to draw the stuff on a GUI desktop would be huge! IBM recognized this a long time ago, and has consistently marketed the S/3xx as being a back-end server. -- Dave Cherkus ------- UniMaster, Inc. ------ Contract Software Development Specialties: UNIX Internals/Kernel TCP/IP Alpha Clusters Performance ISDN Email: cherkus@UniMaster.COM When the music's over, turn out the lights! ###### From: jtNOSPAM@epix.net (Julian Thomas) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Sat, 09 Jan 1999 12:46:46 -0500 Organization: epix Internet Services Lines: 74 Message-ID: <369799c4$1$wg$mr2ice@news.epix.net> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> NNTP-Posting-Host: itha-125ppp35.epix.net X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v1.51 b51 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!newsfeed.nyu.edu!newsfeed.sgi.net!news-xfer.epix.net!news1.epix.net!epix-news In <36978ea0.0@news.destek.net>, on 01/09/99 at 12:15 PM, cherkus@unimaster.com (Dave Cherkus) said: >To do I/O on a S/3xx, one codes a short list of instructions known as >channel control words (CCWs). Then, one uses the SIO instruction (Start >IO) that points at the list of CCWs. The SIO instruction also has the >address of the device that will perform the IO. It is these things (the >SIO instruction and the CCWs) that are standardized and hide the details >of how the device will actually perform the IO. This is true for 360 and 370. ESA abolished the SIO instruction ( x'9C') and replaced it and its friends with SSCH ["Start Subchannel"] and some friends. Technically the SIO instruction specifies the IO address (channel/unit). There is a fixed location (absolute) that is loaded with a pointer to the CCW program. Obviously this limits multithreading, although once the SIO completes its synchronous part, the address of the CCW is held in the channel, and the CAW location can be reused. >Because they are standardized, the operating system can trap whenever it >sees a SIO instruction and rewrite the CCWs to do IO to/from different >main memory addresses and IO device addresses. This is more or less how >VM virtualizes IO access. And CCW translation was also used by MVS - the data addresses in the CCW are real, but an MVS channel program starts out with virtual addresses; the operating system builds a copy of the CCW program with real addresses. >Also, because of standard formats, the CPU can offload the processing of >these CCWs to outboard processors. This is one of the main reasons why >mainframe types say their systems are better at doing IO, and why they >say you can get by with less powerful CPUs on a mainframe class system. Yes. The SIO instruction does some checking (is the device busy, for instance) and then fires off the channel engine with the CAW. The rest is asynchronous to the cpu instruction stream; things are resunch by IO interrupts and some test instructions. >One of the things that I've forgotten the details of is that the IO >'program' (i.e. list of CCWs) can be run in a non-blocking way so the >main CPU can go off and do other things while the IO processor(s) execute >the IO program. The CPU can then determine the result of the IO later, >presumably by polling (reading a main memory address) or by receiving an >interrupt. Again, I forget how this works. But this is how the >mainframe can do a lot of IO per unit time. See above - the CCW program is executed entirely outside of the CPU by the channel engine (and a large 360/370 has a goodly number of these). I should mention for completeness that some of the early smaller 360 and 370 processors (360 up through the 50; 370 through the 158) had "integrated channels" that shared the CPU data flow. There was a fast hardware microcode task switching mechanism - when a channel has work to do (typically a memory fetch or store), an IO breakin "micro"-interrupts the CPU in the middle of wherever it is [not necessarily between instructions], takes a few cycles, and then releases the dataflow back to the CPU function that had been interrupted. ESA moved more function from the operating system into the IO subsystem; there was both a common IO processor that fielded the SSCH instruction, and individual channel engines for each physical subchannel (i.e. IO interface), so there was even more parallelism. I was there.... -- Julian Thomas: jt at epix dot net http://home.epix.net/~jt Boardmember of POSSI.org - Phoenix OS/2 Society, Inc http://www.possi.org In the beautiful Finger Lakes Wine Country of New York State! -- -- The BEEP BEEP VIRUS strikes again!!! ###### From: cherkus@unimaster.com (Dave Cherkus) Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <76paqd$d92$1@winter.news.rcn.net> <76qvh1$67g$3@teabag.demon.co.uk> <76uod9$9im@gwis2.circ.gwu.edu> <36944954.0@news.destek.net> <3696D7D3.3E9A@bell-labs.com> Lines: 24 X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] NNTP-Posting-Host: homerun.unimaster.com Message-ID: <3697a114.0@news.destek.net> Date: 9 Jan 1999 13:33:56 -0500 X-Trace: 9 Jan 1999 13:33:56 -0500, homerun.unimaster.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!cpk-news-hub1.bbnplanet.com!boston-news-feed1.bbnplanet.com!news.gtei.net!news.destek.net!not-for-mail Dennis Ritchie (dmr@bell-labs.com) wrote: > > It was more than "an effort," it was the standard development > environment for the 5ESS CO switch for quite a few years starting > around 1982. Quoting from a 1984 paper, > > Typical operational parameters of an IBM 3033AP are 150 > simultaneous users (upwards of 200 have been observed) > 600 active processes, 90% CPU usage on both processors, > and 10-20% usage of the I/O channels. Interesting! What activities were performed on the 3033? I presume you are referring to software development rather than hardware, but I could be wrong, seeing how Amdahl used UTS for CPU development and Intel used a 3090 running AIX/370 to develop the i486. So, presuming it was used for software development, and presuming the 5ESS did not use S/3xx technology, there must have been some sort of cross-compiler in use as well as the usual software tools. What language was used for programming the 5ESS? -- Dave Cherkus ------- UniMaster, Inc. ------ Contract Software Development Specialties: UNIX Internals/Kernel TCP/IP Alpha Clusters Performance ISDN Email: cherkus@UniMaster.COM When the music's over, turn out the lights! ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 9 Jan 1999 19:27:59 GMT Organization: Net Access BBS Lines: 23 Message-ID: <778ajv$ij9@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news-xfer.newsread.com!netaxs.com!newsread.com!netaxs.newsread.com!bbs.cpcn.com!root > Thanks for pointing that out. I understand that the S/370 is an entirely > different animal to the S/360 when it comes to design concepts etc. Physically it was different, the S/360 used core while the S/370 used semiconductor memories. Also, the S/370 used a higher level of integrated circuits than S/360. S/370 introduced hardware virtual memory to the product line and additional instructions to the hardware set. As a new line, it was naturally faster. IBM was originally contemplating an entirely new system but did not because (1) there was a large installed base of S/360 users that would have to convert all their work and (2) the new system was taking way too long to develop (it was eventually abandoned altogether though parts of it were used in other IBM products.) Programs written 30 years ago for S/360 will still run today without change (though some changes are necessary to take advantage of the latest featurs). For a large company with a large base of software, this is a major advantage. Converting just for Y2k is enormous, converting the programs altogether would be a tremendous expense. ###### Newsgroups: alt.folklore.computers From: spam@nowhere.com Subject: Re: IBM S/360 Reply-To: spam@nowhere.com References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> X-Newsreader: IBM NewsReader/2 v1.2.5 Lines: 142 Message-ID: Date: Sat, 09 Jan 1999 19:28:26 GMT NNTP-Posting-Host: 207.103.30.85 X-Trace: news3.voicenet.com 915910106 207.103.30.85 (Sat, 09 Jan 1999 14:28:26 EDT) NNTP-Posting-Date: Sat, 09 Jan 1999 14:28:26 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.idt.net!news.voicenet.com!news3.voicenet.com.POSTED!not-for-mail Conceptually, SCSI is similar to the S/360 block mode channels, and in fact, IBM I/O architecture going back to the 704 in the 1950s. The general performance of the original SCSI is quite similar to the S/360 selector channels, too. The main differences are a much shorter data cable than S/360 selector channels, and it can support just 7 devices, where a S/360 channel could support 256 devices. One thing that must be clearly understood about the S/360 I/O concept is that it was a four level affair. At the highest level is the main CPU. To start an I/O event, it instructs a channel (or the I/O subsystem) to start reading CCWs. The next level down is the channel. There are almost always several channels on a system. Modern, high capacity mainframe systems typically have dozens, through they are hidden in the I/O subsystem. A PC with a SCSI board has one channel. Conceptually, a channel is a very primitive beast. It can read out CCWs, and send them off to a control unit. It can also perform memory read and write operations as requested by a control unit. The only CCW the channel operates on directly is a Transfer in Channel CCW, which just provides the address of the next CCW. The next level down is a control unit, which typically drives several devices. In a few cases, the control unit is integrated with a device, such as with the 2501 card reader. The important thing about control units is they are designed to be smart. They are the primary interpreter of CCWs. The control unit talks to devices, and it also talks to the channel. For a while, in the 1970s, there was a sub control unit called a head of string that sat between the control unit and devices. The effective purpose of a head of string was to expand the effective length of the channel cable as DASD farms rapidly grew by allowing the control units to be in a closely spaced pool, and also to allow more than one control unit to talk to a string of devices. At the lowest level is a device. Since I sometimes write channel programs at the application level -- not very often any more, it's been well over a year, now -- it might be useful to discuss this matter. In MVS, an unauthorized application programs starts an I/O that does channel programs by using an EXCP macro -- EXCP iob Th EXCP macro is not a blocking macro. It returns as soon as possible, even if the I/O event was not actually started for one reason or another. It is the responsibility of the user program to find out when the I/O event completes. An IOB is a 32 byte -- well, for DASD, 40 byte -- control block. It has flags, addresses of an ECB (event control block, a semaphore like concept), the DCB, and the first CCW. It also has a data area that represents a CSW (Channel Status Word), which is what a channel leaves behind after it interrupts the computer. For DASD, the IOB also has the device address for the first record in the transfer. A DASD channel program in MVS is incomplete. The operating system constructs additional CCWs that provide for data integrity and moves the physical arm to the approriate place, and effectively places them in front of the user channel program. Part of the reason for this is the original I/O really did two I/O events for a DASD I/O. The first event moved the arm. While the arm was moving, the channel and control unit were not blocked, so other events could start. Once the arm was in place, the I/O was resumed with a second physical I/O event. This double I/O was eliminated with block multiplexor channels with the S/370 architecture. A simple channel program to read a data block contains 7 CCWs, and looks like this (with descriptions replacing the command codes and flags)-- CCW seek,device-address,command-chain,4 CCW set-file-mask,file-mask-address,command-chain,1 CCW transfer-in-channel,user-channel-program,0,0 . user-channel-program CCW set-sector,sector-address,command-chain,1 CCW searchIDequal,device-address,command-chain,5 CCW transfer-in-channel,*-8,0,0 CCW read-data,buffer-address,0,buffer-len The first three are provided by the operating system. The other four I supply. The seek is done before the set-file-mask because the file mask generally prohibits further arm movement; this provides data integrity. The file mask may also prohibit further head switching. The set-sector CCW ultimately tells the device to spin around until it finds a fixed sector location. These are spread around the track in equal increments. While the device is spinning it releases the connection to the control unit to allow the control unit to do other things. The program determines the correct sector address either by calculation, or by obtaining one in an earlier I/O operation. Once the device finds the sector it attempts to connect to the control unit. If the control unit refuses, because it is doing something else, the device just tries again. This sector address concept was added with the S/370 changes and the block multiplexor channels. The reason for this is the remainder of the channel program remains connected to the channel and control unit until it completes. The idea was to allow the device to do something simple without blocking the channel and control unit from being able to do something else. Search ID Equal instructs the control unit to wait until a record address, which is part of a special record on the device called a count record, to come up. It then compares the record address with the record address pointed to by the CCW. If they match, the control unit sets a special bit in the channel interface called "Status Modifier", which in turn tells the channel to skip a channel control word, when the control unit signals the channel with control unit end. The TIC *-8 instruction executes if the channel did not set status modifier when the is terminates the search instruction. In effect, it tells the channel to try again. The control unit and device are smart enough to quit with an I/O error if the record address never matches. Last, we read the data record. This is very simplified, of course. Modern devices, for example, no longer use the traditional file mask, and the user CCWs are all virtualized as part of the process of translating the virtual addresses in the CCWs to the real memory addresses understood by the I/O subsystem. The important thing is that, if the set-sector CCW is removed, this is code that a S/360 channel, control unit, and device could execute in 1965. There are probably detail errors in the above description that the people that actually write the OS/390 piece in San Jose would harp on, but I think this gives a fair description of what happens, and to some extent why it happens. -- Steve Myers The E-mail addresses in this message are private property. Any use of them to send unsolicited E-mail messages of a commerical nature will be considered trespassing, and the originator of the message will be sued in small claims court in Camden County, New Jersey, for the maximum penalty allowed by law. ###### From: cherkus@unimaster.com (Dave Cherkus) Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> Lines: 55 X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] NNTP-Posting-Host: homerun.unimaster.com Message-ID: <36918a48.0@news.destek.net> Date: 4 Jan 1999 22:43:04 -0500 X-Trace: 4 Jan 1999 22:43:04 -0500, homerun.unimaster.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!192.156.97.247!news.destek.net!not-for-mail Chris Hedley (cbh@REMOVE_THIS.teabag.demon.co.uk) wrote: : Will they run Linux? Even as a guest? :) In theory it can be done. Various UNIXes other than linux have run on IBM mainframes and some still do. AT&T System V, various now-retired IBM products and Hitachi with an OSF/1 variant come to mind. So, with sufficient interest there is no reason it can't happen. I saw a passing rumour that some IBM employee was working on Linux on S/3xx systems after hours as a hobby but never saw a confirmation of it. GCC has support for S/3xx, but I was told a few years ago that it had some issues. The various UNIXes I worked with had commercial compilers. So this might need work. Then, you'd have the usual machine-dependent things to work on (like paging, fault handling, interrupt handlers, etc.) then the whole world of writing device support for mainframe disks, terminals, etc. Suffice it to say you'd want to think a lot about which devices were worth the effort of supporting, since many of them are culturally incompatible with the UNIX way of doing things. To bootstrap, you could build a linux kernel and its ramdisk image, get it loaded into the mainframe's memory and let it rip. Based on what I remember from working on mainframe UNIX, you'd want to build an image using a cross-development environment (in our case it was an earlier version of mainframe UNIX but in your case it'd be a standard linux environment), then use VM/CMS with TCP/IP to pull the image from UNIX into the VM world. At this point, you'd have an image formatted as a set of 80 column virtual cards in this VM/CMS account. Then, you'd send the image from this account to the virtual card reader of second account. Then, you'd log into that second account, and type a command that meant "please boot my virtual card reader". This would load the image into memory, and then it's off to the races. From what I recall, this wasn't a bad development environment. The image had a built-in debugger fairly early on in the development cycle that was quite good. Before this was ready, the native facilities were good enough to figure out where your virtual machine crashed or where it was hung. It was a lot nicer than trying to debug UNIX on bare metal (i.e. what Linus got to do a lot of very early in his career). It was also kinda fun to see one machine (a 3090 mainframe) running over a hundred different UNIX kernels in various states of being debugged. Using virtual channels and the channel-to-channel driver, you could hook them together in countless network topologies. It made for fairly simple ways to do things that are costly to do with real hardware, such as testing routing protocols. Alas, most of this work has gone the way of the dodo birds. But I wonder if some day someone doesn't try to revive mainframe UNIX. Some of the recent mainframe-class hardware is pretty impressive by any standard, excepting of course cost, but all you need to do is sell one or two big mainframes and you can cover the cost of the whole shooting match. Dave ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 09 Jan 1999 15:08:10 -0800 Organization: Wheeler&Wheeler Lines: 23 Message-ID: References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> <369799c4$1$wg$mr2ice@news.epix.net> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-19.garlic.com X-Newsreader: Gnus v5.6.45/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!netnews.com!news-feed.fnsi.net!cyclone.i1.net!uunet!in1.uu.net!bulb.garlic.com!not-for-mail current description: http://ppdbooks.pok.ibm.com:80/cgi-in/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/CCONTENTS .. specifically http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/13.0 http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/14.0 http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/15.0 http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/16.0 http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/BOOKS/DZ9AR004/17.0 -- -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ###### From: "Joel C. Ewing" Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Sat, 09 Jan 1999 15:12:29 -0600 Content-Transfer-Encoding: 7bit References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> X-Posted-Path-Was: not-for-mail Content-Type: text/plain; charset=us-ascii X-ELN-Date: 9 Jan 1999 21:13:34 GMT X-ELN-Insert-Date: Sat Jan 9 13:15:06 1999 Organization: EarthLink Network, Inc. Lines: 128 Mime-Version: 1.0 NNTP-Posting-Host: 1cust191.tnt2.dfw2.da.uu.net Message-ID: <3697C63D.ABF67767@acm.org> X-Mailer: Mozilla 4.05 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!newsfeed.nyu.edu!newsfeed.berkeley.edu!newsfeed1.earthlink.net!nntp.earthlink.net!posted-from-earthlink!not-for-mail Dave Cherkus wrote: > Keep in mind this is pipe dreaming. I'm not proposing anyone go out > and bring up Linux on a S/3xx, but it doesn't hurt to talk about it - > this is alt.folklore.computers after all! > > Chris Hedley (cbh@REMOVE_THIS.teabag.demon.co.uk) wrote: > > cherkus@unimaster.com (Dave Cherkus) writes: ... > > Sorry if I'm sounding a complete newby here, but since using IBM "big > > iron" as an end-user many years ago, I've been intrigued by "what makes > > it tick," although finding a comprehensive answer in one place (ie reading ... The "bible" for the mainframe itself has always been the Principles of Operation (POP) manuals, which have evolved from S/360 to S/370 to XA Architecture to ESA Architecture, and these are probably available on the IBM web sites. The instruction set directly available to application code has only grown in minor and upward-compatible ways; however, the priviledged instructions available to supervisor-state operating system code has seen some radical changes and growth in complexity. Understanding the hardware support, segment and page table structures, and priviledged instruction support that control virtual memory is non-trivial. Understanding the hardware support for the PC (Program Call) instruction and the way in which this is used by an Operating System like MVS to provide for controlled and secure access to service functions in completely independent and protected address spaces is even an order of magnitude more difficult than the virtual memory support. While the I/O instructions are limited to a very standardized set of channel commands, unfortunately you will have to consult separate manuals for the device and device controllers to find explanations of the meaning of data bytes and permitted command sequences. In particular, at the operating system level the handling of error recovery procedures and interpreting device status bytes can be very complex when you must get down to the level of the channel programs sent to the I/O subsystem and to the interrupt routines that must interpret channel program completion. The Operating System must be designed to isolate application code from this complexity and from device dependency as much as possible. > > My knowledge has faded, but here's how I'd describe what is involved. > It's also overly simplified but hey, I haven't looked at the details > of this in 8 years or so. Corrections are invited. ... Since the introduction of XA Architecture extensions in the 1980's, I/O (at the Operating System level) is initiated by a SSCH (Start Subchannel) instruction, which provides a device address and a sequence of 8-byte channel command words (CCW's) to the I/O subsystem. The distinction from the old SIO interface is that a separate hardware I/O subsystem is now able to keep track of concurrently running channel programs for all possible devices and is responsible for "knowing" what physical channel paths and controllers are used to reach a specific device. If no path is currently available or the associated controller is busy, the channel subsystem automatically resolves queueing of channel programs and initiation as soon as a path becomes available (4, 8, or even more paths through which a single disk device may be accessed is now common in the mainframe world -- 2 were common prior to XA but path selection was done by the Operating System not by the hardware). The I/O subsystem may be implemented with a number of independent processors to provide the required redundancy and performance, and it has its own independent access to central memory for channel program access and data transfer. Application code is not allowed to execute SSCH instructions directly, but must instead execute EXCP (Execute Channel Program) requests to the operating system (uses the SVC instruction to synchronously pass control to the Operating System), which then validates and modifies the channel program as necessary to handle device dependencies and to insure that only authorized and valid actions are being requested. A POST/WAIT mechanism is used to signal completion of the request, and the application program can either choose to continue with other activity or suspend execution with a "WAIT" until the request has been completed. The implementation of POST/WAIT and its integration with the multitasking and CPU dispatching mechanisms is part of the responsibility of the Operating System. Completion of a channel program (or an error termination) causes an processor interrupt. The Operating System must be designed so that this interrupt drives an appropriate interrupt routine, which analyzes the results of the channel program, performs any error recovery and retry that may be required, POSTs completion results back to the original requestor when done, and initiates the next I/O on the same device if one is waiting. Once the SSCH command is issued, the main processor(s) are out of the picture until the channel subsystem signals completion or failure via an interrupt. Polling techniques are not used (except possibly in some really old stand-alone utilities) because it is a wasteful use of an expensive processor resource. ... > > > Suffice it to say you'd > > > want to think a lot about which devices were worth the effort of > > > supporting, since many of them are culturally incompatible with the > > > UNIX way of doing things. > > > > Is this the data-stream vs. block-mode way of doing things that I mentioned > > in another post? > > Yes, in particular the terminal devices in both environments are very > quirky and hard to reconcile. In particular, MVS OpenEdition doesn't support the vi editor on 3270 devices, because there is no way of allowing vi to see each character as it is entered, and its standard behavior requires that capability. ... > > > into the VM world. At this point, you'd have an image formatted as a > > > set of 80 column virtual cards in this VM/CMS account. Then, you'd > > > send the image from this account to the virtual card reader of second > > > account. Then, you'd log into that second account, and type a command > > > that meant "please boot my virtual card reader". This would load the > > > image into memory, and then it's off to the races. ... VM is able to emulate the hardware IPL process off any device that supports an IPL, so in addition to a virtual card reader, you can IPL off tape devices (for standalone utilities) or off DASD devices which have been initialized with IPL records. DASD IPL is the normal method for IPL of any production operating system under VM. VM is able to emulate "virtual" devices because all code executed in a virtual machine, even Operating System code, is really being executed in program mode (emulated program-mode or emulated priviledged mode), so all SSCH commands are intercepted by VM and the requests and results modified as necessary to emulate virtual devices. ... > > > Alas, most of this work has gone the way of the dodo birds. But I > > > wonder if some day someone doesn't try to revive mainframe UNIX. Some ... Of course OS/390 now includes OpenEdition (now called Unix Services) for those who just want Unix capabilities. However, if you're looking for freeware, this doesn't fit the bill. ... -- Joel C. Ewing, Fort Smith, AR jcewing@acm.org ###### Message-ID: <3697FE64.D4D16C79@compuserve.com> Date: Sat, 09 Jan 1999 17:12:04 -0800 From: Dale DePriest X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IBM S/360 References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Newsgroups: alt.folklore.computers Lines: 35 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newspeer1.nac.net!WCG!arl-news-svc-3.compuserve.com!news-master.compuserve.com!nntp-nih2naaa.compuserve.com Dave Cherkus wrote: > Thanks for the excellent post. I have a follow-on question. > > spam@nowhere.com wrote: > > The next level down is the channel. There are almost always several > > channels on a system. Modern, high capacity mainframe systems typically > > have dozens, through they are hidden in the I/O subsystem. A PC with a > > SCSI board has one channel. > > What is the usual hardware connection between the main memory to cpu > bus and these dozens of I/O channels? I understand that it's hard to > build a high speed bus with dozens of connections on it, and the speed > of the channel is slower than the speed of the system bus. Is there > some sort of bridge between the system bus and the IO subsystem, much > like the way most PCI busses get implemented? > On a 360 there could be at most 8 devices going to memory. The memory had a bus traffic cop that provided a path to memory for 1 mutlplexer channel, up to 6 selector channels, and the cpu. The cpu had the lowest priority to memory. Each selector channel, in turn could be connected to 8 controllers which could control up to 8 devices. Later some of these numbers went to 16 but the number of devices that could go to memory was limited to 8. A selector channel could have only one high speed data transfer going on at a time. A multiplexer channel tended to have slow devices like printers and card readers and could multiplex mutliple devices. It also did not generally use an intermediate controller. Dale -- ###### From: cherkus@unimaster.com (Dave Cherkus) Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> <3697C63D.ABF67767@acm.org> Lines: 24 X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] NNTP-Posting-Host: homerun.unimaster.com Message-ID: <3697da27.0@news.destek.net> Date: 9 Jan 1999 17:37:27 -0500 X-Trace: 9 Jan 1999 17:37:27 -0500, homerun.unimaster.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!192.156.97.247!news.destek.net!not-for-mail Thanks for the excellent post. One minor clarification: Joel C. Ewing (jcewing@acm.org) wrote: > VM is able to emulate the hardware IPL process off any device that > supports an IPL, so in addition to a virtual card reader, you can IPL > off tape devices (for standalone utilities) or off DASD devices which > have been initialized with IPL records. DASD IPL is the normal method > for IPL of any production operating system under VM. VM is able to > emulate "virtual" devices because all code executed in a virtual > machine, even Operating System code, is really being executed in program > mode (emulated program-mode or emulated priviledged mode), so all SSCH > commands are intercepted by VM and the requests and results modified as > necessary to emulate virtual devices. Indeed. Just to make sure everything is clear, in my posting I was talking about the makeshift method used to boot test operating systems. I think the reason the virtual card deck was used was because it was the easiest to create and transfer (i.e. spool) to a VM guest virtual machine. -- Dave Cherkus ------- UniMaster, Inc. ------ Contract Software Development Specialties: UNIX Internals/Kernel TCP/IP Alpha Clusters Performance ISDN Email: cherkus@UniMaster.COM When the music's over, turn out the lights! ###### From: cherkus@unimaster.com (Dave Cherkus) Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> Lines: 19 X-Newsreader: TIN [UNIX 1.3 950824BETA PL0] NNTP-Posting-Host: homerun.unimaster.com Message-ID: <3697db6d.0@news.destek.net> Date: 9 Jan 1999 17:42:53 -0500 X-Trace: 9 Jan 1999 17:42:53 -0500, homerun.unimaster.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!chippy.visi.com!news-out.visi.com!cam-news-hub1.bbnplanet.com!boston-news-feed1.bbnplanet.com!news.gtei.net!news.destek.net!not-for-mail Thanks for the excellent post. I have a follow-on question. spam@nowhere.com wrote: > The next level down is the channel. There are almost always several > channels on a system. Modern, high capacity mainframe systems typically > have dozens, through they are hidden in the I/O subsystem. A PC with a > SCSI board has one channel. What is the usual hardware connection between the main memory to cpu bus and these dozens of I/O channels? I understand that it's hard to build a high speed bus with dozens of connections on it, and the speed of the channel is slower than the speed of the system bus. Is there some sort of bridge between the system bus and the IO subsystem, much like the way most PCI busses get implemented? -- Dave Cherkus ------- UniMaster, Inc. ------ Contract Software Development Specialties: UNIX Internals/Kernel TCP/IP Alpha Clusters Performance ISDN Email: cherkus@UniMaster.COM When the music's over, turn out the lights! ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 9 Jan 1999 19:34:04 GMT Organization: Net Access BBS Lines: 24 Message-ID: <778avc$jka@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!news-xfer.newsread.com!netaxs.com!newsread.com!newshog.newsread.com!netaxs.newsread.com!bbs.cpcn.com!root > > It was likely it was running DOS/VSE, which was the smaller scale operating > > system. > > That's one that I know *absolutely nothing* about, as opposed to MVS and > VM, where I just know very little! IBM originally intended for one operating system for S/360 (known as "OS" which is today's "MVS". But OS proved to be too big and bulky for the low end of machines so they had to develop some small scale operating systems, and DOS came out (there were some others too). VM came out of time sharing development efforts, originally CMS. It is so incredible to believe that we go to our WalMart and bring home a 16Meg memory computer for our kids to play with yet back then companies were buying machines with 16K of memory. Before S/360, machines like the 1401 came in as little as 1.2 (or 1.4?) thousand characters of memory, and maxed at 16,000. Even after solid state memory replaced core, memory was still expensive, in 1980, a big corporate wide mainframe could have 8 Meg. The difference hit me when I bought a plane of core memory from the Comptuer Musuem, and realized that I was paying more per bit for that scrap sample (mostly due to shipping costs) than if I were to buy real working contemporary memory. ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 9 Jan 1999 19:38:05 GMT Organization: Net Access BBS Lines: 17 Message-ID: <778b6t$k7t@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!news-xfer.newsread.com!netaxs.com!newsread.com!newshog.newsread.com!netaxs.newsread.com!bbs.cpcn.com!root > Sorry if I'm sounding a complete newby here, but since using IBM "big > iron" as an end-user many years ago, I've been intrigued by "what makes > it tick," although finding a comprehensive answer in one place (ie reading > up in books, asking colleagues etc) seems to be difficult. Perhaps I'm > just setting my sights too high, since there's obviously a lot to take > in! My colleagues gave me vague inklings about how parts of the system > worked, although I was surprised that, culturally, people tended not to > get at all involved with the mechanics of what was going on outside of > their own "domain." There is an excellent book you may wish to read "IBM System/360 and Early S/370" by Emerson Pugh et al. It details the development of the machine including software, hardware, and peripherals. They also wrote a book "IBM's Early Computers". Both published by MIT Press. ###### Newsgroups: alt.folklore.computers From: spam@nowhere.com Subject: Re: IBM S/360 Reply-To: spam@nowhere.com References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> X-Newsreader: IBM NewsReader/2 v1.2.5 Lines: 37 Message-ID: Date: Sat, 09 Jan 1999 19:41:38 GMT NNTP-Posting-Host: 207.103.30.85 X-Trace: news3.voicenet.com 915910898 207.103.30.85 (Sat, 09 Jan 1999 14:41:38 EDT) NNTP-Posting-Date: Sat, 09 Jan 1999 14:41:38 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.idt.net!news.voicenet.com!news3.voicenet.com.POSTED!not-for-mail There has been some discussion about streaming I/O (as in UNIX and the PC) versus block mode I/O, which is perceived as the norm in S/360. Streaming I/O is a presentation of I/O to an end user. The physical I/O for data files is still done with physical blocks. In my option, the idea of streaming I/O really goes back to paper tape, when getting the tape stopped was a real problem. There are two important distinctions. In S/360, the I/O presentation is in blocks of data, and user programs operate on this presentation. The blocks, both logical and physical, can vary in length, either at the record level, or at the physical level, or both. In UNIX, or the PC, physical records are typically fixed in length. Streaming I/O in UNIX and the PC has two effective modes: binary, which is really streaming, or text, when logical records are delimited. In UNIX, a special character, line feed, is the record separtor. In the PC records are delmited by a carriage-return and line-feed character following each other. The nearest thing in S/360 is variable length data records, where each record records its length as a binary length at the start of the record. It is my opinion this is much more efficent than the UNIX approach, and allows all possible characters to be used in the data record. In UNIX, text data is pretty well restricted to, well, text, since one of the characters is pretty well reserved as a record delimiter. In addition, a second character is pretty well reserved as a string terminator, and cannot be used in a text record. -- Steve Myers The E-mail addresses in this message are private property. Any use of them to send unsolicited E-mail messages of a commerical nature will be considered trespassing, and the originator of the message will be sued in small claims court in Camden County, New Jersey, for the maximum penalty allowed by law. ###### Newsgroups: alt.folklore.computers From: spam@nowhere.com Subject: Re: IBM S/360 Reply-To: spam@nowhere.com References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> X-Newsreader: IBM NewsReader/2 v1.2.5 Lines: 39 Message-ID: Date: Sat, 09 Jan 1999 23:21:22 GMT NNTP-Posting-Host: 207.103.30.154 X-Trace: news3.voicenet.com 915924082 207.103.30.154 (Sat, 09 Jan 1999 18:21:22 EDT) NNTP-Posting-Date: Sat, 09 Jan 1999 18:21:22 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.idt.net!news.voicenet.com!news3.voicenet.com.POSTED!not-for-mail There is no standard "bus" in the architecture. There is a very sophisticated storage manager that talks to the CPU, the storage cache, and the I/O subsystem in ways that depend on the exact hardware implementation of the system. This implementation is completely invisible at both the application the operating system levels. _All_ talking to non-CPU devices is through the I/O subsystem, so there is no direct requirement for a bus to expand hardware capabilities as there is on the PC. In <3697db6d.0@news.destek.net>, cherkus@unimaster.com (Dave Cherkus) writes: >Thanks for the excellent post. I have a follow-on question. > >spam@nowhere.com wrote: >> The next level down is the channel. There are almost always several >> channels on a system. Modern, high capacity mainframe systems typically >> have dozens, through they are hidden in the I/O subsystem. A PC with a >> SCSI board has one channel. > >What is the usual hardware connection between the main memory to cpu >bus and these dozens of I/O channels? I understand that it's hard to >build a high speed bus with dozens of connections on it, and the speed >of the channel is slower than the speed of the system bus. Is there >some sort of bridge between the system bus and the IO subsystem, much >like the way most PCI busses get implemented? > >-- >Dave Cherkus ------- UniMaster, Inc. ------ Contract Software Development >Specialties: UNIX Internals/Kernel TCP/IP Alpha Clusters Performance ISDN >Email: cherkus@UniMaster.COM When the music's over, turn out the lights! -- Steve Myers The E-mail addresses in this message are private property. Any use of them to send unsolicited E-mail messages of a commerical nature will be considered trespassing, and the originator of the message will be sued in small claims court in Camden County, New Jersey, for the maximum penalty allowed by law. ###### Mime-Version: 1.0 X-Newsreader: knews 1.0b.0 References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36918a48.0@news.destek.net> <76upvv$aar@gwis2.circ.gwu.edu> <36944cdd.0@news.destek.net> From: mforsyth@really.bogus.com () Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Jan 1999 09:18:21 +1059 Message-ID: NNTP-Posting-Host: 203.40.56.55 X-Trace: 10 Jan 1999 09:34:12 +1000, 203.40.56.55 Lines: 17 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.berkeley.edu!intgwpad.nntp.telstra.net!nsw.nntp.telstra.net!139.134.5.33!really.bogus.com!nobody In article <36944cdd.0@news.destek.net>, cherkus@unimaster.com (Dave Cherkus) writes: > jeffreyb@gwis2.circ.gwu.edu wrote: >: Compaq/Digital is working something called "Wildfire" which >: will allow running multiple, clustered instances of Digital Unix on a >: single system. They're a bit behind, though, and it seems the major goal >: is to do an end-run around Digital Unix's troubles coping on systems with >: large numbers of processors. > > Cough. Digital UNIX has no problem dealing with large number of > processors. Right now, it's running on hardware that's a step > or so behind most of the gang on the high end. When this ??? In terms of clock speed perhaps. But who else has stable, robust and above all PROVEN 64 bittedness ??? Mark F...:) ###### Mime-Version: 1.0 X-Newsreader: knews 1.0b.0 References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36918a48.0@news.destek.net> <76upvv$aar@gwis2.circ.gwu.edu> <777dbo$vtu$4@teabag.demon.co.uk> From: mforsyth@really.bogus.com () Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Jan 1999 09:26:17 +1059 Message-ID: <92l877.geb.ln@really.bogus.com> NNTP-Posting-Host: 203.40.56.55 X-Trace: 10 Jan 1999 09:34:18 +1000, 203.40.56.55 Lines: 20 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!newsfeed.berkeley.edu!intgwpad.nntp.telstra.net!nsw.nntp.telstra.net!139.134.5.33!really.bogus.com!nobody In article <777dbo$vtu$4@teabag.demon.co.uk>, cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) writes: > In article <76upvv$aar@gwis2.circ.gwu.edu>, > jeffreyb@gwis2.circ.gwu.edu writes: >> board level. Compaq/Digital is working something called "Wildfire" which >> will allow running multiple, clustered instances of Digital Unix on a >> single system. > > Didn't Digital work on something similar for the Vax platform in the > early to mid '80s? I'm sure I heard about an attempted enhancement to > the CPU to allow it to run a mixture of VMS and Ultrix sessions on the > same box. Yes and while I don't beleive they succeeded in the way they wanted, it did spit out the dreaded POSIX shell for OpenVMS. Under POSIX, which is free and IMO worth every cent, ANY POSIX compliant application would run OK. It was slow difficult and most applications had to be seen to be believed. Mark F... > > Chris. ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 10 Jan 1999 09:32:13 -0800 Organization: Wheeler&Wheeler Lines: 165 Message-ID: References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-19.garlic.com X-Newsreader: Gnus v5.6.45/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.berkeley.edu!cyclone.swbell.net!uunet!in2.uu.net!bulb.garlic.com!not-for-mail simplex 67 was single ported memory .... the two-processor 67 had a channel controller with dual-ported memory. Heavy load had a "half-duplex" 67 (i.e. single processor with channel controller and dual-ported memory) outperformed simplex 67. anyway from the alt.folklore.computers and comp.arch archives ... Subject: Re: Virtual Memory (A return to the past?) From: lynn@garlic.garlic.com (Anne & Lynn Wheeler) Date: 1995/09/27 References: <811544165.5606@keppel.demon.co.uk> <43tc5o$fmu@usenetw1.news.prodigy.com> Reply-To: (Anne & Lynn Wheeler) Newsgroups: comp.arch .. some of you are probably getting tired of seeing this ... but a typical '68 hardware configuration and a typical configuration 15 years later machine 360/67 3081K mips .3 14 *47 pageable pages 105 7000 *66 users 80 320 *4 channels 6 24 *4 drums 12meg 72meg *6 page I/O 150 600 *4 user I/O 100 300 *3 disk arms 45 32 *4?perform. bytes/arm 29meg 630meg *23 avg. arm access 60mill 16mill *3.7 transfer rate .3meg 3meg *10 total data 1.2gig 20.1gig *18 Comparison of 3.1L 67 and HPO 3081k ======================================== 360/65 is nominal rated at something over .5mips (reg<->reg slightly under 1mic, reg<->storage start around 1.5mic and go up). running relocate increases 67 memory bus cycle 20% from 750ns to 900ns (with similar decrease in mip rate). 67 was non-cached machine and high I/O rate resulted in heavy memory bus (single-ported) contention with processor. drums are ibm'ese for fixed head disks. disk access is avg. seek time plus avg. rotational delay. the 3.1l software is actually circa late 70 or earlier 71 (late in the hardware life but allowing more mature software). the 3081k software is the vm/hpo direct descendant of the cp/67 system. 90th percentile trivial response for the 67 system was well under a second, the 90th percential trivial response for the 3081k was .11 seconds (well under instantaneous observable threshold for majority of the people). the page i/o numbers is sustained average under heavy load. actual paging activity at the micro-level shows very bursty behavior with processes generating page-faults at device service intervals during startup and then slowing down to contention rates during normal running. the 3081k system had pre/block page-in support (i.e. more akin to swap-in/swap-out of list of pages rather than having to individually page fault). big change between 68 and 83 ... which continues today is that processor has gotten much faster than disk tech. has gotten faster. real memory sizes and program sizes have gotten much bigger than disk has gotten faster (programs have gotten 10-20 larger, disk get twice as fast, sequentially page faulting a memmap'ed region 4k bytes at a time takes 5-10 times longer). Also while current PCs are significantly more powerful than mainframe of late '60s and the individual disks are 5-10 times faster, the aggregate I/O thruput of todays PCs tend to be less than the aggregate I/O thruput of the mainframe systems. In any case, when I started showing this trend in the late '70s that disk relative system performance was declining (i.e. rate of getting better was less than the getting better rate for the rest of the system) nobody believed it. A simple measure was that if everything kept pace, the 3081K system would have been supporting 2000-3000 users instead of 320. Somewhat bottom line is that even fixed head disks haven't kept up with the relative system performance. Strategy today is whenever possible do data transfers in much bigger chunks than 4k bytes, attempt to come up with asyncronous programming models (analogous to weak memory consistency & out-of-order execution for processor models), and minimize as much as possible individual 4k byte at a time, syncronous page fault activity. From: lynn@garlic.garlic.com (Anne & Lynn Wheeler) Newsgroups: alt.folklore.computers Subject: Re: 3330 Disk Drives Date: 18 Jun 1995 17:10:56 GMT Organization: Wheeler&Wheeler Lines: 58 Distribution: world References: <95061207293317004@nwcs.org> Reply-To: (Anne & Lynn Wheeler) NNTP-Posting-Host: garlic.com In-reply-to: paul.rogers@nwcs.org's message of Sun, 11 Jun 1995 16:04:00 GMT following from report i originally did in '81 ... part of the numbers were excerpted in postings in this group early last year (archived at ftp://ftp.netcom.com/pub/ly/lynn). 3330 numbers for 3330-ii. overall system numbers showed that 3380 technology had a relative decline in system performance by at least a factor of five compared to 2314 relative system performance. also 4k acc/sec/meg declined by more than an order of magnitude (absolute). Some of the numbers were done in late '70s where it was shown that upgrading from 3330-ii to 3350 only improved performance if allocated data was limited to approx. same as on 3330-ii. The 3380 are the original (single density) 3380. 2305 2314 3310 3330 3350 3370 3380 data cap, mb 11.2 29 64 200 317 285 630 avg. arm acc, ms 0 60 27 30 25 20 16 avg. rot del. ms 5 12.5 9.6 8.4 8.4 10.1 8.3 data rate mb 1.5 .3 1 .8 1.2 1.8 3 4k blk acc, ms 7.67 85.8 40.6 43.4 36.7 32.3 25.6 4k acc. per sec 130 11.6 24.6 23 27 31 39 40k acc per sec 31.6 4.9 13. 11.3 15. 19.1 26.6 4k acc per sec per meg 11.6 .4 .38 .11 .08 .11 .06 ====================================================================== slightly different table ... assuming a uniform access distribution, loading the indicated max. data on the drive (i.e. not filling the whole thing) gives the resulting 4kbyte-block-access/sec/mbyte (i.e. 3380 with only 40mbyte loaded gives approx. the same performance as 2314). 2305 2314 3310 3330 3350 3370 3380 data cap, mb 11.2 29 64 200 317 285 630 4k acc. per sec 130 11.6 24.6 23 27 31 39 20 meg - .041 .091 .082 .098. .122 .152 40 meg - - .023 .021 .025 .031 .039 60 meg - - - .009 .011 .014 .017 80 meg - - - .005 .006 .008 .010 -- -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ###### Newsgroups: alt.folklore.computers From: spam@nowhere.com Subject: Re: IBM S/360 Reply-To: spam@nowhere.com References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> X-Newsreader: IBM NewsReader/2 v1.2.5 Lines: 54 Message-ID: Date: Sun, 10 Jan 1999 10:38:41 GMT NNTP-Posting-Host: 207.103.30.121 X-Trace: news3.voicenet.com 915964721 207.103.30.121 (Sun, 10 Jan 1999 05:38:41 EDT) NNTP-Posting-Date: Sun, 10 Jan 1999 05:38:41 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!news.voicenet.com!news3.voicenet.com.POSTED!not-for-mail My post indicated concepts, and did not deal in limits. Your stated limits applied only to the /65, /67, and /75. The /85 and /195 (which, I concede, were more S/370 than S/360) could provide more. Lower numbered machines provided less, both because the memory was slower, and also because the channels were stealing CPU clicks to operate. Remember, too, that by current standards the memory on these machines was incredibly slow. The memory on the /65 through /75 had a read-write back, if memory (mine) serves correctly, of 600 ns, which indicates an effective maximum data rate, for the CPU and channels, of about 13.3 megabytes/second, assuming everything was working on 8 byte units, the basic memory width. Even my lowly 60MHz Pentium PC has faster memory, Your analysis is flawed in one other respect. The 2870 byte multiplexor channel could have one or two selector sub-channels attached to it. These dudes operated just like selector channels for medium speed devices, though at the cost of limiting the data rate of the byte devices. By "medium" speed devices, I mean tape drives, though I know of one use of 2311s through a selector sub. In any event, that adds two additional "fast" data streams to your analysis. The fastest "traditional" S/360 I/O device, the 2301 drum, had a data rate of 1.2 megabytes/second. The 2314, the normal "fast" DASD on these machines, ran at a rockin' .356 megs/second. 6 2301s attached to 6 selector channels would have a data rate of 7.2 megs/second, which is within the maximum possible data rate. Fast PC devices tend to quote speeds in megabits per second, which sounds impressive until you convert that to megabytes per second. In <3697FE64.D4D16C79@compuserve.com>, Dale DePriest writes: [snip] >On a 360 there could be at most 8 devices going to memory. The memory had a >bus >traffic cop that provided a path to memory for 1 mutlplexer channel, up to 6 >selector channels, and the cpu. The cpu had the lowest priority to memory. >Each selector channel, in turn could be connected to 8 controllers which could >control up to 8 devices. Later some of these numbers went to 16 but the >number of devices that could go to memory was limited to 8. A selector >channel could have only one high speed data transfer going on at a time. A >multiplexer channel tended to have slow devices like printers and card readers >and could multiplex mutliple devices. It also did not generally use an >intermediate controller. > >Dale -- -- Steve Myers The E-mail addresses in this message are private property. Any use of them to send unsolicited E-mail messages of a commerical nature will be considered trespassing, and the originator of the message will be sued in small claims court in Camden County, New Jersey, for the maximum penalty allowed by law. ###### From: andrew@cucumber.demon.co.uk (Andrew Gabriel) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 10 Jan 1999 12:26:12 GMT Organization: home Message-ID: <77a694$39c@cucumber.demon.co.uk> References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> NNTP-Posting-Host: cucumber X-NNTP-Posting-Host: cucumber.demon.co.uk:158.152.58.86 X-Trace: news.demon.co.uk 915971284 nnrp-07:17692 NO-IDENT cucumber.demon.co.uk:158.152.58.86 X-Complaints-To: abuse@demon.net X-Newsreader: knews 0.9.6 Lines: 22 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!ayres.ftech.net!news.ftech.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!cucumber.demon.co.uk!usenet In article , spam@nowhere.com writes: >Remember, too, that by current standards the memory on these machines >was incredibly slow. The memory on the /65 through /75 had a read-write >back, if memory (mine) serves correctly, of 600 ns, which indicates an >effective maximum data rate, for the CPU and channels, of about 13.3 >megabytes/second, assuming everything was working on 8 byte units, the >basic memory width. Even my lowly 60MHz Pentium PC has faster memory, A mini-computer I knew well of the same era had 700ns read-write back, but it 4-way interleaved it's memory crates, so it could do upto 4 accesses at once, and achieve much better memory throughput than you would imagine if you just considered the 700ns access time (it wasn't 4 times better, perhaps 2 to 3 times better). I don't know the S/360 at all, but wouldn't be surprised if it had something along these lines too. -- Andrew Gabriel Consultant Software Engineer ###### Newsgroups: alt.folklore.computers From: spam@nowhere.com Subject: Re: IBM S/360 Reply-To: spam@nowhere.com References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> <77a694$39c@cucumber.demon.co.uk> X-Newsreader: IBM NewsReader/2 v1.2.5 Lines: 40 Message-ID: Date: Sun, 10 Jan 1999 17:33:01 GMT NNTP-Posting-Host: 207.103.30.148 X-Trace: news3.voicenet.com 915989581 207.103.30.148 (Sun, 10 Jan 1999 12:33:01 EDT) NNTP-Posting-Date: Sun, 10 Jan 1999 12:33:01 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!isdnet!netnews.com!news.voicenet.com!news3.voicenet.com.POSTED!not-for-mail You are correct. The /65 and /67 had 2-way memory interleaving. The /75 had 4-way memory interleaving. Memory interleaving is of greatest assistance for long sequential operations from the CPU. It is of less value for more random access, such as access from channels, which was the thrust of my post. What they really needed was a cache, but that was way off in the future. In <77a694$39c@cucumber.demon.co.uk>, andrew@cucumber.demon.co.uk (Andrew Gabriel) writes: >In article , > spam@nowhere.com writes: >>Remember, too, that by current standards the memory on these machines >>was incredibly slow. The memory on the /65 through /75 had a read-write >>back, if memory (mine) serves correctly, of 600 ns, which indicates an >>effective maximum data rate, for the CPU and channels, of about 13.3 >>megabytes/second, assuming everything was working on 8 byte units, the >>basic memory width. Even my lowly 60MHz Pentium PC has faster memory, > >A mini-computer I knew well of the same era had 700ns read-write back, >but it 4-way interleaved it's memory crates, so it could do upto 4 >accesses at once, and achieve much better memory throughput than you >would imagine if you just considered the 700ns access time (it wasn't >4 times better, perhaps 2 to 3 times better). > >I don't know the S/360 at all, but wouldn't be surprised if it had >something along these lines too. > >-- >Andrew Gabriel >Consultant Software Engineer > -- Steve Myers The E-mail addresses in this message are private property. Any use of them to send unsolicited E-mail messages of a commerical nature will be considered trespassing, and the originator of the message will be sued in small claims court in Camden County, New Jersey, for the maximum penalty allowed by law. ###### From: arargh@arargh.com (Arargh!) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Sun, 10 Jan 1999 10:10:38 GMT Organization: Arargh!! Lines: 14 Message-ID: <36987c6e.636002116@news.mcs.net> References: <778avc$jka@netaxs.com> Reply-To: arargh@arargh.com NNTP-Posting-Host: jwright.pr.mcs.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.452 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!212.63.192.161.MISMATCH!newshub.bart.net!news.tele2.nl!newsfeed1.swip.net!swipnet!news.maxwell.syr.edu!news-peer.gip.net!news.gsl.net!gip.net!newspump.sol.net!news.mcs.net!ddsw1!news.mcs.net!not-for-mail On 9 Jan 1999 19:34:04 GMT, hancock4@bbs.cpcn.com (Lisa or Jeff) wrote: >It is so incredible to believe that we go to our WalMart and bring home >a 16Meg memory computer for our kids to play with yet back then companies >were buying machines with 16K of memory. Before S/360, machines like >the 1401 came in as little as 1.2 (or 1.4?) thousand characters of memory, IIRC the smallest was 400 chars - arargh >and maxed at 16,000. Even after solid state memory replaced core, memory >was still expensive, in 1980, a big corporate wide mainframe could >have 8 Meg. > ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 10 Jan 1999 15:05:45 -0800 Organization: Wheeler&Wheeler Lines: 80 Message-ID: References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-19.garlic.com X-Newsreader: Gnus v5.6.45/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.maxwell.syr.edu!logbridge.uoregon.edu!uunet!in5.uu.net!bulb.garlic.com!not-for-mail 370s were 115, 125, 135, 145, 155, 165 (and sort of 195) initial 155 & 165 had no virtual memory (relocation) hardware it was possible to open the front panel of the 155 and disable the cache ... and the thruput of the machine dropped to that of about a 145. to announce virtual memory ... the 155s & 165s in customer shops needed a hardware retrofit. Turns out for the full virtual memory announcement ... an extra hardware line thru much of the 165 would have had to be designed and built ... and would have delayed virtual memory announcement by an additional six months. Since SVS (effectively MVT remapped to a virtual memory space) stated that they had no need for the full architecture ... they would be perfectly happy to go with abbreviated virtual memory hardware roll-out. The other machines shipped day one with the virtual memory support built in ... but had to wait for 155/165 & software before it was turned on. 155s and 165s were upgraded with 158s & 168s ... and 135s and 145s then with 138s and 148s. The 168-1 had an interim upgrade to a 168-3 which doubled the size of its cache (although there were a couple shops who installed the 168-3 field upgrade and saw performance decline). The 158s&168s were then upgraded by 3031, 3032, and 3033. The big feature of the 303x line was the channel director (somewhat analogous to the channel director on the 360/67 duplex configurations ... and actually a seperate stripped down 158 processer with a different microcode load). The 3031s and 3032s were 158s and 168s repackaged with I/O support going thru the channel director. The 3033 started out as a 168 wiring diagram remapped to a faster chip technology. The 138s & 148s were upgraded to 4331 and 4341 ... and then to 4361 and 4381. The internal network was tagentially involved in the 145 support. The internal network was larger than the arpanet/csnet pretty much from the start up thru sometime in the mid-80s. One of the first links in the internal network (besides those running between machines in the same building) was between cambridge (mass) and endicott (ny). Most of the virtual machine work was done in cambridge and the 370/145 work was being done in endicott. Endicott came to cambridge and proposed a joint project to build a 370 virtual machine capability ... which ran within a CP/67 (i.e. 360/67) virtual machine ... simulating the features that were different between the 360 and 370. A version of CP/67 was created that would provide 370 virtual machine architecture (this was reference to as 3.1h). Then a version of CP/67 was modified so that it ran on the 370 relate architecture (referred to as 3.1i). For various security reasons ... partly because there were people like MIT students that had access to the Cambridge CP/67 service ... the environment looked like: standard CP/67 running on real 360/67 providing 360/65 and 360/67 virtual machine service a 3.1h operating system running in a 360/67 virtual machine providing 370/145 (both relocate and non-relocate) virtual machines a 3.1i operating system running in a 370/145 relocate virtual machine providing 370/145 (both relocate and non-relocate) virtual machines cms running in a 370/145 non-relocate virtual machine This evironment had been running for a year before the very first 370/145 engineering machine (of any kind) was up to the point that it could be tested. The first time that the "3.1i" system was booted on the first engineering 370/145 machine ... it failed. After some quick diagnostic, it turned out that the engineers had implemented some of the architecture wrong. The operating system was quickly patched to correspond to the incorrect hardware implementation ... and the testing then proceeding succesfully. -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ###### Message-ID: <36993625.68B72172@compuserve.com> Date: Sun, 10 Jan 1999 15:22:14 -0800 From: Dale DePriest X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IBM S/360 References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Newsgroups: alt.folklore.computers Lines: 79 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.idt.net!WCG!arl-news-svc-3.compuserve.com!news-master.compuserve.com!nntp-ntdwwaaw.compuserve.com spam@nowhere.com wrote: > My post indicated concepts, and did not deal in limits. > > Your stated limits applied only to the /65, /67, and /75. The /85 > and /195 (which, I concede, were more S/370 than S/360) could provide > more. Lower numbered machines provided less, both because the memory was > slower, and also because the channels were stealing CPU clicks to operate. > Of course, the /85 and /95 were not real 360's but came much later as pre-cursor 370's. This limits I defined were for numbers not time so memory speed wasn't a factor. I agree that the smaller machines emulated part of the channels with the CPU and were thus different in how the memory mutliplexor worked. > Remember, too, that by current standards the memory on these machines > was incredibly slow. The memory on the /65 through /75 had a read-write > back, if memory (mine) serves correctly, of 600 ns, which indicates an > effective maximum data rate, for the CPU and channels, of about 13.3 > megabytes/second, assuming everything was working on 8 byte units, the > basic memory width. Even my lowly 60MHz Pentium PC has faster memory, Actually 650 nsec full cycle on the 65 and 75 but the main meory had an access time of 1/2 of that number since the last half of the time was used to rewrite the data. Memory was interleaved so that, at least some of the time, the processor was slowed down by the memory write cycle. Of course this only applied to main memory which only went to 1 megabyte. After that you were using extended core which, from IBM had an 8 microsecond cycle time, and from Ampex had a 2 microsecond cycle time (Same as main memory on a model 50). If I remember correctly the /65 microcode had a 200nsec cycle so things couldn't be sped up too much. Of course the /75 was a hardware machine so it didn't have this limit. > Your analysis is flawed in one other respect. The 2870 byte multiplexor > channel could have one or two selector sub-channels attached to it. These > dudes operated just like selector channels for medium speed devices, > though at the cost of limiting the data rate of the byte devices. By > "medium" speed devices, I mean tape drives, though I know of one use of > 2311s through a selector sub. In any event, that adds two additional > "fast" data streams to your analysis. Yes, I was over simplifying but from the memory view they only got the one multiplexor channel interrupt slot. Therefore there had to be mediation at the channel level for these devices. Dale > The fastest "traditional" S/360 I/O device, the 2301 drum, had a data rate > of 1.2 megabytes/second. The 2314, the normal "fast" DASD on these > machines, ran at a rockin' .356 megs/second. 6 2301s attached to 6 > selector channels would have a data rate of 7.2 megs/second, which is > within the maximum possible data rate. Fast PC devices tend to quote > speeds in megabits per second, which sounds impressive until you > convert that to megabytes per second. > > In <3697FE64.D4D16C79@compuserve.com>, Dale DePriest writes: > [snip] > >On a 360 there could be at most 8 devices going to memory. The memory had a > >bus > >traffic cop that provided a path to memory for 1 mutlplexer channel, up to 6 > >selector channels, and the cpu. The cpu had the lowest priority to memory. > >Each selector channel, in turn could be connected to 8 controllers which could > >control up to 8 devices. Later some of these numbers went to 16 but the > >number of devices that could go to memory was limited to 8. A selector > >channel could have only one high speed data transfer going on at a time. A > >multiplexer channel tended to have slow devices like printers and card readers > >and could multiplex mutliple devices. It also did not generally use an > >intermediate controller. > > > >Dale -- > > -- Steve Myers > > The E-mail addresses in this message are private property. Any use of them > to send unsolicited E-mail messages of a commerical nature will be > considered trespassing, and the originator of the message will be sued in > small claims court in Camden County, New Jersey, for the maximum penalty > allowed by law. ###### Message-ID: <3699370E.F35C472F@compuserve.com> Date: Sun, 10 Jan 1999 15:26:06 -0800 From: Dale DePriest X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IBM S/360 References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Newsgroups: alt.folklore.computers Lines: 37 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!news.maxwell.syr.edu!newspeer1.nac.net!WCG!arl-news-svc-3.compuserve.com!news-master.compuserve.com!nntp-ntdwwaaw.compuserve.com Julian Thomas wrote: > In <778ajv$ij9@netaxs.com>, on 01/09/99 > at 07:27 PM, hancock4@bbs.cpcn.com (Lisa or Jeff) said: > > >Physically it was different, the S/360 used core while the S/370 used > >semiconductor memories. > > Not totally true. 370/155 used core memory (the same 2 usec arrays used > in the 360/50) and added a cache. The 155 was a stop gap machine and was replaced with the 158. While it did use 360/50 memory it was a whopping 144 bits wide. Installation required hooking up all of those bits individually. We premounted some of them in a little carrier called a 6-pack to make installation a bit easier. Cache was only 8K of 500 nsec memory. > Also, the S/370 used a higher level of > >integrated circuits than S/360. > > Yes. > > >S/370 introduced hardware virtual memory to the product line and > >additional instructions to the hardware set. > > Again, not initially. Virtual memory was not part of the initial 370 > offering, but came along later. The 155 was replaced by the 158, with > virtual memory and also semiconductor memory arrays. > > > -- > Julian Thomas: jt at epix dot net http://home.epix.net/~jt > Boardmember of POSSI.org - Phoenix OS/2 Society, Inc http://www.possi.org > In the beautiful Finger Lakes Wine Country of New York State! > -- -- > Windows: Just another pane in the glass. ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 10 Jan 1999 15:35:10 -0800 Organization: Wheeler&Wheeler Lines: 10 Message-ID: References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-19.garlic.com X-Newsreader: Gnus v5.6.45/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!newspeer1.nac.net!news.maxwell.syr.edu!rill.news.pipex.net!pipex!ams.uu.net!ffx.uu.net!in5.uu.net!bulb.garlic.com!not-for-mail for those of you familar with 370/145 front panel ... the 370/145 engineering model didn't have any of that ... instead of a button to boot (i.e. IPL) ... there was a knife switch -- -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ####### From: jtNOSPAM@epix.net (Julian Thomas) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Sun, 10 Jan 1999 16:09:18 -0500 Organization: epix Internet Services Lines: 30 Message-ID: <3699177e$1$wg$mr2ice@news.epix.net> References: <778ajv$ij9@netaxs.com> NNTP-Posting-Host: itha-125ppp106.epix.net X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v1.51 b51 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.nyu.edu!newsfeed.sgi.net!news-xfer.epix.net!news1.epix.net!epix-news In <778ajv$ij9@netaxs.com>, on 01/09/99 at 07:27 PM, hancock4@bbs.cpcn.com (Lisa or Jeff) said: >Physically it was different, the S/360 used core while the S/370 used >semiconductor memories. Not totally true. 370/155 used core memory (the same 2 usec arrays used in the 360/50) and added a cache. Also, the S/370 used a higher level of >integrated circuits than S/360. Yes. >S/370 introduced hardware virtual memory to the product line and >additional instructions to the hardware set. Again, not initially. Virtual memory was not part of the initial 370 offering, but came along later. The 155 was replaced by the 158, with virtual memory and also semiconductor memory arrays. -- Julian Thomas: jt at epix dot net http://home.epix.net/~jt Boardmember of POSSI.org - Phoenix OS/2 Society, Inc http://www.possi.org In the beautiful Finger Lakes Wine Country of New York State! -- -- Windows: Just another pane in the glass. ###### From: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 10 Jan 1999 19:34:25 GMT Organization: The National Capital FreeNet Lines: 11 Message-ID: <77avc1$c03@freenet-news.carleton.ca> References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> <77a694$39c@cucumber.demon.co.uk> Reply-To: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) NNTP-Posting-Host: freenet5.carleton.ca X-Given-Sender: ab528@freenet5.carleton.ca (Heinz W. Wiggeshoff) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newshub.northeast.verio.net!newsserver.jvnc.net!xcski.com!freenet-news.carleton.ca!FreeNet.Carleton.CA!ab528 (spam@nowhere.com) writes: > You are correct. The /65 and /67 had 2-way memory interleaving. The > /75 had 4-way memory interleaving. Memory interleaving is of greatest > assistance for long sequential operations from the CPU. It is of less > value for more random access, such as access from channels, which was the > thrust of my post. > > What they really needed was a cache, but that was way off in the future. As in the /360 model 85 ? ###### Newsgroups: alt.folklore.computers From: spam@nowhere.com Subject: Re: IBM S/360 Reply-To: spam@nowhere.com References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> X-Newsreader: IBM NewsReader/2 v1.2.5 Lines: 46 Message-ID: Date: Sun, 10 Jan 1999 22:01:11 GMT NNTP-Posting-Host: 207.103.30.92 X-Trace: news2.voicenet.com 916005671 207.103.30.92 (Sun, 10 Jan 1999 17:01:11 EDT) NNTP-Posting-Date: Sun, 10 Jan 1999 17:01:11 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!howland.erols.net!newsfeed.cwix.com!207.103.147.20!news.voicenet.com!news2.voicenet.com.POSTED!not-for-mail The S/370 165 also used core memory, and was effectively replaced by the 370/168. The 165 was basically a S/360 Model 85, with what amounted to S/360 Mod 50 memory fronted by a cache. In <3699177e$1$wg$mr2ice@news.epix.net>, jtNOSPAM@epix.net (Julian Thomas) writes: >In <778ajv$ij9@netaxs.com>, on 01/09/99 > at 07:27 PM, hancock4@bbs.cpcn.com (Lisa or Jeff) said: > >>Physically it was different, the S/360 used core while the S/370 used >>semiconductor memories. > >Not totally true. 370/155 used core memory (the same 2 usec arrays used >in the 360/50) and added a cache. > >Also, the S/370 used a higher level of >>integrated circuits than S/360. > >Yes. > >>S/370 introduced hardware virtual memory to the product line and >>additional instructions to the hardware set. > >Again, not initially. Virtual memory was not part of the initial 370 >offering, but came along later. The 155 was replaced by the 158, with >virtual memory and also semiconductor memory arrays. > > >-- > Julian Thomas: jt at epix dot net http://home.epix.net/~jt > Boardmember of POSSI.org - Phoenix OS/2 Society, Inc http://www.possi.org > In the beautiful Finger Lakes Wine Country of New York State! > -- -- > Windows: Just another pane in the glass. > > -- Steve Myers The E-mail addresses in this message are private property. Any use of them to send unsolicited E-mail messages of a commerical nature will be considered trespassing, and the originator of the message will be sued in small claims court in Camden County, New Jersey, for the maximum penalty allowed by law. ###### From: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 10 Jan 1999 22:35:40 GMT Organization: The National Capital FreeNet Lines: 19 Message-ID: <77b9vs$g5q@freenet-news.carleton.ca> References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> Reply-To: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) NNTP-Posting-Host: freenet5.carleton.ca X-Given-Sender: ab528@freenet5.carleton.ca (Heinz W. Wiggeshoff) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!newsserver.jvnc.net!xcski.com!freenet-news.carleton.ca!FreeNet.Carleton.CA!ab528 Julian Thomas (jtNOSPAM@epix.net) writes: > In <778ajv$ij9@netaxs.com>, on 01/09/99 > at 07:27 PM, hancock4@bbs.cpcn.com (Lisa or Jeff) said: > >>S/370 introduced hardware virtual memory to the product line and >>additional instructions to the hardware set. > > Again, not initially. Virtual memory was not part of the initial 370 > offering, but came along later. The 155 was replaced by the 158, with > virtual memory and also semiconductor memory arrays. I clearly remember reading that some IBM customers were majorly pissed off that the conversion of a 155 to a 158, and possibly a 165 to a 168 involved a quick visit by the CE to activate the DAT (Dynamic Address Translation) box that was _already in the CPU cabinet_! The statement above may be true for really low-end /370s though. ###### From: bayko@pollux.cs.uregina.ca (John Bayko) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 11 Jan 1999 00:40:32 GMT Organization: University of Regina, Dept. of Computer Science Lines: 21 Message-ID: <77bha0$69k$1@sue.cc.uregina.ca> References: <76p5o4$l8u@netaxs.com> <76upvv$aar@gwis2.circ.gwu.edu> <36944cdd.0@news.destek.net> NNTP-Posting-Host: pollux.cs.uregina.ca Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!news.maxwell.syr.edu!cyclone.bc.net!mongol.sasknet.sk.ca!news.uregina.ca!not-for-mail In article , wrote: >In article <36944cdd.0@news.destek.net>, [...] >> Cough. Digital UNIX has no problem dealing with large number of >> processors. Right now, it's running on hardware that's a step >> or so behind most of the gang on the high end. When this > >??? In terms of clock speed perhaps. But who else has stable, robust and >above all PROVEN 64 bittedness ??? Um, everybody? IBM (AS/400), HP (PA-RISC 8000), Sun (UltraSparc), MIPS/SGI (R4000 and up)... 'Cept Intel, of course, but if you had customers climbing over each other to give you gobs of money for *not* making 64-bit products, would you say "no thanks"? -- John Bayko (Tau). bayko@cs.uregina.ca http://www.cs.uregina.ca/~bayko ###### From: jeffreyb@gwis2.circ.gwu.edu Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Organization: The George Washington University Lines: 27 Message-ID: <77c6gq$78@gwis2.circ.gwu.edu> References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> Date: 11 Jan 1999 01:42:34 -0500 NNTP-Posting-Host: 128.164.127.141 X-Trace: fozzy.nit.gwu.edu 916036785 128.164.127.141 (Mon, 11 Jan 1999 01:39:45 EDT) NNTP-Posting-Date: Mon, 11 Jan 1999 01:39:45 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!newspeer1.nac.net!news.new-york.net!cpk-news-hub1.bbnplanet.com!washdc3-snh1!cpk-news-feed3.bbnplanet.com!news.gtei.net!fozzy.nit.gwu.edu!not-for-mail In article <77b9vs$g5q@freenet-news.carleton.ca>, Heinz W. Wiggeshoff wrote: > I clearly remember reading that some IBM customers were majorly pissed > off that the conversion of a 155 to a 158, and possibly a 165 to a 168 > involved a quick visit by the CE to activate the DAT (Dynamic Address > Translation) box that was _already in the CPU cabinet_! > > The statement above may be true for really low-end /370s though. > George Washington University's potential upgrade path for its brand new, dual-processor S/390 Multiprise system is: 1) Pay IBM great big gobs of money. 2) IBM CE arrives. 3) IBM CE types in a special code, and flips a switch. 4) Voila'! We have a quad-processor mainframe. Don't even think it has to be turned off for the upgrade. As an economist, I find this application of market power by IBM fascinating. Can anyone say if Fujitsu/Amdahl and Hitachi do this, too? --Jeffrey Boulier PS Before anyone jumps over IBM for this, let me point out that practically every software vendor does the same thing with their licensing. ###### From: The Bakers Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 11 Jan 1999 03:26:25 GMT Organization: AT&T WorldNet Services Message-ID: <36996F5B.573FEE4F@dont.even.try> References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <3699370E.F35C472F@compuserve.com> NNTP-Posting-Host: 208.250.114.165 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en Lines: 11 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!195.200.0.51.MISMATCH!newshub.bart.net!ayres.ftech.net!news.ftech.net!dispose.news.demon.net!demon!nntp.news.xara.net!xara.net!news.maxwell.syr.edu!wn4feed!worldnet.att.net!135.173.83.225!attworldnet!newsadm Dale DePriest wrote: > The 155 was a stop gap machine and was replaced with the 158. Wasn't there also a 370/155-II and 370-165-II, or somesuch nomenclature, which was assigned to original issue 370/155 and 370/165 respectively which had been upgraded with DAT hardware, etc. to make them functionally equivalent to the "new" 370/158 and 370/168 ? IIRC anyhow. No doubt some sort of marketing maneuver. ###### Newsgroups: alt.folklore.computers From: spam@nowhere.com Subject: Re: IBM S/360 Reply-To: spam@nowhere.com References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <3699370E.F35C472F@compuserve.com> <36996F5B.573FEE4F@dont.even.try> X-Newsreader: IBM NewsReader/2 v1.2.5 Lines: 37 Message-ID: Date: Mon, 11 Jan 1999 06:00:04 GMT NNTP-Posting-Host: 207.103.30.82 X-Trace: news2.voicenet.com 916034404 207.103.30.82 (Mon, 11 Jan 1999 01:00:04 EDT) NNTP-Posting-Date: Mon, 11 Jan 1999 01:00:04 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!masternews.telia.net!newsfeed.direct.ca!netnews.com!news.voicenet.com!news2.voicenet.com.POSTED!not-for-mail Yes indeed there were. And, you would be impressed with what IBM charged for the upgrade. I believe it was $200K for a 155, and $400K for a 165. And for this, you got a DAT box on a seriously memory challenged machine. The place I worked for in 1972 bought - yes, bought - a 165. In 1974 or 1975, they had a 168 to replace the 165. The 165 was still under power, and they finally sold it, after some long time, some place down south. I have no idea what the poor fool that bought it paid for it. However, before it left the floor they put the DAT box on the machine. I think there were brand-X memory manufacturers that would put semi-conductor memory on these boxes in place of the original core memory, and bring the total memory up to something reasonable. This was not a game IBM played in. In <36996F5B.573FEE4F@dont.even.try>, The Bakers writes: >Dale DePriest wrote: > >> The 155 was a stop gap machine and was replaced with the 158. > >Wasn't there also a 370/155-II and 370-165-II, or somesuch nomenclature, which was >assigned to original issue 370/155 and 370/165 respectively which had been upgraded >with DAT hardware, etc. to make them functionally equivalent to the "new" 370/158 >and 370/168 ? > >IIRC anyhow. No doubt some sort of marketing maneuver. > -- Steve Myers The E-mail addresses in this message are private property. Any use of them to send unsolicited E-mail messages of a commerical nature will be considered trespassing, and the originator of the message will be sued in small claims court in Camden County, New Jersey, for the maximum penalty allowed by law. ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 11 Jan 1999 08:45:42 -0800 Organization: Wheeler&Wheeler Lines: 14 Message-ID: References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> <77d74k$gt9@top.mitre.org> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-19.garlic.com X-Newsreader: Gnus v5.6.45/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!news-raspail.gip.net!news-lond.gip.net!news.gsl.net!gip.net!rill.news.pipex.net!pipex!ams.uu.net!ffx.uu.net!in5.uu.net!bulb.garlic.com!not-for-mail >drums are ibm'ese for fixed head disks. well ... alright ... i added it to the '95 posting after getting questions from the posting in early '90s seemingly coming from no knowledge of either DASD nor drums ... "fixed head disks" seemed to be the simplest throw-away to get over that bit. i tried to get a separate read/write data path (ala 2505 device "exposures) to the 3350 but it got shot down by the vulcan crowd. -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ###### Message-ID: <3699E9DA.5684C45C@trailing-edge.com> From: Tim Shoppa Organization: Trailing Edge Technology X-Mailer: Mozilla 3.03Gold (X11; I; OpenVMS V7.0 DEC 3000 Model 300L) MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> <77d74k$gt9@top.mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 17 Date: Mon, 11 Jan 1999 12:08:58 -0400 NNTP-Posting-Host: 198.232.144.27 X-Trace: audrey2.cais.com 916075023 198.232.144.27 (Mon, 11 Jan 1999 12:17:03 EDT) NNTP-Posting-Date: Mon, 11 Jan 1999 12:17:03 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!howland.erols.net!news-peer1.sprintlink.net!news-backup-west.sprintlink.net!news.sprintlink.net!in1.nntp.cais.net!199.0.216.204.MISMATCH!audrey2.cais.com!not-for-mail Joe Morris wrote: > You could also order 3350 disk drives with a special (rather expensive) > option that placed fixed r/w heads over certain cylinders, allowing > access to the data on these cylinders without suffering the latency > of seek time, The other cylinders of the disk were accessed in typical > disk fashion, moving the head rack to place the heads over the desired > cylinder. This was an option of many of the popular mini- and mainframe oriented SMD drives up until the mid/late 80's. Many of the superminis of the 80's could be set up to synchronize paging/ swapping activities to the rotation rate of the Fuji Eagle to take advantage of these heads, and the logical addressing of the fixed heads is still reflected in some of the distributed Unix-like-OS disktabs. Tim. ###### From: jcmorris@mwunix.mitre.org (Joe Morris) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 11 Jan 1999 15:59:16 GMT Organization: The MITRE Corporation Lines: 24 Message-ID: <77d74k$gt9@top.mitre.org> References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> NNTP-Posting-Host: mwunix.mitre.org Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.axxsys.net!logbridge.uoregon.edu!news.fas.harvard.edu!news.tufts.edu!blanket.mitre.org!news.mitre.org!mwunix!jcmorris A minor nitpick: Anne & Lynn Wheeler writes: >drums are ibm'ese for fixed head disks. Not really; "drums" are members of the class "fixed head DASD". The word is a literal description of the device; the magnetic recording surface was usually a slightly tapered cone on a vertical axis of rotation. Admittedly, AFAIK there was only one production fixed-head DASD device that wasn't a drum: the 2305 FHSD ("Fixed Head Storage Device"). Drums were hideously expensive on a cost-per-byte basis, but they provided the fastest access speed for bulk storage at that point in the timeline of mainframe computers. You could also order 3350 disk drives with a special (rather expensive) option that placed fixed r/w heads over certain cylinders, allowing access to the data on these cylinders without suffering the latency of seek time, The other cylinders of the disk were accessed in typical disk fashion, moving the head rack to place the heads over the desired cylinder. Joe Morris ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 11 Jan 1999 20:31:35 +0100 Organization: My own Private Self Lines: 27 Sender: neil@chonsp.franklin.ch Message-ID: References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> X-Newsreader: Gnus v5.3/Emacs 19.34 jeffreyb@gwis2.circ.gwu.edu writes: > > 3) IBM CE types in a special code, and flips a switch. > > As an economist, I find this application of market power by IBM > fascinating. I call it milking the customers. Somehow does not fit in with all that "serving the customers" crap. OTOH it just shows that customers are sheep. If they would gang up on the vendors such behaviour would vanish quickly. >Can anyone say if Fujitsu/Amdahl and Hitachi do this, too? Hitachi does, according to an colleague of mine who is CE there. But it requires pulling or inserting (I can't remember which) a jumper (but this was 2 years ago, perhaps they have improved it in the mean time). -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ Programming: when you stop hammering around on the computer as if it were a piece of dumb matter and instead tell it what to do for you ###### Sender: marc@dumbcat.snafu.org Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> From: Marco S Hyman Date: 11 Jan 1999 16:11:40 -0800 Message-ID: Organization: S.N.A.F.U. (www.snafu.org) X-Newsreader: Gnus v5.5/Emacs 20.3 Lines: 20 NNTP-Posting-Host: 204.94.187.130 X-Trace: nntp1.ba.best.com 916099901 16686 marc@204.94.187.130 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.berkeley.edu!news2.best.com!news3.best.com!nntp1.ba.best.com!not-for-mail Neil Franklin writes: > I call it milking the customers. Somehow does not fit in with all that > "serving the customers" crap. Ahhh, you sound like one who has not yet learned that there is no relation between the cost of an item and its price. The price is often based upon customer perception. In this case the customer perceives that a quad processor is worth more than a dual processor machine and is willing to pay for that perception. A successful business is one who manages to keep costs below the price. Doesn't always happen. It is some times the case that the low end of a range of products costs MORE than the price. This may be an acceptable thing if it gets customers into a product line where upgrades occur and the loss can be turned into an eventual profit. But I suppose you are against that, too. // marc ###### From: "Don Chiasson" Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Mon, 11 Jan 1999 19:07:33 -0500 Organization: UUNET Canada News Transport Lines: 20 Message-ID: <77e3o0$10o$1@nntp2.uunet.ca> References: <778avc$jka@netaxs.com> NNTP-Posting-Host: 209.167.85.20 X-Newsreader: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!cyclone.news.idirect.com!island.idirect.com!news1.tor.metronet.ca!news1.cal.metronet.ca!news.uunet.ca!not-for-mail Lisa or Jeff wrote in message <778avc$jka@netaxs.com>... >It is so incredible to believe that we go to our WalMart and bring home >a 16Meg memory computer for our kids to play with yet back then companies >were buying machines with 16K of memory. Before S/360, machines like >the 1401 came in as little as 1.2 (or 1.4?) thousand characters of memory, >and maxed at 16,000. Even after solid state memory replaced core, memory >was still expensive, in 1980, a big corporate wide mainframe could >have 8 Meg. Back in the 70's, I worked with Honeywell H316 minicomputers and as I recall core memory (1.5 microsecond) cost $4k for 4k words, that is for 8k bytes. In other words, 1MB of memory, if you could get it, would cost half a million dollars. The H316's could hold a maximum of 32k words, or 64k bytes. Don ###### From: jeffreyb@gwis2.circ.gwu.edu Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Organization: The George Washington University Lines: 36 Message-ID: <77e8nu$1bf@gwis2.circ.gwu.edu> References: <76p5o4$l8u@netaxs.com> <36918a48.0@news.destek.net> <76upvv$aar@gwis2.circ.gwu.edu> <36944cdd.0@news.destek.net> Date: 11 Jan 1999 20:32:46 -0500 NNTP-Posting-Host: 128.164.127.141 X-Trace: fozzy.nit.gwu.edu 916104597 128.164.127.141 (Mon, 11 Jan 1999 20:29:57 EDT) NNTP-Posting-Date: Mon, 11 Jan 1999 20:29:57 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!washdc3-snh1!cpk-news-feed3.bbnplanet.com!news.gtei.net!fozzy.nit.gwu.edu!not-for-mail In article <36944cdd.0@news.destek.net>, Dave Cherkus wrote: >Cough. Digital UNIX has no problem dealing with large number of >processors. Right now, it's running on hardware that's a step >or so behind most of the gang on the high end. When this >hardware came out, it set world records. Unfortunately for >CPQ/DEC/whatever, the competition stole a day's march on them. > I was wrong about my wildfire claim - it seems I was misremembering some stuff from a long and horrible DEC-performance flame war a while back. Replace that with "At the present time, Digital Unix's ability to cope on extremely multiple-processor systems can't be stated with any certainty." > Companies with >large SMPs publish the absolute numbers of the full-blown system, but >don't tend to publish curves showing the incremental game of adding each >CPU, so you don't know much about anyone's ability to deal with a large >number of processors. I did get some data from Sun describing U-10000 performance. At least SPEC_rate wise, it was impressively linear (well over 90%). I haven't seen anything from SGI, but they'd never be able to sell their 128-CPU boxes without some degree of scalability. > >I'd even settle for seeing the curve showing the gain for each 2 or 4 >CPUs. When you do see such numbers, they tend to be for scientific >workloads [...] Two good places to go for SPEC "scientific benchmarks" of this sort are www.spec.org (duh) and John di Marco's collection of SPEC '92 & '95 results available from ftp.cs.toronto.edu/pub/spectable. --Jeffrey Boulier ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 12 Jan 1999 00:12:59 GMT Organization: Net Access BBS Lines: 11 Message-ID: <77e42b$1vj@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.idt.net!news.maxwell.syr.edu!newsfeed.cwix.com!24.92.32.21!cyclone.nycap.rr.com!news.nycap.rr.com!news-toy.newsread.com!netaxs.com!newsread.com!newshog.newsread.com!netaxs.newsread.com!bbs.cpcn.com!root > As an economist, I find this application of market power by IBM > fascinating. Can anyone say if Fujitsu/Amdahl and Hitachi do this, too? Well, all I can tell you is that my employer, who watches their money closely, replaced their Hitachi mainframes with a new IBM box. I trust that the IBM box offered a better value. IBM's "market power" is but a shadow of what it once was. First, there are other mainframe makers, both plug compatibles (Hitachi, Amdahl) and other systems (Unisys, Bull), as well as other approaches (networked intermediate boxes such as Sun). ###### From: "Peter Hendén" Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Tue, 12 Jan 1999 02:02:42 +0100 Organization: Teknisk Dokumentation AB Lines: 26 Message-ID: <77farh$msi$2@cubacola.tninet.se> References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> NNTP-Posting-Host: du66-146.ppp.algonet.se X-Trace: cubacola.tninet.se 916139697 23442 195.100.146.66 (12 Jan 1999 11:14:57 GMT) X-Complaints-To: abuse@algo.net NNTP-Posting-Date: 12 Jan 1999 11:14:57 GMT X-Newsreader: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!masternews.telia.net!news-feed.inet.tele.dk!bofh.vszbr.cz!howland.erols.net!nntp.abs.net!newsfeed1.telenordia.se!pepsi.tninet.se!not-for-mail Neil Franklin wrote in message ... >jeffreyb@gwis2.circ.gwu.edu writes: >> 3) IBM CE types in a special code, and flips a switch. >> As an economist, I find this application of market power by IBM >> fascinating. >I call it milking the customers. Somehow does not fit in with all that >"serving the customers" crap. >OTOH it just shows that customers are sheep. If they would gang up on >the vendors such behaviour would vanish quickly. Sorry for butting in like this, but what exactly is so wrong with this behaviour? Regards, Peter -- Peter Hendén http://www.algonet.se/~phenden ICQ: 14672398 Teknisk Dokumentation AB http://www.tdab.com ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 12 Jan 1999 10:30:45 -0800 Organization: Wheeler&Wheeler Lines: 23 Message-ID: References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> <77g3lk$6vq$1@vixen.cso.uiuc.edu> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-19.garlic.com X-Newsreader: Gnus v5.6.45/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newspump.monmouth.com!newspeer.monmouth.com!worldfeed.news.gte.net!uunet!in1.uu.net!bulb.garlic.com!not-for-mail cp/67 started out being less than a single tray of "binary" cards. vm/370 simulated card decks got much larger ... not only because there was much more code ... but also typically upwards of half the cards in any particular txt/binary deck was the source code tracking information (PTFs, macro libraries, updates, source libraries, etc). the output of such a load was printed output of all the entry points in each module ... plus all the source code tracking information. I remember being in madrid in the mid-80s ... and going to a theater showing some 30? minute drama "short" done at the university ... in several shots there was a wall of TV sets (20-30?) all "scrolling" the same information at around 1200 baud. I felt funny being able to recognize it was the VM/370 "loadmap" (i.e. output from the binary program load) ... i felt even funnier being able to recognize the year & month of the system based on the source code information scrolling past at 1200 baud. -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ###### From: glass2@glass2.lexington.ibm.com Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 12 Jan 1999 14:31:09 GMT Organization: IBM Austin Lines: 52 Message-ID: <77fmbd$nve$1@ausnews.austin.ibm.com> References: <778avc$jka@netaxs.com> <77e3o0$10o$1@nntp2.uunet.ca> Reply-To: wa4qal@vnet.ibm.com NNTP-Posting-Host: glass2.cv.lexington.ibm.com X-Newsreader: IBM NewsReader/2 2.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news.idt.net!nyd.news.ans.net!abq.news.ans.net!newsfeeds.ans.net!news.chips.ibm.com!newsfeed.btv.ibm.com!rtpnews.raleigh.ibm.com!ausnews.austin.ibm.com!not-for-mail In <77e3o0$10o$1@nntp2.uunet.ca>, "Don Chiasson" writes: > >Lisa or Jeff wrote in message <778avc$jka@netaxs.com>... >>It is so incredible to believe that we go to our WalMart and bring home >>a 16Meg memory computer for our kids to play with yet back then companies >>were buying machines with 16K of memory. Before S/360, machines like >>the 1401 came in as little as 1.2 (or 1.4?) thousand characters of memory, >>and maxed at 16,000. Even after solid state memory replaced core, memory >>was still expensive, in 1980, a big corporate wide mainframe could >>have 8 Meg. > > >Back in the 70's, I worked with Honeywell H316 minicomputers and as I recall >core memory (1.5 microsecond) cost $4k for 4k words, that is for 8k bytes. >In other words, 1MB of memory, if you could get it, would cost half a >million dollars. The H316's could hold a maximum of 32k words, or 64k bytes. > > Don > Time for an interesting factoid. In April 1957, IBM set a low price record for (core) memory. For the first time in history, memory prices dropped below US $1.00 per bit. This was the IBM model 738 Magnetic Core Storage unit. It contained 32768 words of 36 bits (1,179,648 bits). It originally sold for US $1,040,000, and was later reduced to US $940,000. The model 738 was the first IBM memory product to use transistors. Another IBM memory product, the model 737 Magnetic Core Storage unit, consisted of 4906 words (147,456 bits), and was rented at US $6100 per month. This unit had a cycle time of 9 microseconds, was 98 inches long, 29 inches wide, and 64 inches high, and weighed 1620 pounds (736 kilograms)! Ok, who wants to see prices rolled back to what they were in 1957? :*) The B series of the IBM S/360 came equipped with 4K of memory (4K, NOT 4M). I can remember that while I was going to school, the university made a big deal out of how they had just upgraded their mainframe (an IBM S/370 model 168, I think) from 2M to 4M of real memory. Dave P.S. Standard Disclaimer: I work for them, but I don't speak for them. Reference: Charles J. Bashe, Lyle R. Johnson, John H. Palmer, Emerson W. Pugh, "IBM's Early Computers", 1986, MIT Press ###### From: Bob Shair Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 12 Jan 1999 18:18:28 GMT Organization: University of Illinois at Urbana-Champaign Lines: 21 Message-ID: <77g3lk$6vq$1@vixen.cso.uiuc.edu> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> NNTP-Posting-Host: delphi.itg.uiuc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-Newsreader: TIN [UNIX 1.3 unoff BETA 970217; 000047148900 AIX 2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!nntp.abs.net!news-peer-east1.sprintlink.net!Sprint!news-peer1.sprintlink.net!news.sprintlink.net!vixen.cso.uiuc.edu!delphi.itg.uiuc.edu!not-for-mail Dave Cherkus wrote: > After booting countless virtual card decks, I really wanted to find a > way to get my virtual UNIX card deck punched onto real cards, and find > a real card reader, and boot the mother. I'm sure the place I worked > had all the required facilities, but in my own mind I could never > justify the expense. Sigh, a big opportunity lost forever... I did this once, just for the fun of it (I was building VM/370, not Unix, at Parkland College about 1980). It wasn't that exciting. It produced about 4 trays of cards (perhaps 11000 of them) which booted (standalone) from the card reader just fine. You didn't miss much. -- Bob Shair rmshair@delphi.itg.uiuc.edu Open Systems Specialist Champaign, Illinois /* Opinions expressed are mine... go get your own! */ ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 12 Jan 1999 21:39:50 +0100 Organization: My own Private Self Lines: 87 Sender: neil@chonsp.franklin.ch Message-ID: References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> X-Newsreader: Gnus v5.3/Emacs 19.34 Marco S Hyman writes: > > Neil Franklin writes: > > > I call it milking the customers. Somehow does not fit in with all that > > "serving the customers" crap. > > Ahhh, you sound like one who has not yet learned that there is > no relation between the cost of an item and its price. Nope. I have noticed this a long time ago. I just simply regard it as an Bad Thing, that it is so. I was not critisizing the claim that it exists, rather its acceptance by society. > The price is often based upon customer perception. Or missperception. Often deliberately generated by the Marketroids. > In this case the customer > perceives that a quad processor is worth more than a dual processor > machine and is willing to pay for that perception. Nothing against this. You can get more done with it. And it costs more to make. Paying more for more is a sound principle. What is not OK is demanding for acces to 2 processors the price that can cover the costs of putting 4 there. And then there is the point about 2 processors standing there idling, a.k.a. waste. They costed to be made, and they could be doing work. It is not as if users were drowning in surplus processor power (if you are, could you tell me where it is and how to get at it). > A successful business is one who manages to keep costs below the price. > Doesn't always happen. Fully in agreement there. It cost > price for a longer time the business goes the way of Hayes :-). Basic resource starvation. > It is some times the case that the low end > of a range of products costs MORE than the price. This may be an > acceptable thing if it gets customers into a product line where > upgrades occur and the loss can be turned into an eventual profit. A value system (loss/profit) and behaviour which may be good for the vendor. But most likely not for the customers: - the lower "model" customer who pays for say 3 processors (assuming price < cost by 25%) and only gets 2 - the upper "model" customer who pays for 5 (someone has to cover them 25% loss above) and only gets 4 The 2 wasted processors have to be produced. The cost for this is being payed for by someone (assuming the vendor is not making an loss and going Hayes), but no one is getting their power. > But I suppose you are against that, too. Yep. Absolutely. 1 Waste, 2 deception, 3 damage to the customers, 4 dishonnesty (3 combined with the "serve the customer" bla bla). That's 4 things any decent person finds reprehensible. And certainly not something to be admired. Historical cite from Adam Smith, Wealth of Nations (on manufacturers): an order of men, whose interest is never exactly the same with that of the public, who have generally an interest to deceive and even to oppress the public, and who accordingly have, upon many occa- sions, both deceived and oppressed it. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ Programming: when you stop hammering around on the computer as if it were a piece of dumb matter and instead tell it what to do for you ###### From: Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Tue, 12 Jan 1999 21:00:22 -0500 Organization: Kettering University (formerly GMI E&MI) - Flint MI Lines: 39 Message-ID: References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> <77farh$msi$2@cubacola.tninet.se> NNTP-Posting-Host: nova.kettering.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE In-Reply-To: <77farh$msi$2@cubacola.tninet.se> Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!howland.erols.net!netnews.com!chnws02.mediaone.net!24.131.128.14!elnws02.ce.mediaone.net!24.131.1.12!denws01.mw.mediaone.net!news.gmi.edu!nova.kettering.edu!lee1089 On Tue, 12 Jan 1999, Peter Hend=E9n wrote: > Neil Franklin wrote in message ... > >jeffreyb@gwis2.circ.gwu.edu writes: > >> 3) IBM CE types in a special code, and flips a switch. >=20 > >> As an economist, I find this application of market power by IBM > >> fascinating. >=20 > >I call it milking the customers. Somehow does not fit in with all that > >"serving the customers" crap. >=20 > >OTOH it just shows that customers are sheep. If they would gang up on > >the vendors such behaviour would vanish quickly. >=20 > Sorry for butting in like this, but what exactly is so wrong with > this behaviour? I have to agree. The customer paid for a system advertised with the capabilities it had before IBM typed in their code and hit their switch. Then they paid more for a system with the capabilities after IBM hit the switch. Sure IBM didn't say that no extra hardware would be needed for the upgrade but the company obviously felt the added functionality was worth the price no matter what the upgrade itself consisted of. Basically, they got at least what they were willing to pay for both times. ___________________________________________________________________________= _ | "A little nonsense now and then, | "If it walks out of the fridge, let Is relished by the wisest men." | it go" -- John Dougherty --W.W. | "If it loves you it will come back." | -- Ian Davis __________________________________|________________________________________= _ Theta Xi=20 Kappa Sigma ###### Message-ID: <369BC511.12ED6FE2@bio.vu.nl> Date: Tue, 12 Jan 1999 22:56:33 +0100 From: Thomas Tonino X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.2.0-pre6 i586) MIME-Version: 1.0 Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> <77d74k$gt9@top.mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 15 NNTP-Posting-Host: node10605.a2000.nl X-Trace: newton.a2000.nl 916178203 2202 24.132.6.5 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!feeder.qis.net!news-peer.gip.net!news.gsl.net!gip.net!news.idt.net!newsfeed1.swip.net!swipnet!news.tele2.nl!newsgate.cistron.nl!het.net!pascal.a2000.nl!62.108.1.23.MISMATCH!newton.a2000.nl!not-for-mail I once had a fixed-head disk. It was ceramic, about 25 cm diameter and 1 cm thick. The heads blocks, I think 10 heads or so per block, were set in a thick aluminum plate and fixed from the rim. The thing was covered with a stamped steel over and driven with a motor I estimate at 100 - 200 watts with a 2 to 1 belt drive. I think the disk will have been spinning around 6000 RPM, but maybe just half of that. The machine contained more of these. Got it from a friend who took it out a dumpster, later gave it to other friend. I think it was in my possesion around 8 years back. I do not remember any manufacterer being evident. Thomas ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 12 Jan 1999 23:36:17 -0800 Organization: Wheeler&Wheeler Lines: 26 Message-ID: References: <76p5o4$l8u@netaxs.com> <369799c4$1$wg$mr2ice@news.epix.net> <3697db6d.0@news.destek.net> <3697FE64.D4D16C79@compuserve.com> <77d74k$gt9@top.mitre.org> <369cc95a.110177830@enews.newsguy.com> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-19.garlic.com X-Newsreader: Gnus v5.6.45/Emacs 20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!newsfeed.cwix.com!158.43.192.17!rill.news.pipex.net!pipex!ams.uu.net!ffx.uu.net!in2.uu.net!bulb.garlic.com!not-for-mail cp/67 originated with people from cambridge science center and some work being down by people from lincoln labs ... summer of 68 ... a couple of the people left and formed NCSS offering enhanced CP/67 online service ... another group left and formed IDC (interactive data) ... NCSS was down in Stanford Conn ... IDC was out in waltham mass. I was undergraduate ... there was an IBM sponsored class on CP/67 that summer down someplace in LA ... I got pressed into teaching part of the CP/67 class ... possibly because one or more of the IBM'ers had left and gone to NCSS. back then you could get CP/67 from IBM ... sort of like you can get linux today ... all the source and do whatever you wanted with it. Lots of places ... including universities got copies with source ... and large numbers (well not large numbers by today's standards) ... but still significant numbers ... took the system & source and did various things with it. all of this well before VM/370. Tymshare later used VM/370 to offer online service ... mid-70s -- -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 13 Jan 1999 03:05:08 GMT Organization: Net Access BBS Lines: 3 Message-ID: <77h2h4$5bh@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newshub.northeast.verio.net!news-xfer.newsread.com!netaxs.com!newsread.com!netaxs.newsread.com!bbs.cpcn.com!root Do they know for sure that all IBM had to do was flip a simple switch to upgrade the system to a more powerful model? Maybe there was more to it than was obvious. ###### From: meowing@banet.net (Fluffy) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 References: <77h2h4$5bh@netaxs.com> Organization: If one may meow, all may meow. X-P-Tickle: Mixy X-P-Meow: Meow Mail-Copies-To: never X-URL: http://members.tripod.com/~gerglery/ X-Newsreader: slrn (0.9.5.3-canlock UNIX) Message-ID: <77h3th$jge@meow.invalid> Cancel-Lock: sha1:Bn6L3+VLUTPQGaLmvYa6KRPeg4s= NNTP-Posting-Host: 32.101.27.185 Date: 13 Jan 1999 03:29:00 GMT X-Trace: 13 Jan 1999 03:29:00 GMT, 32.101.27.185 Lines: 11 X-Notice: Items posted that violate the IBM.NET Acceptable Use Policy X-Notice: should be reported to postmaster@ibm.net X-Complaints-To: postmaster@ibm.net Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!nntp.abs.net!news-peer.gip.net!news.gsl.net!gip.net!newsm.ibm.net!ibm.net!news3.ibm.net!32.101.27.185 Lisa or Jeff wrote: > Do they know for sure that all IBM had to do was flip a simple switch to > upgrade the system to a more powerful model? Maybe there was more to it > than was obvious. This magic-code approach has been common with the big vendors' software products for a long time too, so the idea doesn't seem all too odd to me. OS login limits are the most common, but features get enabled this way too (DECnet routing in VMS, for one). -- "Meow." --me ###### From: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 13 Jan 1999 03:57:23 GMT Organization: The National Capital FreeNet Lines: 8 Message-ID: <77h5j3$m4s@freenet-news.carleton.ca> References: <77h2h4$5bh@netaxs.com> Reply-To: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) NNTP-Posting-Host: freenet3.carleton.ca X-Given-Sender: ab528@freenet3.carleton.ca (Heinz W. Wiggeshoff) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news-feed.inet.tele.dk!bofh.vszbr.cz!newshub.northeast.verio.net!newsserver.jvnc.net!xcski.com!freenet-news.carleton.ca!FreeNet.Carleton.CA!ab528 Lisa or Jeff (hancock4@bbs.cpcn.com) writes: > Do they know for sure that all IBM had to do was flip a simple switch to > upgrade the system to a more powerful model? Maybe there was more to it > than was obvious. Of course. That's why they get $$$$$/hour. ###### Message-ID: <369CCF6B.48877D79@compuserve.com> Date: Wed, 13 Jan 1999 08:52:59 -0800 From: Dale DePriest X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: IBM S/360 References: <77h2h4$5bh@netaxs.com> <369caee4.24549851@news.bright.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Newsgroups: alt.folklore.computers Lines: 47 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!195.252.142.12!newsfeed.tli.de!newsfeed.nacamar.de!isdnet!arl-news-svc-4.compuserve.com!news-master.compuserve.com!nntp-ntawwabp.compuserve.com deke.spamblock@generous.net wrote: > On 13 Jan 1999 03:05:08 GMT, hancock4@bbs.cpcn.com (Lisa or Jeff) wrote: > > >Do they know for sure that all IBM had to do was flip a simple switch to > >upgrade the system to a more powerful model? Maybe there was more to it > >than was obvious. > > If it were as simple as flipping a switch, don't you think users would have > passed along the information as to where the switch was, and which way it needed > to be switched? > > I had heard that there were traces on a board that needed to be cut or a wire > soldered in place instead of a switch - seems silly to spend $5 on something as > unreliable as a switch when it's only going to be switched once. > > But in any case, the *real* key to the upgrade was getting the operating system > to recognize all the hardware that was physically present. > > I don't think IBM is to be faulted for allowing smaller shops to have a crippled > machine at a lower cost, and I cannot imagine that the smaller shops felt > cheated. The larger shops would have had to pay still more for their machines > had not IBM been able to spread development costs over a larger installed base. > > deacon "uh, waiter? I'd like a half-order of the all-you-can-eat buffet" blues > It was also true that the faster machines required more maintenance. So there was costs to IBM in supporting a faster machine. They failed more often and were more critical of timing problems in the machine. Almost every release of the OS caused timing problems and other latent hardware problems to surface requiring extensive maintenance. Dale > > > ------------------------ > Let love find you! http://generous.net > A list for flirting generousSingles-subscribe@onelist.com > Over The Hill Gang generousSinglesOTHG-subscribe@onelist.com > College and younger generousTeens-subscribe@onelist.com > Lots of Personal Ads generousProfiles-subscribe@onelist.com > If it's not 'just the way you are', it's not love.... ###### From: mark@hubcap.clemson.edu (Mark Smotherman) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 13 Jan 1999 11:49:46 -0500 Organization: Clemson University Lines: 13 Message-ID: <77iira$spu$1@hubcap.clemson.edu> References: <77h2h4$5bh@netaxs.com> <369caee4.24549851@news.bright.net> NNTP-Posting-Host: hubcap.clemson.edu Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!netnews.com!newspeer1.nac.net!news.maxwell.syr.edu!news-peer.gip.net!news.gsl.net!gip.net!newspump.sol.net!nntp.msen.com!170.140.150.7.MISMATCH!finch!hubcap.clemson.edu!not-for-mail deke.spamblock@generous.net writes: >If it were as simple as flipping a switch, don't you think users would have >passed along the information as to where the switch was, and which way it >needed to be switched? Years ago, I worked at a (non-IBM) installation where the CE showed the operators where the jumper was located; so, during crunch times (e.g., end-of-year/etc. processing) the operators would occasionally remove the jumper and speed up the machine. -- Mark Smotherman, Computer Science Dept., Clemson University, Clemson, SC http://www.cs.clemson.edu/~mark/homepage.html ###### From: deke.spamblock@generous.net Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Wed, 13 Jan 1999 14:41:00 GMT Organization: GenerousCity is a virtue - find romance at http://generous.net Lines: 39 Message-ID: <369caee4.24549851@news.bright.net> References: <77h2h4$5bh@netaxs.com> NNTP-Posting-Host: paul-cas1-cs-10.dial.bright.net X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!nntp.abs.net!news-xfer.siscom.net!streamer1.cleveland.iagnet.net!NewsNG.Chicago.Qual.Net!205.212.123.11!news.bright.net!not-for-mail On 13 Jan 1999 03:05:08 GMT, hancock4@bbs.cpcn.com (Lisa or Jeff) wrote: >Do they know for sure that all IBM had to do was flip a simple switch to >upgrade the system to a more powerful model? Maybe there was more to it >than was obvious. If it were as simple as flipping a switch, don't you think users would have passed along the information as to where the switch was, and which way it needed to be switched? I had heard that there were traces on a board that needed to be cut or a wire soldered in place instead of a switch - seems silly to spend $5 on something as unreliable as a switch when it's only going to be switched once. But in any case, the *real* key to the upgrade was getting the operating system to recognize all the hardware that was physically present. I don't think IBM is to be faulted for allowing smaller shops to have a crippled machine at a lower cost, and I cannot imagine that the smaller shops felt cheated. The larger shops would have had to pay still more for their machines had not IBM been able to spread development costs over a larger installed base. deacon "uh, waiter? I'd like a half-order of the all-you-can-eat buffet" blues ------------------------ Let love find you! http://generous.net A list for flirting generousSingles-subscribe@onelist.com Over The Hill Gang generousSinglesOTHG-subscribe@onelist.com College and younger generousTeens-subscribe@onelist.com Lots of Personal Ads generousProfiles-subscribe@onelist.com If it's not 'just the way you are', it's not love.... ###### From: Lee Courtney Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Wed, 13 Jan 1999 10:50:23 -0800 Organization: Monterey Software Group Inc. +1 (650) 964-7052 Lines: 56 Message-ID: <369CEAEF.CF8CAB0D@slip.net> References: <77h2h4$5bh@netaxs.com> <369caee4.24549851@news.bright.net> NNTP-Posting-Host: sf-usr1-7-135.dialup.slip.net Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CFC3180E4BD763AF35C91A75" X-Mailer: Mozilla 4.04 [en] (Win95; I) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!news-feed1.eu.concert.net!btnet-peer!btnet!rill.news.pipex.net!pipex!newsfeed.slip.net!news.slip.net!not-for-mail --------------CFC3180E4BD763AF35C91A75 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBM is not the only vendor to perform this feat. In the early 80's when Hewlett-Packard provided a 'hardware upgrade' for the HP3000 Series 68 to the Series 70, customers purchasing the upgrade received 1)a new nameplate for the CPU and 2)a (small) tape with updated micro-code. Many cusotmers expressed 'disappointment' in not actually receiving new boards as had been the case with earlier upgrades. I was impressed with how Product Marketing (I was still in the MPE Lab) was able to successfully position the upgrade and charge big $. The CPUs on many of HP's RISC systems differ only in the amount of cache and clock-speed. Lee Courtney President -- Monterey Software Group Inc. EMail: leec AT slip DOT net 1350 Pear Avenue Voice: 650-964-7052 Suite J Fax: 650-964-6735 Mountain View, California 94043-1302 Pager: 408-237-1705 www.editcorp.com/Businesses/MontereySoftware --------------CFC3180E4BD763AF35C91A75 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit IBM is not the only vendor to perform this feat. In the early 80's when Hewlett-Packard provided a 'hardware upgrade' for the HP3000 Series 68 to the Series 70, customers purchasing the upgrade received 1)a new nameplate for the CPU and 2)a (small) tape with updated micro-code. Many cusotmers expressed 'disappointment' in not actually receiving new boards as had been the case with earlier upgrades. I was impressed with how Product Marketing (I was still in the MPE Lab) was able to successfully position the upgrade and charge big $. The CPUs on many of HP's RISC systems differ only in the amount of cache and clock-speed.

Lee Courtney
President
--
Monterey Software Group Inc.          EMail: leec AT slip DOT net
1350 Pear Avenue                      Voice: 650-964-7052
Suite J                               Fax:   650-964-6735
Mountain View, California 94043-1302  Pager: 408-237-1705

www.editcorp.com/Businesses/MontereySoftware
  --------------CFC3180E4BD763AF35C91A75-- ###### From: jtNOSPAM@epix.net (Julian Thomas) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Wed, 13 Jan 1999 17:11:22 -0500 Organization: epix Internet Services Lines: 21 Message-ID: <369d1bac$1$wg$mr2ice@news.epix.net> References: <77h2h4$5bh@netaxs.com> NNTP-Posting-Host: itha-125ppp68.epix.net X-Newsreader: MR/2 Internet Cruiser Edition for OS/2 v1.51 b51 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!howland.erols.net!news-peer1.sprintlink.net!news-backup-west.sprintlink.net!news.sprintlink.net!news-xfer.epix.net!news1.epix.net!epix-news In <77h2h4$5bh@netaxs.com>, on 01/13/99 at 03:05 AM, hancock4@bbs.cpcn.com (Lisa or Jeff) said: >Do they know for sure that all IBM had to do was flip a simple switch to >upgrade the system to a more powerful model? Maybe there was more to it >than was obvious. There was actually an earlier instance of this "upgrade" mechanism - before 360. Needing a "competitive" line of EAM (punched card) equipment, IBM introduced the 'series 50' line in the late '50s. The difference between a standard unit and a series 50 was a speed reducer gear or something like that - easily replaceable for an upgrade. -- Julian Thomas: jt at epix dot net http://home.epix.net/~jt Boardmember of POSSI.org - Phoenix OS/2 Society, Inc http://www.possi.org In the beautiful Finger Lakes Wine Country of New York State! -- -- Error: Keyboard not attached. Press F1 to continue. ###### From: yuska@bgs.com Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Wed, 13 Jan 1999 19:04:17 GMT Organization: Deja News - The Leader in Internet Discussion Lines: 41 Message-ID: <77iqn8$6p7$1@nnrp1.dejanews.com> References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> NNTP-Posting-Host: 204.165.159.3 X-Article-Creation-Date: Wed Jan 13 19:04:17 1999 GMT X-Http-User-Agent: Mozilla/4.04 [en] (X11; I; SunOS 5.5.1 sun4m) X-Http-Proxy: 1.0 x4.dejanews.com:80 (Squid/1.1.22) for client 204.165.159.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!howland.erols.net!news.maxwell.syr.edu!nntp2.dejanews.com!nnrp1.dejanews.com!not-for-mail In article <77c6gq$78@gwis2.circ.gwu.edu>, jeffreyb@gwis2.circ.gwu.edu wrote: > In article <77b9vs$g5q@freenet-news.carleton.ca>, > Heinz W. Wiggeshoff wrote: > > I clearly remember reading that some IBM customers were majorly pissed > > off that the conversion of a 155 to a 158, and possibly a 165 to a 168 > > involved a quick visit by the CE to activate the DAT (Dynamic Address > > Translation) box that was _already in the CPU cabinet_! > > > > The statement above may be true for really low-end /370s though. > > > > George Washington University's potential upgrade path for its > brand new, dual-processor S/390 Multiprise system is: > > 1) Pay IBM great big gobs of money. > 2) IBM CE arrives. > 3) IBM CE types in a special code, and flips a switch. > 4) Voila'! We have a quad-processor mainframe. Don't even think it has to > be turned off for the upgrade. > > As an economist, I find this application of market power by IBM > fascinating. Can anyone say if Fujitsu/Amdahl and Hitachi do this, too? > > --Jeffrey Boulier > > PS Before anyone jumps over IBM for this, let me point out that > practically every software vendor does the same thing with their > licensing. The practice of switched upgrades was not restricted to IBM. In the seventies, CDC made two machines, the CYBER 72 and CYBER 73, which differed only in clock speed and about 250k in price. The upgrade consisted of changing the clock module. I still have one of the clock modules. Joe Yuska > -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ###### Newsgroups: alt.folklore.computers From: spam@nowhere.com Subject: Re: IBM S/360 Reply-To: spam@nowhere.com References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> <77iqn8$6p7$1@nnrp1.dejanews.com> X-Newsreader: IBM NewsReader/2 v1.2.5 Lines: 56 Message-ID: Date: Wed, 13 Jan 1999 20:30:14 GMT NNTP-Posting-Host: 207.103.30.186 X-Trace: news3.voicenet.com 916259414 207.103.30.186 (Wed, 13 Jan 1999 15:30:14 EDT) NNTP-Posting-Date: Wed, 13 Jan 1999 15:30:14 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!masternews.telia.net!news-nyc.telia.net!feeder.qis.net!news-peer.gip.net!news.gsl.net!gip.net!news.voicenet.com!news3.voicenet.com.POSTED!not-for-mail It wasn't just CPUs. The 2501 came in two models: 600 CPM and 1000 CPM. The difference was the timing chip and a pully and belt. In <77iqn8$6p7$1@nnrp1.dejanews.com>, yuska@bgs.com writes: >In article <77c6gq$78@gwis2.circ.gwu.edu>, > jeffreyb@gwis2.circ.gwu.edu wrote: >> In article <77b9vs$g5q@freenet-news.carleton.ca>, >> Heinz W. Wiggeshoff wrote: >> > I clearly remember reading that some IBM customers were majorly pissed >> > off that the conversion of a 155 to a 158, and possibly a 165 to a 168 >> > involved a quick visit by the CE to activate the DAT (Dynamic Address >> > Translation) box that was _already in the CPU cabinet_! >> > >> > The statement above may be true for really low-end /370s though. >> > >> >> George Washington University's potential upgrade path for its >> brand new, dual-processor S/390 Multiprise system is: >> >> 1) Pay IBM great big gobs of money. >> 2) IBM CE arrives. >> 3) IBM CE types in a special code, and flips a switch. >> 4) Voila'! We have a quad-processor mainframe. Don't even think it has to >> be turned off for the upgrade. >> >> As an economist, I find this application of market power by IBM >> fascinating. Can anyone say if Fujitsu/Amdahl and Hitachi do this, too? >> >> --Jeffrey Boulier >> >> PS Before anyone jumps over IBM for this, let me point out that >> practically every software vendor does the same thing with their >> licensing. > >The practice of switched upgrades was not restricted to IBM. In the >seventies, CDC made two machines, the CYBER 72 and CYBER 73, which differed >only in clock speed and about 250k in price. The upgrade consisted of >changing the clock module. I still have one of the clock modules. > >Joe Yuska > >> > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own -- Steve Myers The E-mail addresses in this message are private property. Any use of them to send unsolicited E-mail messages of a commerical nature will be considered trespassing, and the originator of the message will be sued in small claims court in Camden County, New Jersey, for the maximum penalty allowed by law. ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 13 Jan 1999 22:36:12 GMT Organization: Net Access BBS Lines: 23 Message-ID: <77j74s$l3f@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!howland.erols.net!feed1.news.rcn.net!rcn!chippy.visi.com!news-out.visi.com!uunet!in3.uu.net!news-nb.rutgers.edu!news-toy.newsread.com!netaxs.com!newsread.com!newshog.newsread.com!netaxs.newsread.com!bbs.cpcn.com!root > >upgrade the system to a more powerful model? Maybe there was more to it > >than was obvious. > > There was actually an earlier instance of this "upgrade" mechanism - > before 360. Needing a "competitive" line of EAM (punched card) equipment, > IBM introduced the 'series 50' line in the late '50s. The difference > between a standard unit and a series 50 was a speed reducer gear or > something like that - easily replaceable for an upgrade. In the case of mechanical equipment, such as card readers and all EAM equipment, there was a definite correlation with speed and expense. Usually, the faster a machine runs, the faster it will wear and need service. Faster machines normally process more data which equates to more wear and tear and more maintenance requirements. IMHO IBM was fully justified in charging more rental for such upgrades. In the case of CPU upgrades, someone mentioned that it was posted specifically what switches were thrown. I remain curious as to if in fact that was all that was needed with absolutely no other upgrades (perhaps installed at a different time) to bring up the CPU to a higher speed level. ###### From: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 13 Jan 1999 22:57:55 GMT Organization: The National Capital FreeNet Lines: 9 Message-ID: <77j8dj$s06@freenet-news.carleton.ca> References: <77h2h4$5bh@netaxs.com> <369caee4.24549851@news.bright.net> <77iira$spu$1@hubcap.clemson.edu> Reply-To: ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) NNTP-Posting-Host: freenet5.carleton.ca X-Given-Sender: ab528@freenet5.carleton.ca (Heinz W. Wiggeshoff) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news-feed.inet.tele.dk!bofh.vszbr.cz!newshub.northeast.verio.net!newsserver.jvnc.net!xcski.com!freenet-news.carleton.ca!FreeNet.Carleton.CA!ab528 Mark Smotherman (mark@hubcap.clemson.edu) writes: > Years ago, I worked at a (non-IBM) installation where the CE showed > the operators where the jumper was located; so, during crunch times > (e.g., end-of-year/etc. processing) the operators would occasionally > remove the jumper and speed up the machine. Did the Hobbes meter on the CPU speed up too? ###### From: jeffreyb@gwis2.circ.gwu.edu Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Organization: The George Washington University Lines: 11 Message-ID: <77k3ja$5gg@gwis2.circ.gwu.edu> References: <77h2h4$5bh@netaxs.com> Date: 14 Jan 1999 01:41:46 -0500 NNTP-Posting-Host: 128.164.127.141 X-Trace: fozzy.nit.gwu.edu 916295934 128.164.127.141 (Thu, 14 Jan 1999 01:38:54 EDT) NNTP-Posting-Date: Thu, 14 Jan 1999 01:38:54 EDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!cpk-news-hub1.bbnplanet.com!cpk-news-feed3.bbnplanet.com!news.gtei.net!fozzy.nit.gwu.edu!not-for-mail In article <77h2h4$5bh@netaxs.com>, Lisa or Jeff wrote: >Do they know for sure that all IBM had to do was flip a simple switch to >upgrade the system to a more powerful model? Maybe there was more to it >than was obvious. In our case, I believe it is a "flip a switch" equivalent plus enter some huge long password thing into the microcode. Yours Truly, Jeff Boulier ###### From: spalding@iol.ie (Nick Spalding) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Thu, 14 Jan 1999 12:26:55 GMT Organization: Ireland On-Line Lines: 15 Message-ID: <36a3e219.66080011@news.iol.ie> References: <77j74s$l3f@netaxs.com> Reply-To: spalding@iol.ie NNTP-Posting-Host: dialup-0480.dublin.iol.ie Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 1.5/32.452 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!iol!not-for-mail Lisa or Jeff wrote: > In the case of CPU upgrades, someone mentioned that it was posted > specifically what switches were thrown. I remain curious as to > if in fact that was all that was needed with absolutely no other > upgrades (perhaps installed at a different time) to bring up > the CPU to a higher speed level. The 1440 and 1460 CPUs were virtually identical but one's clock had a cycle time of 10.5musecs and the other about 6. I used to put a 1460 clock card into the 1440s I looked after every now and again to chase off any cards which were beginning to fail. Everything IIRC worked correctly except the printer interface which dropped characters. -- Nick Spalding ###### From: Frank McConnell Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 16 Jan 1999 10:45:33 -0800 Organization: Reanimators Lines: 21 Message-ID: <77qmod$8g3$1@daemonweed.reanimators.org> References: <77h2h4$5bh@netaxs.com> <369caee4.24549851@news.bright.net> <369CEAEF.CF8CAB0D@slip.net> NNTP-Posting-Host: daemonweed.reanimators.org Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!news.new-york.net!news.kjsl.com!news.reanimators.org!not-for-mail Lee Courtney wrote: > IBM is not the only vendor to perform this feat. In the early 80's > when Hewlett-Packard provided a 'hardware upgrade' for the HP3000 > Series 68 to the Series 70, customers purchasing the upgrade > received 1)a new nameplate for the CPU and 2)a (small) tape with > updated micro-code. Many cusotmers expressed 'disappointment' in not > actually receiving new boards as had been the case with earlier > upgrades. I think you're thinking of the 64->68 upgrade, which was new microcode to support the MPE V/E CST expansion. 68->70 included new microcode and also several replacement boards in the CPU section of the card cage which increased the memory cache from 8KB to 128KB (I think). Well, at least our CE made a show of turning off the CPU and replacing some boards, and when he was done we had noticeably more oomph to go with the new "Series 70" faceplate. I can't remember the 68 being that much faster than the 64, just that it let us run MPE V/E and/or let us have more active code segments. -Frank McConnell ###### From: tph@longhorn.uucp (Tom Harrington) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 18 Jan 1999 17:24:13 GMT Organization: Mechanist Industries Lines: 17 Message-ID: <77vqnt$g411@eccws1.dearborn.ford.com> References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> <77iqn8$6p7$1@nnrp1.dejanews.com> Reply-To: tph@rmi.net NNTP-Posting-Host: 19.53.90.53 X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsxfer3.itd.umich.edu!jobone!dailyplanet.srl.ford.com!eccws1.dearborn.ford.com!longhorn!tph yuska@bgs.com wrote: : The practice of switched upgrades was not restricted to IBM. In the : seventies, CDC made two machines, the CYBER 72 and CYBER 73, which differed : only in clock speed and about 250k in price. The upgrade consisted of : changing the clock module. I still have one of the clock modules. This sort of thing _still_ happens, with desktop systems, and often it's even simpler than changing a clock module. Just find the jumpers that set the clock speed, fiddle with them a bit, and voila, you get a faster system. Typically this voids the warranty, but that doesn't stop people. -- Tom Harrington --------- tph@rmii.com -------- http://rainbow.rmii.com/~tph "The only conclusion that can be gained here is that I must treat you as imaginary from this time forward." -Yalin Ekici, ephesus@netcom.com Cookie's Revenge: ftp://ftp.rmi.net/pub2/tph/cookie/cookies-revenge.sit.hqx ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 18 Jan 1999 20:18:22 +0100 Organization: My own Private Self Lines: 26 Sender: neil@chonsp.franklin.ch Message-ID: References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> <77iqn8$6p7$1@nnrp1.dejanews.com> <77vqnt$g411@eccws1.dearborn.ford.com> X-Newsreader: Gnus v5.3/Emacs 19.34 tph@longhorn.uucp (Tom Harrington) writes: > > yuska@bgs.com wrote: > : seventies, CDC made two machines, the CYBER 72 and CYBER 73, which differed > : only in clock speed and about 250k in price. The upgrade consisted of > > This sort of thing _still_ happens, with desktop systems, and often it's > even simpler than changing a clock module. Just find the jumpers that > set the clock speed, fiddle with them a bit, and voila, you get a faster Not quite the same thing. Clocking say an 300MHz chip at 366MHz is running it outside the its _technical_ specification. This results in a drop of reliability and of lifespan before faillure. Here you are abusing safety margins. The above discussion was more about selling an 300MHz with an fixed 233MHz chock chip and then charging extra for the 300MHz clock chip. Purely an sales thing. 300MHz is just as safe. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ Programming: when you stop hammering around on the computer as if it were a piece of dumb matter and instead tell it what to do for you ###### From: tph@acm.org (Tom "Tom" Harrington) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 19 Jan 1999 04:59:24 GMT Organization: Mechanist Industries Lines: 31 Message-ID: References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> <77iqn8$6p7$1@nnrp1.dejanews.com> <77vqnt$g411@eccws1.dearborn.ford.com> NNTP-Posting-Host: shell.rmi.net X-Trace: news1.rmi.net 916721964 3253 166.93.8.17 (19 Jan 1999 04:59:24 GMT) X-Complaints-To: abuse@rmi.net NNTP-Posting-Date: 19 Jan 1999 04:59:24 GMT User-Agent: slrn/0.9.5.4 (UNIX) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!166.93.8.12!natasha.rmii.com!news1.rmi.net!tph In article , Neil Franklin wrote: >tph@longhorn.uucp (Tom Harrington) writes: >> >> This sort of thing _still_ happens, with desktop systems, and often it's >> even simpler than changing a clock module. Just find the jumpers that >> set the clock speed, fiddle with them a bit, and voila, you get a faster > >Not quite the same thing. > >Clocking say an 300MHz chip at 366MHz is running it outside the its >_technical_ specification. This results in a drop of reliability and >of lifespan before faillure. Here you are abusing safety margins. That's not what I was talking about. >The above discussion was more about selling an 300MHz with an fixed >233MHz chock chip and then charging extra for the 300MHz clock chip. >Purely an sales thing. 300MHz is just as safe. That _is_ what I was talking about. I don't know about the industry as a whole, but in the case of Apple's G3 desktops this is exactly what they did. They made one motherboard for the line, and sold it at 233MHz, 266MHz, and 300MHz. The only difference between the three was the jumper configuration, it's just that they charged more to arrange the jumpers for 300MHz than they did if they were arranged for 233MHz. I suspect the same is true of the new G3 systems. -- Tom "Tom" Harrington ----- tph@rmi.net ----- http://rainbow.rmi.net/~tph "Madness. Madness? I call it gladness!" ###### From: "Gareth Alun Evans" Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Tue, 19 Jan 1999 08:40:51 -0000 Message-ID: <916737800.871.3.nnrp-02.9e98250c@news.demon.co.uk> References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> <77iqn8$6p7$1@nnrp1.dejanews.com> <77vqnt$g411@eccws1.dearborn.ford.com> NNTP-Posting-Host: cemetery.demon.co.uk X-NNTP-Posting-Host: cemetery.demon.co.uk:158.152.37.12 X-Trace: news.demon.co.uk 916737800 nnrp-02:871 NO-IDENT cemetery.demon.co.uk:158.152.37.12 X-Complaints-To: abuse@demon.net X-Newsreader: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Lines: 15 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.maxwell.syr.edu!woodstock.news.demon.net!demon!news.demon.co.uk!demon!cemetery.demon.co.uk!not-for-mail Tom "Tom" Harrington wrote in message ... > made one motherboard for the line, and sold it >at 233MHz, 266MHz, and 300MHz. The only difference between the three >was the jumper configuration, it's just that they charged more to arrange >the jumpers for 300MHz than they did if they were arranged for 233MHz. >I suspect the same is true of the new G3 systems. Commodore were sharper with the PET.... If you bought an 8K PET, it was the same motherboard as the 16K PET, but all the holes for the extra RAM chips were drilled right out. ISTR that you could buy the chips on the open market for about 1/10th of the price differential charged by Commodore. ###### Path: chonsp.franklin.ch!usenet From: Neil Franklin Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 19 Jan 1999 22:35:53 +0100 Organization: My own Private Self Lines: 42 Sender: neil@chonsp.franklin.ch Message-ID: References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> <77iqn8$6p7$1@nnrp1.dejanews.com> <77vqnt$g411@eccws1.dearborn.ford.com> X-Newsreader: Gnus v5.3/Emacs 19.34 tph@acm.org (Tom "Tom" Harrington) writes: > > In article , Neil Franklin wrote: > >tph@longhorn.uucp (Tom Harrington) writes: > >> > >> This sort of thing _still_ happens, with desktop systems, and often it's > >> even simpler than changing a clock module. Just find the jumpers that > >> set the clock speed, fiddle with them a bit, and voila, you get a faster > > >The above discussion was more about selling an 300MHz with an fixed > >233MHz chock chip and then charging extra for the 300MHz clock chip. > >Purely an sales thing. 300MHz is just as safe. > > That _is_ what I was talking about. I don't know about the industry > as a whole, but in the case of Apple's G3 desktops this is exactly > what they did. They made one motherboard for the line, and sold it > at 233MHz, 266MHz, and 300MHz. Ah, you are talking about motherboards. The message you had followed on from was talking about mainframe machines (implying processors), so I assumed you were talking about PC processors. > The only difference between the three > was the jumper configuration, it's just that they charged more to arrange > the jumpers for 300MHz than they did if they were arranged for 233MHz. And then the little thing about replacing the slow processor chip with an faster one... :-). Most likely smaller than the mainframe clock module, but a large percentage of PC cost. > I suspect the same is true of the new G3 systems. And of all PC motherboards I have seen since the 486 generation. -- Neil Franklin, Nerd, Geek, Unix Guru, Hacker, Mystic neil@franklin.ch.remove http://neil.franklin.ch/ Programming: when you stop hammering around on the computer as if it were a piece of dumb matter and instead tell it what to do for you ###### From: pinhead@grove.ufl.edu (Joseph G Perez) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 21 Jan 1999 17:52:44 GMT Organization: University of Florida Lines: 21 Message-ID: <787phc$3oae$1@spnode06.nerdc.ufl.edu> References: <778ajv$ij9@netaxs.com> <3699177e$1$wg$mr2ice@news.epix.net> <77b9vs$g5q@freenet-news.carleton.ca> <77c6gq$78@gwis2.circ.gwu.edu> <77iqn8$6p7$1@nnrp1.dejanews.com> <77vqnt$g411@eccws1.dearborn.ford.com> <916737800.871.3.nnrp-02.9e98250c@news.demon.co.uk> NNTP-Posting-Host: grove.ufl.edu X-Trace: spnode06.nerdc.ufl.edu 916941164 123214 128.227.8.14 (21 Jan 1999 17:52:44 GMT) X-Complaints-To: abuse@ufl.edu NNTP-Posting-Date: 21 Jan 1999 17:52:44 GMT X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!212.63.192.161.MISMATCH!newshub.bart.net!news.tele2.nl!newsfeed1.swip.net!swipnet!news.maxwell.syr.edu!news.magicnet.net!newsfeeds.nerdc.ufl.edu!pinhead Gareth Alun Evans (gareth@cemetery.demon.co.uk) wrote: : Commodore were sharper with the PET.... If you bought an 8K PET, : it was the same motherboard as the 16K PET, but all the holes for : the extra RAM chips were drilled right out. This same feat carried over into the Amiga years. Late model A-500s (those with 41256 memory chips) had 512k worth of memory on the board (4 chips) and an extra set of drilled but soldered-in holes for 4 more chips. It is thus a simple hack to upgrade the A-500 10 1 megabyte internally. To my knowledge, Commodore never actually exploited this trick, preferring to use the more expensive A-501 memory expansion card. Unfortunately, this card filled the machines only memory slot, forcing additional RAM upgrades to be placed on the peripheral expansion bus. (Sound familiar, PC/XT users? ;) -=>Joe Perez<=- -=>pinhead@grove.ufl.edu<=- ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 22 Jan 1999 03:14:01 GMT Organization: Daedalus Consulting Lines: 16 Message-ID: <788qdp$fc4$1@news.wlg.netlink.net.nz> References: <778ajv$ij9@netaxs.com> <916737800.871.3.nnrp-02.9e98250c@news.demon.co.uk> <787phc$3oae$1@spnode06.nerdc.ufl.edu> NNTP-Posting-Host: toyunix.zl2tnm.gen.nz Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!203.97.37.7!newsfeed.clear.net.nz!news.wlg.netlink.net.nz!don Joseph G Perez wrote: >card filled the machines only memory slot, forcing additional RAM upgrades >to be placed on the peripheral expansion bus. (Sound familiar, PC/XT >users? ;) Not just the XT -- IBM PC/ATs did the same thing. It wasn't really 'til the 386 came out that that the system bus separated from the ISA bus, since the 386 is 32 bit and typically operates at higher clock rates. In the AT days, it was common to run the entire system at faster than the standard 8 MHz. Unsurprisingly, some cards in such systems didn't work... In my experience, 10 MHz boxes were generally fine, but 12 MHz systems gave trouble with some cards. -- Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724 ###### Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 References: <778ajv$ij9@netaxs.com> <916737800.871.3.nnrp-02.9e98250c@news.demon.co.uk> <787phc$3oae$1@spnode06.nerdc.ufl.edu> <788qdp$fc4$1@news.wlg.netlink.net.nz> Organization: Wizvax Communications, LLC From: multics@wizvax.wizvax.net (Richard Shetron) NNTP-Posting-Host: wizvax.wizvax.net Message-ID: <36a8abd4.0@news.wizvax.net> Date: 22 Jan 1999 11:48:20 -0500 X-Trace: 22 Jan 1999 11:48:20 -0500, wizvax.wizvax.net Lines: 19 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newspump.monmouth.com!newspeer.monmouth.com!newsfeed.wizvax.net!news.wizvax.net!wizvax.wizvax.net!multics In article <788qdp$fc4$1@news.wlg.netlink.net.nz>, Don Stokes wrote: >Joseph G Perez wrote: [snip] >In the AT days, it was common to run the entire system at faster than >the standard 8 MHz. Unsurprisingly, some cards in such systems didn't >work... In my experience, 10 MHz boxes were generally fine, but 12 MHz >systems gave trouble with some cards. The IBM PC-AT standard was 6Mhz. Everyone who made clones quickly made 8Mhz systems and I think near the end of the 286 days, there were companies making 20+Mhz AT systems. The turbo switch came about as all the games designed to run at 6Mhz on an AT would run too fast on an 8Mhz system so you'd take the system out of turbo mode to run at 6Mhz. The system clock was an option so the games did instruction loops for delays. >Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724 ###### From: Mike Swaim Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers References: <778ajv$ij9@netaxs.com> <916737800.871.3.nnrp-02.9e98250c@news.demon.co.uk> <787phc$3oae$1@spnode06.nerdc.ufl.edu> <788qdp$fc4$1@news.wlg.netlink.net.nz> <36a8abd4.0@news.wizvax.net> Organization: PointeCom User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/2.2.8-RELEASE (i386)) Lines: 11 Message-ID: Date: Fri, 22 Jan 1999 17:13:15 GMT NNTP-Posting-Host: 209.127.0.130 X-Trace: news2.giganews.com 917025195 209.127.0.130 (Fri, 22 Jan 1999 11:13:15 CDT) NNTP-Posting-Date: Fri, 22 Jan 1999 11:13:15 CDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newspump.monmouth.com!newspeer.monmouth.com!nntp.giganews.com!news2.giganews.com.POSTED!gemini.c-com.net!swaim Richard Shetron wrote: : The turbo switch came about as : all the games designed to run at 6Mhz on an AT would run too fast on an : 8Mhz system so you'd take the system out of turbo mode to run at 6Mhz. I remember it dropping the clock speed down to 4.77Mhz. -- Mike Swaim, Avatar of Chaos: Disclaimer:I sometimes lie. Home: swaim@c-com.net Alum: swaim@alumni.rice.edu Quote: "Boingie"^4 Y,W&D ###### From: "Jack Peacock" Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Fri, 22 Jan 1999 14:32:39 -0800 Organization: Simco Lines: 33 Message-ID: <78atsl$ed6$1@remarQ.com> References: <778ajv$ij9@netaxs.com> <787phc$3oae$1@spnode06.nerdc.ufl.edu> <788qdp$fc4$1@news.wlg.netlink.net.nz> <36a8abd4.0@news.wizvax.net> <78aqt0$9jj$1@news.wlg.netlink.net.nz> NNTP-Posting-Host: 207.168.124.145 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: 917043925 EWMV79OYA7C91CFA8C usenet54.supernews.com X-Complaints-To: newsabuse@remarQ.com X-Newsreader: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!feeder.qis.net!remarQ-easT!remarQ73!supernews.com!remarQ69!not-for-mail Don Stokes wrote in message <78aqt0$9jj$1@news.wlg.netlink.net.nz>... >Richard Shetron wrote: >>Don Stokes wrote: >>>In the AT days, it was common to run the entire system at faster than >>>the standard 8 MHz. Unsurprisingly, some cards in such systems didn't >>>work... In my experience, 10 MHz boxes were generally fine, but 12 MHz >>>systems gave trouble with some cards. >> >>The IBM PC-AT standard was 6Mhz. Everyone who made clones quickly > >The first ATs were 6 MHz. But it didn't take long before the IBM PC-AT >ran at 8 MHz -- I'm guessing, but I assume that the thing was originally >designed for 8 MHz, but 8 MHz 80286s weren't available in sufficient >quantities. > Most 6Mhz '286s ran just fine at 8Mhz. The IBM AT motherboard had a socket mounted clock crystal so it was very easy to swap them out and see how fast a particular machine would run. I still have an early IBM AT that I upgraded to 8Mhz. There were xtal kits sold with 7, 8, and 9 Mhz xtals. Mine ran at 8 but not 9. (I also added a 386 socket adapter, then put in a Cyrix clock doubled 486Dr2, so mine now runs an effective 16Mhz CPU speed.) Jack Peacock ###### From: don@news.daedalus.co.nz (Don Stokes) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 22 Jan 1999 21:34:24 GMT Organization: Daedalus Consulting Lines: 16 Message-ID: <78aqt0$9jj$1@news.wlg.netlink.net.nz> References: <778ajv$ij9@netaxs.com> <787phc$3oae$1@spnode06.nerdc.ufl.edu> <788qdp$fc4$1@news.wlg.netlink.net.nz> <36a8abd4.0@news.wizvax.net> NNTP-Posting-Host: toyunix.zl2tnm.gen.nz Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!news.maxwell.syr.edu!newsfeed.cwix.com!203.97.37.7!newsfeed.clear.net.nz!news.wlg.netlink.net.nz!don Richard Shetron wrote: >Don Stokes wrote: >>In the AT days, it was common to run the entire system at faster than >>the standard 8 MHz. Unsurprisingly, some cards in such systems didn't >>work... In my experience, 10 MHz boxes were generally fine, but 12 MHz >>systems gave trouble with some cards. > >The IBM PC-AT standard was 6Mhz. Everyone who made clones quickly The first ATs were 6 MHz. But it didn't take long before the IBM PC-AT ran at 8 MHz -- I'm guessing, but I assume that the thing was originally designed for 8 MHz, but 8 MHz 80286s weren't available in sufficient quantities. -- Don Stokes, Networking Consultant http://www.daedalus.co.nz +64 25 739 724 ###### From: deke.spamblock@generous.net Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Sat, 23 Jan 1999 10:14:30 GMT Organization: GenerousCity is a virtue - find romance at http://generous.net Lines: 28 Message-ID: <36a99d18.22527136@news.bright.net> References: <778ajv$ij9@netaxs.com> <916737800.871.3.nnrp-02.9e98250c@news.demon.co.uk> <787phc$3oae$1@spnode06.nerdc.ufl.edu> <788qdp$fc4$1@news.wlg.netlink.net.nz> <36a8abd4.0@news.wizvax.net> NNTP-Posting-Host: paul-cas2-cs-13.dial.bright.net X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!24.130.1.14!lsnws01.we.mediaone.net!24.131.1.12!denws01.mw.mediaone.net!news.altair.com!NewsNG.Chicago.Qual.Net!205.212.123.11!news.bright.net!not-for-mail On 22 Jan 1999 11:48:20 -0500, multics@wizvax.wizvax.net (Richard Shetron) wrote: >The IBM PC-AT standard was 6Mhz. Everyone who made clones quickly >made 8Mhz systems and I think near the end of the 286 days, there were >companies making 20+Mhz AT systems. The turbo switch came about as >all the games designed to run at 6Mhz on an AT would run too fast on an >8Mhz system so you'd take the system out of turbo mode to run at 6Mhz. >The system clock was an option so the games did instruction loops >for delays. I had a 286/25, but this was introduced almost *past* the end of the 286 days. The manufacturer pointed out that because most programs were optimized for the 8088 or 80286, it was actually faster than a 386/25 for most tasks. On the other hand, it was *really* slow with Windows 3.1 deacon "in fact, I'm *still* waiting for Win31 to come up on it" blues ------------------------ Let love find you! http://generous.net A list for flirting generousSingles-subscribe@onelist.com Over The Hill Gang generousSinglesOTHG-subscribe@onelist.com College and younger generousTeens-subscribe@onelist.com Lots of Personal Ads generousProfiles-subscribe@onelist.com If it's not 'just the way you are', it's not love.... ###### From: Tracy Nelson Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Sun, 24 Jan 1999 11:05:04 -0500 Organization: Ralph Spoilsport Motors Lines: 13 Message-ID: <36AB44B0.99DBFBE1@fast.net> References: <778ajv$ij9@netaxs.com> <916737800.871.3.nnrp-02.9e98250c@news.demon.co.uk> <787phc$3oae$1@spnode06.nerdc.ufl.edu> <788qdp$fc4$1@news.wlg.netlink.net.nz> NNTP-Posting-Host: maxtnt04-abe-8.fast.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.33 i686) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!nntp.abs.net!newsfeed.fast.net!news.fast.net!not-for-mail Don Stokes wrote: > In the AT days, it was common to run the entire system at faster than > the standard 8 MHz. Unsurprisingly, some cards in such systems didn't > work... In my experience, 10 MHz boxes were generally fine, but 12 MHz > systems gave trouble with some cards. I remember *that*! I built some AT-clones for the company I was working for at the time. They would boot all right and run for several minutes, but after an hour or so the disk controller would go south. Very bad, since they were used by the marketing team for proposal writing. Boot it up, load WP, work all morning, then get an error trying to save your work before you went to lunch. Turned me off from build-your-own systems for a long time... ###### From: Mike Swaim Subject: Re: IBM S/360 Newsgroups: alt.folklore.computers References: <778ajv$ij9@netaxs.com> <916737800.871.3.nnrp-02.9e98250c@news.demon.co.uk> <787phc$3oae$1@spnode06.nerdc.ufl.edu> <788qdp$fc4$1@news.wlg.netlink.net.nz> <36a8abd4.0@news.wizvax.net> <36a99d18.22527136@news.bright.net> Organization: PointeCom User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/2.2.8-RELEASE (i386)) Lines: 12 Message-ID: Date: Sun, 24 Jan 1999 19:57:19 GMT NNTP-Posting-Host: 209.127.0.130 X-Trace: news1.giganews.com 917207839 209.127.0.130 (Sun, 24 Jan 1999 13:57:19 CDT) NNTP-Posting-Date: Sun, 24 Jan 1999 13:57:19 CDT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newspump.monmouth.com!newspeer.monmouth.com!nntp.giganews.com!news1.giganews.com.POSTED!gemini.c-com.net!swaim deke.spamblock@generous.net wrote: : I had a 286/25, but this was introduced almost *past* the end of the 286 days. : The manufacturer pointed out that because most programs were optimized for the : 8088 or 80286, it was actually faster than a 386/25 for most tasks. I'm not sure about that, but it was faster than a 386sx, and cheaper to boot. -- Mike Swaim, Avatar of Chaos: Disclaimer:I sometimes lie. Home: swaim@c-com.net Alum: swaim@alumni.rice.edu Quote: "Boingie"^4 Y,W&D ###### From: lisard@zetnet.co.uk Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 24 Jan 1999 22:37:28 GMT Lines: 25 Message-ID: <78g7b8$ac5$3@roch.zetnet.co.uk> References: <36a99d18.22527136@news.bright.net> NNTP-Posting-Host: man-110.dialup.zetnet.co.uk X-Trace: roch.zetnet.co.uk 917217448 10629 194.247.40.141 (24 Jan 1999 22:37:28 GMT) NNTP-Posting-Date: 24 Jan 1999 22:37:28 GMT X-Everything: Net-Tamer V 1.08X Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!aquitaine.fr.clara.net!195.8.69.68.MISMATCH!fr.clara.net!demeter.clara.net!news.clara.net!peer.news.zetnet.net!zetnet.co.uk!not-for-mail On 1999-01-23 deke.spamblock@generous.net said: :I had a 286/25, but this was introduced almost *past* the end of :the 286 days. :The manufacturer pointed out that because most programs were :optimized for the 8088 or 80286, it was actually faster than a :386/25 for most tasks. If you do cycle counts, you probably need to get out more (take it from one who knows ;> ) but it does become clear that the 286 does, marginally, have the edge on the 386, especially the 386sx. The exception is if you're doing lots of multi-bit shifts, which are constant-time on the 386+. (ISTR) :On the other hand, it was *really* slow with Windows 3.1 I thought everything was really slow with Windows 3.1, just that on a 386 you could have several DOS programs being really slow all at the same time...? I once considered trying Win95 on a 386sx. Don't laugh, please... -- Communa (lisard@zetnet.co.uk) -- you know soft spoken changes nothing ###### From: deke.spamblock@generous.net Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Mon, 25 Jan 1999 08:01:34 GMT Organization: GenerousCity is a virtue - find romance at http://generous.net Lines: 21 Message-ID: <36ac24a8.29194727@news.bright.net> References: <36a99d18.22527136@news.bright.net> <78g7b8$ac5$3@roch.zetnet.co.uk> NNTP-Posting-Host: paul-cas1-cs-46.dial.bright.net X-Newsreader: Forte Free Agent 1.11/32.235 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!newsfeed.berkeley.edu!marge.eaglequest.com!streamer1.cleveland.iagnet.net!NewsNG.Chicago.Qual.Net!205.212.123.11!news.bright.net!not-for-mail On 24 Jan 1999 22:37:28 GMT, lisard@zetnet.co.uk wrote: > :On the other hand, it was *really* slow with Windows 3.1 >I thought everything was really slow with Windows 3.1, just that on a 386 >you could have several DOS programs being really slow all at the same >time...? That was a joke. The last version of Windows that would run on a 286 was 3.0 deke ------------------------ Let love find you! http://generous.net A list for flirting generousSingles-subscribe@onelist.com Over The Hill Gang generousSinglesOTHG-subscribe@onelist.com College and younger generousTeens-subscribe@onelist.com Lots of Personal Ads generousProfiles-subscribe@onelist.com If it's not 'just the way you are', it's not love.... ###### From: "Gareth Alun Evans" Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Mon, 25 Jan 1999 11:49:19 -0000 Message-ID: <917266114.13172.1.nnrp-05.9e98250c@news.demon.co.uk> References: <778ajv$ij9@netaxs.com> <916737800.871.3.nnrp-02.9e98250c@news.demon.co.uk> <787phc$3oae$1@spnode06.nerdc.ufl.edu> <788qdp$fc4$1@news.wlg.netlink.net.nz> <36a8abd4.0@news.wizvax.net> <36a99d18.22527136@news.bright.net> NNTP-Posting-Host: cemetery.demon.co.uk X-NNTP-Posting-Host: cemetery.demon.co.uk:158.152.37.12 X-Trace: news.demon.co.uk 917266114 nnrp-05:13172 NO-IDENT cemetery.demon.co.uk:158.152.37.12 X-Complaints-To: abuse@demon.net X-Newsreader: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Lines: 9 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news.belnet.be!newsfeed.wirehub.nl!btnet-peer!btnet!dispose.news.demon.net!demon!news.demon.co.uk!demon!cemetery.demon.co.uk!not-for-mail Mike Swaim wrote in message ... > I'm not sure about that, but it was faster than a 386sx, and cheaper to >boot. Well, I've never measured the cost of booting my PC :-) ###### From: korpela@islay.ssl.berkeley.edu (Eric J. Korpela) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 25 Jan 1999 17:24:20 GMT Organization: Cal Berkeley-- Space Sciences Lab Lines: 33 Message-ID: <78i9c4$2mc$1@agate.berkeley.edu> References: <36a99d18.22527136@news.bright.net> <78g7b8$ac5$3@roch.zetnet.co.uk> <36ac24a8.29194727@news.bright.net> NNTP-Posting-Host: islay.ssl.berkeley.edu Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.berkeley.edu!agate!islay.ssl.berkeley.edu!korpela In article <36ac24a8.29194727@news.bright.net>, wrote: >On 24 Jan 1999 22:37:28 GMT, lisard@zetnet.co.uk wrote: > > > :On the other hand, it was *really* slow with Windows 3.1 > > >I thought everything was really slow with Windows 3.1, just that on a 386 > >you could have several DOS programs being really slow all at the same > >time...? > >That was a joke. The last version of Windows that would run on a 286 was 3.0 This is a troll, right??? Windows 3.1 runs just fine on a 286. Windows/1.0X: was the first released version. It allowed multitasking of well behaved DOS applications in a window. Windows/2.0: was the first version to allow overlapping windows. The dos multitasking was removed because too many DOS applications are not well behaved. Windows/286: was windows 2.X with a different name Windows/386: was windows 2.X with a different name. It was also the first version to inlude some 286 specific code and some hint of protected mode. Windows/3.0: was the first version to actually be capable of running in protected mode. DOS multitasking came back for those with a 386 machine. Windows/3.1: was the first version that wouldn't run on a 8086. It also included multimedia support. Window for Workgroups/3.11: was the first version that wouldn't run on a 286. Eric -- Eric Korpela | An object at rest can never be korpela@ssl.berkeley.edu | stopped. Click for home page. ###### Newsgroups: alt.folklore.computers From: jwbirdsa@picarefy.picarefy.com (James W. Birdsall) Subject: Re: IBM S/360 Message-ID: <1999Jan25.175436.11143@picarefy.picarefy.com> Organization: Green Tiger Software References: <36a99d18.22527136@news.bright.net> <78g7b8$ac5$3@roch.zetnet.co.uk> <36ac24a8.29194727@news.bright.net> Date: Mon, 25 Jan 1999 17:54:36 GMT Lines: 22 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.cwix.com!199.181.164.14!news.seanet.com!nntp.picarefy.com!picarefy!jwbirdsa In article <36ac24a8.29194727@news.bright.net> deke.spamblock@generous.net writes: >On 24 Jan 1999 22:37:28 GMT, lisard@zetnet.co.uk wrote: > > > :On the other hand, it was *really* slow with Windows 3.1 > > >I thought everything was really slow with Windows 3.1, just that on a 386 > >you could have several DOS programs being really slow all at the same > >time...? > >That was a joke. The last version of Windows that would run on a 286 was 3.0 No, 3.0 was the last version of Windows that would run on an 8088. 3.1 dropped "real" mode but was perfectly happy to crawl along agonizingly on a 286 in "standard" mode. I've done it (12MHz 286, 4M RAM -- OS/2 1.3 ran much better on the same hardware). Windows for Workgroups dropped "standard" mode and would only run on 386es and up in "enhanced" mode. -- James W. Birdsall http://www.picarefy.com/~jwbirdsa/ jwbirdsa@picarefy.com "For it is the doom of men that they forget." -- Merlin Get the Sun-2 Hardware Reference from ftp.picarefy.com:/pub/Sun-Hardware-Ref Sun-2 Hardware Reference Web Page: http://sun-www.picarefy.com/ ###### From: dg@ (David Given) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Mon, 25 Jan 1999 18:50:41 GMT Organization: I'm organised? Wow! Message-ID: <917290241.21187.0.nnrp-02.9e9878e0@news.demon.co.uk> References: <36a99d18.22527136@news.bright.net> <78g7b8$ac5$3@roch.zetnet.co.uk> NNTP-Posting-Host: taos.demon.co.uk X-NNTP-Posting-Host: taos.demon.co.uk:158.152.120.224 X-Trace: news.demon.co.uk 917290241 nnrp-02:21187 NO-IDENT taos.demon.co.uk:158.152.120.224 X-Complaints-To: abuse@demon.net Lines: 34 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!news-nyc.telia.net!newsfeed.berkeley.edu!woodstock.news.demon.net!demon!news.demon.co.uk!demon!taos.demon.co.uk!!dg In article <78g7b8$ac5$3@roch.zetnet.co.uk>, wrote: [...] >I thought everything was really slow with Windows 3.1, just that on a 386 >you could have several DOS programs being really slow all at the same >time...? > >I once considered trying Win95 on a 386sx. Don't laugh, please... Linux runs just fine on a 386. I had it going on a 386SX/16 with 2MB. It made a superb dumb terminal, and with a decent quantity of memory it would have made a pretty good (small) mail and web server. Interestingly, the direct-video console made it seem like lightening after DOS, despite the fact that DOS applications had more raw CPU power to play with. You do *not* want to do a kernel recompile on this sucker, though. I used a 1.2 series kernel and had to make my own distribution. I also got Desqview running on an 8086 at one point. The multitasking seemed to work pretty well, but it wasn't suitable for what I wanted it for so I gave up. And just for useless value: there's a project to port Linux to 8086-based machines. A very stripped down version of Linux. Someone's even doing a 286-PM version, complete with preemptable device drivers. It's going quite well; the current version runs sash in 3 VT's, lets you run processes, pipes, signals... -- +- David Given ------------McQ-+ | Work: dg@tao.co.uk | Smile! The Illuminati are watching. | Play: dgiven@iname.com | +- http://wiredsoc.ml.org/~dg -+ ###### From: ruth@smiley.private.net (Joeri van Ruth) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Sat, 13 Feb 1999 18:23:53 +0100 Organization: XS4ALL, networking for the masses Lines: 16 Message-ID: References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> Reply-To: ruth@wins.uva.nl NNTP-Posting-Host: dc2-isdn230.dial.xs4all.nl X-NNTP-Posting-Host: dc2-isdn230.dial.xs4all.nl [194.109.148.230] X-XS4ALL-Date: Mon, 15 Feb 1999 12:47:46 CET X-Newsreader: slrn (0.9.4.3 UNIX) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.belnet.be!newsfeed.wirehub.nl!xs4all!ruth On 9 Jan 1999 12:15:12 -0500, Dave Cherkus wrote: .. > (indeed transferred using a > mechanism similar to 3270) .. So how does 3270 work? I see it mentioned a lot but I have never found an explanation. I suppose it is completely block-oriented, so what does it do? Does the remote end send full screens to the terminal? And what does the terminal send back? Lines? Please enlighten me. Joeri ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 15 Feb 1999 05:46:55 -0800 Organization: Wheeler&Wheeler Lines: 13 Message-ID: References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-19.garlic.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Gnus/5.070076 (Pterodactyl Gnus v0.76) Emacs/20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.idt.net!WCG!198.6.0.215!uunet!ffx.uu.net!in3.uu.net!bulb.garlic.com!not-for-mail 3270s operate analogous to restricted version of HTTP forms. There is control format for writing things to a page/screen .. output only areas, input areas, output&input areas, etc. Imagine early version of web/tv ... initially no color and no graphics, 25+ years ago, and interface between processor and controller ran at 640kbytes/sec. -- -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ###### From: tph@longhorn.uucp (Tom Harrington) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 15 Feb 1999 17:52:39 GMT Organization: Mechanist Industries Lines: 17 Message-ID: <7a9mt7$e467@eccws1.dearborn.ford.com> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> Reply-To: tph@rmi.net NNTP-Posting-Host: 19.53.90.53 X-Newsreader: TIN [version 1.2 PL2] Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.he.net!nozzle.tacom.army.mil!news2.acs.oakland.edu!jobone!dailyplanet.srl.ford.com!eccws1.dearborn.ford.com!longhorn!tph Anne & Lynn Wheeler (lynn@garlic.com) wrote: : 3270s operate analogous to restricted version of HTTP : forms. There is control format for writing things to a page/screen : .. output only areas, input areas, output&input areas, etc. : Imagine early version of web/tv ... initially no color and no : graphics, 25+ years ago, and interface between processor and : controller ran at 640kbytes/sec. And, of course, 640kb/sec should be enough for anyone. -- Tom Harrington --------- tph@rmii.com -------- http://rainbow.rmii.com/~tph "Rock 'n' Roll, as a sound, is what grandparents listen to." -Fraser Clark, Mondo 2000 Cookie's Revenge: ftp://ftp.rmi.net/pub2/tph/cookie/cookies-revenge.sit.hqx ###### From: hancock4@bbs.cpcn.com (Lisa or Jeff) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 15 Feb 1999 17:55:25 GMT Organization: Net Access BBS Lines: 13 Message-ID: <7a9n2d$1df@netaxs.com> NNTP-Posting-Host: bbs.cpcn.com Originator: root@bbs.cpcn.com Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!howland.erols.net!news-xfer.netaxs.com.MISMATCH!news-xfer.newsread.com!netaxs.com!newsread.com!netaxs.newsread.com!bbs.cpcn.com!root > So how does 3270 work? I see it mentioned a lot but I have never > found an explanation. From a CICS application programming perspective, we prepare a map of the fields we want to send out. Each field is preceded by an attribute character (which takes up a position on the screen), that character tells the terminal the attributes of the field--display only or enter, color, etc. On return it tells the computer whether the field was modified or not. My guess is that 3270 screens are very efficient in sending data back and forth as only changed data is sent. Remember, it was developed back in the days of much slower data lines. ###### From: "Joel C. Ewing" Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Tue, 16 Feb 1999 00:01:50 -0600 Content-Transfer-Encoding: 7bit References: <7a9n2d$1df@netaxs.com> X-Posted-Path-Was: not-for-mail Content-Type: text/plain; charset=us-ascii X-ELN-Date: 16 Feb 1999 06:03:27 GMT X-ELN-Insert-Date: Mon Feb 15 22:05:06 1999 Organization: EarthLink Network, Inc. Lines: 46 Mime-Version: 1.0 NNTP-Posting-Host: 1cust4.tnt8.dfw5.da.uu.net Message-ID: <36C909CE.6CA7A6D6@acm.org> X-Mailer: Mozilla 4.05 [en] (Win95; U) Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!newsfeed-zh.ip-plus.net!news.ip-plus.net!News.Amsterdam.UnisourceCS!masternews.telia.net!news.algonet.se!algonet!news.maxwell.syr.edu!nntp.flash.net!worldfeed.news.gte.net!newsfeed1.earthlink.net!nntp.earthlink.net!posted-from-earthlink!not-for-mail Lisa or Jeff wrote: > > So how does 3270 work? I see it mentioned a lot but I have never > > found an explanation. > > From a CICS application programming perspective, we prepare a map of > the fields we want to send out. Each field is preceded by an attribute > character (which takes up a position on the screen), that character > tells the terminal the attributes of the field--display only or enter, > color, etc. On return it tells the computer whether the field was > modified or not. > > My guess is that 3270 screens are very efficient in sending data back > and forth as only changed data is sent. Remember, it was developed back > in the days of much slower data lines. The field attribute byte could be chosen so that data from the field would always be transmitted or so data was only transmitted when changed. The latter was much more efficient if remote transmission over communication lines was involved, but the former sometimes made programming logic simpler because the user's 3270 could in effect be used as a data "storage" device to hold transaction state information. Most of the logic was contained in a controller, which could handle up to 32 separate 3270 devices and which was either direct-channel attached (local) or attached to a bi-sync communication line (remote). A full screen image could be transfered to the controller as a single I/O operation. The user could enter up to a full screen of data (depending on screen format), but actual data transfer to the host only occurs when one of several special keys is depressed (ENTER, or one of the 24 Program Function keys PF1 - PF24, which were used as shortcut for application-defined commands), and at that time all entered characters were again transferred as a single I/O operation to the host. The controller actually time-multiplexed data transfer to and from the individual 3270 terminals and polled keyboards for character input, but transfer rates were so high that the users had the illusion that these functions were performed by their own 3270 (unless the coax broke). 3270's came in several different flavors, the most common being 24 lines by 80 characters, but 24x132, 43x80 and at least one other format (32x80?) also existed. Earliest models were limited to mono-color displays (normal and hilighted) and to upper case only. This evolved to dual case and eventually included color displays and displays able to support a limited form of raster and symbol graphics (at a cost of considerably more bandwidth). The 3270 family also includes several printers models that can be attached to the same controllers. -- Joel C. Ewing, Fort Smith, AR jcewing@acm.org ###### From: jnickelsen@acm.org (Juergen Nickelsen) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Tue, 16 Feb 1999 01:18:44 +0100 Organization: [Posted via] Interactive Networx Lines: 12 Message-ID: <1dnagj3.yffmttcydwsqN@n241-82.berlin.snafu.de> References: <74kun5$mmq@netaxs.com> <76ogkm$7kl$1@teabag.demon.co.uk> <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> <7a9mt7$e467@eccws1.dearborn.ford.com> NNTP-Posting-Host: n241-82.berlin.snafu.de User-Agent: MacSOUP/2.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!newscore.univie.ac.at!newsfeed.ecrc.net!news-lond.gip.net!news.gsl.net!gip.net!news-fra.maz.net!origin200.news.is-europe.net!news-hh.maz.net!unlisys!news.snafu.de!jnickelsen Tom Harrington wrote: > : [...] interface between processor and controller ran at 640kbytes/sec. > > And, of course, 640kb/sec should be enough for anyone. :-) I'd like to know how many thought of that one -- I certainly did. 640 really is a magic number -- I remember how I howled when I learned that the Apple Newton had 640 KB of memory (in the beginning). -- Juergen Nickelsen ###### From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 16 Feb 1999 04:47:03 -0800 Organization: Wheeler&Wheeler Lines: 42 Message-ID: References: <7a9n2d$1df@netaxs.com> <36C909CE.6CA7A6D6@acm.org> Reply-To: Anne & Lynn Wheeler NNTP-Posting-Host: lynn-19.garlic.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Gnus/5.070076 (Pterodactyl Gnus v0.76) Emacs/20.3 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.belnet.be!newsgate.cistron.nl!het.net!news.tele2.nl!newsfeed.wirehub.nl!newspeer1.nac.net!netnews.com!feed1.news.rcn.net!rcn!newsfeed.atl!uunet!ffx.uu.net!in1.uu.net!bulb.garlic.com!not-for-mail the original 3270 was 3272 controller and the 3277 (24x80) terminal which had keyboard & other logic in the head. The 3274 controller moved much of the head logic back into the controller ... reducing the per terminal costs and introduced the 3278 (43x80 & other modes), 3279 (color and graphics), 3290(?) (flat panel). The 3270 terminals had and annoying habit of dropping characters and locking the keyboard if you happened to be typing a character at the very moment that there was a write to the screen. Repeat and cursor positioning speeds were also maddening slow. On the 3277, because the logic was in the head ... some user modifications were possible ... 1) little soldering on the board inside the keyboard and you adjust the repeat delay, repeat rate, and cursor positioning speeds. It was actually possible to overdrive the repeat rate so that the screen update fell behind the keyboard repeat ... it took a little practice to position the cursor under a specific character ... since the cursor would continue to move for several positions after you lifted the cursor positioning key. 2) FIFO box inserted between where the keyboard plugs into the head which eliminates drop character and keyboard lockup. It wasn't possible to fix the 3274-based terminals because the logic had moved back into the controller. The 3270 card for the IBM/PC offerred the opportunity to do some creative programming to enhance the user interface characteristics. In the early 80s my brother was a regional apple sales rep. I attended dinners with the mac developers during the early mac period ... and getting into heated arguments about tainting the "kitchen table only" machine with something as unthinkable as a terminal emulator (3270) adapter -- -- Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key http://www.garlic.com/~lynn/ ###### From: "Larry Liska" Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Wed, 17 Feb 1999 16:42:59 -0600 Organization: PLATINUM technology, Inc Lines: 81 Message-ID: <7afgf0$f9t$1@news.platinum.com> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> NNTP-Posting-Host: 192.168.56.207 X-Newsreader: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!isdnet!howland.erols.net!newshub.northeast.verio.net!news.new-york.net!uunet!ffx.uu.net!in2.uu.net!news.platinum.com!not-for-mail Joeri van Ruth wrote in message ... >So how does 3270 work >... >I suppose it is completely block-oriented, so what does it do? >Does the remote end send full screens to the terminal? >And what does the terminal send back? Lines? Most always block-oriented, but they did have an "unformatted" mode, which made the entire screen in effect one big block-- or page-oriented, you could say.... This can be seen in some parts of TSO (sorry, I forget where, maybe the command input screen?), and in VTAM SSCP-LU sessions. 3270s are dependant devices-- the host controls the conversation, and the terminal depends on it. You can't simply hook a 3270 up to a Linux box, unfortunately. :-) Actually, this is on 2 levels-- the master slave relationship between host & terminal, which I just mentioned, as well as the fact that 3270 terminals use a proprietary hardware protocol-- coax (after the coaxial cable that attaches terminal to controller.) I am unclear in this part-- is this protocol "bisync", or is it a protocol unto itself? Oh yeah-- as another poster already mentioned, many 3270 terminals are actually strawmen, with the real smarts actually located in the control unit, not the terminal. This would then make the terminal like a "waldo".... The host app builds screens on the 3270 one field at a time using various Write commands. These commands contain flags, such as KeyboardLock, etc, and the fields have properties such as readonly, hi intensity, visible, etc. The rest of the Write command data is a mixture of "orders" and plain text. Orders (and commands) are roughly analogous to escape codes in the async world-- position cursor, repeat, clear, etc. Oh yeah-- 3270's, like most things IBM, use the EBCDIC character set, not ASCII. Once the screen is built, the terminal is pretty much on its own. All keystrokes, with the exception of certain ones, are handled locally. Thus, you arrow and tab around a screen, typing data, and the host sees no impact, and no data is being sent back. The special keys are referred to as "AID keys." Enter, Clear, PA1-2, PF1-24, SysReq, etc. When an aid key is hit, it generates a message back to the host, a "Response", if I remember my terminology correctly. This contains the ID of the aid key, the cursor location, and data (see next paragraph). 3270's offer a lot of power, which is more or less utilized, depending on the application. When a field is altered, it sets the MDT flag (a "dirty" bit). On a read, only the dirty fields are sent back. But, the app can force the MDT on fields, which means they will always be read, whether modified or not. Do this to enough fields and you end up reading a good part of the screen back. Also, apps can tailor the amount of data sent back on a read-- just text (fastest), text & fldattrs, or text and charattrs for each character being sent back. The most verbose read mode is used by some "wysiwyg" (for lack of a better term) editors, (I think SAS has such an editor), or "popup" messages that obstruct a screen-- the host reads maximal data in, so that it can rebuild the screen correctly after the popup message goes away. Of course, over time, the 3270 family gained lots of cool features, like graphics, downloadable fonts ("symbol sets"), smart field features, like data validation, trigger-on-enter and trigger-on-exit (like aid keys), light pens, multiple codepages, etc etc. What I always found to be righteous about these terminals was their backward-compatibility. The new features were pretty much added as supersets to the basic dumb original 3270 capability. A random, hideous 70's-era application would probably work just fine with your brand-new, feature-laden 3179-G graphics terminal (or emulator), since it can fall back to base behavior. I wish Microsoft would make this principal a priority in their software.... Last time I checked, a few years ago, the "3270 DataStream Programmer's Ref" was selling for about $60 (US dollars) from IBM Publications. This, as well as the 3174 control unit Functional ref, should be sufficient reading for ya'... lcl ------ #include ###### From: "John L. Pearlman" Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: Wed, 17 Feb 1999 20:27:09 -0500 Organization: The Internet Access Company, Inc. Lines: 42 Message-ID: <36CB6C5B.37CC@tiac.net> References: <76p5o4$l8u@netaxs.com> <76p9nd$rk@freenet-news.carleton.ca> <36978ea0.0@news.destek.net> <7afgf0$f9t$1@news.platinum.com> Reply-To: jlp@tiac.net NNTP-Posting-Host: tapuach.tiac.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) To: Larry Liska Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.belnet.be!newspump.monmouth.com!newspeer.monmouth.com!news-feed1.tiac.net!posterchild2!news@tiac.net Larry Liska wrote: > > Joeri van Ruth wrote in message ... > >So how does 3270 work > >... > >I suppose it is completely block-oriented, so what does it do? > >Does the remote end send full screens to the terminal? > >And what does the terminal send back? Lines? > > Most always block-oriented, but they did have an "unformatted" mode, which > made the entire screen in effect one big block-- or page-oriented, you could > say.... This can be seen in some parts of TSO (sorry, I forget where, maybe > the command input screen?), and in VTAM SSCP-LU sessions. > > 3270s are dependant devices-- the host controls the conversation, and the > terminal depends on it. You can't simply hook a 3270 up to a Linux box, > unfortunately. :-) Actually, this is on 2 levels-- the master slave > relationship between host & terminal, which I just mentioned, as well as the > fact that 3270 terminals use a proprietary hardware protocol-- coax (after > the coaxial cable that attaches terminal to controller.) I am unclear in > this part-- is this protocol "bisync", or is it a protocol unto itself? Oh > yeah-- as another poster already mentioned, many 3270 terminals are actually > strawmen, with the real smarts actually located in the control unit, not the > terminal. This would then make the terminal like a "waldo".... (snip) IIRC, the protocol was "bisync". In the early eighties, I was working on a project that required a high speed character connection between a S360 or 370 machine (I forget which) and a HP system 1000 minicomputer. We did it with a protocol converter (off the shelf from Black Box) that made the HP look like a 3270 to the 360 and the 360 looked like a very smart ascii terminal to the HP. Cheers, John -- John L. Pearlman or If one man calls you a donkey, pay him no heed. If two men call you a donkey, get yourself a saddle. (ancient Rabbinic saying) ###### From: cbh@REMOVE_THIS.teabag.demon.co.uk (Chris Hedley) Newsgroups: alt.folklore.computers Subject: Re: IBM S/360 Date: 20 Feb 1999 16:06:42 GMT Organization: Honest Chris' Sysadmin Emporium Message-ID: <7ammii$rnn$6@teabag.demon.co.uk> References: <7a9n2d$1df@netaxs.com> <36C909CE.6CA7A6D6@acm.org> NNTP-Posting-Host: localhost X-NNTP-Posting-Host: teabag.demon.co.uk:193.237.4.110 X-Trace: news.demon.co.uk 919530006 nnrp-10:17192 NO-IDENT teabag.demon.co.uk:193.237.4.110 X-Complaints-To: abuse@demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Newsreader: knews 1.0b.0 Lines: 23 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!news.belnet.be!newsfeed.ecrc.net!newsfeed.nacamar.de!newsfeed.nacamar.de!newspeer.clara.net!news.clara.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!teabag.demon.co.uk!not-for-mail In article <36C909CE.6CA7A6D6@acm.org>, "Joel C. Ewing" writes: > Most of the logic was contained in a controller, which could handle up > to 32 separate 3270 devices and which was either direct-channel attached > (local) or attached to a bi-sync communication line (remote). This just reminded me of the rather perverse concoction of protocols which were used for one method of dial-up access to the mainframe system of a former employer. Instead of a 3270 unit, the processing was done by a job running on a Unix system connected to the mainframe's FEP using a (slow) bisynch line, and that did all the EBCDIC/3270 to ASCII/curses processing. The ASCII datastreams were re-multiplexed and sent via another bisynch connection to one of the Unix system's terminal controllers, which would then unpack the signal and send it to the relevant serial ports; these were individually hard-wired to the modem controller's serial multiplexor which would in turn do the work of separating the data out again to the relevant 'phone lines. It actually worked very well in spite of the complexity, and much faster response times were possible than via the mainframe's own dial-up facility. Chris.