Mainframe Programming to Make a Comeback?

ajw1976 writes to tell us that IBM has released a series of announcements today "introducing many new software tools, academic programs, and support for outside developers." The new releases are designed to help entice programmers and businesses back to the mainframe. From the article: "The announcements, according to analysts briefed on them in advance, signal a shift from defense to offense in the company's mainframe strategy. Last month, I.B.M. introduced a machine priced at $100,000, about half the previous starting price for its mainframes, which can run up to several million dollars. The announcement of the low-end mainframe was made in China, which I.B.M. regards as a promising market for the machines."

Comments

mainframes rock

[yagu]

Cool, I can dust off my old bell bottom pants and platform shoes. I knew they would come back!

All seriousness aside, I started out coding for mainframes, mostly assembly. To this day some of the most screaming and cool programs I ever wrote were on mainframes (wrote (in assembly) an on-line trouble logging system to replace a paper system back in '76).

I did lots of COBOL programming and maintenance for a major, now absorbed by increasingly corrupt larger pseudo-telcos, telco. COBOL, not the most exciting language, but the throughput and data integrity of those days I've not seen matched since (and I still love Unix as my first choice for environment).

Which brings me (and us) to what I think works in favor of mainframes having a chance at a major comeback:

• TCP/IP stack not builtin and assumed. In the old days, if you wanted to communicate with other architectures it was a RPITA. With internet protocol everything is easy. Now you can take the raw power and integrity of the mainframe and lace it up to foreign technology.
• IBM's OSS/Linux participation. I don't know if IBM has completely jumped on this bandwagon, but they've made contributions, and you can "do" Unix on their mainframes. And, they have cool passthrough mechanisms, how cool is it to write a shell script that can access VSAM data? If you don't know, it is very cool.
• Mainframes historically have gi-huge support organizations built up around them. They have backups to backups. And, it's all managed for you.
• Mainframes are single point of support, you all know you're using the same configuration (well, to the extent you're in the same virtual system on a mainframe).
• Mainframes aren't Windows (sorry, had to put that in for the troll mods.)

This is a partial list. I've long lusted for the raw power of mainframes with the standard support and the nimble Unix utilities.

Re:mainframes rock

[EmoryBrighton]

I have heard a lot about mainfraimes (heck, I work for the gov and we rent a 3M+/year Unisys mainframe for certain sensitive databases) ... but I have never seen statistics that show *how much better* those mainframes are...

Does anyone know of any (non VENDOR) studies & comparisons vs traditional computer architectures?

Re:mainframes rock

[AuMatar]

Mainframes are just too different a world. Its not just performance (in fact, the performance difference is due only to an insane number of cores and memory, not an inherently better chip), its reliability. Some IBM mainframes have CPUs that do every instruction twice in parallel (different cores on the chip). If the results don't match, it turns the chip off as defective and shunts the program to a backup. That kind of thing just doesn't exist in traditional architectures.

Although in the days of clusters, I don't know if mainframes can make it. Clusters have the same edge and much lower cost. I think we're more likely to see some of the OS advantages of mainframes get ported down.

Re:mainframes rock

[morgan_greywolf]

Does anyone know of any (non VENDOR) studies & comparisons vs traditional computer architectures?

Mainframes are traditional computer architecture! Unix is 'new' compared to mainframe technology.

The modern mainframe is, in general, vastly more reliable than even the best of the best of 'big servers.' Mainframes are generally redundant to the point that you can change out thefr CPUs, memory, drives, etc. without turning the power off or rebooting the machine. Linux and Unix servers might boast about a couple of years of uptime, but many mainframe systems have been up for decades.

Many mainframe systems can process orders of magnitude more transactions than your typical *nix system running Oracle -- even when compared to systems with SMP, gigabytes of memory and the latest in high-speed storage. In fact, the stuff that people use nowadays for high-speed, high-reliability storage -- storage area networks (SANs) -- have their roots in mainframe technology. EMC, one of the market leaders in SANs was formerly part of Data General. In fact, so does most of the rest of your high availability 'enterprise-class' technologies -- SMP, NUMA, clustering, etc. Where do you think Linux's current SMP technologies came from? IBM. Who developed them on mainframes, ported them to AIX and then eventually ported them to Linux.

Massively-clustered systems like Google's are quickly become the norm for high-end stuff. But there are certain things that will probably always run on Big Iron. Whenever tasks are mission-critical and need to 24x7 and 'three 9's' doesn't even touch the tip of the iceberg in what you need in reliability -- you'll see mainframes running those tasks more often than not.

The value of the mainframe is in the hardware...

[kcbrown]

Mainframes don't have the fastest CPUs around. Instead, they have the most reliable ones.

The same is true of their memory subsystems, their disk subsystems, etc., though their backplane performance tends to be second to none. Mainframes are designed for throughput.

Mainframes are capable of staying operational for decades at a time. If you don't want your computer to ever go down and can afford the price, a mainframe is what you want.

One other nice benefit: they've had virtualization figured out on mainframes since the 1960s, so allocating resources is a relatively easy thing to do.

If you're interested in finding out what the older mainframe OSes were like, check out the Hercules IBM mainframe emulator here.

Cluster computing is better

[starfishsystems]

There is a strong movement toward cluster computing as a way of sharing the costs and benefits entailed by massive compute resources.

It turns out to be a lot like mainframe computing in terms of physical infrastructure and administration, and in fact often takes over disused mainframe computing centres, at least in the university space.

Unlike the mainframe environment, anyone with Unix/Linux experience is already equipped to take full advantage of cluster and grid computing. Either enviroment provides specialized resources that you have to learn how to access, but to me, the advantage goes to whichever environment provides the most universal expression of those resources, and is least likely to lock my efforts into one particular architecture.

A mainframe is an especially proprietary architecture. Portability has never been its strong point. Conversely, most cluster computations that I've seen have been quite trivially ported from one cluster environment to another. And to some degree it's in every vendor's interest to make it so.

The exceptions are interesting but, at this point, surprisingly rare. Relatively few researchers are decomposing problems in a way which requires either MPI or shared memory. Perhaps the field is not mature enough for that yet, much less for the sorts of computation envisioned by the Grid community, though that day will eventually arrive.

What I mean is, the biggest market for massive computation is always going to be driven by ordinary computation which happens to operate at a massive scale. And for that, the plainer, more symmetric, and more standardized the architecture, the better, because development and testing costs are not going to go down in the face of massive computing resources, they're going to go up.

The perfect mainframe, in other words, is one node in a Beowulf cluster. And that's fine. Just don't go running MQ Series on it, okay?

Re:Cluster computing is better

[Animats]

A mainframe is an especially proprietary architecture.

Actually, no. The IBM 370 architecture is open, as a result of an antitrust decree decades ago. There are plug-compatible peripherals and software-compatible CPUs. There's even a good emulator for PCs. It's actually more open that x86 or PowerPC.

Re:Cluster computing is better

[Arker]

Clusters really aren't comparable.

They compete with supercomputers, not mainframes.

A lot of people confuse the two, but they're very different sorts of machines designed for very different purposes, with very different characteristics.

Supercomputers are great for intensive calculations. When you have a relatively small dataset and a very long string of operations to be performed on that dataset, you want a supercomputer.

A subset of supercomputer tasks are easily parallelised, and on that subset, in particular, a cluster can really rock.

But the weakness of clusters has always been in throughput - their ability to move large amounts of data around is rather weak.

Mainframes aren't great at intensive calculation, they don't compete with supercomputers, what they're designed for and great at (besides incredible reliability) is throughput. Those suckers can move enormous quantities of data around very very quickly.

Want to calculate more digits to pi? Break an encryption key? That's a supercomputer job, and a cluster can probably handle it fairly well.

Want to search a database that contains every transaction your company has ever had, with any customer or supplier, globally, for the past fifty years? That's a mainframe job. And neither a supercomputer nor a cluster is going to get close to a mainframe at doing it. All those hot little cpus will sit mostly idle while waiting for all the data to trickle in through a relatively narrow set of connections, while on the mainframe, all those (relatively slow) CPUs are being kept busy by a massive array of hard drives on an interface with more bandwidth to memory than most of us can even imagine.

Apples and oranges.

What makes a mainframe a mainframe?

[toybuilder]

Asking most programmers to appreciate mainframes must be like asking most drivers to appreciate 18-wheel big rigs -- you know they exist, and large companies rely on them, but you never really have a *need* to know what it's like to operate one.

I've always believed that mainframes have their place in the world, even when the world was announcing the era of the personal computers and the death of mainframes. But while I understood them to be highly specialized high-throughput high-reliability machines, I never had a personal experience with a mainframe operating environment. So I never truly understood what a mainframe is...

I've worked on (relatively) bigger Unix systems (8 processor SPARCservers, 4-rack Sequent NUMA-Q's, and others), but at the end of the day, they seemed no different from a single desktop Unix machine -- just faster and with more memory and storage. I've also used a VAX, briefly, during my freshman year in college. I've always imagined that VMS was closest to what a mainframe environment must be like.

So, to the folks that understand the mainframe -- what is it about them that makes them more than just faster versions of desktop machines, or even server systems that us non-mainframes are used to?

Re:What makes a mainframe a mainframe?

[swordgeek]

To answer your question at least partly, look at something that Sun termed "midframe," the SunFire 6800.

This beast can be physically partitioned into multiple domains. One OS runs on each domain. CPU/Memory boards and I/O boats can be dynamically moved from one domain to another. You can run Solaris 8 in one domain, Solaris10 in another, Linux in a third, and um...*BSD in a fourth. Any of them runs independently of the others. If a board dies, you can deallocate it from a domain, swap it out, and add it back in--all live.

Now multiply that by a LARGE number, add crazy amounts of fault tolerance, and you're getting into the world of mainframes.

Re:What makes a mainframe a mainframe?

[Anonymous Coward]

Your analogy of a 18-wheeler is probably a good one.

It's not the fastest thing in the world, but would you want to haul a load of water main pipes with a Porche?

background.. I'm a mainframe systems programmer..

There are two major aspects of a mainframe. One is the physical hardware (and software), on how it is designed and the other how they are used. The hardware is designed from the ground up to be robust and redundant. Yes it costs thousands (millions?) of dollars for a mainframe system, but with that you get the assurance that the system *WILL NOT CRASH* when an error happens. Instead the system will perform a self diagnosis, make an automated phonecall back to support. Support will send out an engineer (CE) with the replacement parts, which will be replaced while the system is still running (note that there are some (very few) instances where the repair does require downtime to actually perform the repair).

A few years ago, one of our CE's informed me that one of our mainframes had called home with a CPU failure. I asked if he would need to schedule some downtime to replace the card(s). He said ".. No.. we would have to lose 5 more before they would get worried.." Now.. from my viewpoint, I did not see any error, I still see the same number of "Processors" as I did before. What happens is that the system has a bunch of spare CPUs that are kept online. Instructions are run in parallel across multiple CPUs and then the results are checked. If there is a failure (as in the results don't all agree) the system will determine which CPU "failed", perform a diagnosis on that CPU and if it's determined that there is a problem will fence the failed CPU off from use. Note that this is all done under the covers from the operating systems. There is nothing that I need to do to enable or disable this.

Mainframe operating systems behave very differently then the Windows/Unix world. -- Lets take a simple example. An application allocating memory. Under Windows/Unix what happens if the memory allocation fails? -- Answer, the program is handed back control with the hopes that it will test the returned value. On a mainframe by default if there is a memory allocation error, the application will be "abended". Now the program *can* request that if there is an error to allow it to continue by explicitly stating that it will handle the error. This concept is carried throughout the system API. By default the application will be halted if there is an error. Under Windows/Unix the default is to simply return some error flag and hope that the application will handle it.

The way mainframes are used and maintained is a little different. Things are usually not done on a whim. This really isn't due to anything physically different on a mainframe, but more of the "culture". Yes these are big expensive boxes, therefore the company that owns (rents) them wants to make sure they are maintained and running efficently. When changes are made, they are researched and documented with fallback plans. When even minutes of downtime could mean millions of dollars lost, it's well worth the investment in time to make sure that a change is correct. Going back to the 18-wheeler analogy, I suspect that when it's time to do a scheduled maintenance on the tractor there is a lot more testing/verification then you would have done on your family car.

Forget z/OS, try Linux under z/VM

[swamp boy]

For any organization that may contemplate getting into mainframes -- skip z/OS (MVS). MVS is what most folks dread when they think about mainframes (JCL, pre-allocate datasets, etc.). A modern mainframe (z/990 or z9) running z/VM (5.1 or 5.2) and a bunch of linux guests is *COOL STUFF*. What's really cool is when you need to setup a temporary testing environment -- no problem, just add a half-dozen configuration statements to your "USER DIRECT" and clone an existing guest image to the new machine's disk volumes. Done! Need more memory in that virtual Linux server? No problem, bring up USER DIRECT in XEDIT and edit a single line of text and issue DIRECTXA. Restart the linux guest and now is has more memory. Disk space (volumes) can be added while the Linux systems are running (add as many as you need).

Re:But how can anyone learn to use mainframes?

[jacobsm]

The company I work for hired a person right out of college. Spent about $2500 on him by geting him an IBM Education card which gave him one year of IBM education. This person has grown to fill a very important postion in our technical services department. He started working with CICS and is now performing a zOS operating system upgrade.

I wish we could have more like him.

Mark Jacobs
Time Customer Service
Tampa, FL