Talk:Mainframe computer
|
|
Put your text for the new page here.
Some PDP's were mainframes.
Year 18-bitters 12-bitters 16-bitters 36-bitters 1960 PDP-1 ------------------------------------------------------------ 1961 | \ 1962 PDP-4 <--- LINC -------- \ 1963 | PDP-5 \ \ | 1964 PDP-7 | \ \ PDP-6 1965 | PDP-8 --\ | \ | 1966 | PDP-8/S LINC-8 | | 1967 | | | | PDP-10 KA10 1968 PDP-9 PDP-8/I,L | | | 1969 | | PDP-12 | | 1970 PDP-15 | PDP-14 PDP-11(/20) | 1971 | PDP-8/E / | \ | 1972 PDP-15/76 PDP-8/M PDP-11/05 | PDP-11/45 -- PDP-10 KI10 1973 | / | PDP-11/40 | \ | 1974 | / | | | \ | 1975 PDP-8/A PDP-11/03 PDP-11/04 | | PDP-11/70 PDP-10 KL10 1976 | PDP-11/34 | PDP-11/55 | | 1977 VT78 | PDP-11/60 | | 1978 PDP-11/34C VAX-11/780 PDP-10 KS10
In a nutshell all the 36-bitters were mainframes and the rest weren't.
DEC pulled out of the mainframe business before completing the PDP-10 KC10 and jilted their whole mainframe customer base (including CompuServe and MCI/Tymenet) which marks the beginning of the end for DEC since many of those customers moved to UNIX not VMS where DEC couldn't pull the rug out from under them again.
Removed this:
- The internal redundancy of these computers can be such that, in at least one reported case, technicians could move one from one site to another by disassembling it piece by piece, and reassembling it at the new site, whilst leaving the machines running. The switchover in this example took place entirely transparently.
I know this is in the Jargon File, but on reflection a better and more specific source would be nice. --Robert Merkel 05:11, 17 Feb 2004 (UTC)
mainframes used non-"dumb" terminals, with some editing and form functionality in the terminal itself. in "dumb terminals" each keypress was transmitted to the host, which updated the display accordingly. the "dumb terminal" was coined in contrast to the terminals used before with mainframes that had more smarts.
comparison with supercomputers: basic idea: supercomputers are for compute tasks, mainframes are for reliability and io problems. actually the difference is pretty hard-and-fast one in my opinion. if you look at products marketed by suprecomputer companies and mainframe companies, you see at least the following differences: supercomputers are geared towards doing computations instead of organising data and shuffling around io. mainframes are engineered for reliability, availability and serviceablity. mainframes typically have relatively feeble cpu power compared to their contemporary high performance computing platforms. mainframes are designed to reliable transaction processing, whereas supercomputers are designed to churn through computative workloads with i/o systems fast enough not to bog down the computation business.
there is a saying: a supercomputer is a machine that converts an i/o bound problem to a compute bound problem.
sorry i'm not much good with producing wikipedia-quality article text..
| Contents |
Mainframe language breakdown
Where does the breakdown of programming languages used come from? I know that a lot of mainframe programming was done in Assembler, and much of that code is still out there being maintained. After Assembler, COBOL was popular, and probably is the most popular high-level language out in mainframe-land; but is it 90% of development? I doubt it. Nowadays, there is a lot of development in Java (especially on Websphere [which as far as I can tell is an IBM mainframe version of Apache], but also in CICS). C/C++ has been used for years (I know because I've done some). Then there are all the scripting languages: REXX, EXEC, CLIST, even JCL.
- Got it from a bloke at work the other day who's been working on mainframes for 35 years, other than that i can't really justify the figure given. Even though a lot of the new code is in Java, i believe thats only because its enjoying its 15 minutes of fame. I guess the reason COBOL perseveres so much would be down to the 20 year nearly competition free spate it enjoyed as the main language on the mainframe. To this day a lot of changes and expansionon code on mainframes would be done in COBOL while they have the employees with the skills. The complexity of COBOL is not far off assembly, and i believe a direct descendant of tape code
- If you think we should drop that statement i have no problem, i will try and get some firmer evidence later this week.Pluke 23:53, 12 Jul 2004 (UTC)
- Have adjusted the figures accordingly from talking to some serious mainframe evangalists at work. Trying to find the figure for lines of new COBOL code written for mainframes each year, its supposed to be huge! Pluke 20:41, 14 Jul 2004 (UTC)
Speculation on evolution of the word mainframe
This is pure guesswork, but the use of the word to mean "big honkin' MIS computer" has always puzzled me. Here's my speculation. Comments welcome. I always used it to mean "the bay or bays containing the CPU in any floorstanding computer," and was annoyed one day when someone said "that's not what it means; it means a computer that costs more than a million dollars." Here's what I'm guessing took place.
- First, mainframe means "the bay or bays containing the CPU in any floorstanding computer."
- Third-party vendors of plug-compatible peripherals for IBM 360-series computers don't want to mention IBM by name, so start referring to IBM with the circumlocution "the mainframe vendor." Or, people need a neutral or indirect way to say "IBM and/or Amdahl." So the phrase "mainframe vendor" comes into use.
- Extrapolating from this use, "a mainframe vendor" is soon taken to mean "manufacturer of big honkin' MIS computers." Or "IBM and the seven dwarfs."
- One more cognitive step is needed, though, because IBM of course made computers of all sizes. So the next step is "mainframe" comes to mean "the kind of computer most commonly associated with IBM" = "big honkin' MIS computer."
Thoughts? [[User:Dpbsmith|Dpbsmith (talk)]]
Why did mainframes survive the predicted doom?
They're big and they're very expensive, how come modern day servers with all their claims to be 'autonomic' and with their improved qualities of service, haven't killed the mainframe for good?
Is it just a case of it being too expensive and risky to transfer over to the servers that companies stick with mainframes?
Are there any scenarios that a company would move over to a mainframe solution from a server solution?
Any hard evidence to show the benefits of Mainframes over servers?
How long before they actually die out? --80.40.60.154 18:09, 20 Sep 2004 (UTC)
- While I am not an expert on this, I believe there are a few factors. One is that mainframes tend to survive in places where speed of data access is critical. Mainframes can be designed to optimise data throughput, in a way that Intel boxes cannot be. Secondly reliability. One mainframe replaces several Intel servers; this basicly means fewer possible causes of failure. Thirdly, support. Again if one mainframe replaces many Intel boxes that's less maintenence work to do. Fourthly one stop shopping. If your IBM mainframe breaks, IBM will come and fix it for you. DJ Clayworth 18:19, 20 Sep 2004 (UTC)
One cannot ignore simple inertia and platform lock-in. COBOL is not as portable as most literatures makes out. Vendors have, over the years (given the extremely slow rate of change in standards... 1960, 1974, 1985, 2002) have implemented their own extensions. Companies with literally millions of lines of COBOL simply cannot take it off. Additionally, transactionality/unit of work management is important. Without an adequate and performant two-phase commit ability, slowly migrating systems away from the mainframe is difficult. One can think of the mainframe as a nail in the centre of a system, with attempts to migrate away being a rubber band fastened around the nail. Problems often mean that the path of least resistance (if not ultimately the optimal path) is still on the mainframe, being written in COBOL. 7 Jun 2005.
Performance
Finally, I get to ask an encyclopedia a question. What sort of performance do mainframe computers have? CPU speed (GHz)? Number of processors? Number of MIPS? Quantity of memory? I know that there will be a range of values, but it would be good to see either a range of values or particular values for one mainframe type. Thanks. Mjm1964 16:41, 22 Jun 2005 (UTC)
- Generally speaking, "mainframe" computers contain about the same speeds of processors as you'll see in other computers; everything is built out of the same ULSI semiconductor processes so the speeds and scales of the processors naturally fall out of that. One difference you will see is that certain processors (such as those used in the IBM z/OS computers) are actually internally-duplicated processors running in lockstep; if the two processors disagree on the results of a machine-language instruction, they fault it out to the service processor to figure out which one got it right,disable the one that got it wrong, call the Field Service Engineer, and then continue as if nothing had happened using only the non-faulted half of the chip. Such processors probably clock a little slower than your average bear, but they essentially never fail completely so the trade-off in speed is thought to be well worth it.
- With regard to memory, mainframes tend to contain a lot of it but not many binary orders of magnitude more than is current at any given time. I'd guess that it tops out at several hundreds of GB right now. With regard to processors, it depends on the architecture and just what you're calling a mainframe. I *THINK* z/OS systems are still pretty low in processor count (8? 16?) while PowerPC-, Alpha-, and SPARC-based systems range up in the 128-1024 processor range.
- If we were to include this sort of data in the article, I think we'd have to consider very carefully what represents a "mainframe" versus what represents a "supercomputer" versus what just represents a state-of-the-art big Unix server. If we're going to go down that route, I'd suggest that we use the IBM z/OS series as the reference point (and it's certainly well-enough described often-enough in editions of the IBM Journal of Research and Development that we could draw good, reliable data from there).
- Atlant 18:28, 22 Jun 2005 (UTC)