Slashdot Mirror
IBM's Mainframe Dinosaur Turns 40
theodp writes "According to an SFGate.com article, PCs were supposed to kill off the mainframe, but Big Blue's big boxes are still crunching numbers, posting sales of $4.2 billion in 2003. First unveiled on April 7, 1964, the IBM mainframe computer celebrates its 40th birthday this week with a sold-out party at the Computer History Museum." The SFGate article also reveals: "Doug Balog, an IBM vice president, noted that 70 percent of the world's data are still housed in mainframe computers."
Mainframes are usually more robust, have a more developed architectures and in general are designed around a more stringent set of standards. Most mainframes have 24/7 use in mind. A friend of mine at NORAD talked about a PDP-11 with a 6 year uptime. Granted a PDP isn't a mainframe but those machines are architected with longevity in mind
Thalasar
While the overall structure of mainframes (OS, programming languages, etc.) have not changed much over the last 40 years, the actual guts of these computers have actually improved with the times (disk, computing capacity, etc.). Mainframes are much more suited for data warehouse and batch process applications then today's more "sexy" multi-tier architectures. The only downside to mainframe computing would be cost.
I personally don't think mainframes will be gone... ever.
I do find that statistic a bit hard to believe. Especially when you consider the amount of information residing on terraserver, google, etc.
Dan East
Better known as 318230.
Not only are they still around, the world is moving back towards a mainframe-ish approach.. Hell, a webserver is a mainframe-ish approach if you consider a browser a dumb terminal (which I do).
Mainframe + dumb terminals:
Code executes in one place (one machine to maintain from a software viewpoint). Code 'lives' with the data.
Collaboration/groupwork/etc is a no-brainer. "Brenda bring up invoice #43223 and blah blah blah".
Software is protected from users (for the most part).
PCs + Fat/thin Clients:
Code excutes all over. You wind up with versioning/dependency hell. It's a bitch to administrate. Just when you think everythings good, some jackass installs a swimming fish screensaver and you're back to level 0.
Data winds up in multiple, disjointed, locations. Bleh..
Where I work we installed, and still support (and will for a decade past the official HP EOL date) HP 9000 series mainframes. I mainly deal with moving that stuff to the PC world, and I can tell you, lifes a whole lot simpler when you dont have to worry about what version of the OS, etc, etc, etc is running on the client machines..
We're looking hard at Windows Terminal Services - essentially a modern day mainframe implementation, complete with GUI. Or we could go multiple X sessions, but our customers aren't to thrilled with the idea of *nix..
I don't need no instructions to know how to rock!!!!
Maybe you should have looked it up at some point over the last few decades. Here is an extract from Wikipedia:
A datum is a statement accepted at face value. Data is the plural of datum. A large class of practically important statements are measurements or observations of a variable. Such statements may comprise numbers, words, or images.
The word data is the plural of Latin datum, neuter past participle of dare, "to give", hence "something given". The past participle of "to give" has been used for millennia, in the sense of a statement accepted at face value; one of the works of Euclid, circa 300 BC, was the Dedomena (in Latin, Data). In discussions of problems in geometry, mathematics, engineering, and so on, the terms givens and data are used interchangeably. Such usage is the origin of data as a concept in computer science: data are numbers, words, images, etc., accepted as they stand.
Bah!
This claims that as of the end of 2002, 15% of the mainframes IBM was selling would be running Linux.
Has that number dropped off?
And IBM takes yet another spin on that. Their view is "if it breaks, figure out why and change it so that it won't break that way again". Mainframes are very powerful and have great I/O, but their greatest strength is reliability. They have tremendous failover capability, can hotswap components so that they can keep running as they're repaired or upgraded, and are instrumented so if one does fail the cause can be traced and corrected. No, make that the cause will be traced and corrected. Whenever an IBM mainframe fails, anywhere in the world, IBM will hear about it and go to the trouble of a post-mortem.
There's no point in questioning authority if you aren't going to listen to the answers.
According to the terraserver web page, they have 4 nodes with 2TB each... that's not all that much data.
My sig is blank, I typed this by hand.
I used to hate the SPF/PDF interface, but after a decade of being forced to use (by employer) with the utter shit that is MS Windows, it's now just fond memories of something that WORKED. also, REXX did (and still does) rock.
and long after no one cares who billgates was, there will still be Big Blue Iron.
oh yeah, BSD Lives!
Can anyone explain the difference between a mainframe and a supercomputer?
I saw my first computer in 1966 - a IBM 360/44 ( a mod 40 without MVCL instruction). FORTRAN was the language of choice. I knew where my career was headed. Here I am almost 40 years later.
Tired of computing and hoping for a less-stressful retirement.
In Woodland Hills, CA, there is a mainframe that contains all the medical records of every event that has ever taken place in the state. (I used to work IT there, and I've seen it...farkin' impressive piece of machinery.)
They TRIED to convert it to a more conventional system, but they couldn't, due to the fact that no database on earth could handle the sheer number of records.
Impressive, no?
Why PCs Crash, and Mainframes Don't
Best Slashdot Co
What does the "Z" in Z-series stand for?
Zero Down-time
(I especially like the Willow Rosenberg quote).
I do not agreee with this at all!
Alternatives to COBOL have existed since the 60's. PL/I is an excellent alternative. It supports literally everything that is any good in COBOL and gets rid of most of the COBOL crapola. The biggest reasons people have not switched is probably because they don't know any better and go with the idea that if it ain't broke, don't fix it.
As to reltaional databases, well - they are NOT a good alternative for many tasks that run quite well in the mainframes. The fundamental design objective of a relational data base is to expose any and all data to applications. In fact, this is diametrically opposed to what we really need.
Most data ends up archived at some point and from that point on we need read only access. This is not what relational database systems try to accomplish.
Another thing the wanna be replacement computers do not have is the Partition Dataset. We probably can build such a beast into Linux using loopback mounts or a variation thereof. But it is going to take a lot of work for reasons I'll describe next.
A PDS is tied to a set of applications and to a group of users. When you do a loopback mount of a file the system exposes the contents of the file to every user and application in the system. Thus every file in the directory becomes subject to tampering, either inadvertent or deliberate.
Meanwhile the contents of the PDS can be relied upon in much the same was as the contents of a tarball can be relied apon.
What this all boils down to is that the mainframe provides capabilities that are not found in alternative systems.
While I am also a fan of IBM mainframes (we've had numerous mainframes that have had up-time measured in years), in all fairness, they have to be replaced periodically as well. Not because they're no longer capable of doing the job, but because after a while, IBM will take them "off maintenance", or will take an old rev of the OS (or VTAM, or NCP, or CICS) "off maintenance" and it just turns out that the current supported level will not run on your box. IBM has to make money, too. And any company that can afford a mainframe and needs one to run its core business would no more run an unsupported OS than you would go to work without your pants. So maybe the upgrade cycle isn't as short as PC's, but I'd bet you have almost no chance of finding a 15-year-old MVS box running any business anywhere.
"A mainframe could make an ideal web server because of its security and multi-processing capabilities. If this is the case, then why is it not done often?"
Interesting. See Yahoo.com for an example of a unix front-end with a mainframe housing the data.
The newer boxes, by the way, have a native Unix kernel (I believe that last kernel level I saw was 2.4, but I could be mistaken). The company I'm with now doesn't have a clue how to use it, as the environment is too political. But the last company I was with (Fortune 35, last I heard) uses the Unix partition to process many thousands of orders (for pharmaceutical products) a day.
Once they're gone, they'll be back. From personal experience, I've seen that centralized systems always work better than multiple PCs spread all over the place in terms of reliability. So, I don't think you'll see mainframes go away that quickly AND you'll eventually see them come back. There's just too many benefits, the main one being efficient use of power. I expect that what we'll wind up seeing in the future is a "centralized" system where the OS and the applications and the data are all one entity and the entire network is one big computer.
Think about it... Back when people used to actually, literally wire programs into old time computers... all that stuff still happens in that box on by your feet or on your desk. Thin abuout how many levels and how much duplication in task there is in a PC:
You have the microcode at the processor level which is really an analog to programs. But they aren't programs for you, the user. They are programs for the CPU's infrastructure. Then the RAM... It' all over the freakin' place. It's in the CPU, on the motherboard in various places, in your DIMMs, your video card, many periphs, etc... Then you've got the BIOS which is like higher level software compared to the microcode. It's a st of single purpose applications again. But not for you... it's for your hardware. And it interfaces with the OS at some point which (in many cases these days) takes over for the BIOS adding yet another layer of software.
This time, the software that the OS is, is partially for you and partially for your hardware. If you are strictly speaking kernel-wise, then it's pretty much a bridge between user space apps (shell) and the machine. Then you have your final layer of applications which ARE for you. But will it end there? No... you've got the network protocol stacks. This is the top layer of the multilayered cake that leads to the network.
But think about it. It's ALL THE SAME THING. Over and over again at different levels with slightly different purposes. So... at some point in time, all these PCs are going to be embedded devices, or wearables, or implants or entities providing even more layers. But when you peel the onion, you're still going to see THE SAME THINGS. Over and over and over again. And on top of all of that, you are going to see the shifts back and forth from centralized to de-centralized and back again. It's part of some cosmic imperative because if you think even eeper you see it mimicked in politics, communications technology (think old time TV vs. satellite vs. over the air digital vs. WLAN based PVRs), and even the automobile vs. mass transportation.
It's some kind of cosmic rhythm that pulses through the millennia like an ethereal rave...
Un-news
Anyone who's familiar with mainframes and mainframe culture wouldn't doubt the statement is accurate, or very close. PC "culture" is about today, and mainframe culture is about forever. You can't begin to imagine how much data is being stored on and offline for mainframe use. It's mind-boggling.
Well, while I have my gripes with some things in the pSeries, IBM has managed to bring over the virtualization (including dynamic allocation) to the UNIX world pretty well.
My understanding is that they're pretty hot to get the dynamic memory and CPU allocation for virtualization working in Linux next as well.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
> The "problem" with mainframes is not so much that they are old, but that most of the applications didn't use relational databases.
DB2 was the second commercial database out there (following oracle by 1 year around 1983). It's been on mainframes since the very begining. I first starting working on relational databases in 1986 - and it was about 10 years before I finally began to meet a reasonable number of unix or windows developers with database experience. And oh yeah - I've gone through *hundreds* of resumes while hiring back in the 90s, so i'm not hallucinating here.
> If the applications used relational databases, then one could much more easily slowly replace
> COBOL applications with a more pleasant language of implementation in piecemeal.
Hmmm, on an IBM mainframe you've got rexx (like a simple functional version of python), c, java, pl1, etc. All reasonable languages. And they've been there for a while - I wrote C in MVS back around 1992, and Rexx back around 1990. They all talk to DB2. And btw, you can develop good systems with JCL & COBOL it is a little challenging, but not impossible. And I've seen COBOL systems that were far easier to manage and use than their modern counterparts. Of course, much of this has to do with the skill of the developers.
> A mainframe could make an ideal web server because of its security and multi-processing
> capabilities. If this is the case, then why is it not done often?
Reason #1: many mainframe shops are still running the software legacy from the early 90s. They don't have a linux lpar and old-timey protocols aren't ideal for this (often require expensive middleware). But for those organizations that set things up right, there's no real technical limitations.
Reason #2: simple economics. Web serves are the simplest applications out there - and it's awfully easy to deal with scalability & reliability through redundancy. They're probably the worst candidate for rehosting on a mainframe. Database servers, on the other hand, are good candidates.
However, in my experience the best candidates for hosting on a mainframe - are database standby servers. You can run a nearly infinite number of the things for nothing - since almost all are idle, and db2/oracle/sybase/postgresql/mysql/etc - all run just fine on suse/whatever linux on vm.
Accuracy, reliability, and security, is only achieved on mainframes.
I have always wondered why modern managers don't care about failures - resorting to re-boot and cross fingers.
IBM goes after failures hammer and tongs, because DATA CORRUPTION is not acceptable at any price.
Makes me wince thinking of Financial Institiutions on all MS - who cares about inflight I/O's, memory 'leaks', and glitches.
Comment removed based on user account deletion
With regards to the printers: 128 at the moment via local connections (though 127 sharing 12Mbps of bandwidth, if you include networked postscript printers, effectively unlimited) Terminals: serial (atm, just 2, though I have a couple of multi-port pci serial cables), network(effectively unlimited, and already has netbooted machines (sparcs and x86)), console(could go two console), or combination? Given that it doesn't have tapes, no.
Computers today could do it. It's just a matter of having the extra parts to handle it. Of course most mainframes are going to beat the crap out of single channel scsi raid, 2 64-bit pci busses, etc for IO. Though compared to this thing's processors, the word creamed comes to mind for cpu-intensive tasks.
Not that I disagree about the fast cpu (which is likely unable to even pull the memory speeds reqired.) Comparitively, a RS/6000 (workstations & servers) from 1997 has 4 256-bit memory paths of PC50, which puts it at the equivelent of a PC200 DIMM, and if they interlaced the banks themselves (of which I am not sure, and doubt) it would be equivelent of a PC800 DIMM, only dual-channel DDR400 can match that, from a 7 year old machine.
That's funny, we LOVE our Citrix environments, and so do our clients. We only have a couple of boxes per client we really have to worry about, backups are guarenteed to be centralized since the thinterms have no local storage, and best of all new terms are $50 new or $25 used. We generally have only a couple percent fat clients for those wierd but necessary apps that all customers seem to have which we don't feel safe loading on the Citrix farms. Best of all anyone with a web browser can get setup from home if the client is using NFuse, it's the webapp thing that Java applets never even came close to living up to. (ok so you have to be running Windows for the normall plugin to work, but I'm pretty sure there are Citirix clients for most OS's).
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I did some work for a large payroll company, and this was the platform IBM sold them for running mission critical payroll processing for its thousands of customers.
This isn't about legacy application as much as it is about consolidating clustered applications into an easier to manage platform. Believe it or not, you can still do state-of-the-art software development despite the physical housing being a mainframe.
We did all the software development on the PC. The mainframe was simply the deployment destination. This is one advantage of the J2EE architecture. This also ruled out .NET, as Windows didn't offer the stability that Linux offered on the mainframe. However, we did happen to use Windows on the PCs in order to be able to use Rational Rose. Barring Rose, which isn't needed in deployment, our development architecture was completely compatible with Linux.
From a J2EE perspective, this eliminated the need to manage clusters in operation, as well as to develop for them. Clustering, despite its raves in the news, has a lot of production related issues that the mainframe solves. This is part of IBM's marketing pitch.
Open Standards Portal
Well, don't go getting all excited about this. As a PC guy at a Fortune 50 company in the '80s, I asked the person testing the "XT/370" about it.
...)
Yes, that's right. The first version I saw of this unholy process was a PC/XT chassis (with one 10MB hard disk), with a second "expansion chassis" (containing the other 10MB hard disk). The required connection to the mainframe was via an early IBM PC-SNA adapter (don't remember the number) over coax (what else?).
The tester told me it took 20 minutes to download the 370 subset and IPL the system. And then the running box was almost worthless - because it was an instruction "subset", meaning you couldn't run any of the development tools from the real mainframe at your desk (which, of course, was the point of having a "personal mainframe").
More interesting to me is the connection between the STRETCH, the ACS, the System 360 (especially the Model 91), and what we have today, in terms of the Power architecture, and all the rest. After reading the various history sites for all that (example - http://www.cs.clemson.edu/~mark/stretch.html), I can once again believe there is nothing new under the sun - with of course the exception of the next Microsoft OS: LongHorn.
Just imagine if IBM re-wrote the OS every 5 to 7 years, and forced everyone to purchase new versions of all the software. (Oh wait, that seems familiar - wondered where Bill_G had borrowed that idea
JAAC (just-another-anonymous-coward)
Yes - this is certainly true - you can restrict access. However the act of doing said restriction is subject to errors.
A tape with the write enable ring / switch pulled off cannot be modified because the hardware it is mounted on checks for this. In a database with everything on-line a simple keystroke error defeats what you wish to accomplish.
Simply put - if I take my data off line then it does not matter how insecure the system is - you cannot access it.
The gist of what I tried to comment on is the value in a Partition Data Set concept. Here is a for instance. Apache has a lot of components. If Linux ran a PDS then we could simply put all of apache in one PDS, mount it exclusively for the server in question and as for the websites - set each of these also in their own PDS and there really IS no security issue any more. To switch back and forth between a couple versions of apache would be no more difficult than flipping a switch so to speak.
The install process is eliminated with the PDS.
Managment of vast volumes of data becomes really easy.
Linux and Unix users invented the tar ball and they live and die by the wonderful packaging capabilities a tar ball provides.
In a mainframe - the PDS does the tar ball packaging with live applications. We really need this in Linux!
Ways Ive seen an IBM mainframe fail:
- I'll just IPL (reboot) the test partition to test out some changes Ive made. Opps, wrong partition.
- I'm on this test partition with this new OS ready for testing. Hmm this security database copy tool appears to corrupt the database. I'll take diagnostics and send the results off to IBM. Oops Ive just copied onto the live production database and corrupted it, and now everything is failing security checks. I cant switch to the backup database cos I cant work out which security message is the one for the database switch.
- I'm a dumb bulding subcontractor, I'm in the basement drilling into walls, but I dont want to electrocute myself, so I'll go and throw that big switch with the red mnessages over there.
- I'm an even dumber contractor, some idiot has thrown the main 3 phase power switch and walked off, so I'll just throw it back again. BANG!!
- The power has been rather unreliable of late, and the UPS has been continually taking short 5 minute loads whilst the generators kick in. Now the power has gone for the 10th time this weekend, and the UPS has run dry, and the generator cant kick in in time.
It is possible to bring a mainframe down, but it requires stupidity, superuser proviledges, access to the poser supply, or a large axe.
**TODO** Steal someone elses sig.