Western civilization runs on the mainframe

http://fosspatents.blogspot.com/2010/08/western-civilization-runs-on-mainframe.html

by a2tech • 16 years ago

154 149 16 years ago

fosspatents.blogspot.com

wallflower2• 16 years ago

"According to Maclean, comparing mainframe performance against, say, Oracle running on an x86 server platform may yield similar results in a low usage scenario. However, a mainframe will prove its value as that application set scales up in volume. The difference isn’t in the CPU, which (in non-IBM cases) is the same on both sides of the comparison. Rather, the difference is in the architecture of the operating environment."

http://www.processor.com/editorial/article.asp?article=artic...

dan_sim• 16 years ago

In fact, western civilization runs on the mainframe AND excel. As a consultant, I see a lot of both...

mkr-hn4• 16 years ago

More broadly, western civilization runs on entrenched systems which no one has the will to replace.

Sometimes it's easier to stick with what you know works than to try the newer thing, and that's probably the reasoning used by the people making the buying decisions.

ramchip• 16 years ago

Why would Excel need to be replaced? It's good software.

jacquesm17• 16 years ago

> The mainframe software market is twice as big as the Linux market

That's one hell of a compliment for Linux then.

njharman• 16 years ago

I came here to mention that was the most stunning bit of the article. Not the fact. But that someone is using the size of the Linux market to demonstrate how large mainframe's share is.

I'm old and have lived through the growth of Linux. Starting as nothing, through all the FUD, and naysayer pudits, and claims it was communist, and MS many monopolistic attempts to squash it, etc. Comments like that still make my jaw drop.

hernan7• 16 years ago

... and we are talking about "market", that is about usage of Linux that involve exchange of money, no? So that's even more impressive.

yummyfajitas• 16 years ago

Obviously there is a business use case for mainframes, these can't all be legacy systems. But what is it? Can someone who has worked with such a system shed some light?

gaius11• 16 years ago

1) If you need to do a lot of relatively simple things bloody quickly. There's nothing in the Unix world that can match the TPS of a mainframe. "Eventually consistent" just doesn't cut it for credit card auths.

That is the real difference between mainframes and supercomputers. A supercomputer is about computation, a mainframe is about I/O.

2) Extreme reliability. There are mainframe clusters in production with a continual service availability for decades. Again, nothing in the Unix world can touch this.

rbranson15• 16 years ago

1) I refuse to believe banks and insurance companies have I/O that can't be satiated by commodity hardware. InfiniBand QDR can transfer 40Gbit/sec with 1µsec latency. That's easily 200,000 synchronous round-trip messages per second PER link. If you can deal with higher latency, those can be aggregated and you can easily exchange tens of millions per second. Let's take this one step further: ECNs and automated trading systems. Their latency and I/O requirements make banks look like amateurs, yet they almost entirely run on off-the-shelf hardware and systems. Billions are at stake in these systems.

2) When was the last time Google or Amazon or NASDAQ or Arca was actually out of service because of hardware failure or maintenance?

gxti• 16 years ago

I haven't worked with mainframes, and I frequently chortle every time someone mentions one even though deep down I know the article is right. But still, lack of experience has never stopped me from making stuff up before, so:

I imagine that the primary reason companies buy mainframes is that their monolithic architecture abstracts away a lot of the hard thinking that goes into a clustered system by putting it all in one chassis. If my 2000 CPUs are on separate machines then I have to write code to coordinate them and move data between them. If there's a super-fast bus connecting them and they can work with shared address space and let the OS deal with scheduling and data flow then even the average corporate code monkey can write naive large-scale apps that run a little slower but get the job done well enough to please their corporate overlords. And maybe the cost of developing a "proper" architecture for these sorts of business jobs is too high compared to the cost of a few hundred thousand in rent-a-mainframes.

pedanticfreak• 16 years ago

I have not worked on mainframes per se. But I was once tasked with investigating why a particular project to replace a mainframe process with a modern Java one failed.

Basically, the mainframe is FAST. Everything is simple there. The process in question was more or less a COBOL stored procedure doing a bunch of lookups in an incredibly denormalized DB2 database. The entire batch job would take less than 15 minutes on the mainframe of which this particular process was only a small fraction.

Now, the Java app to replace the mainframe process was apparently written by some smart dudes that had gone on to make lots of cash doing more exciting things by the time I got there. The replacement system was what lots of naive people drinking the Hibernate Kool-Aide were writing back then. The database was normalized to the extreme, it had a hierarchical object model that was mapped to objects with Hibernate, had a slick web interface, and so on. Well it ran like balls. It got exponentially slower as data was added. The administrative interface took 30 minutes to save a setting. This new process would increase the runtime of the overall batch by an estimated 10 hours. So I looked at it, and with another guy cleaned up a bunch of bad SQL and Hibernate.

The administrative interface got shaved down to seconds for a post. But in the end the overhead alone of marshaling and unmarshaling XML for the service calls was enough to push the batch process a full two hours longer than the mainframe one. Which, by the way, was unacceptably long for the 1 hour maximum processing window allotted to the batch.

OK, I know what you're saying. That's when you bring in the cloud and run a bunch of parallel instances and such and such. Or dump XML and use some kind of raw binary message format. But shit. The mainframe already did all that with a single threaded COBOL stored procedure in under 15 minutes. Needless to say, today they're still using that same old COBOL stored procedure and they're still making money hand over fist.

So yeah. Big companies spend lots of money trying to get off the mainframe every year. Believe me, I have personally witnessed tens of millions of USD lost to failed mainframe replacement projects by developers who think they know better. It's not like some manager looked at the the estimate and said "hell no." Actually they said, "Hell yes! My top architects say the mainframe is dead. I will write a check for $50 million dollars right now because that is nothing compared to the $10 billion in revenue we make." It's just not as easy as it looks.

thibaut_barrere• 16 years ago

I've seen these for at least:

- payment processing

- mail order sending (retail market)

- insurance databases

All on fairly large (world-sized) markets. Never programmed these myself, but had to interface (file or api) with it.

My feeling is that high reliability / data throughput is favored over programmer productivity and data structure elegance (most data I've seen there was fixed width strings :-).

See Host Integration Server (http://www.microsoft.com/biztalk/en/us/host-integration.aspx) for an example of product that allows to use .Net (I guess, even IronRuby) to talk to a mainframe.

Kadin2• 16 years ago

They're powerful, reliable, and compared to writing software for an equally-sized cluster or distributed system, (once you're in the right mindset) easy to write for. Or alternately, not to write for -- you can just keep migrating the same ancient COBOL up to newer systems, without ever changing it, and the stuff just keeps ticking.

The business case is that they work, and have a great track record.

Overall the biggest selling point that I've seen is probably reliability. There's a perception that mainframes are more reliable than commodity-parts systems. In truth I think this is confirmation and sample bias; if you run a business that has a mainframe (very expensive, built for reliability, software has had 20+ years of debugging) and a bunch of servers (inexpensive, cost-optimized, software is constant work-in-progress), it's always going to seem as though the mainframe is unbreakable and everything else is dangerously unreliable. It's as much a mindset issue as an architectural one.

So many businesses will pay the premium for mainframes as their "core" systems, and then hang a lot of commodity systems off of it to provide access or interaction with the mainframe data.

thaumaturgy3• 16 years ago

You're exactly right.

I worked on a mainframe for a major Bay Area school district during and shortly after high school, as a computer operator and COBOL programmer.

I was there for a couple of years; rebooting the mainframe was unheard-of. It never seemed to develop memory leaks, it didn't get more quirky after it had been running for a long time. Since it wasn't accessible to the internet (or even most of the network), it didn't need to have any time spent on it trying to secure it against the latest Windows bug. It never required software updates, other than the ones that we coded ourselves and deployed without having to reboot anything. The database didn't fall over when we ran a payroll job or report cards.

But, best of all -- and I love telling this story, because I think it really illustrates something that the techs using all the modern stuff just don't "get" -- it had the best recovery systems I have ever seen, hands down.

So, one day there was a power outage. We had backup power systems, but like a lot of data processing departments we were just a couple of overworked people and they hadn't been checked in a while. They didn't last as long as we were expecting and the mainframe kicks off. Around that time, I'd been playing around with Linux and such, and I had some idea of just how ugly things got when a complex operating system powered off in the middle of doing things.

I was a little bit stressed out. The other guy, a clean-shaven greybeard, wasn't.

When the power came back on, the mainframe booted up -- quickly -- and resumed its operations from pretty much the exact point at which the power had gone out. It didn't miss a beat, none of the data it produced was erroneous.

That was in '98 or thereabouts.

To say that mainframes are more reliable than the popular alternatives is an understatement. :-)

wmf3• 16 years ago

They're powerful, reliable, and compared to writing software for an equally-sized cluster or distributed system, easy to write for.

Of course a big SMP such as System p has the same advantages (plus the greater familiarity of Unix), so in my mind the question stands. Why mainframes?

astine• 16 years ago

One major advantage of a mainframe vs commodity built clusters with similar capacity is internal bandwidth. With clusters, you are limited by your network speed. A high end ethernet based network is about 10Gbit, and you can reach higher with specialty hardware like Infiniband, but then you're no longer using commodity components. Within a mainframe your interprocess bandwidth is limited only by your bus speed. Problems that things like memcached are meant to solve are no longer a concern.

rbranson15• 16 years ago

How is Infiniband not commodity? It's not GbE cheap, but it's also a lot lower latency and 20x-40x the bandwidth. Infiniband is about $250-$500 per port, which is around what 10GbE costs right now.

wmf3• 16 years ago

Within a mainframe your interprocess bandwidth is limited only by your bus speed.

You're ignoring System p, Superdome, Altix, Beckton, etc. which are also big SMPs but are significantly cheaper and easier to use than mainframes.

mseebach• 16 years ago

So that's a $6 billion profit for keeping western civilisation open for business? I'm not sure I'm buying the premise that that is somehow unreasonable.

jacquesm17• 16 years ago

In fact, at that price it's cheap.

ugh• 16 years ago

I don’t think that’s the point of the article.

Herring• 16 years ago

You shouldn't buy that premise, because that's not what the article claimed was unreasonable.

ssp• 16 years ago

Fake Steve on mainframes:

http://www.fakesteve.net/2009/10/why-ibm-is-in-trouble-with-...

http://www.fakesteve.net/2009/10/case-against-ibm-continued....

vdm• 16 years ago

Priceless.

GavinB• 16 years ago

It's hard to think of it as a monopoly when the same services can be performed by a rack of servers running other software. For any type of data processing that mainframes perform, I'm sure you can find examples of similar jobs running in server farms.

You can't define mainframes as a separate market just because they're physically large.

jacquesm17• 16 years ago

The whole point is that you can't.

> You could perform the same services by a rack of servers running OTHER software.

But with the software that is there today the cost of re-writing it would be prohibitive and that's why the mainframe market is still as large as it is.

It's nothing to do with them being physically large.

Converting a couple of billions of lines of COBOL to something more modern, re-test the whole thing and add a bunch of magic to get the same kind of reliability is not a task any sane CTO at a bank or insurance company is going to sign off on.

sophacles2• 16 years ago

Not to mention, the system interface provided by mainframes has inherent failover capabilities. This means the cobol software is intentionally less robust in the "what happens if a part of the system fails" area, as that is something that rarely happens in a way that actually affects app level software.

gaius11• 16 years ago

Well, this is kind of "the web is the whole of computing" mentality.

You pick up the phone, you get a dial tone, not a fail whale. You put in a plug, you get electricity. When a bank's core systems go down, it makes the evening news. It's a whole 'nother world from OMG sharding RoR lol that web kids think is "scalability".

rbranson15• 16 years ago

Web companies operate in a different world entirely. If Twitter goes down, it's sad, but nobody really cares. They also don't have very much money, so running lean on development time and hardware is critical to survival. If Twitter had the IT budgets like banks and insurance companies, things would be a little different. Of course scaling isn't that hard when you have billion dollar budgets. Per byte of content processed, Twitter probably operates at orders of magnitude more efficiency than banks or insurance companies. Each byte of data HAS to cost almost nothing, or the business can't exist. Nobody would pay for social networking, so it has to be dirt ass cheap.

bitwize• 16 years ago

No. You can't replace a mainframe with a rack of x86 boxes. In mission critical applications where reliability (effectively 100%; five nines just isn't good enough) and I/O throughput are of paramount importance, System z is your only choice. These applications underpin our entire monetary system, among other things.

timthorn• 16 years ago

Yes, you can. I know of a delivered project at one of the World's major financial institutions where their mainframe was replaced with x86 hardware. The system architecture was funky, but the hardware was commodity.

Just because one x86 box doesn't have the required level of reliability doesn't mean you can't build a reliable system out of them.

ronnier• 16 years ago

What does Eastern civilization run on?

maukdaddy• 16 years ago

Redframes.

chunkbot• 16 years ago

This belongs on reddit.

jakevoytko• 16 years ago

There's no pressing reason for a company to toss its legacy mainframes. What VP would sign off on replacing core systems that run an international corporation? The downsides are infinite! I mean, are you insane? Just throw money at an "expensive" COBOL programmer and get out of my office!

I grilled an employee at a Major Package Shipping Company a few years ago about their infrastructure, and it's pretty stereotypical: a few mainframes that were coded decades ago in COBOL and an expensive team of legacy programmers performing surgical tweaks. They're porting unimportant side systems to modern hardware + languages (ostensibly so the mainframe programmers can focus on the major systems), but there are no plans to replace the core. Ever. Replacement systems just aren't good enough to consider switching the heart of their company. And so it will continue until there's a compelling storyline for dropping mainframes

mey• 16 years ago

These corporations may not see it, because they do not understand it, but having such legacy systems a risk to their operations. The longer they wait to migrate, the more expensive it will be, and the harder it will be to attract talent to the project. There may come a point where they can no longer find anyone to support their hardware or software, and it'll force them to stagnate against their competition who may be able to provide better or different offerings because they are not tied to a system they can't modify.

My understanding of business is that you should never stagnate, and always keep advancing.

People that I've talked to who have worked with such systems indicated that they built giant shims around the systems in other languages to allow them to be adaptable. In theory this gives them a clear interface definition (it may be huge, thousands of method signatures, and possible direct schema access, but it can still be a clear interface) to boot strap a core system replacement in another language and hardware system.

jacquesm17• 16 years ago

The laws of supply and demand will make sure that there will always be people available to maintain those systems. The price will go up until some 'modern' programmer is tempted enough to open a 3 decades old book on COBOL and JCL.

Your understanding of business is flawed, businesses are advancing by marketing, not by shacking up with every new hot tech that comes along in favour of their old, trusted and reliable tech.

The larger, older and more profitable a business is the more likely that they are going to be ultra-conservative about using new technology at the core of their business.

Eventually we'll get rid of this stuff but I wouldn't bet on it happening in the next two decades, unless someone finds a way to emulate a mainframe on a cluster with similar reliability. And then we still need to get rid of the software.

rbranson15• 16 years ago

He's talking about FedEx. They understand that it's a risk to their business continuity. The guy who hijacked a FedEx plane planned to fly it into their datacenter near the airport, which houses the primary mainframe that runs FedEx's most critical business software. He wasn't an IT employee either, so it's fairly common knowledge. AFAIK, they are now running in a hybrid mainframe / client+server model. Most of the package transactions are processed simultaneously. Apparently all of the tracking on FedEx.com uses the client+server system to back it. Obviously they are taking it slowly and carefully (it's like a decade-long project) to avoid any screwups.

Hoff4• 16 years ago

Don't presume that you're operating with sufficient domain knowledge to make those judgements, and don't presume that the folks that are making those judgements are ignorant of the options and alternatives.

When you're operating at the juggernaught-scale of business or with industrial-scale production, the rules and the requirements and the competitive landscapes are different.

And the risks can come not from the existing environments - which generally work - but from making the changes to the environment, and from the risks of outages and downtime.

Every vendor that can make even a tangental case for a platform or application or process migration or update or new hardware is also certainly pressing that, too; that's an automatic education for the folks involved.

If you can't process customer orders for a week or a month or can't ship orders or your outage slags a whole production line, you could well end up out of business. I know of places that have had similar meltdowns during updates and during migrations, and it's Not Pretty.

fmora2• 16 years ago

You have to remember that they use these systems to run their business and they've been tested for thousands or millions of hours so the system is extremely reliable. It is naive to suggest to switch to a newer platform or language. Those things are always changing. Also, once you are a seasoned software developer in multiple languages how long do you really think it will take you to learn cobol? Not much I can assure you. You'll probably be familiar with the basics in a couple of days, and maybe even enough to be dangerous. Switching to a platform just for the sake of switching is extremely dangerous and potentially quite costly. Especially when from the customers point of view it really makes no difference whether behind the scenes the business is using cobol, fortran, java, ruby or whatever new fad of the day. If the system is going to behave exactly the same whether you use java or cobol then what is the point of switching?

hcho• 16 years ago

The rules of the free market game says someone using cutting edge technology will come up and sweep all. Which doesn't seem to happen. So maybe, as long as it works, it doesn't matter if it's Cobol and the expensive Cobol programmer is being paid peanuts when compared to the money being made.

jacquesm17• 16 years ago

Or compared to the money that could be lost in case of a business interruption.

Some of these companies carry a downtime penalty on the order of hundreds of dollars per second. You really don't want to mess up when there is that kind of money on the line.

SandB0x• 16 years ago

Technology is irrelevant. It doesn't happen because there are so many requirements and regulations that even if you had the world's smartest hackers writing in the purest Clojure/Ruby/etc, your software would still have to contain all this horribly complicated business logic and would take years to develop.

Super_Jambo• 16 years ago

By 'the rules of the free market game' I presume you mean the Efficient Market Hypothesis.

The EMH supposes that every actor has total and correct information, every actor is rational and products are fungible.

Whilst we might approach this on say a stock exchange to imagine most companies compete in an efficient market. When so much of modern business is about branding and advertising (destroying fungiblity and corrupting actors information and rationality). Is, I suggest, somewhat naive.

Essentially modern businesses do not generally compete on product, they compete on their ability to distort the markets they're in.

rbranson15• 16 years ago

Anyone know why legacy mainframe software couldn't be emulated/compiled to run on a cluster of Linux boxes? Licensing, patents, legal concerns, etc? Obviously this is not a trivial issue, but it seems as if the amount of data we're talking about is not immense. Banks exchange and process large amounts of information, but how does it really compare to what people are doing with Hadoop or what Google does with MapReduce? I would imagine Google processes orders of magnitude more information than banks.

gaius11• 16 years ago

The simple answer is that you have to have a consistent view of the world. Let's say that 100 Linux boxes in a cluster == 1 mainframe. Let's also say you're a bank. Someone connects to node 1 and makes a withdrawal from a joint account, and someone simultaneously makes a withdrawal from the same account on node 100. How do you check they haven't gone over their overdraft unless you can serialize those transactions? And if you can, and make it scale, congratulations: you're now where IBM was in the 70s'.

It's pointless to invoke the almighty Google; they simply don't deal with problems in this class.

skalpelis• 16 years ago

I know that Google Checkout isn't a "real" financial institution but surely, I'd think those problems were of the same class - perhaps it's just that they don't have to worry about legacy problems (yet).

rbranson15• 16 years ago

Banks are actually kind of a bad example for needing synchronized processing. Banks settle transactions pseudo-asynchronously in batches. While they adjust your "available balance" as well as they can, AFAIK, transactions are officially settled in the old school, nightly batch.

Even then, there are consistent, synchronous databases that run on Linux clusters. Oracle RAC and Sybase ASE come to mind. Linux also supports hardware NUMA implementations, which allow single system image software. An emulation layer could run on top of NUMA hardware.

jtbigwoo• 16 years ago

> It's pointless to invoke the almighty Google; they simply don't deal with problems in this class

FWIW, I worked at a major bank (top 5 in the U.S.) and listened in on several discussions between their top tech guys. As mentioned in other comments, their number one worry was the supply of COBOL coders.

They were terrified of Google and/or Paypal and what would happen if one of those companies got serious about competing in the banking arena. Most of the top architects _knew_ that it was possible to build a bank on a huge cluster of servers. They also knew that there was no way an existing bank could build the infrastructure and software while also maintaining their existing infrastructure.

LaPingvino• 16 years ago

There is actually mainframe emulation, it can certainly be done. However, IBM is doing everything to keep that unattractive and with a bad image.

rbranson15• 16 years ago

I suppose what I'm talking about is a company with real biz clout (like HP) coming up with a solution to compete with IBM.

masterponomo4• 16 years ago

Not sure about running on Linux, but there are COBOL and CICS systems that run on small servers. In fact there are a whole range of mainframe-like machines (e.g. AS/400) from IBM, to support different size businesses. The amount of data in some applications IS immense. If you are managing a multi-million-account credit card portfolio on a single mainframe, which nicely supports all your realtime apps (including a 100-request per second authorizations system) and your 6-hour batch cycle, there is no reason at all to port that to smaller machines. The mainframe is marvelously stable and nowadays the whole machine rarely gets hung up (I haven't seen or heard of this happening to my company or its customers since the early 90's).

Sure, you could move those apps to a bunch of smaller boxes. Then you open yourself up to server failure, admin costs of maintaining multiple boxes, etc.

Mainframes wrote the book on SaaS long before 'net cloud computing came along. IBM and others have operated computing as a utility for years and years. What manager who gets his IT done on rented computer time is going to suggest taking the apps in-house on a bunch of servers? None that I know of.

Hoff4• 16 years ago

There can be substantial differences among what's technically feasible and what's economically feasible and what's politically feasible.

An existing environment is usually a large pile of twisty dependencies on operating system calls, on database or file formats that aren't entirely portable, on language extensions that don't exist elsewhere, on objects built from source code that's been lost, on dependencies on products from vendors that no longer exist, and it's all often inextricably linked with front-ends that would have to be rewritten, data bridges that would have to be rewritten, and users that need to be retrained.

In some cases, this effort can involve re-architecting substantial parts of a manufacturing facility that's involving six or ten buildings and that are each most of a kilometer long. And with many industrial-scale environments, change is not going to happen. You (might) see a new environment implemented when the entire production line is nuked and paved at the end of its useful lifetime, and replaced with a newly-deployed production line. In other cases, you'll probably see the existing system patched and re-used.

For many of these cases, just ramping up a load test would be a substantial effort.

Some hunks of the environment will have test cases and specs and documentation, and some hunks probably won't.

For many of these installations, substantial downtime has SEC-level visibility, or can involve exposures to various legal entanglements, or can involve re-establishing politically- or legall-mandated external certifications, or can cost thousands or millions of dollars per unit time off-line, or requires the production line to be cleaned with a jack-hammer or entirely replaced, or other issues.

If you can afford an incremental port or a big-bang port, well, what's that cost in comparison with the incremental costs of keeping the existing environment going?

C-level folks just don't blindly sign the really big bills involved in keeping these environments going, and most competing vendors seeking to acquire least part of these mainframe-scale budgets.

vl• 16 years ago

Any large distributed system barely runs on the specific hardware/OS it was designed for and required constant monitoring and maintenance. Even OS upgrade (i.e. in theory it should stay compatible and "just work") in the large datacenter takes weeks of testing and fixing. Migrating from mainframe to linux is very very very expensive. On top of that to achieve same reliability there will be a need to re-architect some software pieces.

BTW, Google needs with MapReduce are fundamentally different - it favors scalability and thoughput over correcteness vs banks that need distributed transaction consistency most of all.

masterponomo4• 16 years ago

As a 25-year professional z/os programmer working primarily in COBOL and CICS, I think the dearth of new COBOL programmers is not the big problem it is made out to be. Having learned C, Java, SQL, Common Lisp, and Scheme on my own, I have no doubt that programmers will jump to COBOL when the marketplace starts offering rewards (higher salaries) for doing so. The outsourcing trend is holding this back as companies continue to pursue the holy grail of cheap programmers, but all such efforts eventually run afoul of the need for local talent with a deep understanding of the application. A good programmer can get up to speed on COBOL very quickly. Getting up to speed on a large application? That'll take a few years.

The problem with legacy apps on any platform is not the language (unless you're talking about some very obscure unsupported language). The problem in my experience is the tangled mess of new code piled on top of poorly designed old code. In such systems, a small change can have unintended side effects. The solution is exhaustive testing (expensive and time-consuming) or a Hail Mary installation (leading to "testing" in production and yet another reactive fix). COBOL didn't create this problem and changing to another language won't fix it. In my shop, we practice test-driven development and deliver high quality releases. Success on the receiving end of these releases varies along with the established coding/testing/integration practices at each customer site.

thaumaturgy3• 16 years ago

True, except that a lot of programmers want to follow the "sexy" technology, and COBOL just ain't that.

pavel_lishin2• 16 years ago

It's amazing how sexy technology can get when someone's offering you a six or seven figure salary to figure it out.

jacquesm17• 16 years ago

It's nothing to do with COBOL not being sexy, it has everything to do with the applications.

Bookkeeping in any form isn't sexy, but it is where the big money is when you're 'just' an application programmer.

ams6110• 16 years ago

What is sexy today is tomorrow's "ancient" legacy technology. And once you've been in the business for a decade or so, you start seeing the old ideas coming around again, cloaked in some new names, with a lot of newbie fans excited about how sexy it is.

masterponomo4• 16 years ago

Working on big iron, I get to work with assembler, CICS, MQ Series, and DB2 in addition to COBOL. No, it's not flashy like web apps, but there's a certain appeal to bit-diddlers like myself. Perhaps it's the same as the difference between driving a PT boat and working in the engine room of an aircraft carrier. I would choose the carrier.

Also, Greenspun's Tenth Rule is in effect in the COBOL world as much as in any other language.

http://en.wikipedia.org/wiki/Greenspuns_Tenth_Rule

The difference in the COBOL world is that you are more likely to work with people who would not know what you are talking about if you mentioned Lisp or Greenspun's Rule, or even the word "predicate" just to pick an unrelated example. So if you are into programming more than you are into business, you can function in the mainframe world as a sort of playground for exercising your programming muscle in ways that suit you, even if your colleagues aren't aware that something different is going on.

For instance, I generate a lot of code using a Common Lisp system I wrote for my own use. No one knows or cares--all they know is they seem to get reliable code from me very quickly. If I suggested that more people use the Lisp code generator, it would not fly because it would require training and might cost maintenance dollars. So it remains a personal tool.

More: My job involves a weekly task to analyze a release while it is under development. My predecessor did this manually and took all week. I wrote a Java/MySQL system to do it, and it takes me all of 10 minutes a week. Another win for the intrepid programmer.

More out in the open, I recently led development of a rules-based system. The team did not speak rules, evaluation, predicates, or the general use of collections. The challenge for me was to design the system using these concepts, then present it to developers who will never want to learn the general concepts. Done in record time, by some mysterious process (I broke the design into small pieces w/o reference to the comp sci terms, gave each developer a focused task, and tied it all together myself).

Definitely more Sears foundation garment than Frederick's of Hollywood, but I like it.

squidsoup• 16 years ago

Given that you guys are into TDD, I'm assuming you're running Cobol on Cogs?

http://www.coboloncogs.org/INDEX.HTM

(sorry, couldn't help myself)

rythie• 16 years ago

Essentially people are locked into those mainframes. It doesn't make sense to pick them if you are starting from scratch.

I wonder if in 20 years people will be locked into the cloud systems they are investing in now in the same way.

SwellJoe• 16 years ago

This article makes me want to buy some IBM stock. But, it's never performed very well...

Kadin2• 16 years ago

Well, it's mostly factored into the price; IBM's mainframe division isn't that big a secret.

But like most "blue chips", IBM is probably a reasonably solid income stock. They have an obvious income stream (software licensing) with a locked-in market, in addition to their consulting/services divisions.

Whether or not it's too much to pay for the income (compared to similar companies with license-based revenue models, i.e. Microsoft) is the question for a potential investor. I'm not sure anyone would regard it as a hot speculative play...

zandorg• 16 years ago

IBM also makes a lot from their consulting (human mainframes).

gritzko• 16 years ago

Well, a friend of mine writes software for mainframes. Says, the platform has two advantages: customers are totally locked in and there are enormous possibilities for kickbacks (no market => no fair price => case-by-case pricing => guess what) Otherwise, the technology is totally inferior, compared to anything.

stralep• 16 years ago

Should I learn COBOL 2002, or some earlier version?

Are mainframes COBOL standard compliant?

Is there free standard document?

unohoo• 16 years ago

One of my friends who works on a Z mainframe told me that the last time their mainframe was 'rebooted' was about 4 years ago. Hows that for downtime ?

rbranson15• 16 years ago

This only works if you exclude the entirety of commodity and stock exchange business, which runs almost completely on off-the-shelf hardware. I'd say this is a pretty big part of western civilization. Of course, the I/O requirements of these systems massively eclipse that of "puny" banks, logistics/distribution, manufacturing, and insurance companies.

herdrick• 16 years ago

There are estimates that 80% of the world's data are processed by mainframes.

Pretty clueless estimates I'd have to think.

jeberle• 16 years ago

Mainframes are very good at their jobs. Where do you think virtual machines, NoSQL databases, SQL databases, etc., got their start -- about 40 years ago?

http://en.wikipedia.org/wiki/VM_(operating_system) http://en.wikipedia.org/wiki/VSAM http://en.wikipedia.org/wiki/IBM_System_R

Page at a time remote interfaces anyone?

Western civilization runs on the mainframe

Related Stories