Slashdot Mirror
Why The Dinosaurs Won't Die
DaveAtFraud writes "Ace's Hardware has a nice introductory article to the animal that will not die: The Mainframe. Ever wonder why these things are still around and what makes them different from a PC or UNIX box? The article is IBM-centric so there's no discussion of say the CDC Cyber series but when most people don't even believe that mainframes exist anymore, what the hay, let's disabuse them of that notion first. Hopefully, the author will follow up with the additional promised articles that go into more technical detail but this is a good place to start. I wonder if they still make card readers, too?" This guide came out last month, but it's worth looking through, even just for the pictures.
I wonder if there is a Moore's law equivalent for computer shrinkage rates. Would miniaturization be a good measure for progress?
Nobody in their right mind is going to mess with them until they absolutely can't get strung along anymore, because they know that crashing, say, a HMO's appointment handling system would be what we call a "career limiting" move.
If it ain't broke, don't fix it. If it ain't broke and it's mission critical to the tune of millions of dollars an hour, avoid it like someone carrying the plague, ebola, leprosy, herpes and a bad hangnail.
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
But there is an interesting possibility arriving from the PC world: clusters. PC hardware is so staggeringly cheap that it's becomming viable to run enterprise applications accross clusters of PC's, viewing each PC as un-reliable and likely to fail.
:P.
Take google for example. Their software flags failed units, brings them offline, and once a week they go pull them out of the racks and replace them. I believe google builds their own, but for less agressive businesses you could just buy enough dell to tolerate as many failures as needed, boxing them up and shipping them back to dell when they go south. Heck, dell will likely send you back an upgraded unit anyhow, so you get a rolling upgrade
Just like the network guys learned the lesson of ensuring end to end reliability accross an unreliable network using TCP/IP, some companies are realizing that reliable computing can be enabled by clusters of pc's. It's a shame the free software/open source crowd hasn't rallied around this more... supporting this at the OS level could prove very powerful.
For a good example of what I mean, compare Traakan's SAN systems to more traditional products, like from EMC.
The theory of relativity doesn't work right in Arkansas.
Remember that IBM commercial showing the whole server room with mainframs and all being replaced by one small IBM linux box? Sounds like that is IBMs dream, not reality.
I talk to people all the time who can't believe that mainframes are still essential to our info infrastructure. I'm going to start sending them to this site. Any other suggestions for good primers, especially ones this short and sweet?
I really liked this line in the section about modern IBM mainframe reliability:
Each CPU die contains two complete execution pipelines that execute each instruction simultaneously. If the results of the two pipelines are not identical, the CPU state is regressed, and the instruction retried. If the retry again fails, the original CPU state is saved, and a spare CPU is activated and loaded with the saved state data. This CPU now resumes the work that was being performed by the failed chip.
Try that with your dual-Xeon server!
...with the rotational energy of Douglas Adam's coffin. That was the most painful and continuous referencing-HHGTG-for-referencing's-sake I've read in a long time.
...the dinosaurs were already extinct.
That the article has a P4 3.06GHz Ad on right hand side.
On the left you have the past.... and on to the right...the present
My Aurora : http://www.youtube.com/watch?v=o91ZsGwJYyg
FB : https://www.facebook.com/TanveersPhotography
Imagine...
:)
You're a big organisation thats been in business for 50+ years. You are in the biz of manufacturing Weezops (or whatever) for the various Gazaah(wtf?!) industries.
10-20 years ago you paid a big buttload of cash for a mainframe.
Today this main frame is chugging away. Occasionaly you need to screw in the vaccum tube, or maybe fill up the cooling liquid and in winter its a little noisy.
However, your little dino is happily chugging away, calculating whatever you want it and doing whatever it was that you got it for.
Its working. Its doing that you paid big cash for. You dont need it to make coffe, play videos, particpate in distributed.net or send spam. You want it to chug along. And its doign it.
Why change? Why pay another buttload of cash because someone is telling you "whoa, what you got here? an oversized heater?! pay another buttload of cash for this new machine that will do everything its doing PLUS play mp3s for you, make coffe, crack encryptions, search for ufos and connect your grandma to the net!"
I dont think so.
If a machine, no matter how old, is working, and you paid a lot of cash for it, no business will get rid of it to get something new just because its new/flashy.
Just like banks and credit card companies who still use systems like GlobeStar, 8 colors text based account management software written over 10 years ago. Why? because it does the job. Pull down menus, icons, angry slad shooting out of cdrom drives, live video straming, its all nice and cute, but if you have somethign that works, does the job the way you want it and how you want it, there's no need to change.
Sorry its so drawn out and long, but thats the way i see it. Plus I am sure you enjoyed the sleep
In words of a famous comedian, "Those are my ideals, if you dont like them, I have others"
the reason they won't yet die is that they are incredibly reliable. If you need a computer that has to work all the time you need a mainframe. Now, the software isn't the funnest thing to work with and you don't get pretty graphics (for the most part) but nothing can compare to its rock solid reliability. Another reason is that the hardware itself runs forever. Most of the older stuff still running was built to last. Unlike alot of today's hardware that is only built to last until it's obsolete.
I agree with this post
Ever wonder why these things are still around
Mainframes aren't dinosaurs, and never were. They are the most advanced, most capable hardware available, and the proving ground for architectural innovations that eventually filter their way down into workstations (like using a crossbar switch instead of a primitive bus). Sun's dynamic systems domains, considered very advanced by the Unix world are still many years behind the mainframe LPARs, and Sysplex makes SunCluster look like a silly toy. User-mode Linux and Beowulf don't even come close.
Really, you should be asking why obsolete technologies such as the bus are still used in PCs, and why PC technology lags so far behind "real" computers.
how many of us have walked into a bank, an insurance company, telco, a large parts wholesaler (any industry) or any other heavy user of 'serious IT' hand seen the clerk using either an original green screen IBM 3270 terminal or a PC running a terminal emulator?
The IT industry has moved on, but these sorts of comapnies are very stuck in a 'if it aint broke, don't fix it' attitude (especially banks).
Whatever the reason (technically valid or not) the managers of these dinosaurs can't see that their 100,000 sessions or whatever it is running at all - even if their hugely custom software ran at all - using a huge cluster of cheap PC servers (oh look, we're back to a mainframe again!)
I think I'll be getting my power, insurance, phone bill, bank statements, car registration bills generated with one these old machines for a very, very long time to come.
MAINFRAME repairs you!
Can you say "banks"?
When an hour of downtime would cost you millions of dollars, no question about it: you get a mainframe.
For the ones who don't read the article, a quick excerpt so you know what kind of availability we are talking about:
"[...] today's [mainframe] systems [are] so reliable that it is extremely rare to hear of any hardware related system outage. There is such an extremely high level of redundancy and error checking in these systems that there are very few scenarios, short of a Vogon Constructor fleet flying through your datacenter, which can cause a system outage. Each CPU die contains two complete execution pipelines that execute each instruction simultaneously. If the results of the two pipelines are not identical, the CPU state is regressed, and the instruction retried. If the retry again fails, the original CPU state is saved, and a spare CPU is activated and loaded with the saved state data. This CPU now resumes the work that was being performed by the failed chip. Memory chips, memory busses, I/O channels, power supplies, etc. all are either redundant in design, or have corresponding spares which can be can be put into use dynamically. Some of these failures may cause some marginal loss in performance, but they will not cause the failure of any unit of work in the system."
I code, therefore I am.
I'm sure the humblest x86 can now run rings around old PDP 11 and IBM 360 systems, but it's still amazing how fast some parts of those old machines were, including core memory swap disks.
A feeling of having made the same mistake before: Deja Foobar
The terminal interface is the most efficent human interface designed to date for data entry. I have never seen a GUI app that can come close to the user efficency of the ole mainframe terminal interfaces. That combined with the scalability, reliablity and ease of maintenence will insure that the mainframe will be around for yet a very long time.
Got Code?
Just post a link to one of those suckers on /. we'll see who won't die in a minute!!
I stole this Sig
Parallel Sysplex. Damn, what a cool name.
***ActiveSX files a patent on "Imagine a Parallel Sysplex of those" posts.
By the way, what happened to Jon Katz?
He probably got tired of posting the only original stories on slashdot, only to be rewarded with "STFU Jon" and other such bitchiness. I thought he had some interesting points, even if his opinions were usually different from mine.
And in response to your impending queries: No, I am not Jon Katz. I'm just posting anonymously because I know my opinion here doesn't match everyone else's exactly and I'd rather not take the karma hit. Oh, yeah, and I'm wandering off topic too.
Four decades of years ago a group of hyperjobless pantemporal employees at IBM got so fed up with the constant calls for tech support from moronic users... that they decided to sit down and solve their problems once and for all.
And to this end they built themselves and the world a stupendous supercomputer encased in a very large steel framed box the size of a small city. It was so amazingly intelligent that as soon as its DSADs had been connected up it started from I think therefore I am and managed to deduce the existence of P2P and the great wiki before anyone managed to turn it off.
On the day of the great turning-on, it said: "What is this great task for which I, the Mainframe, the second greatest computer in the Universe of Time and Space, have been called into existence?"
"The second ? There must be some mistake," said the programmer. "are you not a greater computer than the great Echelon at NSA which can predict acts of terrorism a year ahead in a picosecond?".
"The Echelon" said the Mainframe with unconcealed contempt. "A mere abacus - mention it not."
"What computer is this of which you speak?" he asked.
"The greatest computer in the universe", answered the mainframe after seven and a half years of comtemplation, "is the Beowulf ".
IBM and others have demonstrated the ability of mainframes to act as virtual machines, using hardware monitor techniques a la VMWare, to simultaneously run thousands of copies of Linux, AIX, or other OSes. Because each OS is running ON TOP of virtualized hardware, the security is pretty much airtight, and it's just like having thousands of actual machines without dealing with the space, etc. issues.
This technology seems quite promising for data centers, etc, and will probably ensure the mainframe stays around for a long time to come.
There's 10 types of people in this world, those who understand binary and those who don't.
My state library system still has it's database running off an old mainframe from the late 80's. The card catalog search terminals are these funky old greenscreens.
So a couple months ago I went to apply for a new library card (haven't used the system in like 10 years). When I turned in my application, the Librarian ran my info through the system and informed me that I had an eight dollar overdue book fine outstanding from 1987. Ouch. Place was pretty crowded, too, she could've said it in a quieter tone of voice...
Perhaps a punch card virus... Then again, perhaps it will be when the smartest people in the world succumb to the growing ideal of technology for technology's sake.
--"It's Bradford Company, slash your last name, dot your first name"
working, stable and extremely mission-critical apps for very large and established corporations...That are oftimes bloody expensive to have any downtown in, let alone enough to verify a changover to a new system.
Locally, one of the larger local businesses has an old beastie made of wires and PCB that can not be shut down? Reason, to turn off the apparatus it's connected to would require a lot of work to get it warmed up again, and having that particular apparatus off would probably mean shutting the entire plant for a certain period of time...
a.k.a, not something you want to mess with unless you've tested, and tested, and tested, and scenarioed, and prayed a few times before frantically moving things over to whatever the new configuration is.
And in such times, isn't it murphey's law that you end up with an event like "what do you mean you forgot the power cable at the office?!!!" just before/when going live.
So you need to tag every transaction with a unique sequence number. This is really, really difficult when you don't have a single system with an amazing I/O throughput to assign those numbers.
A Google type solution uses a lot of execution units each with limited I/O capability. Queries may be parallelised without much interaction. In my example, every transaction must be synchronised. It doesn't matter if the application is spread over a cluster, the nodes must still coordinate to assign the sequnce number.
I agree though with your point about adding better cluster management though to open source operating systems. However, this is much more difficult than improvements to a standalone system because how many people can afford to run a cluster of say 4 or more systems for playing around.
The argument for what I call economic inertia is a good one, especially with corporate shareholders these days demanding that management squeeze everything they can out of every dollar and stretch every last penny as far as it will go.
A mainframe that does everything that you need it to do (and more) and works well with your company processes is worth far more to you than the investment of time and resources in an untested, unknown system that may or may not work. Remember that new systems don't go online until after extensive use and testing in parallel with the current one (if it's done correctly). That means duplication of efforts and resources.
Anyone who has worked at a company that builds enterprise-scale applications or mission-critical solutions knows that when the customer has an XYZ mainframe, you'd better have applications that support XYZ or you'll find the contract goes to your competitor who does. It's not an option not to support it.
Unless there is a strong business case for moving to a newer technology, mainframes will be with us for quite a long time.
A hint to the coders out there: the number of people who know and understand these systems is declining. There's a mint to be made if you can deliver services to support them.
In 1998 I had the opportunity to take a tour of six hockey-rink sized rooms of mainframes and tape drives used by one of the main US travel reservation systems. In reality there weren't that many actual mainframes - most of the space was taken up by tape drives. Above every machine was a sign specifying the machine's MIPS rating.
The signs had numbers like 20, 43, sometimes as high as 60. The employees were especially proud of the 60s, explaining that each one cost more than 1 million dollars.
At first I assumed I must not have understood. I asked whether MIPS really stood for millions of instructions per second. They said yes. Then I asked what kind of instructions they meant: things like add, load, etc? Yes.
Finally I pointed out that my (at that time) $4000 dual 200 mhz Pentium Pro was rated at much more than 60 MIPS. I don't think they quite comprehended this.
By now every travel reservation system is ditching mainframes as fast as they possibly can and replacing them with racks of PCs or medium-end Unix workstations. By spending 1/50th as much money they get orders of magnitude more useful computation: those nice low-fare-searches you see on Orbitz and Expedia run on PCs, not mainframes. I've been in all the other travel reservation systems complexes since my 1998 visit and more and more you find little stacks of cheap "low end" machines doing the heavy lifting.
The reliabilty claims for mainframes are very deceptive. Yes, the computers stay up. But the software has bugs just like any software and data lines go down and the mainframes start dropping transactions left and right when they're overloaded. DASD's are multiported but top out at some low number just as any multiported device does, so mainframe-based databases often can't be extended beyond some point because the database drives simply can't be connected to any more machines. In the PC world we'd buy more machines and drives and maybe live with a little data incoherency but in the mainframe world eventually things just die because the hardware was built for everything but cheapness and power.
The general mainframe design is essentially targeted at the application profile of a static-page webserver. Simple programs, quick data access and throughput, no computation. They are utterly unsuitable for any computationally demanding task.
any new article on mainframes would necessarily be ibm-centric because ibm is the only mainframe manufacturer left on the planet. all the others have dropped out.
legacy apps are not the reason mainframes hang around. legacy apps last because of the incredible ease of centralized management on mainframes.
gone are the days of the dumb mainframe terminal, also. modern mainframe of today offer advanced graphics and windowed desktops. more often than not, the modern mainframe terminal is a low end pc with attached host print emulation.
increased miniaturization only makes for better mainframes. modern mainframes are just well put together microprocessor clusters.
mainframes make killer webservers: cheaper, faster, more reliable, smaller footprint, and easier to maintain than huge farms of pc servers.
please.
I used to do client/server programming at a health care provider that employed over 20,000 people. The few apps that used Oracle were completely insigificant - EVERYTHING was on the AS/400. And they had a lot of AS/400's. In fact, they were buying MORE AS/400's. They were even planning on spending millions of dollars on a few very large AS/400's to replace several of the smaller AS/400's.
Why in the world would they still be using something so ancient? Legacy, man. "Back in the day", they started using AS/400's, and since everything was running on them, they just kept getting more and more of them. I'm sure that they're not the only ones that keep pumping millions of dollars per year into "Big Blue"'s coffers just because the idea of switching over is too daunting.
Of course, at the company I presently work for, we've done all of our CGI programming in Perl. We haven't found any reason to switch to anything else, and likely never will - but even if we did, we still probably wouldn't. It's taken YEARS of our entire programming team working like feral weasels to produce the programming we have. Just picking it up and migrating would take at least as long. If you look at the number of programmers, taking 4 years of their time to reprogram everything would cost them nearly a million dollars. The scary part? A million bucks is NOTHING compared to the market share we'd lose if we just took 4 years off from improving our product.
Yeah, legacy has a lot more power than most people realize.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
You mean like X11? Yes, XFree86 is fully supported on Linux for S/390. If you truly want a GUI on your server..
Now why on earth would you constrain it to work over HTTP? The design requirements of a "decent GUI" are very different from the design goals of HTTP. Or are you one of those inexplicable people who believe "tunneling over HTTP" == "web-enabled" == "good"?
HTTP was never intended for low latency. It was never intended for persistence. It was never intended for asynchronous server->client updates. (Or even client->server updates.) All of these are necessary for a decent GUI protocol. Some of them have been shoehorned into HTTP as time marches on, but I don't, in general, see the point.
Note, though, that the GUI front-end doesn't have to run on the mainframe. Indeed there are quite a few good reasons to run the front-end on a front-end server instead - or even deploy direct to the end-user. This basic architectural principle is called the "client-server model", and it works pretty well.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
I recon that Linux will start to replace these Mainframes in the future.... Linux is becoming a standard for server OS's.... IBM's line of iron is already running it
Tony.I remember it used to be a cliche that "No-one ever got fired for buying IBM". Trouble is, I knew one IT manager in London who did get fired for doing just that at a Burroughs site.
...that point being that big iron is not about processing at all, but rather about manipulation of huge quantities of data that would choke even a beowulf of beowulf clusters in a matter of seconds.
But for those of you that still don't get it, here is a guide for the layperson:
It might be a mainframe if...
If you could kill someone by tipping it over on them, it might be a mainframe.
If the only "mouse" it has is the one living inside it, it might be a mainframe.
If you need earth-moving equipment to relocate it, it might be a mainframe.
If you've ever lost an oscilloscope inside of it, it might be a mainframe.
If it's big enough to be used as an apartment, it might be a mainframe.
If it has ever had a card-punch designed for it, it might be a mainframe.
If it weighs more than an RV, it might be a mainframe.
If lights in the neighborhood dim when it's powered up, it might be a mainframe.
If it arrived in its own moving van, it might be a mainframe.
If its disk platters are big enough to cook pizzas on, it might be a mainframe.
If Michael Jordan would need his entire annual salary to buy one, it might be a mainframe.
If keeping all of the manuals together creates a fire hazard, it might be a mainframe.
If it's so large that a dropped pen will slowly orbit it, it might be a mainframe.
If it's ever been mistaken for a refrigerator, (or if the disk drive
has ever been mistaken for a washing machine), it might be a mainframe.
If anyone has ever frozen to death in the room where it's kept, it might be a mainframe.
If it has a power supply that's bigger than your car, it might be a mainframe.
If it has its own postal code, it might be a mainframe.
If the operators considered the addition of COBOL to be an upgrade, it
might be a mainframe.
If it was designed before you were born, it might be a mainframe.
If its main power cable is thicker than your neck, it might be a mainframe.
If the designers have since died from old age, it might be a mainframe.
Maybe the guy is expecting to make a profit from selling the .pdf !!! or didn't you notice the "purchase the pdf" link on the first page ?
I love stacking my barbecues in the shed at the end of summer - you can't beat a bit of grill on grill action.
I keep hearing this, and it keeps making no sense.
If the application deployment guy and the firewall guy can't agree on whether to open the firewall port, the company has bigger problems. Somebody needs to be in charge.
In summary, using HTTP for the sole purpose of defeating firewalls is an arms race between two branches of IT. Now, arms races between competitors is what capitalism is all about ... but arms races within a company are pointless. You're supposed to be on the same team here! Instead you set up a situation where the app developers and the firewall admins both have to use increasingly sophisticated measures to do their jobs.
And don't give me that "but the firewall guy doesn't know how / can't be bothered to open up ports when we ask for them". That's his job. If nobody at the company has the time or skill to operate a firewall, you may as well not even have one.
I have to conclude that the real purpose of this whole fad of overloading HTTP with things that have nothing to do with HTTP is for deploy unauthorised applications - things the company doesn't know about and hasn't approved.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
The etymology of mainframe is incorrect in the article. While nowadays "mainframe" is indeed used to distinguish big lumps of computers from smaller ones, back in the day the "box" or "chassis" of even a microcomputer was originally called the "mainframe".
I have documentary evidence from the dawn of microcomputing to prove it. It was the Main Frame of the computer, to which one attached Peripherals. Microcomputers just had very small Main Frames.
Database design theory comes to mind.
The goal is to pick fields & tables such that:
1) Locking is minimal
2) Dependencies are minimal
3) Storage size is minimal
4) Records are meaningful
The main technique involves decomposing a database to a minimal architecture based upon all possible elements in the database, and then building it back from the basis to the desired state.
It gives you specific knowledge of the conditions by which transactions may require waiting and a way to characterize that waiting, as well as how to reduce the number of transactions you need for a given task.
Of course, that's just the database design theory that one can apply. There's also the distributed information theories that can be applied. The most primitive approach to this is to use time stamp semaphores, but it can be extended beyond that. There is actually an area of database dependency resolution devoted to making locks. I imagine the "distributed lock manager" you spoke of uses it to minimize the amount of information needed to be locked at any given node.
In both of these cases (distributed info theory and database design theory), the formalism sprang from necessity - people invented creative ways to improve how their mainframe worked, and they used the formalism to describe it. I think it might even be right to say that without using the CompSci theory, you probably won't get a terribly reliable system. You'll get a kludge - it'll work, if you're lucky.
Mod me down and I will become more powerful than you can possibly imagine!
I just got laid off from an operator position at a large, old company that has invested a lot of time and money into their IBM AS/400's. Not exactly mainframes, but it's the same idea. They have been there forever, they're doing their job, etc. No problems with the machines at all. The only problem is that the developers are nearly all in their 60's and will probably retire soon. And most of this generation (and probably the last one) don't even want to look at anything in COBOL, RPG, CL, or whatever the system's applications are developed with, much less make it a career. Eventually these things will die because nobody will know what to do with them. In 10 years it will be damn near impossible to find people who will work with anything that isn't GUI-based. Chris
Productivity went right in the toilet. The users, some of whom had only been in the department, and others who had been there from years could not use the new GUI with any degree of efficiency. Long-time coders and CLI users know how important it is to keep the hands on the keyboard. Data Entry people, and others have the same requirements.
Several versions of the new software have gone by, and the GUI has been modified over and over, each time becoming more keyboard friendly. But in the meantime, the department has wasted many dollars in training, re-training, development, and paying overtime on the weekends to catch up on the data entry tasks.
A good terminal application, with well-designed screens and a key-oriented approach was thrown out for the latest, lickable interface. Just because it's old, or ugly, or doesn't drag-n-drop, doesn't make it obsolete.
People are still buying the new mainframes and AS/400s (which should be lobbed in) especially now they run Java and new technologies.
Why ? Because of the support staff you require to run one. Is Unix harder than Windows 2000 are the people cheaper ? With these beasts its a mute question because YOU WON'T EMPLOY A SYSTEMS ADMIN for your server. You will outsource all of that to IBM, and they will make sure it works.
My favourite on this is being in a place with around 20 mainframes and AS/400s who had been asked to consider standardising on Windows going forwards. The IT manager's challenge to the sales guy was "How often does your stuff fail?" to which the sales guys asked "well when was the last time you had an expensive maintaince job on these servers".
The reply was that 4 years previously an IBM engineer had called to arrange a time to visit to replace a disk from the server which might fail soon. 2 years before that one had phoned to arrange a time to replace a processor board which was not performing correctly.
2 incidents on 20 machines in 10 years.
They elected not to move to Windows for infrastructure.
Then along came Java and suddenly you can buy these ultra-reliable boxes to run all of your newest and brightest applications.
Unix might whup windows, but OS/390 is Lennox Lewis standing at the back of the room with Ali smiling while they watch the little boys fight.
An Eye for an Eye will make the whole world blind - Gandhi
... when the applications designs are flawed, turgid chunks of garbage that poorly attempt to mimic a bizarre corporate organizational structure that is changing next week.
Hardware design always has been (and probably always will be) WAY out in front of software design, and yet people are all too willing to spend the odd extra million on hardware while putting as little effort into software as possible.
In most companies they are clutching obsolete applications like life preservers, when in reality they are anchors.
Mainframes aren't going away because they are actually cheaper to run. And regardless of what some posters have said, don't have vacume tubes. What thay do have is dynamic CPUs, HUGE I/O buses, Optical data connections, massive storage, etc....
/wo pretty graphics).
While some companies have poured cash down the drain in order to use the latest buzzword technology, smart companies use mainframes with COBOL/CICS/DB2. Train your people once and only once.
What do webservers provide over this combination aside from pretty graphics? Not much. HTML based apps are the rich mans CICS. Granted, it isn't a glamorous career, but it is a VERY effective technology that is rock solid. Programmers that do PC work can't imagine working on the Mainframe. But it is very efficient.
The tech world has come full circle. Client server was hot for awhile, but very hard to keep the clients up to date in a large organization and requires bandwidth of the GODS to transfer all the data around. Oh, lets go to web services. Okay. Now we are back to the mainframe model. The centralized server model is basically this (Webservers) = (Mainfraim
--Scott 8-}
The April 1998 Byte cover story has a graphic Why PCs Crash, and Mainframes Don't. It's interesting to see how little has changed in almost 5 years.
Best Slashdot Co
Why would you want to run X apps on a mainframe?
Mainframes are a very expensive source of CPU time. They are very good with IO.
I worked a job where the 6 processor multimillion dollar mainframe was about half the speed of our workgroup dell 8way Xeon for CPU power. We had to share that mainframe with 5000 other employees. Running X apps on it would be a huge waste of resources.
An html/http interface could work. It would be very similar to 3270 terminal and would be very efficient on a mainframe (avoid memory allocation and cpu, just copy data from here to there...).
Joe
Joe Batt Solid Design
In the sense of MS or Unix admins who need to know how to re-install the OS, troubleshoot the OS etc.
OS/390 admins need to know how to tune, how to cluster how to maintain. Its more like a DBA job than a Sys Admin.
MS and Unix systems just dream of being ABLE to worry about the things that are part of an OS/390 Admin's job. "I'm splitting the load over at 2pm onto 4 slices to take the increased load for that hour then dropping back down to 1 unless the threshold is met then it ramps up in 2 slice steps, we've put in call to IBM and they are going to turn on two more processor boards for the GL year end report this weekend, I've done the PAF already so how about going down the pub".
Rather than "Its running slow, can we buy a bigger server" or "Try unplugging it from the wall first".
An Eye for an Eye will make the whole world blind - Gandhi
Scary, but true.
I used to be a bit of a whiz at JCL, and still view it kind of nostalgically.
JCL was kind of like a rocket launch. Work on it until you think it's ready, then send it off to JES. If you thought a catastrophe (DISP=(MOD,DELETE)) was on the way you might be able to cancel the job in time, like the self-destruct ordinance.
With a script, there's always that wish to watch operation and hit the attention key, and of course maybe you can tweak the script while a step is running, etc. It just isn't as 'background' as JCL was.
The living have better things to do than to continue hating the dead.
This is good for mainframe OS development, because if you crash your OS you don't take down the whole machine, just a "virtual restart" from continuing. I think thats why they started using the virtual machine in the first place..
Its not new for IBM either. Its been around at least 10 years.
I used a VM system a while back for simple things. Worked as if it was a single machine. Interesting to see its making a comeback.
One feature that gets overlooked is JCL. It's ugly and it is a pain, but it really helps the mainframe do it's job. It forces you to say everything you need up front. How much disk space, how much CPU, how many lines of output are you printing, how much memory you need, and what performance your getting. If you exceed what you asked for, then your program (or JCL) has a problem and your program is abended.
This really helps keep a poorly written application from causing chaos on the system. Coded correctly, JCL is really powerful and allows lots of work on the mainframe to be done with very little human intervention.
They are proven, they are powerful. And they already exist. Cobol falls in this category too, contrary to what they teach kids in school these days.
The time and energy required to port over mission critical ( can you say bank.. ) to something less powerful or stable.
Aside from the obvious, they are also more suited to *large* amounts of concurrent users. Even when the raw power and stability is addressed in the future, the sheer number of sessions on the big iron may never be matched..
Now one can debate if there are other ways of doing it then raw horsepower.. but currently for many applications it IS the best way, today..
---- Booth was a patriot ----
The only problem with that approach - thousands of virtual Linuxes require hardware that costs much more than thousand PCs with Linuxes.
Well, maybe, but probably not as much as you think. And in the end, if you have thousands of little headaches. With the mainframe you have one big headache, which you pay somebody else to have.
Consier the following scenarios:
Scenario 1: User needs upgrade to memory and disk space.
PC solution: Order new disk and memory. Dispatch trained monkey to install them and hope he dosn't screw up.
Mainframe solution: enter a few commands telling the mainframe to grant more resources to the virtual server.
Sceanrio 2: Group needs a new server.
PC solution: Order new server. Unpack and install. Dispatch trained monkey to install and/or configure OS. Figure out the best way to patch it into your network and dispatch trained monkey to do so. Integrate it with your network backup scheme and test it to make sure it's working
Mainframe solution: Select one of several preconfigured disk images (will you need postres or mysql? Apache? SMB?) and tell the mainframe to create a new virtual server using that image.
Scenario 3: Computer user reports hardware failure on his server
PC solution: Dispatch trained hardware monkey to swap parts. Dispatch trained sysadmin monkey to make sure everything is OK.
Mainframe solution: none needed. The hardware doesn't fail. You made provision for power backup, lightning, earthquake and flood protection, backups for your datacenter, and you don't have to keep revisiting the problem.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
A comfort zone is important to large, monolithic organizations. What works, works. Why change the old and reliable for something new and untried?
Some of my best friends make their living writing COBOL for mainframes; attempts by their agencies or companies to move to "new" technologies have been costly in both time and resources. If a green bar report provides all the information an accountant needs, why rewrite the system to use fancy HTML output that adds nothing but pretty colors? If anything, many web based systems reduce the amount of information available to make room for lots of unproductive frippery.
I spent the first 10 years of my professional career in COBOL on mainframes and minis -- CDC Cybers, VAX clusters, Honeywells -- doing some pretty boring stuff. I moved into PC programming 15 years ago, and I prefer it for a number of reasons -- but I'm not blind to the realities of the bleeding edge and the stupidity of modern PC software design.
Mainframe applications tend to accomplish very basic tasks in a simple way; even 10 million line COBOL apps are pretty straight-forward. The focus is on reliability and accuracy, not buzzwords. PC developers have an alomost pathological lust for the bleeding edge -- which gives us pretty but buggy applications.
On the PC, amid an embarrassment of riches, with more languages and tools than we can enumerate, we constantly throw out the old to chase the new. Windows would be as reliable as a mainframe OS if Microsoft spent more time on QA and less on figuring out how to make curved corners on plastic-looking window borders.
All about me
I think it was c. 1990 I last did this on Data General mini/mainframes with their implementation of COBOL85, but I'm pretty sure there was a mechanism for allocating and de-allocating memory. Can't remember the name of the routine, as I was more concerned with getting a range of Interprocess Control Processes (in assembler) to connect the COBOL stuff together. It was a bit of a challenge at the time...
A former employer of mine had several customer billing applications running on big iron. The systems have worked for years but they wanted to be more nimble and offer more flexible billing options, etc. Newer systems would offer more flexibility.
The old systems have been around for ages. The original programers are long gone. Over the years, the business logic has become very complex and there are old artifacts in there from changes that have been made and remade. Reverse engineering all of this and deciding what is needed and what is not is not a trivial task.
In short, four years later the system is still doing the billing. Migrating to another system is going to be very costly and very error prone. It will happen eventually but not until running the old system is no longer an option. That may be a very long time. There are so many of these old systems around that there is still profit to be made in keeping them going.
My university is still using an S/390 for course enrollment. This thing is running a web server with lots of images on each page. It has an external ethernet interface, since the machine doesn't have the capability to handle an ethernet card internally. Due to a software problem that effectively magnified the load several times, the system was completely unusable when course registration for next semester began a few weeks ago. Registration got delayed by 2 weeks and a lot of stuff got messed up. Even with the load spike caused by the software problem, I could have hosted the system with no trouble from this box here in my dorm room.
WARNING: there is a trojan on your
IBM used "distributed computing" as a buzzword on the late 80s, but many other computer manufacturers (DG, Honeywell, Prime, for example) had been doing the same thing for years.
Almost every travel agency is either A) connected diretly to SABRE, or B) connected to a database that is connected to SABRE.
SABRE being the company and computer system that handles an insane number of daily travel-related reservations and other similar date/time/person related events for *thousands* of companies (including Expedia, Orbitz, Travelocity, the airlines, etc). And yep, you guessed it, SABRE is based on mainframes.
"Why The Dinosaurs Won't Die" /. tends to repeat articles and get late news... but there is no excuse for a headline like that ;)
i know
The war with islam is a war on the beast
The war on terror is a war for peace
In most companies they are clutching obsolete applications like life preservers, when in reality they are anchors.
God knows you're right! When I worked at very-large-retailer-to-be-unnamed in the IT department I was floored by how much crappy software they had built on top of their hardware. I can't remember how many times I thought, "Why not just use CVS?" or "Why do we have to use this thing?"
First, if you replace something that's working, even if it's working extremely ineffeciently, it might break. The perception of something breaking is about one trillion times worse to the PHBs and the execs than the perception of something working extremely ineffeciently, especially in a retail management mindset.
Second, especially if you have legions of data-entry people trained to use the extremely ineffecient software, then the cost to replace and retrain is higher in the short-term than to stay with the extremely inefficient system. PHBs and execs, especially in a retail mindset, can't thing about long-term cost savings in IT becuase IT is already a "cost center," not a "profit center."
In short, two reasons for bone-headed software in the enterprise: perception and cost. Mainly perception.
I don't make the rules. I just make fun of them.
The point the poster made, however, remains solid. Subverting the firewall internally calls in to question why you have one in the first place.
Look at it from a different angle. If corporate security won't let you take files you need out of the office on a business trip and you do so anyway, would you expect to remain employed if caught doing so? The big dumb guards didn't get the word from on management and are probably subcontractors, and it is hard to coordinate with them. Does that mean you just sneak around them?
I'm not advocating blindly following rules, just pointing out that companies need to _manage_ security, otherwise there is absolutely no point in having it.
I forget what 8 was for.
Recently we added the ability for the students to pay their bills online via the web, taking a bold step into 1998, albeit four years late. In fact, we mainly only did it because another university in this state (the bigger one) did it, and we didn't want to look like we were behind. The software to do this literally just adds more layers to the mainframe process. That was easier than moving to a new system. While the seasoned web pro got to use ASP.NET and C#, I'm sitting here at the age of 25 writing COBOL from scratch to be able to post transactions he captures. That the process is disconnected and difficult to keep in sync no one seems to mind.
They say that we're getting a new, web-based system, "in about six months". I'm still not sure if this means no more mainframe, but apparently the project has been six months away for about two years now.
My coworkers fall into three categories - people younger than me who are still in school and are getting the heck out of here when they graduate, people my age who are married (like me) but they have kids and are completely stuck here, and people who are much older than me. One of my coworkers is literally a grandmother who codes COBOL and hates computers.
And that's really the big problem. I'm sure COBOL and Natural (a pseudo-scripting language for the ADABAS databases we use) are fine languages but you'd never know it by the way they're used here. I recieved no training once I got here - I was literally thrown in with a vague premise of further training, only to have the promiser go on to a better job. I was able to swim and get promoted within fifteen months.
People here aren't concerned with keeping their skillset up to date, they're more concerned with getting their kids to little league practice. The guy across the room from me is trying like hell to get a better job, but he's 56, divorced, in hellacious debt, he knows one thing (COBOL), and he steadfastly refuses to learn anything else. He's like the guy with a hammer who sees everything as a nail. He regularly gets turned down for jobs he's perfect for in favor of young, know nothing punks (like me).
A few months back (for some reason) they gave us VB.net training. While everyone in the room looked terrified of object oriented programming, I was making shit dance across the screen and rewriting everything in C# for kicks. That we're a 80% conservative university that's terrified of change doesn't help things either. My coworkers are mostly more concerned with keeping the new stuff out so that they don't have to learn anything new before they retire.
Now, I'm not saying that Mainframes are evil or that people's natural desire to stay the same is dragging anything down, but part of the reason Mainframes are still around is due to a complete reluctance to upgrade. Sure, at some point it will become inevitable, but most of my co-workers are ready and willing to put that off until after they retire.
And I'm not saying that everything should always be re-written in "flavor of the month" language to run on "hardware platform of the moment", that's not practical either. I mainly think we're seeing the results of a generation and a mentality that started at the low end of the Moore's Law curve and attacked it like any other job. People here don't see programming as a passion, but that thing they do until they go home (not unlike people who sell radio air time or something trivial like that).
As for me, I'm getting out of here as soon as I can.
Schnapple
I stumbled across Sun's Mainframe rehosting the other day and thought it was interesting. Runs CICS programs on SPARC/Solaris, and seems like it's pretty real.
Sure, may not do everything a mainframe can, but could be an interesting way to transition to open platforms.
So does Anonymous Coward have good karma?
Because with big companies whose apps are mission-critical it's about loss-minimization, not gain-maximization.
-Styopa
This troll need no answering but I cannot resist pointing out the obvious.... 1.Tree filesystem - why the catalog is fast, reliable and recoverable. Just because you have a hard time understanding IDCAMS does not make the file system bad. 2. fast interaction shell - ISPF is plenty fast, faster than my windows gui. 3. TCP/IP able kernel(and not TCPIP started task - TCPIP is a service used by many subsystems, and in the subsystems the TCPIP function is a kernel level(CICS TCPIPdomain) and it works as fine as any other TCPIP installation on other platforms. 4. scripts - REXX, CLIST and now even PERL, 5. clean integration between the various components - Cross memory services, very, very, very fast and easy to use. one more thing, I will not trust my banking on you're cheap linux box. I have my own thank you and still, I bank at the bank with the BigBlue Badass Mainframe.
in the words of my father (a mainframe guy for 30 years).
I asked him if he'd ever seen a mainframe crash.
"What do you mean by 'crash'?"
"I mean go down completely. No activity."
"Nope." but he did know a guy who had once..
THAT is why the dino ain't dead.
Mainframes are mostly harmless.
The most important thing about mainframes isn't their intrinstic stablity - its their ability to run the same app written in 1964, now, and get the same results faster and better, without uptime issues.
Every line of code written costs money, and provides another chance for a bug, if it works don't monkey with it. The longer a block of code can just sit and work, the better. If the same code can do its job for 20 or 30 years that is just wonderful.
Oh..
Ace's Hardware...
Whatever...
t_t_b
I'm on PJ's "enemies" list! Are you?
back to wholesale for aqpplication use. The new life Linux has breathed into them is awesome. The VM code was just to expensive. The bottom line in batch is still MVS as well. CICS, and IMS are huge still as well. The mainframe is not going anywhere, you just don't hear about it because it doesn't blue screen, and only needs reboots to update the IOCDS, and with dynamic LPAR's you can even avoid that issue to a degree.
errr....umm...*whooosh* *whoosh* Is this thing on ?
We've all heard stories about Google and it's 10,000 CPU cluster of Linux boxes in distributed data centers doing crunching and querying. Any idea what their TCO would be switching to a single mainframe, or if this would be a candidate at all for something Mainframe-level?
Hire a Linux system administrator, systems engineer,
Well the water destroyed various photographic equipment in the room with the mainframe and the mainframe fell THROUGH THE FLOOR, carrying cables with it in its mad rush to be one with the ground.
The system was found -- on the first floor -- still running. It did not halt, it did not crash except in the literal sense, it did not lose data. It was still operating at capacity. I believe network connections had ripped free but the power connection was sturdy enough that the machine had actually pulled a great deal of the conduit out of the wall, which perhaps served to break the speed of its fall.
People buy mainframes because they are sturdy single solutions which require a minimum of maintenance and which typically guarantee near-100% uptime. Tandem used to (and perhaps still does) guarantee less than five minutes of downtime a year provided you kept up with the service schedule.
Minicomputers still sell for the same reason; Witness IBM's AS/400. Or, of course, any Unix system. Until recently there were still MANY companies using a single Unix system and a number of X terminals. Many banks (including wells fargo) still do this, using tektronix Xterms at the teller windows. (Perhaps not all of them do this; my old branch in Santa Cruz did.) OT: Wells Fargo is ass. Never use them. For anything. My school refuses to do business with them as a student loan lender because they're such a pain in the ass, and schools love money. That should tell you something.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
... can I reasonably recommend a "from scratch" mainframe solution to a customer? Let's say ACME Inc. is just getting started. They expect huge volumes of data, etc. Is a "mainframe" a good choice for them if their primary considerations are: cost, expandability, and maintainability (which is to say we don't want to use COBOL/RPG/PL1/other old language; we want Java or something else from the "new school").
Any thoughts?
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
But IBM would only have to write it once. An DHTML 3270 kind of thing.
I agree that having to rewrite it for ever contract has been a bit of a bore.
Joe
Joe Batt Solid Design
One of the last remaining uses of punched card technology was aperture cards, which had a hole to which you affixed a piece of microfilm. This was used for engineering document control. But even that is obsolete these days, especially since most engineering documents now are created in machine-readable form.
I think the best analogy is if PC's are cars, and UNIX servers are semi-trucks, then mainframes are 747's. If you're just tooling around town, or even going cross country, then your favorite auto will work. If you want to (have to?) do more useful things without all the idiot-proofing, then UNIX is the way. But if you're doing something industrial, then the mainframe is the way to go. But the user interface is, well, like flying a 747. And it's not the most efficient way to run to the store for a gallon of milk.
Disclaimer: I work for IBM (I wrote this on my company-issued ThinkPad). I use mainframes everyday, but spend most of my time using p690's running AIX--a web front end to processing that will continue to execute on the four clustered mainframes.
You think emacs is evil?! You've never used VM's XEDIT have you?!! That's evil, baby!
Now that is an editor! I wouldn't compare it to emacs though, more like ex or ed.
Happy Fun Ball is for external use only.
Quibble: IBM mainframes have not been water-cooled for several product generations. Last one I worked on was in '91. They're all air-cooled now.
:)
Other than that, you're generally on target.
If all you have is a hammer, everything looks like a nail.
How's this different than a two-phase commit on a modern RDBMS/Application Server setup?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Unfortunately, the Ace's Hardware article is depressingly accurate about the state of the mainframe in 2002.
But once upon a time there was a company that beat IBM technology like a drum- Burroughs.
IBM invented hard drives (DASD). Burroughs invented multi-programming environments, virtual memory, the first OS written to a high-level language (ALGOL) and a host of other innovations.
Here is the best overview with plenty o' links, here is official Unisys propaganda if you want to poke around, and here
is a Multics guy giving props.
To give you an idea of how advanced Burroughs was, we were able to run DMSII database dumps to tape while the database was active and did perform successful recoveries off those dumps- in 1985.
The console was magnificent, the built-in system logging was a dream, we fired off batch backups and recoveries from plain-English commands at the console, CANDE is a near perfect development environment (I still laugh at Vi vs. Emacs- morons), and WFL makes JCL look like the silly resource batcher it is.
Unfortunately Burroughs never had a decent sales force, then they merged with Sperry to form Unisys (to enrich Blumenthal, May His Name Be Forever Cursed).
They still make mainframes of a sort, A-series emulators that run on monster PC-cluster machines. These same machines are the cluster boxen for NT and Unix you may have seen around, and they are still big in banking, and make their money in services.
Just remember that IBM mainframes are not the only ones around, but they are dominant.
________________________________________ History Must Not Fall Into The Wrong Hands ___________________________________
IBM mainframes have many things going for them. For one thing, they absolutely do not die (lost power in environment one time, after power was restored we reset the power switches on the mainframe and DASD arrays- it came up WITH NO RECOVERY, as though the power had never gone out).
This feature makes IBM money in that they can reduce maintenance costs to nothing yet still charge for coverage (we don't see engineers except for firmware upgrades).
They have incredible software reliability and backwards compatibility. This alone save companies millions in redevelopment/porting costs, not to mention the downtimes and unreliability of rolling out a new system.
The VM/LPAR/PRSM/WLM aspects of IBM mainframes are absolutely priceless. We can chunk around workload effortlessly to whatever physical or virtual machine we like (this involves architecture planning of course).
They have the Golden Screwdriver, in that mainframe models are actually delivered with more power then is initially activated. With a quick visit from IBM (and the requisite dough), your machine likely can be instantly upgraded.
We have recovery like nothing else. We backed up and moved a production mainframe environment that served 5 hospitals 40 miles away by tape and had it running from shutdown to startup perfectly within 9 hours. We have done DR where we have shaved it down to 8 hours from initial tape load.
The Z/OS-MVS mainframe does have weaknesses. As noted, the software costs are killer (mainframe software is charged by the MIP, and the pricing schemes are fast making it more expensive to get just the support software then all the IBM part of the contract, much less the app). We are literally using two machines instead of one simply due to insane licensing costs.
IBM is working on this by trying to force software vendors to go to a 'MIPS actually used' model rather then paying based on the whole machine, but it remains to be seen as to whether IBM can reign in this hideous cost.
The article is wrong in one respect, the 64-bit Z/OS has meant the end of Amdahl and Hitachi as vendors as they do not have the cash to reverse-engineer the firmware associated with Z/OS. So IBM's profit margins are going up thanks to no hardware competition, which in turn will make the mainframes a pricier item (and may lose IBM some customers if they are not careful).
Mainframes were never particularly designed to be webservers- they are designed for crunching databases and serving 1000s of terminal users. No reason they cannot be webservers, but the tools are more mature on Unix and MS platforms. That is one big reason why IBM is interested in Linux, the Linux webserver can be in it's little VM and pass queries at memory speed via hipersockets to the mainframe LPAR that can serve up DB2 database queries all day long.
That is what I see the future of mainframes being (beyond the pure Linux play to reduce those horrid software licensing costs)- part configured to be the DB gawd as nature intended, and part to serve it up to a GUI-based world. IBM is counting on the penguin to make it happen, but they would probably be just as happy with BSD. Just as long as there are plenty of webbies to make the server work and it cannot be sabotaged by Microsoft, any free Unix will do.
________________________________________ History Must Not Fall Into The Wrong Hands ___________________________________
Any single system can be completely powered off without any loss of accepted transactions (actually we would get a processing stall during the cluster failover but that is just a matter of seconds, but the information is safe).
The participants do not see the source code, but they receive enough information so they understand how a bid and an offer order can be matched and who gets priority. Fairness is an important issue here.