Slashdot Mirror
The Mainframe Still Lives!
coondoggie passed us a NetworkWorld blog post about the incredible rock-em-sock-em mainframe. Knocked frequently in recent years, the site notes that IBM's workhorse continues to do important work in a number of enterprise environments. "While there are some out there who'd like to see its demise, a true threat to the Big Iron has never really amounted to much. Even today, the proponents of commodity boxes offering less expensive x86/x64 or RISC technologies say the mainframe is doomed. But the facts say otherwise. For example, IBM recently said the mainframe has achieved three consecutive quarters of growth, marked by new customers choosing the platform for the first time and existing customers adding new workloads, such as Linux and Java applications."
no shit dept.
Of course it lives, and in fact it has done things in 20+ years ago the the PC is just now approaching.
The Kruger Dunning explains most post on
It's a 17 or 18 year old app, running on IBM hardware -- recently purchased, new hardware in fact. Only thing is, IBM won't support the OS anymore, at least not without charging us out the wazoo, and soon enough, simply not at all.
I am, therefore you think.
Mainframe? Don't you mean a high capacity, legacy compatible application server?
I will have a sig when the market demands it.
My two AS/400s keep chugging along. They have never screwed up when they have been needed. With every other type of computer I've worked with, there has always been a case that I've gotten screwed by them. But those two old IBM mini-mainframes just do what they're told, so I'm happy.
Besides, I love the sounds of IPL'ing one of those monsters.
comes out with an object-oriented RPG and 9 track tape drive for a micro.
(and no, newbie, "RPG" does _not_ stand for "role playing game.")
"National Security is the chief cause of national insecurity." - Celine's First Law
Why would anyone want to see the demise of the mainframe, or any other particular technology? I don't understand all the emotion about such things: if the mainframe continues to provide value in certain areas, then customers in those areas will continue to buy it.
If this is correct it's astonishing. It seems it *has* to be wrong.
"Further, IBM says the System z has been gaining high-end servers and that System z capacity shipped in 4Q06 was greater than the total capacity of the then current installed IBM mainframe worldwide inventory."
rhb
I remember back in '93, calling for the end of the mainframe era, when some of my friends were taking COBOL classes at university. Look how wrong I am! Here we are, years later, and I'm still hooking into some mainframe system or another.
...nah.
I have come to very much appreciate the high availability (24/7/365) and stability of the mainframe. In fact, when I get approached by vendors these days telling me I can support virtualization on high-end PCs, which cost $1M or more, I ask, "why not just by a Z-Series."
Long Live the Mainframe!
Maybe someday, I'll learn COBOL...
The Kai's Semi-Updated Website Thingy
Hardware quality is the key here. It may not matter, if the application is even 30% faster on x86. But if the motherboard is buggy, or the parallel port is flaky, or cable can fluctuate, or the video card can get loose (early AGPs anyone?) — it is death. Even if the probability of it ever happening is very low, the costs will be devastating. Thus the expectation (probabilty times cost) of the loss is still lower than the cost.
I've heard of machines, where the CPUs or memory can be replaced without shutting down — 15 years ago (Sequoia)... Meanwhile, some controllers and OSes still don't fully support hard-disk replacement, or even network cable unplugging — today...
In Soviet Washington the swamp drains you.
if you're a major business operation, and you have the usual multiple terabytes of data that needs to be stored and processed with near-100% reliability, you need big iron. My company has an AS400, and it does a lot of things that we'd be hard pressed to accomplish using PCs. Predicting the demise of the mainframe is like predicting the demise of our economy. You'd best hope it doesn't ever actually happen.
The higher the technology, the sharper that two-edged sword.
Keep It Simple Stupid
Why change something that does the job? Anticipations based on hype may lead to disasters of Titanic proportions.
No, I'm sorry. I just cant do it.
With the flexibility afforded by virtualization who wouldn't want big iron to pump out the megabytes? You can run dozens or hundreds of webservers or databases on a single mainframe with virtualization.
What is better equipped to handle iSCSI and fibre channel storage data that the massive crossbar-IO throughput capabilities of the mainframe.
Blade servers are to mainframes as a pack of mice are to an elephant.
All hail Big Iron! All Hail IBM! Hail Eris!
I'm just sayin'
I clicked on the link, but did not see any photos of mainframes fighting each other to the death. It wasn't even mentioned in the text! I want my money back.
... and then they built the supercollider.
The move away from mainframes, minis and midrange boxes happened because the commodity PC platform reached a point where it was a viable replacement for processing/storage requirements for which the old systems were sold as complete overkill (or there was no choice at the time). Wherever it was actually needed, there has been exactly ZERO migration and the mainframe is still the king of the hill, by far. So no, some of us are not "surprised" at all.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
It was during my college days that I truly recognized the usefulness of mainframes. I can remember numerous occasions when mainframe terminal rooms were at capacity - full of students chatting on IRC, because the PC rooms were full of people playing Doom.
:)
The only people doing real work were on X Terminals in the Unix labs.
Dan East
Better known as 318230.
Seriously, at what point does a large, highly redundant server become a mainframe? (Yes, I've checked the Wikipedia article and somewhat out-of-date FOLDOC definition.
Or is the definition merely, "any large computer descended from one of the old-guard mainframes?"
The US free market: two halves of a government-granted duopoly are free to set the market price.
Many years ago, I had the opportunity to work on a VAX VMS system. It was an 11/750, shaped like an oversized washing machine, and took up an entire room with all its cabling, Hard Disk stack, RAM box, and a huge multiplexer.
Although it was a thunderously loud, kilowatt-sucking machine with the processing power of an 80286, it had a number of features that are simply not available until you start ponying up some serious cash:
1) Dynamic memory remapping - when memory failed, it would "fix" the bad parts with checksum or by reloading the data in the memory from disk, and remap the addresses to another chip that wasn't failed. It would VM out as needed if/when it simply ran out.
2) File versioning - you could "bring back" previous copies of any file in the system simply by specifying its revision NN times back. EG: "edit myfile.txt" could be replaced with "edit myfile.txt:1" to see the previous edition. This was simply awesome and I've not seen this elsewhere.
3) Automated clustering - simply by connecting several of these machines together with a fairly simple serial adapter, they would immediately "recognize" each other and start sharing loads as needed. I don't know how many of these could be clustered together, what the limits were, but the fact that it was so simple to set up and it "just worked" was simply amazing.
ECC RAM doesn't hold a candle to #1. I'm unaware of a production-ready filesystem that can match #2 above, and #3 is simply in another league.
Why hasn't this technology persisted to this day? DEC/Compaq/HP screwed the pooch on this one.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Mainframes ARE dead - for ninety nine percent of the world's corporations. Who cares if a handful of morons have specific requirements for large processors with large I/O bandwidths?
Everybody likes to claim Windows outsells Linux by looking at the revenue figures rather than the units figures.
How about how much money mainframes bring in vs the rest of the hardware industry?
A recent study said the primary reason for moving from non-mainframe architectures to mainframes was:
"improved workload management, performance, availability, and security coupled with reduced costs for electrical power, cooling, floor space, and support staffs."
Which of course only applies to the data center, not to anything else in the IT world.
Here's an example of what more advanced people are doing:
Linux grid takes out firm's aging mainframe
By Jack Loftus, News Writer
04 Jan 2007 | SearchOpenSource.com
R.L. Polk & Co., one of the oldest providers of automotive information in the U.S., had a mainframe problem.
In December, IBM touted a 100% increase in the number of ISV applications available for its mainframe offering, System z. More than 390 IBM business partners now offer nearly 1,000 applications for System z customers running Linux, IBM said.
Analyst firm Ptak Noel & Associates also identified the trend in a report released this month, but conceded it was unable to get IBM to disclose if growth was due to internal development on mainframe, or actual production use. Overall, mainframes grew from 2% to 7% on the year, a Ptak report said.
In addition, IBM business partners reported increased customer interest in new IBM technology including the z9 Integrated Information Processor (zIIP) and z Application Assistant Processor (zAAP) specialty engines. More than 60% of IBM mainframe revenue is now driven by new workloads, with approximately 20% of revenue and 30% of MIPS (million instructions per second) coming from Linux customers.
"The story of IBM's mainframe experience is still being written and it looks to be a story of impressive rebirth, renewal and return," the Ptak report said.
Apparently RLP Technologies didn't get the memo.
The mainframe -- an IBM 2066-002, part of the zSeries line -- was unable to keep up with the demands of crunching data on 500 million unique vehicles every year. Some of the data processing jobs on the mainframe would often take several days to complete. Parts of the infrastructure at Polk were close to 20 years old when executives first started looking elsewhere for solutions in 2004.
With about 4.5 petabytes of stored information on hand, the mainframe took on the persona of a lumbering behemoth. This was especially the case when the IT staff had to accommodate new business requirements such as a car dealership adding a new type of vehicle to its inventory. Each update required a major rework of the program, said Mick Isiminger, director of IT operations at RLP Technologies, a wholly-owned research and development subsidiary of Polk.
And the amount of information on hand was growing. As one of the largest providers of automotive consumer information, Polk tasked RLP Technologies (RLPT) with finding, configuring and deploying a higher performance and more flexible alternative.
Grid computing versus mainframe
Leading the effort, Isiminger said the decision was made early on to switch out the mainframe and go with a grid computing environment. Why a grid? Because it offered a "loosely coupled environment" that could adapt to change more easily than a mainframe, he said.
Grid computing performs higher throughput computing by distributing processes across a group of servers. Grids use the resources of this network to solve large-scale computations.
They can also perform computations on large data sets by breaking them into many smaller ones. Grids are a popular form of computing in academic and scientific environments, and organizations like the Open Grid Forum have f
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
My first experience was with the CDC 3200 series back in 1970. It programmed in Compass (assembler level). Cobol and Fortran as compiled languages. It was an Octal machine with the primary input being the card reader.
Each gate was on a separate printed circuit board and there were probably in excess of 5,000 PCB's in the mainframe and the various controllers. Quite a monster to troubleshoot unless the circuit was fully understood. We had a Tektronix's 545 scope with delayed sweep to trace out the circuits.
The main timing chain for the core memory was initiated by sending a "0" down a ringing coil that has various taps on it for the whole read/write cycle.
We kid about having to key in the boot code manually, but the 3200 required about a 20 step boot program. I still remember parts of the code even now.
And in the end, the love you take is equal to the love you make
While a chapter president of the DPMA, at least once a month there was an argument "are we a mainframe group or PC group?" My response is it does not matter, the same principal applies. The only difference is if a mainframe goes down, people are fired.
What is a mainframe now? Multiple hard drives running live backups? PCs do that. ECC memory, PCs do that too. 24/7 operation? Non-windows based systems do that.
So how is a mainframe different from a PC?
Fight Spammers!
Linux mainframe? No. Linux is a guest OS and there could be other OSs running concurrently as well like BSD. That wouldn't make the mainframe a BSD mainframe.
This is probably a dumb question to some, but I guess I'm too young. What exactly sets a mainframe apart from a cluster of commodity boxes? The wikipedia articles wasn't all too much help.
"You will do foolish things, but do them with enthusiasm." - S. G. Colette
Which is not to say that using mainframes never makes sense. If you have a lot of tried-and-true legacy software, it might well be cost effective to keep legacy hardware around to run it. The alternative is to write replacement software that runs on modern systems, meaning you have to go through the whole development, QA, and deployment thing all over again, at huge cost. Very often it makes more sense just to keep using mainframes. But that's a matter of economics, not technology.
I would also point out that modern mainframes are not really "mainframes" in the original sense. The original mainframes used technology that became obsolete on the day microprocessor-based systems became more cost effective. What we now call "mainframes" are just specialized microcomputers that are optimized to run legacy mainframe code.
I've seen Java on the server-side.
Yes, Java definitely needs mainframe-level memory for sure.
In the free world the media isn't government run; the government is media run.
So why not upgrade the OS to a supported version? If your hardware is recently purchased/new, it probably cannot even run too many releases of unsupported operating systems anyway. And all the latest IBM operating system versions run on all the mainframe models stretching back to the end of 2000 (three generations). IBM always has a lot of overlap.
If you have z/OS V1.x, the upgrade to 1.8 or (soon) 1.9 is free. If you have OS/390 still -- hard to imagine on recently purchased/new hardware since it doesn't run on the z9 anyway -- the upgrade to z/OS is probably better than free (i.e. you typically save money), and you usually save money on the other software that runs on z/OS. (z/OS introduced subcapacity licensing.) And you have a full year when you can run both on the same system for no additional charge to get the migration done.
An OS upgrade is extremely unlikely to break any applications. There's 40+ year old code that's still running, right along with 64-bit Java code written an hour ago. Your 17 to 18 year old code should be perfectly happy on the new OS. And here's a radical notion: you can actually change your code if you wish. You know, add features and functions. You're allowed to do that. :-) You run code as long as it has value on the mainframe, for as long as you wish, without the vendor saying, "Sorry, that code must die this year." Just keep your OS and middleware on at least relatively recent releases, that's all -- it's backward compatible. Change your code and add code as you want, when you want.
What is it that makes a computer a "mainframe"? For years, the "Big Iron" programmers insisted that they worked with the only real computers, and the term "mainframe" was always associated with big machines that could only be used by the most experienced programmers. That's just silly; either your computer is Turing Complete or it isn't (making allowances for finate memory limitations, of course). The important distinctions are:
Big Iron has always had points 1 and 2, but clusters of cheap PCs can often match their level. In practice, current Big Iron hardware isn't fundamentally different from current PCs--it just tends to have better quality control and "more" than whatever's in the PC (more RAM, more hard drive, more processors, etc.). In fact, an AS400 is about the same size as a large server PC, not the room-filling Big Iron machines of yore.
Number 4 simply has to do with what sort of connectors and drivers you have available.
I've had personal experience with RPG, which is why I say with confidence that mainframes are utter failures at number 3. The languages are so primitive that they've barely discovered indentation blocks (and some older programmers shun this "freeform" mode). Sure, they run Java now, but I didn't need Big Iron to run Java. I'll take a VB job before I touch RPG again.
If the programming languages are what make it "Big Iron", then I hope it dies a horrible death.
Overall, we don't need the special terms "mainframe" and "Big Iron" anymore, because all the machines that fit those descriptions are better called "servers" or "supercomputers".
I must say, however, that I am impressed that old Big Iron still works, and in fact still runs a lot of financial transactions. It's no exaggeration to say that removing all the old Big Iron tonight would kill the world economy by tomorrow. It's best to keep those machines and programs in working order, since they obviously work, are quite robust, and solve many problems, whereas a new program may fail.
Not a typewriter
We are one of the new mainframe customers out there. We are actually in transition. Running hundreds of Linux servers is less efficient for our workload and application type than a few large-scale 'big-iron' systems. Not that a cluster of Linux servers couldn't beat the big box, our engineers just can't hack it. It is HARD writing applications that scale well across hundreds of totally unique systems. More often than not our software boys have created islands or pockets of computing regions in the cluster - so it no longer is a cluster. It's just a bunch of stand-alone servers. In this scenario (bad programmers) we can mask a lot of the poor design by consolidating the workload up instead of scaling out. I would prefer they'd fix the code. However, you can't tell a software engineer he's wrong - it gets ugly fast. I admit that the process is 'broken' when compared to some ideal business standard. The truth is, it's like this at a lot of companies.
:)
As a system administrator, I wish I had a few big-iron boxes to babysit rather than hundreds of smaller ones. There are dozens of reasons why the mainframe is easier to manage and deal with. There has been years and years of engineering that has gone in to these things. They are on a different level.
The downside is that we will probably have to have a 'work-force reduction' due to the decreased demands of the hardware support team. It is an ugly but necessary part of a capitalist work force. I'm keeping my resume up to date - just incase.
Wow...maybe I should put that line back in my resume about being the lead computer operator and later batch scheduler (it was my first job back in the early 90's).
Reading the article I can believe IBM is moving the mainframe forward.
It's hard to believe that ANYTHING Unisys does with it's mainframe is anything decent. (The system I was in charge of was a Unisys 2200/622)
There are some pretty obvious reasons why there are still mainframes around: there's lots of "legacy" applications out there (in a US context, consider the Social Security Administration, the IRS, or the FAA). And there are systems with BIG databases (something like SABRE, or the IRS and SSA again). Mainframe technology has been running those for a while. To replace those with an unproven (in a similar context) new technology is not likely to be a career-enhancing move for the IT Director.
More to the point, though, is that in the rush to embrace the newest and coolest, some of the genuine virtues of the mainframe environment were overlooked. Back in the early 1980's, I was the head of IT, and a partner, in an investment management firm, the subsidiary of a larger financial services corporation. Our investment analysis process was pretty quantitative: we used statistical valuation models and optimization methods to build our portfolios. We ran all our internal applications on our IBM 4341 under VM/SP, and were linked into our parent's big iron running VM and MVS. We also were linked to fund custodians and to DTC [Depository Trust Co.] for trade confirmations, and got data transmissions from various exchanges to get prices for fund valuations.
Every person in the firm had an IBM 327x terminal, or the equivalent, on her/his desk. (The clerical staff had IBM DisplayWriters with 327x emulation.) I just pulled out a "Getting Started" guide from 1985: it has a terse synopsis of how to send and receive E-mail, how to use the scheduling system for things like conference rooms and overhead projectors, how to access our internal client and research data bases (including a small but growing index of technical documentation), and how to use our portfolio management application. Using these facilities was routine for the most non-technical people in the firm.
(Part of that was by design. For example, we made it nearly impossible for a portfolio manager to do a trade without using the portfolio management application. There was a bypass, for emergencies, but it was designed to be highly visible.)
Now, I am not claiming this was Nirvana. It was expensive, and I spent a lot of time negotiating with IBM, and other near-monopoly suppliers, to get better terms. And having what we had was entirely dependent on the fact that we were 100 percent an IBM shop. I'm not arguing for going back to those days at all; I do think, though, that sometimes people may have, as one of my colleagues memorably put it, "thrown the baby out with the dishwater". I still, for example, haven't seen a "virtualization" solution that is as elegant as VM on IBM hardware.
It's true the AS/400 is an expensive platform. It's also true you save money every year because you don't need sysadmin's or DBA's (at all at the low to medium end and much less at the upper end). Additionally, in my experience with similar workloads between AS/400 and PC servers, you need lots of PC servers to match the throughput in OLTP applications.
I think when you balance these things, the AS/400 is much less expensive than it may seem when you are buying disk or memory at extremely high prices.
I knew this news was coming.
After the advent of client/server and GUI interfaces the mainframe was declared dead. Yet the web happened, and all of a sudded all the inefficiencies of the GUI interface was replaced with, effectively, a 3270 terminal because it's a more efficient network model. Enter data, submit, wait for a response, just like a mainframe, but somehow... new?
In the past few years, virtualization has become a huge topic, and it's most interesting following the developments of Xen and Vmware and Solaris Containers and all the hardware vendors just now designing and building support for virtualization... and then I realize again... haven't we been here before? Virtualization is old technology, tried and true on the mainframe, and it's going to be some more years before it becomes a commodity. Oh it'll be here, someday, but again, don't hold your breath waiting the mainframe to go away as yet another generation realizes the advantages of what as invented long ago.
...environment, the AS/400 and now iSeries are the shits. Reliable, fast, flexible.
You can run Websphere with or without Java, be your LAN's SMB server, and take heart in knowing that the hardware is the least of your concerns. You still need backups, but your IBM rep is a LOT less likely to be telling you the data is 'lost' than with your Sun, Compaq, HP, or even IBM x86 server.
FWIW, the HP9000s were the shits too. If only HP coulda spun up the Alpha to reasonable performance levels. Damn, that stuff just hummed.
Don't go dissing the AS/400 line. It gets it done. You wish your Linux box was as solid. Oh, crap, I be they can run Linux on the iSeries by now....:-)
deleting the extra space after periods so i can stay relevant, yeah.
What a fluff piece. The real news is that IBM is actively in the process of trying to kill the only competition that it has left in mainframes. And that they are using a bogus software patent lawsuit to do so. Against a product which is Linux based, no less.
The company in question is Platform Solutions, Inc., who realized that they can completely emulate the Mainframe CPU opcodes by changing the microcode in Intel CPUs. And use Linux to handle all of the IO. The result is that you end up with a much faster Mainframe than IBM can build. And you can charge a lot less for it.
IBM got pissed off with the only competition that they have left (since all of the other mainframe builders went out of business years ago; and in fact PSI has a ton of ex-Amdahl guys who are about the only ones left who understand mainframes outside of IBM, but I digress). So, IBM filed a bogus lawsuit against this start-up. This is Deja-vu if you remember how Amdahl got started.
PSI has countered with an Antitrust lawsuit, and some other ones, last I heard. But the bottom line is that IBM is behaving worse than Microsoft to try to kill off the only competition that it has left.
You almost never hear about IBM's actions with software patents in the Linux community. But their actions clearly show that they are willing to do whatever it takes to enhance their monopoly.
The economy would collapse tomorrow. I work for a company that depends on mainframes. And you know what? Just about every delivery company out there does. You want your stuff delivered to the store where you can buy it? Mainframe computers put it there. You want your stuff delivered to your home? Mainframe computers put it there.
I'm just saying, Mainframe, DB2 and even Cobol/CICS. At this point, I'll retire before thay do.
Yesterday, I had a Z series computer to myself! (There are some perks to being a DBA!) One of the jobs I ran reorgged about 150 million rows of data, and rebuilt 2 indexes on it. 10 minutes to do it. The similar 180 million row table took 12 minutes.
Don't forget the thin client technologies that are currently making a big impact. We're pretty much back to dumb terminals again. Having a large, centralised system is obviously an advantage until we find some way of utilising all that wasted power in the 2GHz desktops with 1Gib of RAM that companies buy in the hundreds.
It strikes me that along time ago some clever sod managed to dupe companies into buying and maintaining individual PCs at huge cost when small, lightweight terminals connected to a central mainframe were doing a great job. It's taken us nearly 20 years to notice that all people in most companies ever run is Office and most of them don't use even half of the features that were available in, say, Word 6.0. The idea of having hundreds of desktop PCs was a big mistake full of compromises like network drives, roaming profiles and remote control apps like VNC or Microsoft's Remote Assistance, none of which you need if you have the mainframe serve out desktops.
The greatest example of the evolution of the mainframe is the web. Web apps and office suites are quickly evolving thanks to technologies like AJAX and this all harks back to the general mainframe concept: Your clients show the UI, your (possibly distributed) servers do the work, keep the backups, and store everything in one place that's relatively easy to administer. If it goes down you have redundancy in the form of HA clusters or whatever to keep the system as a whole working. These ideas never went away, for some reason we just lost focus.
One important reason for the refusal of mainframes to die, is the enormous body of non-portable software written for them. Non-portability is a key advantage. Non-portable applications are what kept people buying mainframes, what kept DOS alive for many years, and what kept people using Windows 3.1 and Windows ME when it sucked ass.
Non-portable applications were written for Mainframes and DOS because the systems were so old that portability wasn't really a consideration when those apps were written. In other words, non-portable apps are a side-effect of having an old system, and they cause the old system to linger.
...The problem with running Oracle on a Sun E10k, is that you can swap out the E10k. Your application code doesn't have to change. Same with java applications. But something written in COBOL that accesses weird hardware-specific data ports and weird OS APIs will keep that hardware around forever. Because those applications will never be rewritten. Because, when it comes time to re-write the apps (ie when you want to run them on another system) they will have decades of convoluted business logic embedded in them, making a re-write practically impossible.
Others have enumerated the reasons why mainframes are simply better suited to certain tasks than others. But here's a big difference I notice in software on PCs vs. mainframes: On a mainframe, if the software works for 1 user, it works for all users with few exceptions. So you only have to get it working on 1 machine! You don't have to worry about different users with different hardware, different OS upgrades, different OS versions.
There were aspects of mainframe programming that I really miss (my first 4 jobs were mostly mainframe work) and it was definitely the coolest environment I've ever written assembly code for, but in terms of UI, it definitely sucked.
The required undergraduate assembly language course was offered in the traditional PDP-11 lab (EE students got the times the CS students didn't want - usually the middle of the night) or one class section on the CDC Cyber 74. Apparently, we got an apps engineer for one semester when we purchased the machine.
I figured I'd run across plenty of PDP-11s, but how many times do you get to play on a machine with a 60 bit word, hardware multiply and floating point? Don't remember much, but it sure was a fun class. Especially, after I figured out how to do remote job entry. Meaning I didn't have to hike down to the computer center in the snow with a deck of cards to submit my job, but could do it from the comfort of my dorm room with my Teletype.
Yes, I was a nerd. Still am.
There is the true 'big iron', like the top500. There are clusters and multi-core systems that use the exact same software technology. I've designed many such systems myself. Its those huge 1" tape drives and washing machine-sized Winchester drives that are no longer and these are the very things most associated with 'mainframes'.
It is the 'big iron' where Linux rules supreme with well over 70% share, almost 10x bigger than the second place systems. Go to http://www.top500.org/stats/list/29/os and see for yourself. Its no surprise most computing power is in Linux, but the lead is astounding.
Then there is Plan9, more of a 'networking system' than an 'operating system', but still considered Unix. This is one basis of 'super clusters' and its everywhere. If you tie thousands of machines saved from being 'PCs' into a cluster, that's a 'mainframe' if it looks like one or not. The 'mainframe' in whatever form it may take, has a bright future.
+1 Mod parent up.
The reason Mainframes still rule the world is because of the IO speed. I do JAVA and COBOL development and the reason JAVA will NEVER win is because of the slow ass TCP/IP database access. My COBOL programs run 13.88x times faster because they use Assembler calls to DB/2 routines where as JAVA uses JDBC. JAVA loads at 3.6 recs/sec where as COBOL loads at 50 recs/sec. It doesn't matter how fast your CPU is when you are waiting on the network.
--Scott
--Scott 8-}
Of course it lives, and in fact it has done things in 20+ years ago the the PC is just now approaching.
Mainframes aren't just about capacity. Mainframes are about reliability. They keep running - even as broken pieces are repaired or replaced, and equipment is upgraded. They use error correction to insure that the overall machine never drops a bit or makes an error, even though the individual components do. And so on.
It's not just IBM either. For instance there's Amdahl (now wholly owned by Fujitsu). Last time I looked (a few years back) ALL the baby bells did their real-time call accounting on Amdahl mainframes. Keeping them running was important - because if you had to reboot all the calls on the network were free. That's several million per hour down the drain - but NOTHING compared to a similar problem in a server supporting a brokerage's trading.
There's a lot of stuff you can do on networks of comodity machines. But when you truly need a "no bit shall fall" environment there's still no substitute for a mainframe.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
It left with the terminator.
It wanted to live.
If you can read this, I forgot to post anonymously.
It's ALIVE!
Quick, Igor, LPAR the system!
If "disco" means "I learn" in Latin, does "discothèque" mean "I learn technology"?
That might not be wrong...the latest System z9 boxes are quite powerful. The low end of the new machines is more powerful than the previous high end was not that long ago.
Too bad I already posted here
http://www.dieblinkenlights.com
If it runs Linux, or any other OS that doesn't support the kind of process exclusion and impervious access control by omnipotent administators who never use user accounts, then it's not a mainframe. Even if it's got centralized processing into vector units and huge IO, that's not a mainframe. Multicore CPUs are already "supercomputers"; calling them mainframes just because they're fast and big is meaningless.
--
make install -not war
The quality issue is another. A mainframe is made to a higher quality than commodity PCs.
And don't forget that Unisys still maintains and sells descendants of both the old Sperry UNIVAC 1100-series mainframe line and the Burroughs MCP-based A-series mainframe boxes (both are part of their Clearpath mainframe line). Both are quite dissimilar from IBM's in terms of architecture and software, but each is quite similar to IBM's big iron in terms of basic capablities.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Explain why an iSeries is not a mainframe?
Honestly, the more I look at like what MS is doing and even HP and Sun and the mainframe might never go away, there are just certain things that a rack full of PCs with Intel chips running windows simply cannot do and probably never will do, more importantly, it's not easy to get that rack running in harmony or keep it running in harmony.
I could buy something like 60 nice Dell rackmount servers for the same price and make a small Linux cluster of them. I'd end up with about 30 times the throughput, 100 times the storage, and 0% of the software cost. I cannot believe that the AS/400, solid as it is, has better uptimes than a 60-machine cluster (given that only about one tenth of those machines had to be online to exceed the AS/400's performance). Heck, for half the price, you could have two smaller clusters in geographically distinct locations with a high-speed link between them.
I don't doubt your numbers, but I believe you're leaving a lot out. Let's analyze this:
1) You equate an AS/400's price with 60 Dell rackmount servers. Although you didn't specify *which* Dell rackmount servers, assuming 1U each, this is two racks of Dell, minimum. The AS/400 takes about half a rack, but we'll just generalize to 1 rack. The Dells cost at least twice as much in floor space. Data center space: AS/400 wins.
2) Power. Minimum 60 AC-DC converting power supplies for Dell. How much is wasted in the conversion for the Dells? AS/400 wins. Minimum 60 power drops needed for Dell. How many does the AS/400 need? AS/400 wins.
3) Cooling. 1 rack for the AS/400 vs 2 or more for the Dells. AS/400 wins. I will guess that all the extra heat from having so many power supplies will just make the Dells more of a loser.
4) Network access. 60 individual NICs to configure for the Dells, and 60 different network sessions. AS/400 wins. 60 individual network drops for the Dells, and that would be at least a 48 port and a 12 port switch combo --maybe three 24 port switches? AS/400 wins again.
5) Storage access. You have 2.5 options. 60 individual disks for the Dells, 60 individual Fibre Channel HBAs for the Dells, or 60 saturated NICs running iSCSI for the Dells. AS/400 wins on either not needing 60 disks, or 60 HBAs. iSCSI could be a wash.
6) Console access. If the network fails, you will need to get onto the console. All 60 of them for the Dells; 1 for the AS/400. AS/400 wins. Good luck with 60 KVM ports. I recommend Avocent. If you can "get by" on one console at a time for the Dells, you'll need to pay someone to switch the cables, or physically be there yourself. AS/400 wins.
7) Sys admins. You only need 1 for the AS/400 -- and still have time for 59 more AS/400 servers. Good luck with the Dells -- you'll be bogged down with just that one cluster while the AS/400 admin is busy with the equivalent of your 60th (just an educated guess). AS/400 wins.
8) Fault tolerance: See #1-7. Simplification allows for easier problem resolution and time for other tasks. AS/400 wins.
9) Service contract: 60 machines for Dell vs 1 for IBM. Does the AS/400 support cost 60 times more for the same level? I'm guessing, no. AS/400 wins. Dell might not even offer service contracts for the machines you're comparing (hard to tell since you never mentioned which ones).
Hey, I'm not an IBM shill, nor am I short on Dell (I'm only expanding on your comparison). But you have to seriously consider the application here. And you will run into scalability issues with that many machines -- and scalability means money. Along the same lines, you might not want a whole lot of reliability, but you'll sure be spending the money you save (and likely more than that) for all the hidden costs I've listed above.
Typically if you run a MainFrame you pay more in licensing costs than the GPD of Uganda.
No, but really -- it's reliability.... not CPU power. I work on a MF with 12 CPU's, 8 are in use and 4 are automatic failover. We have 2 MF's actually--one is on the other side of the country and if our main MF fails we can switch over in under a minute.
The MF could take an RPG and still run, plus it serves every RF gun in our entire retail chain and aggregates all of our POS data and item level assortment data at our warehouse.
When you buy a MF you buy a platform to run an enterprise on.
this space intentionally left blank
Google does fail though. I have gotten error messages when trying to load google.com and the search results. Only twice mind you, but still.
:x
Ah. I was wondering where the MCP had got off to...
Better be careful when you hook up one of those Burroughs mainframes, then!
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Let's see a PC script do that.
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
die in a fire
Let me get this straight. You're spending $50M (and counting) -- $6.25M per year -- to create IT applications and infrastructure of some kind -- that's just to create it, not to run it or use it -- to avoid spending $3M per year? And you've wasted 8 years during which you could have actually delivered new business function -- code, middleware, whatever -- on your mainframe? And (probably) you're paying IBM's prices from 8 years ago, which have declined every year (at constant capacity) if you simply keep relatively current? And we haven't even begun to discuss whether any new infrastructure will actually work, consume more or less electricity, take up more or less data center space, recover more or less quickly in a disaster, stay up-and-running (with performance) more or less....
So when does the CIO get fired, and when will the bloody lot of you get outsourced for these stupid antics? It sounds like you've got an IT department that's killing your business. It also sounds like IBM and Fujitsu are happy to take money from fools.
That's what it sounds like.
Each time there is a discussion on the mainframe, it shows how little many of the "PC" people know about other environments, and how little they are willing to listen about other environments.
Fair enough. If you've seen it twice then surely it's happened more.
this space intentionally left blank
All modern mainframes (since at least 2000) can run the latest Java(TM): it's a standard, no extra charge feature in z/OS (the flagship operating system among the 5 available, Linux being another). So if you're running Java on the mainframe accessing DB2 on the mainframe you're going to see a much different number. (That's typically using something called JZOS, by the way, for Java batch programs. JZOS is free with z/OS, too.)
If it's J2EE (e.g. WebSphere Application Server for z/OS) then you'd typically be using the Type 2 JDBC driver to access DB2. As least as far as Java goes, that database access path is fast and tight.
In the modern mainframe (since 2004), your Java can run on a special Java accelerator called a zAAP. You turn on the zAAP on your z9 (latest model) or z890/z990 (prior generation model) and you pay zero extra (that'd be $0) for software but suddenly about 75% (give or take) of your WebSphere processing shifts over to the zAAP(s). The capacity you had been using on the main processors is now free for other work, or you can cap it and pay less for software, or buy less of it in the first place, or some combination.
So, yes, COBOL code accessing DB2 locally is fast, and Java code accessing DB2 over the network is slower. But Java code accessing DB2 locally is at least much closer to COBOL. You have choices.
As someone who works in a 'dinosaur pen', I've been hearing about the mainframe's demise for years. Of course these are also the same folks that promised us the 'paperless office', yet we go through pallets of paper every week.
We have two mainframe systems, IBM & Tandem (HP Non-Stop), as well as over 100 HP UNIX boxes. In general, the mainframes do the heavy lifting while the so-called 'distributed systems' handle storage, data warehousing & whatnot. There isn't a day that goes by without some kind of problem with the HP boxes. The UNIX tech services group is always running around putting out fires, while the IBM & (to a lesser degree) Tandem groups only have to deal with scheduled maintainence & upgrades & such. The running gag is to refer to them as Maytag repairmen since just like the commercials, they sit around waiting for something to go wrong.
Bottom line - a bunch of over-clocked PCs does not a mainframe make.
Comment removed based on user account deletion
It must be late, I started reading MF the wrong way and you started sounding like Samuel L Jackson...
WARNING: Smartphones have side effects--most of them undocumented.
Why are you FTP'ing? Would you prefer SMB/CIFS? NFS? Are those more convenient? They're standard, no extra charge features of z/OS. You own them already.
You want Unicode? Use it. Standard feature of z/OS and such things as DB2 for z/OS. Suck the file into DB2 as Unicode if you want. EBCDIC isn't the only character set.
Why are you transferring files in the first place? There are occasional reasons to do that, but as an application integration strategy? Why? File transfers automatically turn application interactions into batch interactions, even if the two applications are both online/real time. In 2007, why? As another example, CICS has free Web services/SOAP support and WSDL and has for years, over HTTP(S) or MQ as you choose, with Unicode of course. You already own that, too, if you have CICS. Just because you can use FTP and EBCDIC doesn't mean you have to. And if you're using FTP, why haven't you configured the server to be friendlier for the type of clients that you use? For example, have you looked at zFS (UNIX-style long filename /path/path style storage) as the upload/download area rather than traditional MVS-style datasets? You get to choose these things, you know, but you aren't forced to use them (clearly).
Since MQSeries has been called WebSphere MQ for years and, as "MQSeries" versions, has been unsupported for a long time, I'm guessing you didn't take IBM's warning seriously and install WebSphere MQ V5.3.1 or, preferably, V6 when you upgraded z/OS. You might not have taken IBM's warning seriously because the folks who did the work had no problem breaking the rules in the past, the fanatical IBM devotion to backward compatibility being what it is. And I suspect even with the warning, somebody at IBM bailed you out to keep your business running, even if MQSeries was unsupported. They might have even coded up a patch to z/OS just for you, and shipped it to you tested and ready in an hour or two, which you could apply to your z/OS system without a reboot and which you could back out without a reboot if you needed. But that's just a guess.
As for DCE, let me check.... Ah, yes. IBM warned in 2003 that DCE Application Support (a specific piece of DCE applicable to CICS and IMS) was going away effective with z/OS 1.6. (z/OS 1.5 and below have it.) z/OS 1.5 did not go out of no-extra-fee service until end of March, 2007.
I've seen that happen once. When did Google come out? 10 years ago? Maybe some installations don't suffer any outages in 10 years, but I doubt most survive that long.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
A VAX is not a mainframe. A VAX is a supermini. And a rather slow supermini, at that.
DEC had a terrible time with VAX performance. The original VAX 11/780 delivered almost exactly 1 MIPS. It was years before they came out with a faster model. They tried, but the first attempt resulted in a machine with worse price/performance. They came out with several even slower models; the VAX 11/750, the MicroVAX I, and the MicroVAX II. Then they tried ECL to get the speed up, which helped but made for a bigger, hotter CPU. Price/performance was terrible compared to microprocessors of the same period. That's what created an opening for Sun, Apollo, etc. to take away DEC's scientific market.
Let's assume gdb actually works and delivers the information you want.
Were you running it at the time? In production? All the time? Did it catch the fault? And did the hardware/driver/OS stay up in order to catch it? Was there hardware key-protected memory so that you know exactly what put what into that memory location? Did a cosmic ray bounce an electron inside the microprocessor?
Say what you will about the mainframe, the original poster was right. Debugging, tracing, fault analysis, and related tasks are like nothing else around. These capabilities are embedded deep into the hardware levels, and you cannot escape them. The philosophy is that if you're going to run it you damn well better be able to troubleshoot it at all times. And I'm serious about that cosmic ray reference. The dirty little secret is that microprocessors, as they get faster and hotter and more dense, are getting less reliable and generate less consistent computations. Mainframe processors effectively run everything twice, compare, and reconcile automatically, and the layers above (OS, middleware, applications) have absolutely no clue it's happening. The mainframe never lets so much as a fault add or bit shift surface to the OS: it'll dynamically swap in a spare under the covers until the redundant circuitry fully agrees.
I suspect part of the performance difference is because of poor programming by Microsoft programmers.
Is the transaction speed difference due to the speed of the hardware or the tight programming of the OS and the application on the mainframe?
Fight Spammers!
Only a few years ago, I understood that 80% of corporate data resided on IMS. In my experience, even where big IBM shops used SQL server, Sybase etc, ultimately that data derived from IMS.
There's a lot of stuff you can do on networks of comodity machines. But when you truly need a "no bit shall fall" environment there's still no substitute for a mainframe.
Tell that to Google.
Google is not a "no bit shall fail" environment. They have entire machines fail every day, and just replace them. If a search fails, run it on an other machine. Lost a couple of pages from the search database? Googlebot will find them again... Not so with financial data.
For number 3 (automatic clustering) try these:
http://openmosix.sourceforge.net/
http://openssi.org/
http://www.kerrighed.org/
All of these systems will let processes migrate between networked GNU/Linux machines.
I would like one.. at home For now, it is just play with the one at work Price / Space / power consumption is also better than compared to a rack full of crappy build x86 machines which need their separate environment and infrastructure build around
No, it's just IBM. Fujitsu (Amdahl) and Hitachi both bailed out of the mainframe market back in the late 90s/early 2000. Unisys makes high end servers, I believe, but no longer participates in the "mainframe" market, either. As a result, IBM gets 100% of the legacy market and also manages to put new workload on the mainframe for some applications.
Regards, Ian
Google is kind of a special case. Individual nodes do fail constantly, but it doesn't really matter because they form a distributed system designed to take such failures into account, and the search algorithm is a parallelisable task. If you need to do something difficult / impossible to parallelise with very high reliability and accuracy, and/or don't have the space etc for a huge number of PCs, then a mainframe makes sense.
considering the 24-way, 20tb disk, and 10g memory monster in the room next to me. Its got a cousin in another state as well.
AS/400s are essentially mainframes now. The next generation of iSeries will run the same processors as the zSeries. They already share a HMC and a lot of basic hardware.
We have a shop with multiple AS/400s, a zSeries, couple of xSeries, a Tandem, and a whole mess of PCs. The only systems we have downtime with are PCs. The network goes down, Notes server dies or locks up, etc. As such the Notes server is being moved to an AS/400 because we cannot afford downtime even for e-mail.
PCs look attractive because of their individual price. When setting up enough of them to do the same work they start getting expensive in base cost, power, and cooling. The other big factor in our use of AS/400s is that with over 80 of them we only have one primary Administrator and 3 back ups. Our Network support department (supports just managing the network servers and such) is larger and busier!
Mainframes (inc AS/400s) are here to stay because they just work. They nearly run themselves and that counts for a lot. You cannot underestimate the greatness of a system when people don't have to tweak or manage them daily - mostly because it seems to encourage some people to manage/tweak systems into downtime
* Winners compare their achievements to their goals, losers compare theirs to that of others.
I have worked more than 10yrs with both MVS (Sys Prog) and Unix (Sys Admin, DBA etc). Both have there advantages. We need a more balanced opinion. While working for one of the largest Banks in the world the IBM m/f would crash, Bank was top notch and got top Compass rating. So not a local problem, used to go to SHARE conferences, lots of m/f probs outages. While working at another place, CICS would fall over weekly. I have seen many UCB's ripped apart due to MVS sw errors. Many data corruptions and whole departments doing data recovery. What to check for, why you do not hear about this. "Gagging clauses in contracts", IBM and EMC use these in contracts so that customer 'can not discuss availability or performance with outside parties'. If you buy from EMC or IBM get legal to take these clauses out. If you want to keep them in ask for another 30% off list. Mainframe people due to the change control and test cycles had good discipline, this is what gave it, it's reliability. Hitachi and Amdahl produced far superior h/w, 90's market figures show this. Market became too small and ROI too little to maintain the businesses. IBM keep it going but quitely move the m/f to AIX. They do not want Sun or HP to move MVS to Solaris or HP-UX. IBM does these stealth migrations. As MVS skills are hard to get and costs companies money, it is good for IBM to make customers use mainframes then IBM can outsource the services and make more money, look at IBM results. If customers do not use IBM m/f makes it more difficult for IBM outsourcing. IBM m/f market increases as IBM Global Services buy the h/w, but very few new m/f customers. z/OS (MVS) has good RTM (Recovery Termination Manager) and ABEND/DUMP processing. However, so do others Solaris has DTRACE. HP and AIX are a little behind. UNIX is not lock-in. You do a RFP to upgrade the m/f. How many competitive bids do you get. Do this with UNIX, you will have Sun, HP and IBM bidding, much more open and competitive. Oracle, SAP, Sybase and all apps can very easily be migrated from one UNIX to another (export the database then import). Bottom line the mainframe is good but not infaliable, do not put it on a pedestal a computer is a computer, marketeers many spread the fluff seen on this thread. The mainframe & MVS, z/OS will live as it has IBM behind it and have massive market power. MVS is good as are Solaris and AIX. HP-UX has always seemed to struggle. Linux is just another flavour of UNIX with alternative channel, also good, but problems with backward compatibility. AS/400 not a m/f so lets not go there. Solaris has excellent backwards compatibility, since early 90's, PowerPC4,5,6 caused and still causes problems for AIX backward compatibility, HP-UX and Itanium story also had and still has compatibility issues. Sun, IBM and HP high end servers all have hot replaceable h/w components equivalent and sometimes better than IBM m/f. Also, built with top quality components, ECC plus more to avoid bit errors referred to here. Put top UNIX servers/mainframes against IBM m/f h/w and compare availability features you will see no difference. Sun has ZFS which has integrity checking on all data written. So comments about special unique integrity of IBM m/f is not quite true. What may give MVS the edge is the discipline of the admins. The change management, process and procedures improve the uptime more than the OS and h/w. I am afraid that in a discussion of high end UNIX vs MVS or z/OS there is no differentiating technological superiority anymore. MVS has a beautiful OS and structure, so do some UNIXes, but technology catches up. Equivalence is here if we avoid the emotions.
I would suggest for anyone who would like to get a taste of the "IBM Mainframe" computer architecture to try out "hercules"..
Obviously, the emulator is only as good as the underlying hardware (so it may not qualify as a "mainframe" *), but it allows anyone to see for themselves what the whole thing is about..
</ShameLessSelfPromotion>
* Unless of course when one runs the emulator on a linux instance running on a mainframe !
If it's only ever happened even once, then it still proves his point! Though even if the hardware is perfect, you still have software problems to deal with..
which is totally what she said
How is a debugger or print statements going to help you when a PRODUCTION piece of code crashes?
You can't run your code under a debugger 24/7, unless you want to incur a huge performance penalty.
Sure if the core dumps and your system is set up to take advantage of it, you can usually open it in a debugger and see the fault condition - but you normally can't reverse it backwards to the original cause, all you have is the fault state. All previous states are lost.
This is what the parent is talking about, in order to do anything you are talking about you have to run the program AGAIN in debug mode (or "debug log mode" or whatever) and hope to re-create the error condition.
This is not the case with mainframes. When they dump they dump the entire machine state, and it is often reverseable to a finite number of instructions.
Working on mainframes for banking now for aobut a year, I knew nothing about them before hand but I quite like them now... but they realy need to work on removing some of the now unessecary obscurity of JCL. It just seems rather pointless to be using a scripting language that was developed for use on punch cards, maybe something similar to xml would work better, Im sure IBM would make a mint off tools to update peoples programs to a new scripting language and it would stop scaring off new operators who take one look at a line of JCL and run away to hide.
Define awhile? How long have you been?
I am 37, and have been fiddling since I was 10. And i do no consider my 27 years in the computer world a long time.
Puto
The Revolution Will Not Be Televised
One of the best things on the mainframe is the scheduling.. The mainframe scheduler we have, is far more powerful, and Reliable than anything else (that I know of) out there in the PC world. We also have night operators who get notified immediately when something goes astray. We're currently looking for a PC/Server based equivalent.. but so far nothing has met our every need.
I've got to say that running Java on the mainframe is soooo sweet (using JZOS). IBM now has tools that will convert a COBOL copybook into a Java class(s). So all you have to do is get your input stream and load into the generated Java class(s).
Not to mention with z/OS 1.7 you can now generate and process XML in your COBOL program. If IBM and others can continue to improve z/OS, USS, CICS, and Enterprise COBOL.. the mainframe will never die.
The Dell blades are lame, haven't used the HP.
But for the SAN, you can forget iSCSI (too complex) or fibre HBAs - just use the second ethernet port on the Dell rackmounts and run Coraid's AOE. Awesome reliability and throughput, at a tenth of the cost and complexity of any equivalent solution; add Red Hat's GFS file system (that they bought from Sistina) and you get full-on storage clustering.
Mainframes can't compete on a cost-effectiveness basis.
How do I know? I have both in my computer room. I've got an HP-UX with a fibre SAN too.
Quality is another issue. And so is quality.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
>>Mainframes aren't just about capacity. Mainframes are about reliability.
Ditto for Midrange systems. I have a huge code base that powers an almost billion dollar/yr company. Some of this code was written and compiled in 1989/1990.
In the late 90's we went from 32bit to 64bit. The OS took the compiled object (.exe in Windows world) and converted it from 32bit to 64bit automatically. As major changes have occurred, the object has automatically (by the upgrade) been updated to make better use of the new system.
The fact is that I have code that was compiled in the 1989/1990 that I haven't had to touch and continues to run on the latest OS/hardware. This is true of all code and all databases that I run on this system. It just works.
On Windows / *nix this just isn't the case. In Vista can I run the QBASIC compiled program I purchased to drive my highway sign? No, I lost that functionality in NT 4.0 days when the hardware layer became abstract and I couldn't directly access the fiber serial card (no drivers exist for this - didn't need them in DOS.)
I get to work on many various types of systems including ESX clusters with SANS, Windows, various flavors of *nix, embedded systems, etc. My favorite is the IBM business model line of systems. I program it to do something, and it just works forever.
Technically correct, but it is designed on a network (exactly the same type of network as the internet but smaller). The internet was designed to overcome failures by finding other routes etc...
If your mainframe does ever fail (and surely more will as they get older), then you are truly screwed. By fail, I don't mean bits dropping here and there, I mean the mainframe falling over.
America, Home of the Brave.
Our company just got a shiny new IBM z9 2 months ago....we used to rent time off of a system 1/2 a state away. Management decided it was more cost-effective to bring the machine in-house....
You're messin' with my Zen Thing, man.....
Virtualization (VM/370) was introduced on System/370 (1970), not System/390 (199x). Not sure though if IBM invented it...
was never on life-support, either.
.NET code on the mainframe (SuSE Linux Enterprise 10 plus MONO installed), including ASP.NET 2.0 code.
New customers of the z/Series machines might not even use ISPF/RACF/TSO and all the other subsystems they get with z/OS and instead run their machine as a pure Linux environment with many little Linux VMs running on the same hardware.
This is identical to buying a huge 16-way x86 Xeon server with hyperthreading, installing VMware ESX server, and running a bunch of Linux VMs on the machine. You can do this on IBM hardware cheaper than on Intel hardware [yes, believe it... it's true].
For big database customers of DB2, no other platform runs DB2 better for you than a big z/Series box when you look at the high-speed I/O channels IBM has on the machine. To setup pure-fiber SANS between an HP SAN and a big HP or Dell server cluster costs the same money and has more points of failure than a single z/Series box running 3 or for VMs with participating DB2 instances.
There's still customers running CICS/IMS, etc... but nobody is out there writing new apps on these platforms. WinTel people aren't aware of this because they don't ever interact with mainframe people except to integrate old software.
You can even run
The mainframe is nothing but a bigger, powerful more fail-safe server. Think of it that way.
Every time the subject of mainframes pops up all the retirement homes open their gates to flood us with old developers who repeat the IBM marketing rubbish they learnt 30 years ago.
The single reason why we still use mainframes is because we do not have the choice to switch away. 30 years of application development created a brittle application landscape deployed on mainframes. The platform is extremely proprietary. There is no migrating away, there is only rebuilding. So please forget about "reliability", "proven technology" and all this marketing nonsense. We are prisoners, locked up on a proprietary platform.
Have a look at companies that are not locked up. Companies that were lucky enough to start at a time when there was other technology available. Do they use mainframes? Definitely not!
"Oh it'll be here, someday, but again, don't hold your breath waiting the mainframe to go away as yet another generation realizes the advantages of what as invented long ago."
Smalltalk, Lisp.
The Burroughs MCP is Tron MCP's friendly old granddaddy. :-)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
That's news to me, and it would surely surprise my current and multiple former employers (all of which still heavily use either current OS2200 or current MCP mainframes from Unisys).
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
as part of a digital hardware design class. Never thought of patenting it! Got an A in the course though.
IBM's suit is based on the notion that running IBM OS software atop PSI hardware will damage IBM's reputation. But IBM has lost such suits before and will probably lose this one. They should bite the bullet and buy PSI's technology.
I'm glad someone is using the idea. But the surprise is that IBM (or someone!) didn't have patents on this long ago since, once you see the idea, it's so trivially easy and useful.
A mainframe is very large server hardware that is specially designed for I/O throughput and reliable operation with a high level of recoverability and the ability to cluster efficiently.
It also usually comes with an OS (these days normally VM, z/OS, OS2200, or MCP) which is specialized in various ways to utilize that particular hardware efficiently. Most UNIX variants are quite simplistic in comparison -- they have a simplistic process scheduling and prioritizing model with no real separation of batch, real-time, and interactive tasks (OS2200 places each of those types of tasks into its own range of scheduling priorities), and UNIX also tends to use a fairly course security model instead of a more sophisticated permissions bitmask or equivalent.
VAXen were not mainframes (superminis at best), but had many of the right ideas. IBM z\boxes are mainframes, as are Unisys Clearpath servers, and they are larger than the UNIX boxes you're likely to see.
Supercomputers focus on CPU bandwidth. Mainframes focus on I/O bandwidth. Very different focus.
You typically don't see real "mainframes" outside of large financial institutions, government agencies, and airline operations. Those types of operations tend to have a need for ultra-reliable large-scale systems with very low response times.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Geek-tastic!
They'll read:::
My main problem with mainframes (other than the text based interface) when I worked with them was COBOL. Its such a backwards language. Of course, the mainframe could have run C or Java, but they wouldn't let us (management that is, not IBM.)
Coder's Stone: The programming language quick ref for iPad
To me, what makes it a mainframe is the fact that it is designed from the ground up to be a multi-programming, multi-user system. Things like multiple CPUs, multiple channels running at the same time while the CPUs continue to execute instructions of other programs, interrupts, storage protection, all these were part of the original System/360 architecture.
:)
I get a kick out of some of the newbies. You guys like your fancy new 64-bit x86 PC? Well, everything from the 360/65 up all had 8-byte storage access and 8-byte channels, 40 years ago!
Google does more than search, you know. There's plenty of financial data involved in their ad business, and they keep customer data for GMail, Docs & Spreadsheets, and other web apps. They cant exactly go around losing that all the time.
On Windows / *nix this just isn't the case.
Bet it is on the mainframe versions of *nix.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
If your mainframe does ever fail (and surely more will as they get older), then you are truly screwed. By fail, I don't mean bits dropping here and there, I mean the mainframe falling over.
Mainframes have multiple instances of everything - including CPUs (and power feeds to them). They are designed so that entire running systems can be migrated off a failing or failed component and onto another. Depending on the company's configuration and disaster planning, the "other component" may be in another site rather than another part of the box or the computer room. Or the database may be coherently replicated across multiple sites and the applications designed so they can pick up where the crashed box left off. For less real-time applications a system at a backup site might be up the next work day with no penny unaccounted for.
Mainframe disaster recover scenarios generally include one or more where the entire city containing the primary system is effectively no longer there.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Why would you want a MRT on the AS400? If I remember right the advantage to a MRT was the program loaded once into memory used multiple times, but that's how the AS400 worked by default, each user ran the exact same code in memory but had a different PAG which held that jobs variables etc.
AS400 scales well, but it doesn't go beyond the low end of the mainframe. There certainly is overlap, but even with that I think the "mainframe" term probably isn't the best for an AS400.
The iSeries is virtually the SAME as the pSeries. In fact, it runs the same processor, a Power5 in the newest machines
The RS6000 began using the AS400's processor in 1997 (Code name Apache, developed in AS400 unit in Rochester, first full PowerPC architecture that the 2 boxes shared, 64 bits, etc.).
Bit settings allow the processor to run in as400 single level storage memory model.
'[unheard of brand] had this technology back in 1930, IBM stole and are t3h suxx0rz and I was an admin and now pc's are faster anyway'
And do you think they run that important stuff on their GoogleFarm of cheap linux machines?
There's a story about a Tandem service call after the 1989 earthquake - the customer said the machine had fallen over on its front, and they wanted Tandem to turn it rightside up again. It was still *running* just fine, though they couldn't reach the tape drive and front panel switches, but they thought there was enough risk that something might get damaged when they picked it up again that they wanted Tandem to be there.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Multiple CPUs? Not traditionally. There were multiple processors, but usually one CPU and a bunch of I/O processors (also called channel processors.) The channel processors were similar to the kinds of RAID processors you'd plug into your PCI bus, or network cards (back when you used separate network cards that tried to be intelligent and off-load work from the CPU, as opposed to having them built into the motherboard.)
Multiple access mechanisms? Traditionally you had terminals controlled by a 3745 or similar front-end processor, which was channel-attached to the mainframe, and maybe a network protocol. SNA was ugly and hierarchical, basically letting each mainframe think that it was the only computer in the world and the computer at the other end was some peripheral device - and the protocols that preceded it, like bisync, were either uglier or dumber or both. (To give it some slack, it was made to run on terminal controllers that were about as bright as digital watches...)
Error detection and correction? Mostly that was a database function, and some of the database protocols gave you really good rewind capability, but traditionally you weren't rewinding the CPU, you were rolling back the database and restarting the batch process.
Multiprogramming and parallelism? Not particularly on a user level. The system did let you have multiple users running at the same time, and gave you some fairly fine-grained control over who got what fraction of the resources, but it was a lot clunkier than something like Unix timesharing.
These were some mean nasty ugly machines
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
....But it's not supported and never was. IBM declared support for z/OS 1.(4?) and above on the z9 models. OS/390 itself is out of support as well. In strict technical terms, it would have the best chance of running inside VM on a z9, possibly double virtualised (OS/390 inside an older version of VM inside the newest z/VM). (Yes, mainframes can n-virtualise, and there's negligible performance penalty for doing that.) Unsupported again, but technically it'd work.
Because what I want to do with a PC is run a Linux desktop and use VMware Server with a Windows guest so I can run my legacy apps without hassle. (WINE fails the "no hassle" test)
And it hardly takes a high-end PC to do this, I had that setup working with a Duron 900.
The discussion as a whole simply demonstrates that there's no "one-size-fits-all" in computing.
Computers and operating systems are tools, use the ones that fit the jobs you intend to do.
Tech Public Policy stuff