Tuesday, July 15, 2008

You WANT to Program the Mainframe!

I started out in the IT field learning the fundamentals of application design and development on a Radio Shack TRS-80 Microcomputer with a cassette tape drive - Woo Hoo! My next hands-on experience was as a student, leaning the basics of business computing on a Sperry-Univac 90/30. This mainframe system ran at the blazing speed of 0.5 Mhz and had 8K of RAM. That's 'K' as in 1024 bytes. We typically buy RAM in Gigabytes, 'G', as in 130,000 times more. My current laptop operates at 2 Ghz; 4,000 times faster. So my laptop, built in 2008 is significantly more powerful than my 1973-era mainframe.

Clearly the future belongs to smaller personal computers and their bigger cousins, servers; right?. Programmers graduating from two and four-year programs want to develop web services, service oriented architectures, object oriented applications, applications with cool user interfaces, and, of course, work on meaningful projects - so the mainframe is magnus-calculus-non-grata; right?

Ask any new programmer if they would like to work on the 'big iron' and very few, if any, will assert to the positive. You are more likely to get a snicker and an eye role, than any form of civil communication. And yet, there are some real reasons why programmers entering the workforce, or even experienced developers should consider a mainframe-based career.

First, the mainframe is not going away. Rumors have abounded for years on this topic and in fact, these same prognostications led me to enter the world of distributed computing 27 years ago. Talk about dinosaurs, stone knives, and bear skin rugs! We've come a long way with personal computers, servers, and mid-range systems, but remember, mainframes had a 40 year head start - and they haven't stood stagnant lo these past few decades. So the mainframe is a vibrant, growing technology stack and represents a solid career path for as many years into the future as anyone can predict.

So instead of asking "Do you want to program the mainframe?" ask a question like, "Do you want to work on the most important applications requiring the highest level of reliability, performance, security, and visibility?" "Do you want to be able to analyze, process, and mine more data, faster, and more often than ever thought possible?" Consider this, with Parallel Sysplex technology, you can combine the processes of up to 32 z/OS systems, yet make these systems behave like a single, logical computing facility. What's more, the underlying structure of the Parallel Sysplex remains virtually transparent to users, networks, applications, and even operations. Let me be clear - this capability is even transparent to the developers. Imagine writing an application that could run on/across 32 mainframe systems as if it were one super large system running billions of instructions per second.

You may say, "We can do that with clusters of servers and a grid computing model.", and I'd say well - partially. You cannot do it transparently to the application; you have to specifically design the application to take advantage of the grid - no trivial feat. And even if you did you'd still under perform the mainframe's input/output processing. No, the reality is, if you want/need raw horsepower including I/O that is well managed - you cannot beat the mainframe.

How about this - do you care about the environment? I don't mean are you a tree-hugging, business-hating, log cabin living eco-focused tofu eater. I simply mean, do you care at all? David Anderson, an IBM green consultant says "A single mainframe running Linux may be able to perform the same amount of work as approximately 250 x86 processors while using as little as two to ten percent of the amount of energy." IBM's new z10 is the equivalent of nearly 1,500 x86 servers, with up to an 85% smaller footprint, and using 85% less energy. According to Morgan Stanley, energy now represents 44% of the total cost of operating a data center.

So if the raw power impresses you and the Green IT message resonates, all that is left is the visceral degradation you associate with ... here it comes, say it with me... COBOL. The Monty Python of programming languages (I'm not dead yet, I think I'll go for a walk). Each and every day there are more COBOL programs executed than there are web pages viewed on the entire Internet. COBOL is here, but that doesn't mean a mainframe career is necessarily entrenched in MOVE, PERFORM, Working-Storage, and Filler Pic X(9). How about architecting, building, and managing the company's hundreds of service-oriented CICS-based transactions all exposed as real honest-to-goodness web services? All exposed and available at the highest speeds, in the most reliable environment, eco-friendly, and time-tested. These are the routines upon which the company, our customers, and your paycheck depend.

I'm not suggesting that there aren't any distributed application of importance - surely there are. Most of them happen to be fed from information and transactions running on the mainframe. Here's a killer, on the topic of straight performance, according to Forrester, COBOL still outperforms J2EE in a direct function-point versus function-point comparison.

Today's mainframes require as many diverse skills as you would find in the distributed environment. In fact, with WebSphere running on the the 'z', all of the distributed development technologies including Java, J2EE, HTML, CSS, Javascript, and XML are in play. But so are CICS, DB2, IMS, VSAM, and a host (pardon the pun) of other technologies upon which one could build a long, dynamic, lucrative career. And given the maturity of the environment, it's a career where you'd be inventing things, not re-inventing them.

Follow by Email