drk@june.cs.washington.edu (Dan Kerns) (06/03/89)
In article mat@uts.amdahl.com (Mike Taylor) writes: >We could start a whole new debate - what is a mainframe? We make them >but I'm not sure that there is a well-understood definition. This could really be interesting. What with micro-mainframes, mainframes-on-a-chip, mainframe-pc's... So, what is a mainframe? -- Dan Kerns drk@cs.washington.edu U of Washington Computer Science
fotland@hpihoah.HP.COM (Dave Fotland) (06/04/89)
A mainframe is a machine whose minimum usable configuration costs over $1 Million (or pick your favorite number). You can't use performance in the definition since it varies with time. Mainframes have other distinguishing features, such as: Availability (total unplanned downtime/total time) > 99.8% Mean time to repair (including travel and diagnose time) < 4 hours Operating system/hardware support for high thruput, low latency transaction processing. -David Fotland
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (06/05/89)
In article <8442@june.cs.washington.edu> drk@uw-june.UUCP (Dan Kerns) writes: * In article mat@uts.amdahl.com (Mike Taylor) writes: * >We could start a whole new debate - what is a mainframe? We make them... * This could really be interesting. What with micro-mainframes,... * So, what is a mainframe? Wellllll........ A mainframe is: 1) a way to use up computational horsepower in "managing" user "access" instead of making it available to the users. 2) a way to increase the importance of the "MIS" manager's position. 3) a way to minimize the users' control over the work they need to do. 4) a way to justify exorbitant software costs. 5) not the same as a shared (files, I/O, archive, mail, etc.) server. 6) not the same as a shared, high-performance computational server. 7) not the same as a shared (database, transaction, etc.) server. 8) any hardware implementation which allocates more cost to user separation than to user service. Grrruuuuummmmmppphhhh?
foo@titan.rice.edu (Mark Hall) (06/05/89)
In article <4420012@hpihoah.HP.COM> fotland@hpihoah.HP.COM (Dave Fotland) writes: >Mainframes have other distinguishing >features, such as: > >Availability (total unplanned downtime/total time) > 99.8% Our experience has been that unplanned downtime/total has been no more than 90% ;^)
peter@ficc.uu.net (Peter da Silva) (06/05/89)
I was taught that there was a fairly clear distinction between micros, minis, and mainframes: Micro: CPU substantially on one chip. Mini: CPU on a single card. Mainframe: CPU on multiple cards. I know there are machines that stretch these definitions (the PDP-8, for example) as well as machines that don't fit any of these categories (massively parallel machines, for example), but it still seems to me to be a good place to start from. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
pechter@scr1.UUCP (Bill Pechter) (06/07/89)
In article <4400@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I was taught that there was a fairly clear distinction between micros, minis, >and mainframes: A couple of amendments to cover the 1960-1985 minis... > Micro: CPU substantially on one chip. Should be CPU on a chip or "set of chips." That will cover everything from the early 4 chip PDP11/03 through the MicroVax and other chip-set micros. > Mini: CPU on a single card. CPU on a card or group of cards. Price under $250k for the CPU. Minimum of 8 bit words. > Mainframe: CPU on multiple cards. Price above $250k for CPU alone. Minimum 32 bit words. -- Bill Pechter -- Home - 103 Governors Road, Lakewood, NJ 08701 (201)370-0709 Work -- Concurrent Computer Corp., 2 Crescent Pl, MS 172, Oceanport,NJ 07757 Phone -- (201)870-4780 Usenet . . . rutgers!pedsga!tsdiag!scr1!pechter ** MS-DOS is CP/M on steroids, bigger bulkier and not much better **
childers@avsd.UUCP (Richard Childers) (06/07/89)
fotland@hpihoah.HP.COM (Dave Fotland) writes: >A mainframe is a machine whose minimum usable configuration costs over >$1 Million (or pick your favorite number). Having a preference for simple and durable definitions, how about : A mainframe is any machine that's large enough to live in. -- richard -- * "We must hang together, gentlemen ... else, we shall most assuredly * * hang separately." Benjamin Franklin, 1776 * * * * ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers@tycho *
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (06/07/89)
In article fotland@hpihoah.HP.COM (Dave Fotland) writes:
* ...
* features, such as:
* Availability (total unplanned downtime/total time) > 99.8%
Welll... I'm sure this is a bit of a typo on Dave's part, but I've
known a system or two where it seemed to be the case :-(mo@prisma (06/07/89)
I/O rates. You didn't mention I/O rates. Large computers can do Large I/O, regardless of the binary encoding of their instruction set. -Mike
peter@ficc.uu.net (Peter da Silva) (06/08/89)
In article <366@scr1.UUCP>, pechter@scr1.UUCP (Bill Pechter) writes: > In article <4400@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >I was taught that there was a fairly clear distinction between micros, minis, > >and mainframes: > A couple of amendments to cover the 1960-1985 minis... > > Micro: CPU substantially on one chip. > Should be CPU on a chip or "set of chips." No, should be "substantially" on one chip. If the ALU is on a single chip that's good enough. But some of DEC's early "micros" looked like minis to a lot of people (for example, Cromemco). > > Mini: CPU on a single card. > CPU on a card or group of cards. Apart from the PDP-8 (which had a rather psychotic architecture) what else would you call a mini that had a multi-card CPU? The PDP-8s cards were really more like ICs. > Price under $250k for the CPU. I don't think price is a good criterion. Inflation remains a factor. > Minimum of 8 bit words. Not relevant. > > Mainframe: CPU on multiple cards. > Minimum 32 bit words. What about the early 360s? What about their precursors? They're all mainframes. You can come back with the point that any definition that includes chips isn't relevant before chips showed up, but that just points out that micros had a definite starting point. The basic thing to consider is that the three classes of machine have different ranges of real-estate available for non-CPU activities (I/O, for example). This makes them suited for different classes of problems even if their performance ranges intersect. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
usenet@cps3xx.UUCP (Usenet file owner) (06/08/89)
In all this discussion of what defines a (micro,mini,main)frame machine, most of the discussion has been around cards versus chips. COnsidering some of the discussion is ranging over machines designed 20 years apart, wouldn't a much better metric be transistor counts, with a minimum number of transistors for each category within a 5 year span? Then, again I'm sure we all have more important things to do than argue transistor counts ;-) John H. Lawitzke UUCP: Work: ...rutgers!mailrus!frith!dale1!jhl Dale Computer Corp., R&D ...uunet!frith!dale1!jhl 2367 Science Parkway Home: ...uunet!frith!ipecac!jhl Okemos, MI, 48864 Internet: jhl@frith.egr.msu.edu
keith@mips.COM (Keith Garrett) (06/09/89)
In article <4445@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: [definitions of mainframe, minicomputer, microcomputer deleted] > >The basic thing to consider is that the three classes of machine have different >ranges of real-estate available for non-CPU activities (I/O, for example). This >makes them suited for different classes of problems even if their performance >ranges intersect. peter, could you expound on this statement more. i can't think of anything that is intrinsically unique to the different classes of machines. -- Keith Garrett "This is *MY* opinion, OBVIOUSLY" UUCP: keith@mips.com or {ames,decwrl,prls}!mips!keith USPS: Mips Computer Systems,930 Arques Ave,Sunnyvale,Ca. 94086
jkrueger@daitc.daitc.mil (Jonathan Krueger) (06/09/89)
From Juergen Winkelplatz, Kunstwissenshaftliche Geschichte (History of Technology), translated by Francine Przwroclaw, excerpted in Computer Lib/Dream Machines, Ted Nelson, Tempus Books, 1987, page 91 of the Computer Lib part: ---------------------------------------------------------------------------- Four Ages of Mainframes ======================= THE CLASSICAL MAINFRAME: THE 7094. Classic means stark, simple, clean, and what the People Yearn For Abstractly. THE BAROQUE MAINFRAME: (PDP-6 and -10 family, IBM 360 and 370 and so on). In the baroque era, the classic structures become embellished and adorned. While the original ideas are remembered and still recognizable, the embellishments shift and enhance their apparent qualities. THE ROMANTIC MAINFRAME: VAX. What is the Romantic? It is the system of ideas that reorients and redirects. While the old, which previously seemed eternal, is remembered, it now seems superfluous, superseded, in the onrush of up-gathering newness. THE MODERN MAINFRAME: RISC. Comes at last then the Modern. At this culture-time becomes apparent a system of shapes amongst the old more stark, more rarefied and more intrinsic than previously suspected could have been. Out from the confusion of the more recent eras, reaching beyond the classic to a primeval hypothesized simplicity, they arrive, newness condensing oldness into a boldly reduced Reformation. ---------------------------------------------------------------------------- I trust this answers today's question, "what's a mainframe, Dad?" It used to be what the People Yearn For Abstractly, now it's a system of shapes more intrinsic than previously suspected could have been. Hmmm. May have lost something in translation. Well, you get the idea. -- Jon --
peter@ficc.uu.net (Peter da Silva) (06/10/89)
In article <21287@obiwan.mips.COM>, keith@mips.COM (Keith Garrett) writes: > peter, could you expound on this statement more. i can't think of anything > that is intrinsically unique to the different classes of machines. It's more a trend than anything intrinsically unique, but for a given CPU speed you can generally do more I/O at the mainframe end of things. After all, the micro has to feed the whole world through its I/O pins. A mini has a bus and often a bunch of ribbon cables. A mainframe has multiple I/O processors. Compare and contrast static column caches in a micro like an AT/386 with the multiple interleaved memory channels of a mainframe with the same dhrystones rating. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.
sbf10@uts.amdahl.com (Samuel Fuller) (06/13/89)
I think that a good way to classify computers nowadays is not by the horsepower of the CPU but rather by the number of interactive users which it is designed to comfortably support. Microcomputers can support a few users (typically one). Minicomputers can support a few dozen users. Mainframes can support a few hundred users. The small mainframe which I am using now, currently has 102 users logged on. The big corporate system, has a login limit of 525 users. To support this type of load, mainframes need what minis and micros don't -- a very powerful I/O system. It takes more than a fast CPU to call yourself a mainframe. Sam Fuller / Amdahl System Performance Architecture
mcdonald@uxe.cso.uiuc.edu (06/14/89)
>I think that a good way to classify computers nowadays is not by the >horsepower of the CPU but rather by the number of interactive users >which it is designed to comfortably support. Microcomputers can support >a few users (typically one). Minicomputers can support a few dozen >users. Mainframes can support a few hundred users. The small mainframe >which I am using now, currently has 102 users logged on. >The big corporate system, has a login limit of 525 users. To support >this type of load, mainframes need what minis and micros don't -- a very >powerful I/O system. It takes more than a fast CPU to call yourself a >mainframe. But what can those 525 users do at once? How many people can use Emacs at one time and be UNABLE to tell they weren't running on a $6000 PC, by themselves. Doug McDonald
stuart@bms-at.UUCP (Stuart Gathman) (06/14/89)
In article <230@gvlv2.GVL.Unisys.COM>, kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) writes: > Wellllll........ A mainframe is: . . . > 8) any hardware implementation which allocates more cost to user separation > than to user service. That must be why mainframes are so popular with government! -- Stuart D. Gathman <stuart@bms-at.uucp> <..!{vrdxhq|daitc}!bms-at!stuart>
dtynan@altos86.Altos.COM (Dermot Tynan) (06/15/89)
How about this. Forget price, # of {chips,cards,transistors} per CPU, or
anything else. The ultimate indicator is load average :) :) :)
Microcomputer: Average <= 1.0
Minicomputer: Average <= 4.0
Supermini: Average <= 20.0
Mainframe: Average... Well, you get the idea :)
- Der
--
My address: dtynan@altos86.Altos.COM (Hopefully!)
Otherwise: {altnet,amdahl,pyramid,sun}!altos86!dtynan
--- "May the blessings of Jeyes Fluid fall upon you" ---mac@uvacs.cs.Virginia.EDU (Alex Colvin) (06/18/89)
Micro-, mini-, & main- frames: Someone did this by weight - mini < 50 pounds, main > 500. Good distinctions are by environment & support. A micro doesn't need its own room. A mainframe needs special air (& water?). A micro doesn't need an administrator. A mainframe needs an operator.
david@torsqnt.UUCP (David Haynes) (06/27/89)
In article <187@uvacs.cs.Virginia.EDU> mac@uvacs.cs.Virginia.EDU (Alex Colvin) writes: >Micro-, mini-, & main- frames: > >Someone did this by weight - mini < 50 pounds, main > 500. [ other examples deleted ] My favourite measuring stick is: If it lets you run off the end of memory and doesn't complain, its a micro. If it lets you run off the end of memory and complains, its a mini. If, when you try to run off the end of memory, it swaps in more, its a mainframe. Yes, this does mean that you can make a slow mainframe using chips like the Motorola 6800! -david-
lynch@batcomputer.tn.cornell.edu (Tim Lynch) (06/27/89)
How about: If a single user can afford it, it's a micro. If a department can afford it, it's a mini. If a corporation can afford it, it's a mainframe.
henry@utzoo.uucp (Henry Spencer) (06/27/89)
In article <355@torsqnt.UUCP> david@torsqnt.UUCP (David Haynes) writes: > If, when you try to run off the end of memory, it swaps in more, > its a mainframe. And if, when you try to run off the end of memory, it prints out a PO for more memory, and puts your job in paging wait until it arrives... it's a Multics machine!! :-) :-) :-) -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
ram@shukra.Sun.COM (Renu Raman) (06/27/89)
In article <8266@batcomputer.tn.cornell.edu> lynch@tcgould.tn.cornell.edu (Tim Lynch) writes: > >How about: > >If a single user can afford it, it's a micro. > >If a department can afford it, it's a mini. > >If a corporation can afford it, it's a mainframe. A VP of R&D at some three letter company once said.... "Have you seen the brontosaurus gazing on the show floor? No, really, there's this big pre-historic monster out there, with bodily fluids being pumped through it from a truck outside. And they have built a big observation deck for people to come in a gawk at it - it's just like at the La Brea tar pits!". He was apparently referring to a mainframe from another three letter company. renu raman
chung@CS.UOREGON.EDU (06/28/89)
> How about: > > If a single user can afford it, it's a micro. > > If a department can afford it, it's a mini. > > If a corporation can afford it, it's a mainframe. Sounds good, but o if a millionaire buys a mainframe just for personal use, then the mainframe is just a PC (micro). o if a corporation just needs a PC to handle their accounting, then the PC is now a mainframe. o if you (assume you're a personal user) can afford the mini just for fun, then you can imagine what that would be. Based on what you said, I can give some illogical examples. <:-)) Wing-kuen Chung. The Wing Master of CIS at UO. W W IIIII NNNN NNN GGGGGG W W I N N N G G W W W I N N N G W W W I N N N G GGGG W W W W I N N N G G WW WW IIIII NNN NNNN GGGGGG
sl@van-bc.UUCP (Stuart Lynne) (06/28/89)
>>Micro-, mini-, & main- frames:
If it's design/architecture dates to the early sixties it's a mainframe.
It it's design/architecture dates to the late sixties, early seventies it's
a mini.
If it's design/architecture dates to the late seventies its a micro.
If it's design/architecture dates to the early eighties its a super-micro.
If it's design/architecture dates to the late eighties its a .......
--
Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)bzs@bu-cs.BU.EDU (Barry Shein) (06/28/89)
Mainframes are generally at the top of the line in overall I/O (particularly disk) performance, that's the critical measure. For example, top-end mainframes have separate I/O processors on their disk channels with significant processing capablities (like the ability to search for keys independent of the main cpu.) They also have multi-ported memory systems so many channels can be pumping data simultaneously. This last fact is critical, a mini or micro might claim similar I/O performance on a single stream of data but invariably they can't handle multiple data streams simultaneously so overall system performance is a fraction of a true mainframe. It's not unusual for mainframes to be able to pump 16 or more separate disk channels simultaneously (ie. not by competing for one bus.) Watching a true mainframe spinning several 200 ips tape drives simultaneously at full speed (hint: the tapes are spinning at what looks like full rewind speeds) while keeping a disk farm busy gives one the right idea of what true mainframe users are after. Most minis and all micros I've ever seen can hardly spin data between a disk and a tape without the tape visibly hesitating, particularly when writing the disk. I/O capacity is important also, these days mainframes often manage on the order of a terabyte or more of disk AND CAN ACTUALLY DO SOMETHING WITH IT IN A REASONABLE AMOUNT OF TIME. Another common feature is system hardware robustness, it was putting this type of robustness into minis that earned Tandem its fortunes. Mainframe users demand a lot of uptime, these systems can't go down just because a memory board or disk died. It's not uncommon to have 1000 or more users logged in; you can't idle them every time the system hiccoughs, that's the kind of thing people pay millions of dollars for and can justify in a large organization. Minis and micros are not as well defined but (good) minis often offer mainframe-like performance on a very small number of jobs, you can move a small group off the mainframe onto the mini without much loss of performance. The term "micro" generally refers to a certain type of packaging and manufacturing approach that minimizes costs firstly and might (these days) give near-mainframe performance on very simple, single-threaded applications. But I/O is the real point, 16 simultaneous channels pumping a terabyte of disk farm while 200 ips tapes spin freely and 1000 or more users are getting good interactive response...that's the idea and it takes serious system architectural features to acheive that, you don't do that with one board or simplistic bus designs (at least not yet.) Maybe that's a way of differentiating them, micros often have no real bus, minis usually have one or maybe a very few, mainframes have many with independent I/O processors and separate paths to/from memory. -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs
dik@cwi.nl (Dik T. Winter) (06/28/89)
In article <33942@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > But I/O is the real point, 16 simultaneous channels pumping a terabyte > of disk farm while 200 ips tapes spin freely and 1000 or more users > are getting good interactive response...that's the idea and it takes > serious system architectural features to acheive that, you don't do > that with one board or simplistic bus designs (at least not yet.) > As I said in another newsgroup; I had during a 12 hour session about 260 16kbyte page faults per second on a CDC Cyber 995. I think that ranks as a mainframe. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
brooks@maddog.llnl.gov (Eugene Brooks) (06/28/89)
In article <33942@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >Mainframes are generally at the top of the line in overall I/O >(particularly disk) performance, that's the critical measure. Okay, I will bite on this! Here are elapsed times in seconds for the unpacking of a source archive on some representative machines. MACHINE and OS TIME in SEC Cray YMP running NLTSS 40 Cray XMP4/16 running LTSS 5 SUN2/50 DISKLESS SUNOS 3.4 10.8 SUN3/50 DISKLESS SUNOS 4.0.1 6.9 SUN3 WITH DISK SUNOS 4.0.1 2.7 Which is the mainframe? Which would you rather compile and load a program on? brooks@maddog.llnl.gov, brooks@maddog.uucp
des@yatton.inmos.co.uk (David Shepherd) (06/28/89)
The definitions I have heard are: o If its larger than its user manuals its a mainframe o If its the same size as its user manuals its a mini o If its smaller than its user manuals its a micro david shepherd INMOS ltd (Carefull inspection of the transputer databook shows that it is a micro ;-)
bzs@bu-cs.BU.EDU (Barry Shein) (06/28/89)
>Okay, I will bite on this! Here are elapsed times in seconds for >the unpacking of a source archive on some representative machines. > >MACHINE and OS TIME in SEC >Cray YMP running NLTSS 40 >Cray XMP4/16 running LTSS 5 >SUN2/50 DISKLESS SUNOS 3.4 10.8 >SUN3/50 DISKLESS SUNOS 4.0.1 6.9 >SUN3 WITH DISK SUNOS 4.0.1 2.7 > >Which is the mainframe? Which would you rather compile and load a program on? > > >brooks@maddog.llnl.gov, brooks@maddog.uucp None of those are mainframes and this sort of statistic is useless anyhow, put 16 of those jobs up at once and tell me what they're getting as an aggregate and then perhaps we can talk. I'm not even sure what your point is, and somehow doubt you read the whole message stressing aggregate throughput, not single-stream. -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs
les@unicads.UUCP (Les Milash) (06/29/89)
In article <156@van-bc.UUCP> sl@.UUCP (Stuart Lynne) writes: >If it's design/architecture dates to the late eighties its a ....... _R_I_S_C_
dmb@abvax.UUCP (David Babuder) (06/29/89)
In article <8906271822.AA12529@drizzle.cs.uoregon.edu> chung@CS.UOREGON.EDU writes: > > >> How about: >> If a single user can afford it, it's a micro. >> If a department can afford it, it's a mini. >> If a corporation can afford it, it's a mainframe. > >Sounds good, but > what if a millionaire buys a mainframe the millionaire is probably incorporated > what if a corporation just needs a PC to handle their accounting, then they probably just incorporated for personal fun anyway > what if you (assume you're a personal user) can afford the mini they you should learn to share! As you might guess, I thought the breakdown by affordability is appropriate; we just need to figure out the size of the average budget for users, departments, companies, corporations, and bureaucracies! Dave Babuder Software Quality:Operations and Customer Support Manager Allen-Bradley Company (ICCG) A Rockwell International Company (standard disclaimer applies)
brooks@maddog.llnl.gov (06/29/89)
In article <33968@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >None of those are mainframes and this sort of statistic is useless >anyhow, put 16 of those jobs up at once and tell me what they're >getting as an aggregate and then perhaps we can talk. > >I'm not even sure what your point is, and somehow doubt you read the >whole message stressing aggregate throughput, not single-stream. I think that system response is a useful statistic which either causes users to buy time on mainframes or buy their own affordable workstations. I will supply the benchmark to anyone who wants to run it on a REAL mainframe. What is a mainframe? It's an OBSOLETE COMPUTER! brooks@maddog.llnl.gov, brooks@maddog.uucp
leichter@CS.YALE.EDU (Jerry Leichter) (06/29/89)
In article <518@unicads.UUCP>, les@unicads.UUCP (Les Milash) writes... >In article <156@van-bc.UUCP> sl@.UUCP (Stuart Lynne) writes: >>If it's design/architecture dates to the late eighties its a ....... > _R_I_S_C_ ..which, of course, should not be taken to mean that it has a reduced instruction set (or whatever you want to translate RISC into), just that the marketing people knew that "RISC" was the "buzzword of the year" and a great way to make a new machine sound better, stronger, faster.... -- Jerry
les@unicads.UUCP (Les Milash) (06/29/89)
In article <64991@yale-celray.yale.UUCP> leichter@CS.YALE.EDU (Jerry Leichter) writes: >In article <518@unicads.UUCP>, les@unicads.UUCP (Les Milash) writes... >>>If it's design/architecture dates to the late eighties its a RISC >which should not be taken to mean that it has a reduced instruction set >but just that "RISC" was the "buzzword of the year" kind of my point. as i recall this group could never agree what RISC even meant, somewhere between hardwired logic, exposing innards to the compiler, etc... but then all that real estate was used for windows, registers, scoreboards, graphics junk, etc... i kinda decided in my mind that RISC meant Radical Instruction Set Computer and CISC meant Conservative Instruction Set Computer. these terms are relative to the current trends&thinking. if in 10 yrs Caltech and Stanford are making faster chips easier paging microcode, nanocode, picocode, and fempto code off an optical disk, that'll be Radical, and if it's faster it'll be a good thing generally. for now tho let's quit defining sh*t and talk about how to build faster sh*t. nitey nite.
frank@zen.co.uk (Frank Wales) (06/29/89)
As far as I'm concerned, + if it's mine, it's a mainframe; + if it's yours, it's a mini; + if it's theirs, it's a micro (and a slow one at that). -- Frank Wales, Systems Manager, [frank@zen.co.uk<->mcvax!zen.co.uk!frank] Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217
stuart@bms-at.UUCP (Stuart Gathman) (06/30/89)
In article <27637@lll-winken.LLNL.GOV>, brooks@maddog.llnl.gov (Eugene Brooks) writes: > In article <33942@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >Mainframes are generally at the top of the line in overall I/O > >(particularly disk) performance, that's the critical measure. > Okay, I will bite on this! Here are elapsed times in seconds for > the unpacking of a source archive on some representative machines. > MACHINE and OS TIME in SEC > Cray YMP running NLTSS 40 . . . > SUN3 WITH DISK SUNOS 4.0.1 2.7 A cray is a "supercomputer", not a mainframe. It is not optimized for I/O, but for vector computation. Vaxen are often used as cray front ends. What you need is figures for a 3090, but there're hard to come by since most mainframes run dinosaur OS's that have never heard of a source archive. (Programmers tend not to use macros with their assembler, let alone a high level language.) Most of the massive I/O bandwidth on mainframes is wasted due to stupid software. They can copy files at 3 Mbytes/sec, but even with only one user, editing is faster on a PC. A mini can load indexed files faster than DB2 on a mainframe. I just read an article in Computerworld about how many data centers are automating their operation. The most popular "automation"? A program to ignore the copious messages appearing on the console -- i.e. the operator doesn't need to keep pressing the acknowledge key. I think that even in I/O bandwidth, traditional (three letter) mainframes are about to be overtaken. A typical system has 12 x 3 Mbyte/sec independent (and intelligent) channels. This gives an aggregate throughput of 288 Mbits/sec. The peripheral controller Intel offers with the 486 claims an aggregate throughput of 150 Mbits/sec with 8 independent channels. This is getting close, and it is certainly not hard to beat a 6 Mips CPU these days. I hear that the NeXT has a high throughput peripheral chip also. The micro solution to high throughput disks is not fast (and expensive) disks, but disk arrays. By running lots of cheap disks in parallel you get the throughput of the big jobbers at a fraction of the cost. The fact remains that software, not hardware, is what limits a computer system at any price level. (With a few special purpose exceptions.) -- Stuart D. Gathman <stuart@bms-at.uucp> <..!{vrdxhq|daitc}!bms-at!stuart>
prc@erbe.se (Robert Claeson) (06/30/89)
In article <156@van-bc.UUCP> sl@.UUCP (Stuart Lynne) writes: >It it's design/architecture dates to the late sixties, early seventies it's >a mini. >If it's design/architecture dates to the late seventies its a micro. >If it's design/architecture dates to the early eighties its a super-micro. >If it's design/architecture dates to the late eighties its a ....... Supermini! An interpolation gives that an early nineties design/architecture must be a super-mainframe. -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
shapiro@rb-dc1.UUCP (Mike Shapiro) (06/30/89)
In article <8906271822.AA12529@drizzle.cs.uoregon.edu> chung@CS.UOREGON.EDU writes: ... >> How about: >> If a single user can afford it, it's a micro. >> If a department can afford it, it's a mini. >> If a corporation can afford it, it's a mainframe. > >Sounds good, but > o if a millionaire buys a mainframe just for personal > use, then the mainframe is just a PC (micro). ... Ah, one of our jargon problems. I maintain that from a historical perspective, "personal computer" is not necessarily a synonym for "micro computer." Use of the term as a synonym really came into widespread use with the introduction of the IBM Personal Computer. At times during my career, I have used Control Data 6500 and Cyber 175, IBM 360, and many other non-micro computers as "personal" computers, in this case meaning I was the only user at the time; the machine was dedicated to me. The first computer I worked on was an LGP-30 personal desk computer. It allowed one user at a time (with punched paper tape i/o) and was about the size of desk (including the magnetic drum memory). So there we have it. A mainframe or mini can be a personal computer by my definition. It's just not necessarily a microcomputer. :-)-- Michael Shapiro, Encore Computer Corporation (formerly Gould/GSD) 15378 Avenue of Science, San Diego, CA 92128 (619)485-0910 UUCP: shapiro@rb-dc1 (This location will close, starting July 10. I will be moving on.)
bzs@bu-cs.BU.EDU (Barry Shein) (06/30/89)
>What is a mainframe? It's an OBSOLETE COMPUTER! > > >brooks@maddog.llnl.gov, brooks@maddog.uucp For most people I do agree with you on this point. The situation is that processing speed has grown a lot faster than most organization's needs particularly in the business data processing arena. People who needed a 2 MIPS, 4MB state of the art mainframe in 1980 are now being sold 100+MIPS, 256MB state of the art mainframes and it's not clear at all that their processing needs on that one machine have grown 50X in under a decade (ok, maybe they were dissatisfied with performance on that older machine, but still, 20X?) Especially with the distribution of a lot of the processing out onto small machines which are still faster than those 1980 mainframes. There of course exists that relatively small group of customers with massive hunger like the American Expresses, Master Cards and JC Penneys of the world who can still swallow these machines in one gulp. But, for example, universities who continue to buy and upgrade their mainframes out of habit to handle maybe a few hundred thousand records are being ridiculous, most of what they do can be easily handled today on a good desktop machine or perhaps a little bigger system if there is a good need (shared data base) to hook up a few dozen dumb terminals to one system. It's mostly old guard administrators trying to preserve an empire. It's sort of hard to justify an MIS staff of 100+ people just to manage a desktop or little mini. So, I'd agree that mainframes are mostly obsolete for all but perhaps the fortune 500 companies who really do need to quickly manage on the order of hundreds of gigabytes of data in a timely matter. -- -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202 Internet: bzs@skuld.std.com UUCP: encore!xylogics!skuld!bzs or uunet!skuld!bzs
sbf10@uts.amdahl.com (Samuel Fuller) (06/30/89)
In article <34038@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >>What is a mainframe? It's an OBSOLETE COMPUTER! >> >> >>brooks@maddog.llnl.gov, brooks@maddog.uucp >There of course exists that relatively small group of customers with >massive hunger like the American Expresses, Master Cards and JC >Penneys of the world who can still swallow these machines in one gulp. >So, I'd agree that mainframes are mostly obsolete for all but perhaps >the fortune 500 companies who really do need to quickly manage on the >order of hundreds of gigabytes of data in a timely matter. > I find it hard to believe that a 50 Billion plus dollar-per-year business can be considered obsolete or even mostly obsolete. The mainframe segment of the computer market continues to grow and will probably be around for a lot longer than most of the posters to this newsgroup would like to believe. What is a mainframe? It's a commercial/business supercomputer. Sam Fuller / Amdahl System Performance Architecture My Opinions.
eugene@eos.UUCP (Eugene Miya) (06/30/89)
In article <c4Kj02Dz397m01@amdahl.uts.amdahl.com> sbf10@amdahl.uts.amdahl.com (Samuel Fuller) writes: >In article <34038@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >> Eugene Brooks wrote: >>>What is a mainframe? It's an OBSOLETE COMPUTER! > >>So, I'd agree that mainframes are mostly obsolete for all but perhaps >>the fortune 500 companies who really do need to quickly manage on the >>order of hundreds of gigabytes of data in a timely matter. Then Sam wrote: >I find it hard to believe that a 50 Billion plus dollar-per-year business >can be considered obsolete or even mostly obsolete. The mainframe >segment of the computer market *continues* to grow and will probably >be around for a lot longer than most of the posters to this newsgroup >would like to believe. > >What is a mainframe? It's a commercial/business supercomputer. Well, I just got this Datamation rag (from my older days 8), and while I can't quite get as extreme as Keith, I don't think, nor do the Datamation folk think that mainframes are continuing growth. They are peaking, stagnating, (add your own adjectives). The growth is largely in perpherals like the disk drives for the mainframes. Pardon my comments to mainframe manufacturers, but maybe its approaching time to try and replace lots of these machines. Sure, the micros don't have the bus bandwidth, but is this a matter of time and integration, or do you believe such bandwidth will be forever confinded to mainframes and supercomputers? Yes, COBOL and RPG on future micros. 8) Another gross generalization from --eugene miya, NASA Ames Research Center, eugene@aurora.arc.nasa.gov resident cynic at the Rock of Ages Home for Retired Hackers: "You trust the `reply' command with all those different mailers out there?" "If my mail does not reach you, please accept my apology." {ncar,decwrl,hplabs,uunet}!ames!eugene Live free or die.
tmyers@orion.cf.uci.edu (Tracy Myers) (07/01/89)
A mainframe is any machine which runs COBOL !!!! :-)
pfeiffer@nmsu.edu (909) (07/01/89)
> >If a single user can afford it, it's a micro. > >If a department can afford it, it's a mini. > >If a corporation can afford it, it's a mainframe. and if Lucasfilms or the US Gummint can afford it, it's a Cray! -Joe.
brooks@vette.llnl.gov (Eugene Brooks) (07/01/89)
In article <164@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes: >The micro solution to high throughput disks is not fast (and >expensive) disks, but disk arrays. By running lots of cheap >disks in parallel you get the throughput of the big jobbers at a >fraction of the cost. An impressive example of this is the self healing disk system for the Connection Machine. Its throughput is 32 megabytes per second, and it is composed of an array of disk drives such that each drive handles one bit of a 64 bit word. 72 drives are used in a standard error correcting scheme and if one disk fails completely the think stays up. You replace the disk and its data gets reconstructed from the error correction code. Now all we need it a "real mainframe" for it to keep fed, which of course should be an array of microprocessors... brooks@maddog.llnl.gov, brooks@maddog.uucp
friedl@vsi.COM (Stephen J. Friedl) (07/01/89)
In article <27814@lll-winken.LLNL.GOV>, brooks@vette.llnl.gov (Eugene Brooks) writes: > An impressive example of this is the self healing disk system for the > Connection Machine. Its throughput is 32 megabytes per second, and > it is composed of an array of disk drives such that each drive handles > one bit of a 64 bit word. 72 drives are used in a standard error correcting > scheme and if one disk fails completely the think stays up. You replace > the disk and its data gets reconstructed from the error correction code. I think Micropolis came out with one of these as well. They used nine drives with spindle synchronization logic. Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl ---> vsi!bang!friedl <-- NEW "Friends don't let friends run Xenix" - me
seanf@sco.COM (Sean Fagan) (07/02/89)
In article <27637@lll-winken.LLNL.GOV> brooks@maddog.llnl.gov (Eugene Brooks) writes: >Okay, I will bite on this! Here are elapsed times in seconds for >the unpacking of a source archive on some representative machines. > >MACHINE and OS TIME in SEC >Cray YMP running NLTSS 40 >Cray XMP4/16 running LTSS 5 >SUN2/50 DISKLESS SUNOS 3.4 10.8 >SUN3/50 DISKLESS SUNOS 4.0.1 6.9 >SUN3 WITH DISK SUNOS 4.0.1 2.7 Real-time seconds, or system-time seconds? How loaded were each of the machines? What kind of archive? What program was unarchiving them? Any chance that the YMP had the archive on a disk over ethernet (I *hope* not!)? >Which is the mainframe? Which would you rather compile and load a program on? I'd rather compile on the Cray's, thank you very much. Of course, on the Cray's, I'd also rather program in FORTRAN, not C (assembly would not even be my first choice on those machines). I can, if you wish, come up with other numbers (such as, for example, how long it takes to compiler SPICE on a Sun 2 and 4, versus compiling in on a CDC Cyber 170/760. Incidently, the Cyber was at least an order of magnitude faster); one set of numbers, with no other information, is not a good indicator. -- Sean Eric Fagan | "Uhm, excuse me..." seanf@sco.UUCP | -- James T. Kirk (William Shatner), ST V: TFF (408) 458-1422 | Any opinions expressed are my own, not my employers'.
seanf@sco.COM (Sean Fagan) (07/02/89)
In article <518@unicads.UUCP> les@unicads.UUCP (Les Milash) writes: >In article <156@van-bc.UUCP> sl@.UUCP (Stuart Lynne) writes: >>If it's design/architecture dates to the late eighties its a ....... > _R_I_S_C_ Really? Wow. I'm sure Seymour Cray, who designed, in the early-to-mid '60's, a machine with 70-odd instructions, and most of the features associated with "RISC," would be very surprised to hear that. RISC, as a concept, is decades old, now. Cray did the Cybers that way to make them run quickly; at about the same time, IBM had a research project going on to see if it could, indeed, run more quickly. I'm fairly certain Seymour did *his* because he hardwires his machines (no micro-code on *real* computers 8-)), while IBM was just seeing how true and useful the 80-20 rule was. (I don't *think* either party was influenced by the other, but, since I haven't had a chance to talk to Seymour [aka God 8-)], I can't be certain.) Then, of course, Universities got a hold of the whole idea, and it took off. The rest is, as they say, history. -- Sean Eric Fagan | "Uhm, excuse me..." seanf@sco.UUCP | -- James T. Kirk (William Shatner), ST V: TFF (408) 458-1422 | Any opinions expressed are my own, not my employers'.
brooks@vette.llnl.gov (Eugene Brooks) (07/02/89)
In article <2964@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes: >Real-time seconds, or system-time seconds? How loaded were each of the >machines? What kind of archive? What program was unarchiving them? Any >chance that the YMP had the archive on a disk over ethernet (I *hope* not!)? The problem for the YMP is that it had to go through all of the software layering as if the file had been out on a disk over an ethernet. Some refer to this as a BUG of NLTSS, others refer to this as a FEATURE. The two sun diskless nodes really did suck the files in over an ethernet. Lock-out priority was used on the Crays, and the timings was done at many times during the day (including lightly loaded times) and consistent results were obtained. The archive program and the sample archive can be supplied to anyone who requests it. Remember, however, that the best benchmark is YOUR benchmark. This archive program is something I use frequently to transfer source files to a Cray and this is the reason for its importance to me. brooks@maddog.llnl.gov, brooks@maddog.uucp
bcase@cup.portal.com (Brian bcase Case) (07/03/89)
>Really? Wow. I'm sure Seymour Cray, who designed, in the early-to-mid >'60's, a machine with 70-odd instructions, and most of the features associated >with "RISC," would be very surprised to hear that. (I suspect Cray doesn't give a rat's ass.) >RISC, as a concept, is decades old, now. Cray did the Cybers that way to >make them run quickly; at about the same time, IBM had a research project >going on to see if it could, indeed, run more quickly. I'm fairly certain Sean, what project did IBM have in the mid '60s that investigated RISC? I am not aware of such a project.
shapiro@rb-dc1.UUCP (Mike Shapiro) (07/03/89)
In article <2179@orion.cf.uci.edu> tmyers@orion.cf.uci.edu (Tracy Myers) writes: >A mainframe is any machine which runs COBOL !!!! :-) Oh, you mean like a Kaypro II running RM-COBOL under CP/M? -- Michael Shapiro, Encore Computer Corporation (formerly Gould/GSD) 15378 Avenue of Science, San Diego, CA 92128 (619)485-0910 UUCP: shapiro@rb-dc1 (This location will close, starting July 10. I will be moving on.)
kennel@mickey.cognet.ucla.edu (Matthew Kennel) (07/04/89)
In article <33942@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
)
)[Heavy Metal does big I/O]
)
)Minis and micros are not as well defined but (good) minis often offer
)mainframe-like performance on a very small number of jobs, you can
)move a small group off the mainframe onto the mini without much loss
)of performance. The term "micro" generally refers to a certain type of
)packaging and manufacturing approach that minimizes costs firstly and
)might (these days) give near-mainframe performance on very simple,
)single-threaded applications.
This illustrates the obvious conclusion:
A supercomputer is a mainframe with an adequate CPU.
) -Barry Shein
)Internet: bzs@skuld.std.com
Matt Kennel
kennel@cognet.ucla.edulamaster@ames.arc.nasa.gov (Hugh LaMaster) (07/04/89)
In article <164@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes: >In article <27637@lll-winken.LLNL.GOV>, brooks@maddog.llnl.gov (Eugene Brooks) writes: >> In article <33942@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >> >Mainframes are generally at the top of the line in overall I/O While I agree that MVS is yet another incarnation of a lousy user environment, I have to disagree with the following: >I think that even in I/O bandwidth, traditional (three letter) >mainframes are about to be overtaken. A typical system has 12 x >3 Mbyte/sec independent (and intelligent) channels. This gives >an aggregate throughput of 288 Mbits/sec. The peripheral The Systems and Products Guide that I have in front of me shows the 3090 600S with up to 128 3/4.5 MB/sec channels. Even the 4381 MG92E, in IBM's "toy system" line, allows 20 channels at 3.0 MB /sec. IBM recently announced an option for an additional high speed channel on the 309x running at a measured rate of over 70 MB/sec. (Ultra Corp. has a bus/network that operates at this speed.) Total memory bandwidth available is not specified but a quick calculation on other data listed indicates that it exceeds 465 MB/sec. Many popular mini disk subsystems top out at less than 1-2 MB/sec total disk throughput, and some micros do no better than 100-200 KB /sec., the nominal disk transfer rates of 1.8-3.0 MB/sec notwithstanding. A second issue that has come up in this discussion is database performance. Everyone knows that random reads and writes to disks go little faster on a toy system than on a 3090. So, why doesn't ACP / Sabre / VISA run on a "PC"? Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (07/04/89)
In article <4186@eos.UUCP> eugene@eos.UUCP (Eugene Miya) writes: >Sure, the micros don't have the bus bandwidth, but is this a matter >of time and integration, or do you believe such bandwidth will be >forever confinded to mainframes and supercomputers? Yes, COBOL and RPG As long as you can buy a "mainframe" which can do ~1-4 MB/sec of I/O per MIP, and "micros" can do .01 - .2, I would bet there will be plenty of "mainframes" sold. I certainly would like to see mini/micro systems with more memory and I/O bandwidth, yes. When "micros" can do 1-4 MB/sec/MIP, well, then you have miniaturized the mainframe, not replaced it. Whatever a "mainframe" is... Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (07/05/89)
In article <20071@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes:
* ...
* Sean, what project did IBM have in the mid '60s that investigated RISC? I
* am not aware of such a project.
'Twas called the 801.
------
Regardz,
Kenbcase@cup.portal.com (Brian bcase Case) (07/07/89)
>* Sean, what project did IBM have in the mid '60s that investigated RISC? I >* am not aware of such a project. >'Twas called the 801. No, the 801 was begun in 1975. Please stop sending me mail pointing out that the 801 is the answer to my question. If there is a reference to a RISC, or RISC-like project, at IBM in the mid '60s, I would love to have it.
peter@stca77.stc.oz (Peter Jeremy) (07/10/89)
In article <1642@brwa.inmos.co.uk> des@inmos.co.uk (David Shepherd) writes:
+The definitions I have heard are:
+
+ o If its larger than its user manuals its a mainframe
+
+ o If its the same size as its user manuals its a mini
+
+ o If its smaller than its user manuals its a micro
By this definition, a VAX 86xx running VMS version 5 is a micro, and
an AT clone running Xenix is a mainframe :-).
--
Peter Jeremy (VK2PJ) peter@stca77.stc.oz
Alcatel STC Australia ...!uunet!stca77.stc.oz!peter
41 Mandible St peter%stca77.stc.oz@uunet.UU.NET
ALEXANDRIA NSW 2015newbery@rata.vuw.ac.nz (Michael Newbery) (07/12/89)
If it doesn't have, or is its own, console processor--it's a micro If it uses a micro as a console processor--it's a mini If it uses a mini as a console processor--it's a mainframe If it uses a mainframe as a console processor--it's a supercomputer :-) -- Michael Newbery<newbery@rata.vuw.ac.nz> (...!uunet!vuwcomp!newbery if you must) Which of the following callings is unavailable to a lawyer: prime-minister, governor-general, state governor, embezzler, premier, company director, land speculator, petty criminal or judge? Well the answer is of course, none of these. -- 'Fred Dagg'
roy@phri.UUCP (Roy Smith) (07/13/89)
In <1989Jul12.013046.18610@comp.vuw.ac.nz> newbery@rata.vuw.ac.nz (Michael Newbery) writes: > If it doesn't have, or is its own, console processor--it's a micro I guess that makes a Vax-11/750 a micro. When you hit control-P on the console, the CPU goes in to console mode and Unix (or VMS) stops running. You can exit console mode and restart the OS (which, assuming you havn't missed and essential interrupts may or may not work). -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (07/13/89)
In article <550@stca77.stc.oz> peter@stca77.stc.oz (Peter Jeremy) writes: * In article <1642@brwa.inmos.co.uk> des@inmos.co.uk (David Shepherd) writes: * +The definitions I have heard are: * + * + o If its larger than its user manuals its a mainframe * + * + o If its the same size as its user manuals its a mini * + * + o If its smaller than its user manuals its a micro * * By this definition, a VAX 86xx running VMS version 5 is a micro, and * an AT clone running Xenix is a mainframe :-). And if we take _size_ to be the amount of information in the manuals that is currently correct and/or comprehensible to anyone of lesser rank than cosmic high priest, then _any_ *NIX system is a very big mainframe. :-( ----- Ken
rick@pavlov.tmc.edu (Richard H. Miller) (07/16/89)
In article <164@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes: > >What you need is figures for a 3090, but there're hard to come by >since most mainframes run dinosaur OS's that have never heard of >a source archive. (Programmers tend not to use macros with their >assembler, let alone a high level language.) > I have worked with mainframes systems for close to 15 years including IBM, DEcsystem-10s and Unisys 1100. I can assue you that system software for these systems include extensive use of MACROs. This is the only way to do the software and much of the source is in the form of macros for the assembler or is in a high level language. (PL/S [as I remember]. on 360 architectures, BLISS-36 on the DEC-10 or PLUS on the 1100). Richard H. Miller Email: rick@bcm.tmc.edu Asst. Dir. for Technical Support Voice: (713)798-3532 Baylor College of Medicine US Mail: One Baylor Plaza, 302H Houston, Texas 77030
henry@utzoo.uucp (Henry Spencer) (07/16/89)
In article <1604@gazette.bcm.tmc.edu> rick@pavlov.tmc.edu (Richard H. Miller) writes: >>... most mainframes run dinosaur OS's that have never heard of >>a source archive. (Programmers tend not to use macros with their >>assembler, let alone a high level language.) > >I have worked with mainframes systems for close to 15 years including IBM, >DEcsystem-10s and Unisys 1100. I can assue you that system software for these >systems include extensive use of MACROs. This is the only way to do the >software ... In fact, there is generally a strong correlation between the sophistication of the assembler's macro facilities and the extent to which people are expected to use assembler for "real" programming. The reason Unix assemblers generally don't have *any* macro facility is that nobody uses them for routine programming. (When you're doing speed-critical code or the bottom- level kernel primitives, you usually don't want macros hiding the details of the code.) Back in the pre-Unix days when I did a lot of assembler, it wasn't uncommon to run into macro packages that were almost high-level languages. -- $10 million equals 18 PM | Henry Spencer at U of Toronto Zoology (Pentagon-Minutes). -Tom Neff | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mo@prisma (07/16/89)
Personal computers can be moved by one person, possibly in more than one trip. Minicomputers can be moved by two or three people at once (again the number of trips unspecified) Mainframes need a SERIOUS forklift to be moved. It is usually easier to move the building than to move a supercomputer. -Mike
nelson@udel.EDU (Mark Nelson) (07/17/89)
In article <164@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes: > >What you need is figures for a 3090, but there're hard to come by >since most mainframes run dinosaur OS's that have never heard of >a source archive. (Programmers tend not to use macros with their >assembler, let alone a high level language.) > The Cray Operating System (COS) is written entirely in assembler. Since it is essentially a RISC machine (modulo the vector instructions, depending on your personal definition of RISC), and it has 64 bit words, macros are used very heavily, especially for packing and unpacking bit fields in tables. Cray assembler is written very differently from any other assembler I've used (6502, 8080, Z-80, 8086, PDP-10, PDP-11, 68000, Cyber 205). Instead of giving instructions (or families of instructions) names like MOV or ADD, the instructions are written symbolically, e.g.: A1 A2+A3 Integer add of Address registers 2 and 3 (24 bit), storing result in A register 1 S7 100,A1 Memory load from word (100 + contents of A1) to Scalar register 7 (64 bit) S1 S3*FS7 Floating point multiply of S3 times S7, result in S1 Because of this unusual way of writing instructions, Cray assembler has what are called "Opdefs", which are essentially macros recognized by syntax rather than by name. For example, the Cray has no divide instruction. But by properly defining an Opdef, it would be possible to write S5 S2/FS4 which would expand into the four instruction sequence required to do the divide. Of course, I'm speaking for myself, not speaking for Cray Research officially. Mark Nelson ...!rutgers!udel!nelson or nelson@udel.edu This function is occasionally useful as an argument to other functions that require functions as arguments. -- Guy Steele
dik@cwi.nl (Dik T. Winter) (07/17/89)
In article <19834@louie.udel.EDU> nelson@udel.EDU (Mark Nelson) writes: > The Cray Operating System (COS) is written entirely in assembler. > Since it is essentially a RISC machine (modulo the vector instructions, > depending on your personal definition of RISC), and it has 64 bit words, > macros are used very heavily, especially for packing and unpacking bit > fields in tables. > > Cray assembler is written very differently from any other assembler [Description deleted] This is very similar to the situation for the CDC Cybers (except the 205). I think when Cray started his own shop he took along a lot of hard- and software people along from CDC. When you know CDCs operating system NOS/BE (or before that: SCOPE) using COS is no problem. And now we can have some discussion about 'look and feel'. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
peter@ficc.uu.net (Peter da Silva) (07/17/89)
In article <270@gvlv2.GVL.Unisys.COM>, kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) writes: > And if we take _size_ to be the amount of information in the manuals that is > currently correct and/or comprehensible to anyone of lesser rank than > cosmic high priest, then _any_ *NIX system is a very big mainframe. :-( You work at Unisys and you have the gall to complain about UNIX manuals? People bitching about the difference between Bourne and C shells would run screaming from IPF and the 1100 command language. There are things you can't even *do* in the CL... you have to switch to IPF. Then they'd have to figure out yet another command language for the console. As for meaningful acronyms, tell us about FURPUR. And then there are the manuals. If the command is in FURPUR, you look in one place. If it's a utility, you look in another place. IPF has its own manual set. It's as if you had seperate manuals for csh, sh, and then the normal commands in section 1. Not that other proprietary systems are much better. So the UNIX User's Manual isn't a tutorial... big deal. It's one of the best *reference* manuals in the business. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | Th-th-th-that's all folks... Personal: peter@sugar.hackercorp.com. `-_-' | -- Mel Blanc Quote: Have you hugged your wolf today? 'U` | May 30 1908 - Jul 10 1989
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (07/17/89)
In article <1989Jul15.220613.9054@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
* routine programming. (When you're doing speed-critical code or the bottom-
* level kernel primitives, you usually don't want macros hiding the details
* of the code.)
That's Right! You just use "Optimising C" so there's no correlation whatsoever.
-----
Kenhenry@utzoo.uucp (Henry Spencer) (07/18/89)
In article <2700018@prisma> mo@prisma writes: >Minicomputers can be moved by two or three people at once (again >the number of trips unspecified) Mike, you have obviously never tried to push a fully-configured rack-mount Sun up a ramp! :-) (I refuse to believe that a 3/180 is a mainframe.) With that reservation, actually, that's not a bad classification. -- $10 million equals 18 PM | Henry Spencer at U of Toronto Zoology (Pentagon-Minutes). -Tom Neff | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (07/18/89)
In article <5029@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: * In article <270@gvlv2.GVL.Unisys.COM>, (meself) writes: * > And if we take _size_ to be the amount of information in the manuals that is * > currently correct and/or comprehensible to anyone of lesser rank than * > cosmic high priest, then _any_ *NIX system is a very big mainframe. :-( * You work at Unisys and you have the gall to complain about UNIX manuals? * People bitching about the difference between Bourne and C shells would * run screaming from IPF and the 1100 command language. There are things * you can't even *do* in the CL... you have to switch to IPF. Then they'd * have to figure out yet another command language for the console. well, which is why I work for a part of Big U that can honestly disclaim culpability for the 1100s, etc. * As for meaningful acronyms, tell us about FURPUR. heck, I wish someone could tell _me_ about it! :-( * And then there are the manuals. If the command is in FURPUR, you look in * one place. If it's a utility, you look in another place. IPF has its own * manual set. It's as if you had seperate manuals for csh, sh, and then the * normal commands in section 1. and with *NIX, if I want to know how to send e-mail, I look up the -man- page, for -mail- which is prob'ly online but may be preformatted for some terminal type other than what I'm logged-in on, unless I need to know how to put together an address to get the mail to someone in a strange place, in which case I have to look up -mailaddr-, which is OK unless the *NIX port on my immediate host has preverted the AT&T and/or Berkely implementation, in which case the local guru _may_ have a copy of the port notes somewhere under her desk, except when the address is a -uucp- node three hops beyond an internet node, in which case I have to take a look at the _local_ -sendmail.cf- file, _if_ it's readable-permitted to anyone except the guru, and then all I have to do is remember that a bang-sign imbedded in the middle of an address string is _still_ taken as a -history- reference by the shell... ... * Not that other proprietary systems are much better. no, but they are usually somewhere close to consistent from one installation to the next, unless of course we're talking about 3083s vs. 3090s, or 1100-xx vs. 1100-yy :-) * So the UNIX User's Manual isn't a tutorial... big deal. It's one of the best * *reference* manuals in the business. well, see above ------------- regardz and such, Ken
les@unicads.UUCP (Les Milash) (07/19/89)
In article <1989Jul17.231819.27809@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <2700018@prisma> mo@prisma writes: >>Minicomputers can be moved by two or three people at once (again > >Mike, you have obviously never tried to push a fully-configured rack-mount >Sun up a ramp! :-) (I refuse to believe that a 3/180 is a mainframe.) I saw 4 [BIG] guys brute-force a VAX11/785 with disks out to the loading dock. this is like picking up my Subaru wagon (volume-wise and weight wise). Don't get Steve Cohen from Norfolk VA mad at you; he could probably _throw_ that rack-mount-sun up the ramp at you. A new data-point for the taxonomy: a _Multi_processor_ has more than 0.1% of its weight in silicon (or GaAs). waddya think of _that_, folks? the hughes tuna-can probably qualifies. maybe a bunch of transputers wafers bonded onto a ceramic multilayer substrate would too. Sir Clive's wafer-scale ramdisk might (what ever happened to that, anyway?) i mean we got literally tons of sun's around here, but there's probably less than a gram of Si in the lot, not counting dust in the filters. It _is_ a nice network, tho, works F***in Great. Led Z. Milash
seanf@sco.COM (Sean Fagan) (07/19/89)
In article <2700018@prisma> mo@prisma writes: >Mainframes need a SERIOUS forklift to be moved. Well, we had one mainframe (a [you guessed it] Cyber 174), which, to move out of the building, we would have had to a) put a crane on the roof of the building, and b) blocked all traffic for a block around the building. I'm still not sure how they got it into the building originally 8-). >It is usually easier to move the building than to move >a supercomputer. Not true. A Cray-2 or 3 (by all definitions a super) is quite easy to move. It's small, compact, doesn't wiegh an incredible amount, etc. The disk drives might be a pain to move (there being so many of them 8-)), but the machine itself is easy. -- Sean Eric Fagan | "Uhm, excuse me..." seanf@sco.UUCP | -- James T. Kirk (William Shatner), ST V: TFF (408) 458-1422 | Any opinions expressed are my own, not my employers'.
peter@ficc.uu.net (Peter da Silva) (07/19/89)
In article <279@gvlv2.GVL.Unisys.COM>, kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) writes: > and with *NIX, if I want to know how to send e-mail, I look up the -man- page, > for -mail- OK... > which is prob'ly online Online manuals. Given that having online manuals is an innovation other systems don't afford you, why complain about... > but may be preformatted for some terminal > type other than what I'm logged-in on, I've never actually seen manual pages formatted for a terminal. They're formatted for a line printer, but all the backspacing and overstriking should have been handled by more(1). It has been on every system I've used. Also, support for multiple terminal types is another UNIX exclusive... > unless I need to know how to put > together an address to get the mail to someone in a strange place, How many systems even support email to "a strange place"? If it's on another system, how do you expect the *UNIX* manuals to explain it? > and then all I have to do is remember that a bang-sign imbedded in the middle > of an address string is _still_ taken as a -history- reference by the shell... Now that's the first valid gripe I've even seen. This has been fixed in the current version of the cshell: set histchars='#^' changes the ! to #. This is hardly a problem with the *manuals* though. [I said...] > * Not that other proprietary systems are much better. > no, but they are usually somewhere close to consistent from one installation > to the next, unless of course we're talking about 3083s vs. 3090s, or > 1100-xx vs. 1100-yy :-) I don't understand this. I have here or at home the following manuals: Version 7 (Tektronix) System III Berkeley 3BSD Xenix System III System V, pre release 3. SVID System V.3.2 Apart from the SVID, all of them have the same chapter organisation. I have in a pinch used about any of them as a reference for problems in just about any UNIX system you can name. The consistency, given the number of organisations that have pawed through them, is remarkable. I certainly don't find my RMX-11 manuals useful when dealing with VAX/VMS, even though both use the same command language. [ I said: ] > * So the UNIX User's Manual isn't a tutorial... big deal. It's one of the best > * *reference* manuals in the business. > well, see above Ditto. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "A char, a short int, and Personal: peter@sugar.hackercorp.com. `-_-' | an int bit-field were walking Quote: Have you hugged your wolf today? 'U` | through the forest..."
tak@eecg.toronto.edu (Mike Takefman) (07/20/89)
>Well, we had one mainframe (a [you guessed it] Cyber 174), which, to move >out of the building, we would have had to a) put a crane on the roof of the >building, and b) blocked all traffic for a block around the building. I'm >still not sure how they got it into the building originally 8-). My high school math teacher was a student at concordia university during the middle sixties. Some student radicals managed to enter the computer center at the downtown campus located on the fifth floor and heaved parts of the Cyber out a window. -- Michael Takefman "Who killed John F. Kennedy ? " University of Toronto "The Phone Company!" E.E. Computer Group tak@eecg.toronto.edu True Believer
henry@utzoo.uucp (Henry Spencer) (07/20/89)
In article <5076@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >> and then all I have to do is remember that a bang-sign imbedded in the middle >> of an address string is _still_ taken as a -history- reference by the shell... > >Now that's the first valid gripe I've even seen. This has been fixed in >the current version of the cshell: It was always fixed in all versions of the Bourne shell, which is the only shell (post-V6) properly referred to as "the shell". :-) The problem here is that some twit of a sysadmin has given a novice the C shell. -- $10 million equals 18 PM | Henry Spencer at U of Toronto Zoology (Pentagon-Minutes). -Tom Neff | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
les@unicads.UUCP (Les Milash) (07/21/89)
In article <5076@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <279@gvlv2.GVL.Unisys.COM>, kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) writes: >> and then all I have to do is remember that a bang-sign imbedded in the middle >> of an address string is _still_ taken as a -history- reference by the shell... >Now that's the first valid gripe I've even seen. that's why the Unicad band is called BACK SLASH BANG. we're currently about as "good" as the Unicad softball team was; their record last summer was FLOATING POINT EXCEPTION: underflow (core dumped)
panos@tigger.colorado.edu (Panos Tsirigotis) (07/22/89)
In article <279@gvlv2.GVL.Unisys.COM> kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) writes: > ... >* As for meaningful acronyms, tell us about FURPUR. >heck, I wish someone could tell _me_ about it! :-( FURPUR = File Utility Routines/Program Utility Routines I think that File implied data file and Program implied program file (they were not the same thing; a program file was like a directory). Something else now: In the discussion about the PDP-20 I noticed several similarities in the PDP-20 architecture and the one of the Univac/Sperry/UniSys 1100 series (36 bit instructions, indirection bit, execute instruction, subroutine call etc.) Is that a coincidence ? Panos Tsirigotis ---------------------------------------------------- | Email address: panos@boulder.colorado.edu | ----------------------------------------------------
jgd@csd4.milw.wisc.edu (John G Dobnick) (07/22/89)
From article <10205@boulder.Colorado.EDU>, by panos@tigger.colorado.edu (Panos Tsirigotis): > > Something else now: > In the discussion about the PDP-20 I noticed several similarities in the > PDP-20 architecture and the one of the Univac/Sperry/UniSys 1100 series > (36 bit instructions, indirection bit, execute instruction, subroutine > call etc.) > Is that a coincidence ? And then compare these to the IBM 7090/7094 -- 36 bit words, one's complement, , load/store instruction set, etc. etc. (Was the Dec-20 one's complement?) Is that a coincidence? In the 1100's case, the answer is apparently "No!". The early 1100 series machines [1107, 1108 and "friends" {1106, 1100/10, 1100/20}, 1110, 1100/40] had this Processor State Register (PSR) bit labelled "7090 Floating Point Compatibility Mode". -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee INTERNET: jgd@csd4.milw.wisc.edu UUCP: <backbone>!uwvax!uwmcsd1!jgd "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire
bobw@wdl1.UUCP (Robert Lee Wilson Jr) (07/28/89)
And note that the tube type machines from which the 709x evolved were also 36 bitters, and in turn that 36 is a nice multiple of 12 which is the number of rows in an "IBM" card. Since old machines like the 704/701 read cards as binary images into core, and translated bit patterns into (EBCDIC) characters via internal software rather than something in an I/O channel, this was not a coincidence! The past marches on! Bob Wilson (bobw@wdl1.fac.ford.com)
news@ism780c.isc.com (News system) (07/29/89)
In article <3490016@wdl1.UUCP> bobw@wdl1.UUCP (Robert Lee Wilson Jr) writes: >And note that the tube type machines from which the 709x evolved were also >36 bitters, and in turn that 36 is a nice multiple of 12 which is the >number of rows in an "IBM" card. Since old machines like the 704/701 read >cards as binary images into core, and translated bit patterns into ^^^^ If memory serves, the 701 was not a core machine. The 704 was the first IBM machine with core. >(EBCDIC) characters via internal software rather than something in an I/O >channel, this was not a coincidence! >The past marches on! >Bob Wilson Actually the 701/704/709/7090/7094 read cards row wize. that is the contents of row 9 was read then the contents of row 8 and etc. And since there were 36 bits to the word, only 72 colums of a card were be read. The "not a coincidence" is the fact that FORTRAN lines are limited to 72 characters. The choice of 36 bits for the word size has nothing to do with the 12 bits per card column. My guess is that 36 bits of precision was percieved to be required for scientific computation. Bob is correct in that translating card images (as an array of bits) into characters was done by software. The operation was refered to as corner turning. When I was with Standard Computer Co. I built an emulator for teh IBM 704/709 family. Our card readers read all 80 columns of a card a column at a time. So the card read firmware threw away 8 columns and did a corner turn so that the 709 software could turn it back! Marv Rubinstein - IBM 709/7090 maven
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (08/02/89)
In article <3469@csd4.milw.wisc.edu> jgd@csd4.milw.wisc.edu writes: >And then compare these to the IBM 7090/7094 -- 36 bit words, one's complement, >, load/store instruction set, etc. etc. (Was the Dec-20 one's complement?) The PDP-10 (the DEC-20 was a PDP-10 running the TOPS-20 operating system) was a two's complement machine. The influence of the 7090 was mostly in the word size and in having efficient instructions to manipulate halfwords for Lisp. Mark Crispin / 6158 Lariat Loop NE / Bainbridge Island, WA 98110-2020 mrc@CAC.Washington.EDU / MRC@WSMR-SIMTEL20.Army.Mil / (206) 842-2385 Atheist & Proud / 450cc Rebel pilot -- a step up from 250cc's!!! tabesaserarenakerebanaranakattarashii...kisha no kisha ga kisha de kisha-shita sumomo mo momo, momo mo momo, momo ni mo iroiro aru uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru
seanf@sco.COM (Sean Fagan) (08/08/89)
In article <164@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes: >In article <27637@lll-winken.LLNL.GOV>, brooks@maddog.llnl.gov (Eugene Brooks) writes: >> In article <33942@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > >Most of the massive I/O bandwidth on mainframes is wasted due to >stupid software. They can copy files at 3 Mbytes/sec, but even >with only one user, editing is faster on a PC. *sigh* *Completely* different thoughts, here. FSE, under NOS on a Cyber, was quite fast, for what it was used for, and for what it did. It had the advantage of being a full-screen editor without needing to respond to each and every keypress. Helped system load a *lot*. >I think that even in I/O bandwidth, traditional (three letter) >mainframes are about to be overtaken. A typical system has 12 x >3 Mbyte/sec independent (and intelligent) channels. This gives >an aggregate throughput of 288 Mbits/sec. The peripheral >controller Intel offers with the 486 claims an aggregate >throughput of 150 Mbits/sec with 8 independent channels. This is >getting close, and it is certainly not hard to beat a 6 Mips CPU >these days. I hear that the NeXT has a high throughput >peripheral chip also. You're forgetting something: multi-ported memory. Let's take my favorite machine, a CDC Cyber. Let's take one that is maxed out on processing power, with 2 CP's and 20 IO processors (each set of 10 PP's shares one ALU). The memory is organized into 8 banks, and would have, I believe, a 50 ns access time (i.e., accessing any random memory location will take at most 50 ns), and a 25 ns cycle time on the CP. However: the memory is quad-ported. Each of the CPs, and each of the PP's ALUs, can access memory simeultaneously (sp?). I have not seen *any* micro that can do that, even for 2 channels (cpu and dma), and this slows things down quite a bit. I think it was Henry Spencer who claimed that a bitblt coprocessor was a waste unless you had free cycles on your processor. Cyber's don't need that, and most other mainframes don't, either. -- Sean Eric Fagan | "Uhm, excuse me..." seanf@sco.UUCP | -- James T. Kirk (William Shatner), ST V: TFF (408) 458-1422 | Any opinions expressed are my own, not my employers'.