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.
what the hell does one of John Madden's old employers have to do with mainframes?
A beowulf cluster of mainframes
I wonder if there is a Moore's law equivalent for computer shrinkage rates. Would miniaturization be a good measure for progress?
There still in use at our local hospital.
Thats all that matters, ppl will still use it - cost is also a factor.
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.
sorry if i'm being callous or something, but I really thought that this was a flimsy article, the pictures could have probably been fetched from Google just as easily
I hate to look down on slashdot submissions, but this really is rather weak
Hell, I think that's the most amazing thing I've read all day.
Thanks for sharing!
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.
Because old habits die hard. Mainframes were where it was at in the 70s and 80s. Keep in mind distributed computing wasn't even invented until the late 80s.
sig
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.
In this case, I guess size really does NOT count.
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!
I go to New York University, and in one of our main buildings, there exists a mainframe. It's the most amazing thing to walk inside. Practically a half the floor of the building is devoted to this one piece of hardware. Sort of like those old Dianetics commercials (the before pictures).
Yeah, most older universities have a mainframe or two because it's just too expensive to replace
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.
mainframes are reliable as hell but when there's a big load on the system during, for example, month-end processing at a bank, these things can really start to crawl on every friggin' LPAR in the sysplex. And that can really make it hard to Get Stuff Done. And the "traditional IT" types of companies like banks, insurance companies, etc. are usually pretty resistant to adding more CPUs, memory, DASD, tape drives, etc. until it's taking like 5 minutes for screens to update on the 3rd Saturday afternoon of the month. Damn those penny pinching suits up in Corporate... Unfortunately, I know all of this from personal experience. Ack! I'm just a *nix programmer wannabe stuck in a mainframe programmer job. Arrrghhh... where's my copy of K&R2???
Ever notice how mainframe people smell funny?
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.
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.
I agree with your first statement. I strongly disagree with your second. It doesn't follow from the first, logically speaking, and evidence proves you wrong anyways. I administer 8 Linux boxes in a rack at my hosting center. They are made by HP. They each cost less than $2k. As of yesterday, their uptimes vary from 382 days to 651 days. As an example, one of them hasn't been touched since it was turned on and put into full production service 651 days ago. It runs an Oracle database that serves 400+ staff in two offices. No hiccups. Linux is rock solid even if you only half know what you're doing. (I'm no wizard, I assure you.) As for the hardware itself, well, the disks are hot-swappable and mirrored. The machines have two power supplies each. One of the boxes will serve as a temporary hot failover if any one of the other machines experiences disk or power supply problems. This process has been tested, and works magically well.
Welcome to 2002, my old operator friend. As you said, you're a "former" computer operator. Mainframes are great and maybe a few applications need them. But if you need a computer today that has to work all the time, you better open your eyes to the other options because they work for the vast majority of 24/7 requirements that I've seen.
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 ".
This guide came out last month, but it's worth looking through, even just for the pictures.
Proving once again that all of tech is just a giant picture book to timothy.
Read this comment
http://www.freebsd.org
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.
Well, at several million a pop for these things maybe not....maybe just a small mosix cluster....
...and IN SOVIET RUSSIA, beowulf clusters imagine 1, 2, 3 profit!!!! jokes made out of YOU!!!
STRATUS was doing almost same thing w/ cheaper MPUs and their propriately OS VOS/K. I have used it almost 10 years ago. executing one command simultaneously in two CPUs, comparing command, discard CPU unit if it fails.
While I don't know exactly what they are doing and supporting, I'm guessing they are doing same way w/ newer machines. STRATUS may run on XEON.
YES, Mainframe is great. It supports a lot of function I can ever imagine but it's too pre-mature all excellent features of Main Frame is beyond the reach for all other category of computers.
Really.
Have a cluster run 100,000 transactions at the same time as well as batch jobs and 1000 JCL scripts. Plus 10,000 concurrent users.
Oopps, was that the cluster melting down?
Mainframes have their purposes and these are
- Ultimate in reliabilty
- Ultimate in I/O operations.
Horses for course ye of short sight. Work ith a Mainframe for it's intended purpose and you will realise why PC based just do not cut it.
Now, the software isn't the funnest thing to work with and you don't get pretty graphics (for the most part) but
If IBM would settle on an open HTTP-friendly remote GUI protocol like XWT or SCGUI (my pet protocol), there is no reason the user has to even know it is a mainframe on the other end.
At least it could be a web server and serve HTML forms. I suppose this has not worked out very well because HTML forms stink even with DOM+JS for non-trivial forms. DOM+JS+HTML are optimized for e-brochures and not e-biz-forms.
Somebody just needs to push a decent remote GUI protocol that works over HTTP. IBM is in the best position to do such. They could milk their mainframe cash cow for even longer if they would do that. If vendors could rework mainframe apps to have a GUI front-end, management would have little reason to switch, especially if the mainframe could run languages like Java, Perl, PHP, Python, etc.
Table-ized A.I.
I used to work for a HUGE corporation as a mainframe programmer. I cannot even imagine how they could replace the mainframe. There are literally billions of lines of code running every aspect of the business, every second of every day. The damn thing never fails. Sometimes it slows down a bit, but that's about it.
And the I/O man, the I/O!!!!
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.
No matter how better systems we have, legacy plays its role. Does that mean, Windows also is never going to die? (Shivers...)
Hmmm... Ok.. Chivas on the rocks.
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.
Actually you could. On a single system (RAID level 1 or higher) ensures that if any one hard drive goes bad, no data is lost. In raid 1, a second drive simply mirrors the first for example (it gets more efficient and more complicated as one goes up levels but you get the idea.)
No hardware is totally reliable. According to the article, in an early mainframe, there was a 2nd CPU to check the operations of the first.
In the bank example, the cheap and brute force way would be to simply have two systems keep track of any one account. If either system goes down, nothing bad happens. Just put up a new system and have it mirror the data of the one working system.
Redundency is the key to reliability. It doesn't matter if it's implimented on a beowulf cluster or a mainframe.
-- Political fascism requires a Fuhrer.
With this they have remote GUI (X windows) and many other advantages (more staff available to work with system without expansive training/retraining, more applications, more interoperability, ...).
hany
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.
So how much Mainframe technology has migrated down to the PC level? BTW isn't a crossbar used in Nvidia's latest GPU?
:P
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.
I think that there is also beauty in a system that can keep running happily while bits of it are replaced and upgraded. It's almost... organic.
mkb@libero.it
Because after our network guys changed the comms for one terminal emulation application (inhouse developpment) to TCP/IP, it feels now when doing some entries on the host, that I sit right on the mainframe, speed related I mean. I just luv our hosts.
...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.
Define "PC". SGI's O2 workstations used a crossbar switch architecture, and they first came out in, what, 1995? 96? something like that... The strengths of mainframes aren't so much their CPUs (although their processing units are pretty cool from a reliability standpoint, c.f. opcode result comparison), it's their *INSANE* I/O, both VERY fast and VERY high bandwidth and VERY reliable. So odds are that any radical tech that tricks out of the mainframe arena is going to be I/O related, the uptime/reliability stuff is cool but impractical for all but the situations that mainframes are in (you don't hire fleets of repairmen and such for your secretary's PC, or even for your DBA's unix workstation)...
I liked the description of a mainframe in the article...
"an obsolete device still used by thousands of obsolete companies serving billions of obsolete customers and making huge obsolete profits for their obsolete shareholders. And this year's run twice as fast as last year's."
nuff said...
I think the previous AC clearly said that some jobs may still require mainframes but most do not today. Who the hell are you arguing with?!Work ith a Mainframe for it's intended purpose and you will realise why PC based just do not cut it.
Try doing your banking without mainframes....take a pretty big unix cluster to do a batch with integrity.
Happiness is a slider variable
i think most people feel a little more secure doing their banking on a single iseries machine rather than a bunch of emachines held together with bubblegum and bandaids (okay so that is a little harsh). i guess what i'm saying, is that the mindset of pc makers and mainframe/midrange makers are VERY different. pc makers don't worry too much about redudency or reliability. 'that's microsoft's job', the common thinking goes. i will say it is a lot easier to do things right when you control the entire system (like ibm does). you can set the rules, and if you do it right, you don't step on any toes...
Large print giveth, and the small print taketh away
The Octane was the one using a Crossbar Switch, and it was announced in late 96. The O2 used UMA which is somewhat different.
"....when most people don't even believe that mainframes exist anymore...."
Uh, sure. In the minds of many of my non-technical clients, "mainframe" is a term used to refer to almost any kind of server.
The management of one organization (less than 150 employees) seems to think they have like 12 mainframes. You know, their web server, their mail server, file/print, the really fast dual-Celeron (Abit BP6 mainframe, running linux!) in the corner office....
Yeah now i am scared...
Even a P133 can outperform them.
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
You have absolutely no idea of computing power?
Your P133 is like a fly compared to a mainframe from the same age (1980's that is).
Processing power required in banks is simply awful, becouse of all the transactions and checks made.
Also, the banks must know the current balance of their accounts to make sure that no money is stolen (ie if someone hacked the system and would send huge amounts of money to Cayman Islands and that money would never arrive at the bank (from a wire-transfer etc))..
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.
One morning on new year's day about 2am, celebrating a delivery with a few beers at Denny's (no life) my support chief and I were well into our cups when the pager started spinning on the table. An hour later after talking to the less than totally clued user (try phone diagnosis with nothing but a hex keypad at the other end) at the other end of the phone in Florida, I determined it really was a hardware problem and handed the phone back to Mike. After trying to convince the operator that she didn't have to worry, he'd send an engineer out on the next flight & it was all paid for etc. she said no, you can't fly an engineer into Miami.
"Why not?" the innocent question.
"The airports are closed. In fact, there's two feet of water in the computer room right now."
OK to e-mail me for corroboration, I will back the story up with further detail if needed.
Do not mock my vision of impractical footwear
Forgot to mention - hurricane in the Gulf of Mexico. I'm probably too far away now to get sued, but I won't post the customer's name anyway. They're the firm who put their largest domestic air conditioner into the little warehouse computer room. Right BTU count, etc. Didn't work terribly well though -- kept heating the place up. They'd mounted the air intake in the same room with the outflow, no vents. Cool - not.
Do not mock my vision of impractical footwear
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
They are in the middle of a Deathmatch. Checking you in for the flight took 5 keystrokes for your name+enter.
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
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.
There is also the issue of the aging of the pool of experienced mainframers. Training (for example) an IBM systems programmer isn't something done at the drop of a hat. It takes time and someone with the experience and knowledge to do the job well, and a fair number of these people will be retiring someday soon.
Fortunately, IBM is pretty good at maintaining backwards compatibility so skills learned on older versions of IBM's mainframe operating systems generally transfer pretty well to the newer versions. Fortunately for someone wishing to dip a toe into the IBM mainframe world there are (apparently) public domain versions of older IBM mainframe operating systems available. I use the weasel "apparently" because I'm not aware that IBM has officially declared these versions to be in the public domain, but they are devoid of copyright statements and unlicensed.
Now here's the beauty part: a group of retro-computing enthusiasts has resurrected these old public domain IBM mainframe operating systems and run them under the Hercules mainframe emulator under Linux, Windows and a few other platforms. Public domain versions of MVS, DOS/VS, and VM are available from the late 1970s/early 1980s. A turnkey MVS system from this era is available, which gives you a running MVS system capable of doing some fairly useful work. Many people have contributed their efforts to providing various MVS tools, and the historical archives at CBT tape have proven a real treasure-trove of goodies just waiting to be rediscovered. Most of the CBT tape offerings include source code, providing a tremendous learning opportunity.
I'm confused about the difference between Multics and Unix. Unix as all the features described on this Multics page. Unix is multiuser; so there goes the "Uni" vs. "Multi" difference from the names. Unix scales well to big boxes like the Sun E10K. The only things I can think of are that Multics has more robust job control out of the box and Unix has a more portable foundation.
TROLL???
Who are you kidding??
How old are you???
If my post was really a troll, well
it was about time to have a FreeBSD
advocation troll around......
but it wasnt a troll honestly.
I am the man between the MVS and the Open World.
Just tried to express my feelings,
thats all, but troll??? In no way.
I suggested yesterday, a story about the nvidia engine room video. It was all because of the whole Win2k better then linux TCO story. It was rejected for some reason.
Then they post today a story about something I read fully a month ago as NEWS!
ARRRGGSSS. Totally typical of slashdot.
Just wait till good'ol Bush says they're producing weapons of mass production.
Well, i am the above "troll". I had been working as sysprog for 4 years. The S/390, OS/390 (or MVS or whatever they call it tomorow) was the perfect example of bad design as i had learned in school. Interaction thru TSO, ISPF!!! CICS as an "application server"!!! IMS as a DBMS.... SNA as net protocol!!! and a 100MHz CPU clock. That was the situation. Well my mates always talked in favor of MVS the way you do, but the lack of vital features (Tree filesystem, fast interaction shell, TCP/IP able kernel (and not TCPIP started task), scripts, clean intergration between the various components, was more than apparent .... inside....
In contrast we had JES2!!! JOB ENTRY SUBSYSTEM with a tone of manuals for doing just the basics, the minimal!! As far as performance is concerned, i only had the chance to compare, when I (and ONLY I, cause the rest of my co-workers SUCKED) built OS/390 "OpenEdition" features, and setup a TCP/IP configuration (you know the one with *BSD* conf variables, you got the point i think).
Then i simply compiled and benchmarked some c programms. OS/390 was left behind by my cheap linux workstation.
At the same time the IBM "consultants" advised the bank not to go TCP/IP, its not "stable"!! HA HA HA. Not to mention the idiotic magazines about MVS like Xephon.... and the articles about how bad INTERNET IS...
Well everything about VOLUME, PERFORMANCE, STABILITY etc.... are BIG FAT BLUE LIES.
Lets admit it man... The best of MVS persons have the skills of an average windows programmer.
I dont have a problem with them. I have a problem with IBM for forcing them in the DARK...
Go to Big Blue Smoke for related articles.... Get a clue man, i speak from
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 ----
Soon the mainframes will be as large as your digital clock. Would you call your watch a dinosaur?
Information processing is not all about CPU power. What about the data? Mainframes can process huge volumes of data in a fraction of the time a pc (or cluster) could.
:)
imagine... a Beuwolf cluster of s/390s
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.
I am coming straight from college being only familiar with Linux, Windows, and the occasional Mac. I am grouped in a department of people that work on DB2, CICS, Top Secret, etc. etc. I got hired for my knowledge of Java and J2EE, but now the mainframe is starting to grow on me.
Since I have been unfamiliar with the Mainframe, I decided to get on the web and look for some info. I am happy to see some stuff about the Mainframe explaining it to people who were here after its time. I also went to a few classes, but those proved unproductive mainly because I was the only one who didn't remember card readers and punch cards.
What I can say about the mainframe is that they are impressive. They can run Linux and X apps if you want them too. Unix System Services allows you to run standard unix commands and programs, this is running within OS/390 or z/OS. I run WebSphere, and while its not exctly the same as its distributed couterpart, there are definate avantages to using a Mainframe and they are clearly seen by the work that I have been doing.
Think of it this way, if you were moving, distributed side of things would look like a bunch of minivans holding a little bit of your stuff. A Mainframe is a big ass 25 ft Mack truck that has all your crap with more than half the room to spare. Now those vans may be cheaper, but remember, you gotta get gas, oil changes, fix broken headlights etc. on each minivan. While the truck, you only got have to do it once.
Sorry for the long post, but I am the only 22 yr old I know entrenched in Mainframe work. I guess the dinosours are evolving huh?
So let me get this straight... This thing keeps our customers happy and brings in huge profits... And you wanted to throw it away!
Ooooooh!
You should have gone for the extra points and used EBCIDIC.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
That pic of the zSeries looked pretty sweet. But there was not one single mention of frame rate on UT3 or even whether my neon case mods would work.
"Stop throwing the Constitution in my face, it's just a goddamned piece of paper!" - George W. Bush Nov. 2005
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.
STFU Katz!
ooops, sorry, getting nostalgic!
Some will find it hard to believe but the MOST reliable platform out there is the IBM mainframe environment. Here are the guidelines the largest oil company in the world uses to determine where it's applications reside. 24x7x365 No downtime NO EXCUSES = Mainframe + DB2 ------ 24x7x365 Scheduled outages, and room for an OH SHI** = Unix + Oracle ------ Data that I would like regular access to but the world does NOT stop if it is unavailable = WinTel + SQL Server.
I would call this a major reason why we still use mainframes to manage all of the student records at my university/job. When you've got to process various data contained within several hundred thousand individual records in a couple hundred jobs that must run nightly, it's hard to compare much of anything to the mainframe.
Keep in mind that the workload I just mentioned is only for the Registrar's Office (where I work). All the other offices on campus (Financial Aid, Financial Services, etc) are also using this mainframe nightly.
"The further I get from the things that I care about, the less I care about how much further away I get." -Robert Smith
While surfing around to learn more about my own employer's dinosaur, I stumbled upon this company's site. I think "mainframe zealots" would be an understatement in describing their POV. Anyways, they have an article titled The Internet, System 390, and Serious e-Business which is an interesting read. Plus, they "take on" lots of the big names in their Technology War of Words page.
I don't know enough about mainframes vs. pc servers to comment further...maybe someone else wants to read the articles I linked above and put in their two cents?
The mainframe hasn't gone away. It has evolved. While not technically a mainframe, I have a quad-processor RS6000 that I certainly think qualifies as a "mainframe" because it has memory hardware failover, disk subsystem failover, network interface failover and EVEN cpu failover. That's right, if any of these hardware items fail then the machine stays running and operational, albeit at reduced performance and/or fault tolerance level. It emails me an alert and I call IBM who shows up within an hour with the parts to fix it.
This wonderful machine will do the LPAR thing and allow me to run multiple "virtual machines" including Linux if I want to. It only cost about $160K, fits into one 7' tall rack and replaced a huge room full of old 1980's vintage legacy IBM mainframe hardware that cost several million $$$ to buy and maintain over the years. Our IBM hardware and software budget is now only a fourth of what it used to be and the bean counters are happy, my users are happy and most of all I'm happy.
Marque off, is that you?
PHP is the solution of choice for relaying mysql errors to web users.
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.
Instead of being embarassed about your old fine, you should be pleased inside that such an old "dinosaur" system is still doing such a thorough job!!!
The relationship between Mainframes and PC's is symbiotic. The mainframe will not die because it doesn't need to, it's a great database server and middleware engine; the PC is a great distributor of power to the people, and is much more approachable.
There are people here talking about mainframes like they were still fronted by white coated engineers and programmed through the front panel switches! This is a case of listening too closely to your University lecturers and not looking out the window.
Mainframes are faster than is generally comprehensible to the average PC programmer, but they are also as inflexible as a steel bar. GUI apps can be written for mainframes (seen some - they were ugly, check out some of the OfficeVision modules) but it is not their strength. Additionally, you can't take one home in the back of your bicycle and play with it while watching football. PC's might lack the bandwidth, but anyone with enough money or initiative can get one and play with it to their hearts content. Crashing a PC or trashing its Operating System is acceptable - something is generally learned. It's much harder to get that sort of access to a mainframe. However I would lay odds-on that just like every other system out there, any competent programmer could crash a mainframe and destroy its OS in hours if given unrestricted access. These are machines, they are good at what they do. They are stunningly expensive, and while they play chess well they play Quake appallingly.
I asked the dad dude about this once. He harks from the old school: cobol, snobol, etc etc. His answer was that PCs move small amounts of data really fast, a needle thin stream moving at light speed. Mainframes move data like Niagara Falls.
Another MF story: I worked temporarily at this gov place that had a mainframe. I once overheard the mainframe manager complain that revenues for computer time were down when they upgraded the machine because it could do more per slice of time. He actually decided to add a multiplier to the billed CPU time so that the revenue was the same. IOW, the clients (internal) were not going to get any savings from the newer technology. Sneaky.
.NOT technology such that not only do you have to lease the software from them, you'll also probably have to pay them a per-transaction fee on top of that. Oh, and it will only function when connected to their network so that they can snoop on whatever you're doing with their software, and intellectual property rights to all your data will become theirs for market demographics useage.
How do non-mainframes track computer usage for billing, BTW?
You can be certian that Mircosoft is probably hard at work 'innovating' a solution into
This article was worth it just for the reference to The Devils IT Dictionary. Didn't see it before; great fun!
Ciao, Klaus
Free PC version of ChipWits at http://www.breueronline.de/klaus/chipwits/
actually, i take offense to all people with hangnails, even myself. I believe hangnails are a weakness of the human race (have you ever seen another species with a hangnail?)
mechanicos ergo cogito
A friend of the family works for IBM and was telling me recently about one of these beauties running 75,000 virtual machines. These virtual machines can be set up in virtual networks behind virtual firewalls. Do you need a development version of the current production network? Duplicate the configuration, no new hardware required. This guy was telling me that each developer had his own private copy of the system to screw around in. The power of this just makes me drool.
Beowulf might be good for science, because to get the power of 75,000 CPUs you actually need 75,000 CPUs, but for commercial applications that mainly want to move data a mainframe is the way to go.
Glad I always have my towel with me.
No...
Still has a mainframe. And they use 99% COBOL code in everything they write, even today. Here's the philosophy: It's not technical; it's business.
The amount of money that would have to be spent is astronomical, and you would be spending that money to get to the same point that you are right now, just on different machines with different languages.
It costs the company six digits per hour that the mission-critical systems fail.
Do you not see that it is much easier to support than to modernize?
Wired magazine had an interesting article about this a few years ago. Check it out: http://www.wired.com/wired/archive/7.03/punchcards .html?pg=1&topic=&topic_set=
Well, i am the above "troll", the one .... inside....
with the persistent nightmares from the MVS
years....
I posted it allready,but this post is so "insightful" i thought it should placed under the root article.
(BTW the term "root" is not yet known in the
mainframe world).
Here it goes....
I had been working as sysprog for 4 years.
(in a bank, what else....).
The S/390 arch, OS/390 OS (or MVS or whatever they call it tomorow) were the perfect example of bad design as i had learned in school. Interaction thru TSO, ISPF!!! CICS as an "application server"!!! IMS as a DBMS.... SNA as net protocol!!! and a 100MHz CPU clock. That was the situation. Well my mates always talked in favor of MVS the way you do, but the lack of vital features (Tree filesystem, fast interaction shell, TCP/IP able kernel (and not TCPIP started task), scripts, clean intergration between the various components, was more than apparent
In contrast we had JES2!!! JOB ENTRY SUBSYSTEM with a tone of manuals for doing just the basics, the minimal!! As far as performance is concerned, i only had the chance to compare, when I (and ONLY I, cause the rest of my co-workers SUCKED) built OS/390 "OpenEdition" features, and setup a TCP/IP configuration (you know the one with *BSD* conf variables, you got the point i think).
Then i simply compiled and benchmarked some c programms. OS/390 was left behind by my cheap linux workstation.
At the same time the IBM "consultants" advised the bank not to go TCP/IP, its not "stable"!! HA HA HA. Not to mention the idiotic magazines about MVS like Xephon.... and the articles about how bad INTERNET IS...
Well everything about VOLUME, PERFORMANCE, STABILITY etc.... are BIG FAT BLUE LIES.
Lets admit it man... The best of MVS persons have the skills of an average windows programmer.
I dont have a problem with them. I have a problem with IBM for forcing them in the DARK...
Go to Big Blue Smoke [bigbluesmoke.com] for related articles.... Get a clue dudes, i speak from
Dinosaur is pretty relative if you ask me.
The thing is that there are many self proclaimed pundits out there who essentially say if it isn't Windows or UNIX based then it falls into this "legacy systems" category.
Truth is if a system is in active use, contains mission critical applications, then I don't care how old the thing is -- it is NOT legacy hardware.
If one claims a box is legacy hardware they better have something to back that up with. If the box is sitting in a corner and only gets accessed once a year...then yea I can see it.
Most every box that isn't Windows has this image problem from the popular media standpoint. UNIX is held in really high regard as not being legacy....and let's not forget just how damn old UNIX is!
I have this issue every day with the iSeries platform that I work with, and my collegues in the zSeries land have the same issues.
From my space, the iSeries is highly scalable, robust, fully 64-bit architecture and fast as hell -- running OS/400, Linux and Windows under the covers if you want to with Power CPUs...and supposedly its legacy...whatever. We do stuff that the Windows world can barely even dream of.
You look at this article and it kinda says, "Look bud, there's more to life than what you think!" Yea, the article is focused on IBM systems -- but I don't really see an issue with that. Sure, he could have covered more incarnations of the mainframe...but with far less detail than he even has now.
K.
"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
I was surprised a few months ago when I found a comment I'd made a couple of years back used here:
Whait is a Mainframe
This doesn't seem to stray far from that.
-soup (GNUrd, Speaker to Machines) "Laugh at yourself- Why should everyone else have all the fun?" -Romanchek's 6th Ru
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.
I understand why a mainframe is used instead of a cluster of PCs or other options. It's because of the volume of data it can process. So my question is what kind of data do they normally process?
I can't imagine many businesses with that kind of volume of data to process, and what does process mean exactly? Does it add like bills to other bills? Does it come up with graphs and stuff?
Where does the data go once its processed; a database on the mainframe for one end right? But where does it get outputted too? When is that data called and by what? Data terminals?
Who sends the requests for the data? What kind of application requires millions of data transactions per second? I could guess a bank maybe, but then it would be at the center of a banking headquarters right? Well how does the data from one banking location travel to the banking headquarter? Is it just a dumb terminal that requests it or a full workstation desktop computer? What kind of application would run on it? A custom built client or is there some kind of standard app?
I'm very curious about the underlying technologies involved here after seeing the huge numbers specifying a mainframe's capabilities. Its cool seeing those big numbers, but what exactly fills them? I realized I asked a lot just now, so if you can point me to a website or book or whatever I'll read it. Thanks to whoever answers me.
Open Source, Open Standards, Open Minds
400+ users across 2 offices? WTF. Let me give you an example of a real IT shop. 4000 IT staff. 14 LPARS. There is no way possible to count the concurrent user on our systems. One CICS on one LPAR handles 500 concurrent users. (we have 120 production regions). One region handles 2 million + transaction a day on average. Then on the same LPAR (same mainframe partition if you did not read the article) we have an IMS region running 1200+ concurrent user, handling 4 million transactions a day. All this with subsecond response to the user. Then still on the same LPAR, 8 more CICS regions, one more IMS, MQSeries, batch reports (bank account statements etc.) running. TSO with about 40 users logged in. TCPIP with FTP jobs running. And then all the systems and monitoring related software. If this ran on any other platform the staff to handle this workload would go well into the hundreds. The mainframe staff handling OS/390, CICS, IMS, DASD, RACF, System software and Databases (DB2 and IMSdb) a staggering 35.
Customers? 85 large customer (banks etc.) 140 smaller (manufacturing etc.)
Unscheduled downtime? Only on the webservers, routers and file and network servers.
Not too bad I would say.
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
Well, lets see now. Our IBM mainframe has gone over four years without an unplanned outage. There were two planned outages, both to upgrade the hardware. That took about two hours each. The CE unplugged the old box, plugged in the new box and we IPLd (That's a BOOT to you!) No OS or apps changes required. We run 24x6. The operators get Sunday off but the systems are still up in case any workaholic programmers want to work that day too!
We are a fast growing company and kept outgrowing our processor. The model we have now has all the processors installed already. If we need more power we just pay IBM some more money and they turn another one on. Zero downtime!
BTW, a staff of 400 in two offices is small potatoes. The previous company I was at had 2500+ employees scattered around the world, plus several wholly owned subsidiaries and they were all served by one old dinosaur. They replaced it with *two* huge HP systems and had to farm out everything that didn't require RT/OL access. Of course the IT staff took it in the shorts because of the conversion costs and "failure".
And so it goes.
Not connected to the internet, right? There's been quite a few security patches in the last 651 days.
Gamingmuseum.com: Give your 3D accelerator a rest.
Anyway, some sort of manufacturing company contacted this guy and wanted to buy his emulator. They had a PDP-11 driving some sort of milling machine that was crucial to their operation. This PDP-11 was on its last legs and neither spare parts nor service were available any longer. So, the guy went in and put together a '486 with the needed I/O hardware and his emulator to replace it. The new virtual PDP-11 worked perfectly... if they used dumb terminals to connect to it, it would be completely indisguinguishable from the original, especially by the critical milling machine or whatever was plugged into the other end.
The moral of the story: Old machines are being replaced, but not always in the most obvious way.
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
The article is a bit light on technical details, but research.ibm.com has some very interesting articles on the z900:
IBM eServer z900 I/O subsystem
System control structure of the IBM eServer z900
RAS design for the IBM eServer z900
If anyone out in Slashdotland wants to play with a mainframe, this is pretty darn close.
Another good reference is here
If your children ever found out how lame you are, they'd murder you in your sleep
You *can*, but who would want to? 20 year old development tools. Debugger that sucks beyond belief. Get real. Cobol is the langugage of choice on the MF. End of story.
Mike: With these mainframe running around, it will be a kibitimes worse than a supercomputer made of Gigabyte, destroyer of systems!!! No vigilante guardians can stop them now! Run! Run! RUN FOR YOUR CODES!!!
In college my school had a deal with IBM to teach Mainframe skills to students from developing countries. IBM sells all of there old obsolete systems to developing nations at discount prices. Somebody has to program them, so they send students to Northern Illinios, and they learn the mainframe. Contrary to what people believe, stuff like COBOL and JCL are still taught. It's boring but it pays the bills.
The internet was given to you mainframe people
as a gift.
You never put a single line of code to create
what internet is today, all your concern
is about CICS and COBOL,
you sneakily write to web forums when
your boss is away,
and you HAVE THE NERVE TO TALK ABOUT
COMPUTERS!!!
Thats a BLASPHEMY
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.
You will all suffer by the BSD Daemon
after you pass away...
He will erase all 4.3 socket/tcp/ip code,
and put you re-implement the tcp/ip stack
and the socket abstraction...
Or else.....
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 ?
Agent K (MIB): They're not extinct; they just got homesick and went back home...to usenet (*BUH-DUM-CHEESH*)
But I'm sure you already Gnu that.
Didn't work terribly well though -- kept heating the place up. They'd mounted the air intake in the same room with the outflow, no vents.
:-)
They must have graduated from the University of Perpetual Motion
Or The University of Utah
Table-ized A.I.
They choose maybe far better approach than HTTP-based remote GUI: They made Linux available for their mainframes. With this they have remote GUI (X windows)
This does not solve the firewall problem described above. Also, X is a bandwidth hog by some accounts because its "units" are not at a high enough abstraction level, and thus too much bandwidth is wasted micromanaging keystrokes and screen widgets.
The ideal protocol IMO would say things like "draw a text-box at such and such coordinate, and *only* report back to me (server) under these event types......"
Table-ized A.I.
This is a bit aside from the main topic (but not too much), but it is frustrating when people refer to obsolete things as dinosaurs. Why?
Because dinosaurs never went extinct. They live on as the tremendously successful birds that fly all around us and often wind of as dinner. It's completely wrong to say they were obsolete.
Unisys still sells and supports two distinct lines of mainframes which are architecturally dissimilar (to each other as well as to IBM's mainframe line), which have a long history, and which are in roughly the same power class as the IBM boxes:
The Clearpath IX product line are OS2200-based boxes which are directly descended from the UNIVAC 1108 and Sperry 1100-series mainframe lines, which run an OS still largely based on EXEC 8, which still use 36-bit words and support stuff like TIP and FIELDATA, and which still have a heavy presence in the airline and travel industry.
The Clearpath NX product line are MCP-based boxes that are directly descended from the Burroughs (and Unisys) stack-based A-series mainframe line with its ALGOL-like machine language, which still support things like COMS and CANDE, and which still have a presence in places like the banking industry and like the structural glass-manufacturing company where I currently work.
IBM has a huge share of the mainframe market, but that doesn't mean it's the only player!
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
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.'"
Mainframes do not have a bus - no one central line that arbitrates access to memory between
CPU and IO devices.
Instead each device is directly connected to memory (called channel).
A chanel has it's own processor - so you basically tell a channel to copy nnnnn bytes from location aaaaa to your device.
- and then the channel continues on it's own, in paralel.
As a result IO is much faster.
And as a result they have to put in a checksum into a memory block - because in theory
different channels/processors may corrupt the same data.
- that's why they have two cpu's running in parallel - and that's why they have to compare the result
of execution.
So much for reliability.
Also a mainframe has to be 'rebooted' quite often - once usually once per week (at least in my shop)
***
Anyway, channels are the idea behind Intel's firewire spec -
computer architectures are converging.
Mainframes will never die.
What else are they going to hack into in the movies?
... 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!
This is the same article the same author wrote
1 00 2214227
back in March in Real World Tech:
http://www.realworldtech.com/page.cfm?AID=RWT03
Some nice pictures, but it looks the same.
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.
The power of a mainframe is a second reason. I am a developer that works about 75% of the time on the mainframe and about 25% of the time on Client/server applications. I suupport an application that starts with a 52 Gigabyte file on a mainframe, sorts the data, and reformats it down to an 8.5 Gigabyte file that is then sent to an UNIX server for for further processing. When I sort the file on the mainframe it takes about 1.5 hours, when the smaller file is later sorted on the server it takes 6 hours. That is a big difference especially when you consider that the mainframes is usually doing many other things at the same time.
Another huge difference is support. When something fails on a mainframe someone is always responsible. A few years ago I was having problems with a mainframe program crashing. (just the program crashed, it did not take down the system) The problem was eventually escalated to IBM's technical support who took care of it until it was resolved. Too many times on PC's/Servers the application programmers blame the middleware company, the middleware company blames the OS vendor, the OS vendor blames the application programmers. When a business's system is not working like it should they want it fixed. They do not want to be caught up in the middle of a vicious circle of the blame game. This fact that the vendors actually have accountability for their products also makes the mainframe more reliable in the long run.
Looking for a job?
Want your resume written professionally?
DON'T USE TUNAREZ!!!
Spot on. MVS is the pits. Big Blue considers it the
enterprise operating system, and pushes it big time.
Thing is though, VM is much easier and better. I was
VM support (the system programmers called me when
they had a problem). Want to test new software with
your production data? With no production outage?
VM is the way. Just generate a second level system
on VM and test away in safety.
Want to give hundreds, even THOUSANDS of users their
OWN ENTIRE MACHINE (virtual, of course)? VM is the way.
IBM tried several times to kill VM but protests from
the customers saved it.
For the great unwashed (that's you 700l h4x0r), VM is a
hypervisor, that virtualized the real hardware. You could
then run MVS, AIX, LINUX, even VM on top of VM. As
many copies as you wanted. Even I/O was transparently
shared.
Leave the dark side of MVS, and come to VM.
Heisenberg may have been here.
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.
Wow, thanks for the link!
Or the Silver Center, as it's now called.
In my 16 yr programming career I have used DOS, Windows, MacOS, UNIX, MVS, and VM. My favorite, hands down: VM; nothing compares to the power of the mainframe and the convenience of VM.
Well, besides the fact that this is a carbon-copy post from the ars forum, you don't get the point of mainframes at all.
YHBT. YHL. HAND.
The point being that the trend for *corporations* is towards larger machines, not clusters of little ones. Clusters are just way too expensive and difficult to administer.
Funny how the most old-fashioned responses in this thread seem to come from the PC bigots. They must have learned about mainframes from out-of-date college texts.
Did you remember to factor in adminstration costs? PC clusters are *the* most expensive way of running high-transaction, high-availability services. Google doesn't run payroll. You're trying to compare apples to oranges.
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.
The IBM 3270 type terminal is NOT an essential way to contact Z or S series mainframes. For example, the large Washington Mutual uses OS/2, IBM OS/2 which runs all of its databas'ing of mainframes. Dole uses S390's as does Wellpoint. Countrywide uses IBM AS/400's and Bank of America uses AS/400's.
ABOUT RELIABILITY YOU LINUX IDIOTS!
NO NO NO NO NO NO and oh yes, NO!
TANDEM now COMPAQ NON-STOP are the MOST reliable machines. They have been for TWENTY FIVE years. As you read this on your micro-computer realize that the design goals of a mainframe are completely different from your pathetic micro-computer with your busted up watered down version of multics running on it. Maybe you are using the pathetic sorry sickeningly poor done VMware (a copy of VM, a FORTY YEAR OLD IBM product) or, perhaps some other _personal_ computer.
What can VM do? you can run multiple Operating systems, like 30,000 linux instances, simultaneously. Oh your powerful nightly build of Bochs 2.0 may be able to pull 2 off if you have some fantastic micro-computer.
What about the architecture? Every device has a 4 digit code, every device. It's been this way for about 40 years also. This allows for consistency in hardware over decades!
Support: IBM supports ALL PRODUCTS for AT LEAST 10 years! Beat that! You can't!
Just take a peak, a gander at OS/400. It will be ALIEN to you because you are a FREAKING MORON and don't know what you are talking about. PLEASE DON'T POST ON THINGS you know NOTHING about!
now GO AWAY you tux-lovers.
Windows 1.0 was announced in 1982, never accepted until 1991 really, 9 years buddy! GEM, OpenView, Mac, Dos, CP/M and the numerous all-in-one word processors . . . hello?! Who gave you internet access, and why?
OS/2 WAS THE BEST SELLING 32 BIT OS in 1993 and 1994
THE APPLE MACINTOSH IS THE BEST SELLING COMPUTER OF ALL TIME
Until very recently your Gatesian logic was invalid and MS Windows was not in the picture.
It came in in 1991 left in 1993, came back in 1996 and is starting to leave again!
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)
Your moch-up minix with LispM influences is not designed for a mainframe. It's designed for micro-computers. Don't forget that. Putting linux on a mainframe makes about as much sense as putting it on a watch...logging in to tell the time and recompiling the kernel if you want to set the alarm...it is not designed for it the people that put it on it are zealot freaks that a few hundred years ago would be heading up an inquisition.
THATS IT! Tandem non-stop! In san francisco in 1989, the GTE building collapsed with the earthquake and tandem non-stops did not stop.
In 1988, the entire 4 level basement of Security pacific New York was flooded with the servers
Tandem non-stop did not stop.
During the malibu fires, GE's buildings burned down and the heat was high enough to melt plastic.
Tandem non-stop did not stop.
In the gulf war, how did the US maintain systems running during bombings and such?
With tandems.
Tandem non-stop did not stop.
When MS claimed 5 9's with Win NT, what was it on?
Tandems.
Tandem non-stop do not stop even with windows.
Look, amiga and Dec died, why? they made systems that were too good.
MS IS about to release their ELEVENTH version of a WORD PROCESSOR
Software is projects, not perpetuation. If a project was complete in 1969 versus 2002, who cares, the project is finished, the product is delivered.
The perpetuation of redefining programs perpetually is the only way that companies like microsoft can stay alive.
think hard retard.
Yeah, in perfect environments that is true.
What if an earthquake,fire,flood,heat wave, cold front, bombing, or something else happened. What if dust gets in the way or dirt or something like a sugary soda, power spike?
Big problem
Not an issue with non-micros. They have ways to combat such things. Hooray!
How was the P4 made? Where did the ideas come from? All the fantabulous thing on the P4, who had them first?
Trust me, the Pentium 11 may have what mainframes feature now, if your lucky.
Just because a system doesn't give in to market novelty doesn't make it ancient, it just makes it serious.
One of the projects that i worked on was setting up a blackbox style log file for taking care of any messages that the client was unable to send to the server,taking the concept of failsafe to the hardware level for operations execution is a cool feature albeit it has redundant circuit.as a programmer i might not think its a good idea but for the customer it means everything.morale of the story dont bother for the beauty of the code,how relieable is the system matters at the end of the day.
First post on slashdot
Right. And an apt-get update cron entry takes care of that for us. Thanks to Debian.
This doesn't affect uptime, by the way.
CICS logons are easilly trackable, as are TSO, Netview, Tivoli, SARView, etc., etc. What are your customers logging into that you can't track?
If you can't count the concurrent users, your Enterprise Systems and System Security folks must really, really suck.
If all you have is a hammer, everything looks like a nail.
Yes, 400 staff in two offices can be considered small potatoes, and I can relate because it sounds like the company (Fortune 40) I work for.
However, we have several thousand (60k+) customers that access our systems at any time. Not all at the same time, but every single day.
A real IT department is one that can avoid unplanned outages, regardless of size. No more, no less.
If all you have is a hammer, everything looks like a nail.
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 ___________________________________
OS/390 has only used 4 digit codes for a couple years now, not 40. Aside from actual devices, you are limited by 8 digit reference ids to everything else.
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 ___________________________________
You are quite obviously not proficient in ANY programming languages.
I've performed several training classes on mainframe technology, and have rarely actually connected to a mainframe to conduct them? What did I use to simulate the mainframe, you ask? How about something as basic as C++, or occasionally Java. With the appropriate DB loaded down to the server the class was connected to, people thought they were actually working, to the point where one lead freaked out because someone accidentally deleted a record.
If all you have is a hammer, everything looks like a nail.
me = past mainframe operator, currently all-platforms storage tech support.
If I find out my bank are moving the backend of their ATM network to Linux/Microsoft/HPUX/Sun/Veritas clusters, I'll start keeping my money under my matress.
Ummm... learn about different filing systems, especially the numerical system.
;->
You give each computer a unique ID number. You also give it a synchronized clock. It doesn't even have to be good to the microsecond, although it can be, because all you have to check is that each sequential transaction is delayed by one second. That's actually easy to do: pull a pending transaction off the stack, check if its time is previous to yours, and recycle if it isn't.
But then you give the transaction the following ID, made of concatenated strings:
[Galactic location] + [Company ID] +[Computer ID] + [date] + [time] + [Process Order number]. As input transactions, you use the IDs of the previous transactions that they depend on.
Greenwich time will do; really, you just need a planet-normalized time stamp. Naturally, you don't use a Julian date; rather, you use a numerical date [day 0000001=January 1, year -20000 BC] that is 32 bits long. Worry about the year 10^242 rollover when we get to it. To maintain forward compatibility into the space age, assign as the galactic ID [Sun = 00001]+[Planet = 00003], 64 bits for the star, each, 32 bits for the planet (to allow for space stations and what not).
Now, when writing the number on checks and stuff, be sure to recode that number from base 10 or base 2 into base 36 (26 chars+10 digits) or even base 128. That way, instead of having about 200 chars; you will have 16 chars; something short enough to read and stick on any bill.
*THAT* is the techie's way of doing numerical filing, in my opinion. But you gotta be a techie *secretary* to understand it.
Correct Horse Battery Staple: 72 bits of entropy. Enter "Correct H" into google. When it generates the phrase, that's
First let me address one note..
The reason Unix will never replace mainframes is probably the same reason joysticks will never replace video game consoles.
Unix is an os that runs ON MAINFRAMES and PCs and hay now even on PDAs and maybe someday watches (I mean BSD actually runs on some PDAs)
Now for the reason why mainframes will never be replaced...
If you can get say 1,000 things done a second on a PC thats great.
But there will always be the need for computer power that is 1,000,000 times greater than what you can get to todays desktop.
For that you need something so complex it could never fit on a desk.
ID software writes games for computers that don't exist yet. To achive this they use graphics based mainframes.
3D rendering houses need more powerful computers to make this possable they use rendering farms but in the past they used mainframes.
Your avrage file burrocracy is going to take months or years to convert data from the old mainframe to a desktop to make matters worse there is so much data you could never fit it on a desktop anyway. The processing power isn't the issue so much as the storage limitation. For most mainframes you can add a new hard disk rack.
Thow on the aside.. I remember seeing rack mount PCs where you plug the hard disks externally via SCSI and you have something like 15 slots.
I was thinking "Wow I could run a BBS on that" at the time (Think 1980s) A personal mainframe of sorts. Mostly I was thinking hard disks.. many controllers.. many hard disks.. as much space as I could get.
Maybe approching say 20 gigs...
Today we need hot swapable reliable redundent self testing net servers.
Eventually all that will fit in a PC case but not today.
Tomarow when it dose there will be annother need that will not be develuped enough.
There will always be a NEW need that isn't develuped enough to fit in a small box and in such demand that a company will dedicate a room for the job if nessisary.
I don't actually exist.
Anyone who thinks Linux is a "better" OS than z/OS either doesn't know much about z/OS and it's stregths, or simply has no idea what they're talking about. While it is perfectly acceptable to say you "like" or "prefer" Linux for one reason or another, or to claim that it is more appropriate for a specific task, but to claim it's wholely superior is just stupid. z/OS has many features and capabilities that Linux cannot even pretend to. I don't dislike Linux, far from it, it certainly is a very strong effort, and slaughters M$ at every turn, yet it is not even in the same class as z/OS, which was designed around, and into, the hardware on which it runs. Many of the RAS features of the mainframe are actually part hardware and part software, and guess what? You don't get nearly as good availability with Linux.
I would love to talk to someone who actually knows more about z/OS then how to spell it that thinks Linux is a truely "better" OS.
Ford Prefect
The mainframe philosophy has always been to offload menial I/O tasks to "control units", allowing the CPU to focus on the business logic, and not be constantly interrupted (like every time a user types or moves a mouse). In that sense, the PC has become just another "controller" to the mainframe, as it is very adept at the user interface function.
While it is possible to run an X server on Linux on the mainframe, it is very inefficient, and using an outboard PC or RISC box for that function works much better.
Actually, more and more mainframe administration tools are being provided on PCs, with nice GUIs, and communicate with z/OS via either APPC or TCP/IP. From the users perspective, there has been a migration going on, and an ever smaller percentage of users are working directly with mainframe interfaces (3270 type screens), and more is being done in a client-server environment, with the presentation logic being done either by a destop GUI or an HTML front end.
So, while more and more people will interface with mainframes through GUIs, I seriously doubt that there will be any native GUI interface.
Ford Prefect
One day it was announced that the young monk Kyogen had reached
an enlightened state. Much impressed by this news, several of his peers
went to speak with him.
"We have heard that you are enlightened. Is this true?" his fellow
students inquired.
"It is", Kyogen answered.
"Tell us", said a friend, "how do you feel?"
"As miserable as ever", replied the enlightened Kyogen.
- this post brought to you by the Automated Last Post Generator...