Slashdot Mirror
Retired Mainframe Pros Lured Back Into Workforce
itwbennett writes "Businesses that cut experienced mainframe administrators in an effort to cut costs inadvertently created a skills shortage that is coming back to bite them. Chris O'Malley, CA's mainframe business executive VP, says that mainframe workers were let go because 'it had no immediate effect and the organizations didn't expect to keep mainframes around.' But businesses have kept mainframes around and now they are struggling to find engineers. Prycroft Six managing director Greg Price, a mainframe veteran of some 45 years, put it this way: 'Mainframes are expensive, ergo businesses want to go to cheaper platforms, but [those platforms] have a lot of packaged overheads. If you do a total cost of ownership, the mainframe comes out cheaper, but since the costs of a mainframe are immediately obvious, it is hard to get it past the bean-counters of an organization.'"
As early as 2002, I started to half-jokingly tell young co-workers that were asking that they should learn COBOL as a way to insure them a prosperous career. ;-) Back then, most schools were removing or had removed COBOL programming from their course list.
I was half-jokingly telling them that by 2015 they should be earning 150-200K a year as a simple COBOL developer ;-)))
See this article from last year saying basically the same thing :
http://www.computerweekly.com/Articles/2008/08/07/231774/cobol-programmer-shortage-starts-to-bite.htm
Note: I am to old to start to learn COBOL, this is stuff for young people... ;-)
Everything I write is lies, read between the lines.
I speak COBOL, FORTRAN and can do Job Control Language like an old pro, oh wait.
I also program in IBM 360/370 assembler. I'll bet that is almost a lost art.
I learned and taught cobol for awhile, and i can say that cobol is not too far from data entry. It is way too much work to do simple things, and it is way too weak of a language for most things. Its functionality is low that it takes a lot of code to implement simple things. The compiler gives you weird error messages. The language is archane. It is a very miserable language to write in, and I wouldn't code in it for less than several hundreds of dollars per hour, just because its so boring and takes way too much typing to do simple things that would be a snap in other languages.
If recruitment would be any easier if the offer included the right to shout "Where is your 'right-sizing' now, bitches?" into the face of the nearest PHB at will, in addition to the fat salary?
The Mainframe does it job and does it well. Nothing comes close in Data Throughput Processing with the amount of reliability that a mainframe brings.
Computer 'Experts' have been saying that the mainframe is dead since the early 90s, but here we are 20 years later and I still have a job programming for it, and I don't see it going away anytime soon. Small to mid-level servers just don't have the capacity to deal with the growing about of data generated. Fedex does in the neighborhood of 2 billion transactions a day, you cant just wipe together a Beowulf Cluster and think it will do the job reliably.
Or the better question is. How much do you trust the Federal Reserve to run all its processing on Windows machines. Or Wall Street. Ever consider if a transaction there is 'lost' because a windows blue screen? Even linux machines arent as dependable as a Mainframe. The IBM Z boxes actually have their own redundant parts included in them already. Not to mention that it will phone in its own tech support request.
Mainframes are not for everyone, but they do fulfill their job well when you do need them.
There are also enough tools out there like SOA so that even Java "Kids" can write applications for them easily.
Mainframes run the world.
Easier said than done, matey. Some of these systems are running engines that cause me to cower. I have had issues with SQL/Oracle databases and the financial apps of companies that can afford a few hours, or even days downtime. Systems where it was feasible to run two separate versions at once with duplicate data entry.
I've only run theoretical experiments with some of the systems in other companies I've worked at that COULDN'T go down, except for very special periods of time (easter and christmas and new years), oddly enough, enough of the world isn't working those weekends that you can shut down.
I can't imagine taking down the backends of the likes of Bank of America or Citibank. I lived through the quagmire that was the BankBoston/Fleet merger, and they fucked that up royally. And that's just merging systems, not wholesale replacement.
Good F*ing Luck to you.
We were just discussing VAX at work. I personally never got to work on one, but a guy I work with grew up learning on them. He said only guys his age really knew much about VAX and I said he was wrong as several guys I grew up with worked at banks that used them.
Mainfames are like Cobol, they aren't going away until the systems that use them die.
Uh, why?
Mainframes are fucking rock solid, reliable pieces of equipment.
They do the damned job like nobody's business.
The only issue with mainframes is that we haven't kept the people along with the software we chose to run on them decades ago.
from BSG: "Any return to COBOL will exact a price paid in blood."
O'Malley said in 2000 there were more people in system programming than there are today despite the workloads having quadrupled which is quite an anomaly.
This is an actual sentence from the story. I guess reporters don't need to learn how to use clauses, and editors don't edit.
If E. B. White were alive today, he'd be spinning in his grave.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
There was a programmer back in the 1990's that didn't want to mess with the whole Y2K issue. So he cryogenically had himself frozen, hoping that some day (after Y2K) he would be revived and live out his days peacefully.
Some years later, sure enough he wakes up. Asking the nearest person what year it is, they reply, "It's the year 9999 and we need a COBOL programmer to help with this Y10K problem!"
Yeah, it's an old joke. Now GOML!
Odd by today's standards.
No flow-of-control stack. No local variables.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
I went from UNIX in the late 1970's to mainframe zOS (MVS/OS) to VM and Linux on the mainframe. Anything you can do on an Intel box (or a room full of them), you can do on a mainframe, cheaper and more reliably, once you get past the first big financial hit. I've seen the so-called cost studies that supposedly show the room full of Intel white boxes are cheaper. Once you factor in the "unseen" costs, like the article says, and get past the startup, the mainframe looks VERY good.
Current mainframes aren't what people remember from the past. They're (physically) small, agile, and well suited to certain workloads (can you do 256 concurrent DMA transfers on an Intel box?). The problem is, the only companies that seem to be able to justify them for new workloads are ones that already have them for legacy work. IBM hasn't shown much interest in the low-end of the market (sell small boxen, then discontinue them, push licensed emulation, then kill it, etc).
Our biggest problem is finding people who know the technologies. I give classes to our Linux SA's on this, and they're usually surprised at what the current zSeries boxes can do.
Don't misunderstand, there are plenty of applications where Intel boxes make sense, I work both sides of the fence. I just hate to see mainframes maligned as "obsolete" by people who don't understand what they are now.
If I had to pick hardware and software as if my life depended on it - it would be an IBM mainframe with the latest and greatest version of MVS (or whatever the current name of it is) on it.
You not only have to know the application field pretty well (or have the bent to intuit it), but you will have to get used to living without local variables and to a one-call-deep call stack.
Don't ignore the naming conventions. It's what they do to work around the lack of re-entrance.
And never, never, never try anything fancy. If you can't keep the state machine in your head, trying to debug it interactively will eat your lunch and your breakfast, dinner, and midnight snacks, as well.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Also from the Tao of Programming: The Tao gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are ten thousand languages. Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao. But do not program in COBOL if you can avoid it.
There realt isn't a reason to "restart" an IBM mainframe. LPARS are IPL'd every few months if there is a major PTF or such going in. But that only happens a few times a year (depending on your use of the system). I've got 30+ years in on them and their reliabilty is incredivle In the past 7 years we've had 2 unscheduled IPLs that I can remember. Here is our next upgrade, scheduled to be put in in 2 weeks: http://www-03.ibm.com/systems/z/news/announcement/20080226_annc.html
That would be the first time our mainframe has been completely shut down in years. The disk drives need to be recabled for the upgrade. And for those who want a car analogy, I don't have one. But I view the mainframe as a 747, *NIX as fighter jets, and Windows servers as prop planes. They all fly, but all have different purposes.
I have been tracking worldwide server revenues for a few years. Over the past 2-3 years the market share between Mainframe, UNIX, Linux and Windows has been very flat: Windows 40%, Unix 35% Linux 14%, mainframe (ZOS) 11% (IDC Worldwide Server Revenue marketshare).
Quarter Windows Linux UNIX ZOS
02/06 34.20% 12.60% 35.00%
03/06 34.40% 12.40% 34.20% 11.30%
04/06 34.90% 11.40% 33.50% 11.40%
01/07 38.80% 17.00% 35.00%
02/07 38.20% 13.60% 31.70% 9.50%
03/07 40.40% 13.40% 31.10%
04/07 36.60% 12.70% 33.20%
01/08 39.20% 13.70% 30.60% 8.40%
02/08 36.50% 13.40% 32.70% 11.80%
03/08 40.80% 14.00% 29.70% 9.40%
04/08 35.30% 13.60% 36.20%
01/09 37.30% 13.80% 33.10% 9.00%
ZOS is not always reported in press releases and I don't purchase the IDC report.
Looks like neither Mainframe or UNIX is dying, or that Linux is dominating.
...If you do a total cost of ownership, the mainframe comes out cheaper, but since the costs of a mainframe are immediately obvious, it is hard to get it past the bean-counters of an organization.
I've found this to be true of many aspects of IT, not just concerning mainframes. I've watched customers struggle to get decent performance and constantly hit limitations with a certain database product (not Oracle) because it was virtually free and they didn't want to spend the capital cost on an Oracle license. The total man hours spent, time lost, etc on getting their "free" db up to speed vastly exceeded the cost of the Oracle licenses and they still have problems with it.
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
I've long been sold on mainframes, but they suffer from a scalability problem - they don't scale down that far.
Here I am, at a small, organically growing company. We've been growing about 25% - 75% per year, and with the economic slowdown, our growth has accelerated. (since we save our prospective clients money) We're too small to afford mainframes. We have about $50,000 invested in our primary hosting hardware now.
We are having to bust some humps to keep up with this year's growth. We've hit the performance wall of single-system limitations, and have been working furiously on full redundancy and clustering our databases and system stack, based on CentOS Linux, heartbeat, Postgres, and lots of application-level coding. (I turned it all on in production just 3 days ago!) We're still working out kinks with load balancers, round-robin DNS, dynamic database host selection, backup validation, network monitoring, and other similar issues. Mostly though, it's been going quite smoothly.
If our company continues its growth rate, in a few years, we'll be of a budget and company size that a mainframe or three just might be a good idea - but at that point, we'll have invested enough in our current redundant clustering technology that we'll be architecturally unfit for adopting mainframes whole-hog. Instead, we'll have racks and racks of small, cheap, multi-core commodity 1U servers built with network-level redundancy and auto-failover. Not because it's the best for large scales, but because it's the best that we can afford now, and as we grow, we'll add to what we have rather than re-invent the wheel.
If they made mainframes that could scale down to a price comparable to a $1,000, cheap, 1U SATA Linux server, (where my company started years ago, though we've long moved on) and could scale up seamlessly to big iron, that would just rock.
The closest equivalent I'm aware of right now is using IBM's ZOS to host virtual linux hosts, which strikes me as inefficient, even though that's where my development path just might leave us. But I don't know anything about it, and we're too small for anybody to bother (timewise) with, even if we are a million-dollar/year company.
Are you listening, mainframe vendors?
I have no problem with your religion until you decide it's reason to deprive others of the truth.
But I bet google loses lots of data. They certainly have had massive amounts of down time (by main frame standards).
search from 2 places, different results. They don't have highly critical data, so they can sloppily store and syncronize as needed. A liberty that Fedex does not.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Please define "revenues" as I haven't paid anything to install Linux on any of my Linux servers... EVER. Conversely, this year alone I have spent around $25,000 on various Windows Server licenses.
Does this mean that Windows has 100% "market share" in my server rooms?
Mr. Balmer go back to bed, you can count your stock options tomorrow to feel better.
google "32 trillion offshore needs IRS attention"
Finding people who know how to properly use oracle is a real bear. Sure, you can hire people with oracle experience, but most of them were the 'corporate DBA' types who don't know how to do anything out side of the script. I can't tell you how many clients I've seen struggling with their oracle installs; either because the system does not perform as promised, or because the 'cluster' needs to be rebooted every time one node crashes in an unexpected manner.
Now, I'm just the Linux janitor, not a DBA, but when I see those problems on MySQL or PostgreSQL, I can fix them. I've replaced more than one MSSQL database with a MySQL setup, and often see orders of magnitude speed increases that I suspect are due to misconfiguration of the proprietary database. The open-source stuff is just plain easier to use, at least for Linux janitors like me, and has better support.
I'm sure Oracle and MSSQL are both fine databases if you know how to use it and you configure it correctly; I'm just saying that paying a lot of money doesn't relieve you from needing to know those things. You still need to pay for a technician who actually understands it. The advantage of the free (as in freedom) products is that there are a whole lot more people with real (that is, non-scripted, where you need to do something new or are expected to solve a problem beyond 'reboot and apply the redo logs') experience with the free databases than with multi-million dollar oracle installs, and that sometimes your expensive support people just shrug and say 'I don't know. why don't you upgrade your linux kernel.'
Sticking with the free stuff, using a search engine such as google gets you pretty good support for commonly used free software. Often better support than what you get when you pay lots of money for support.