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.
And don't forget that in COBOL, not only is all of your data global to your program, in a typical batch cycle all of the data is global to ALL of the programs.
I used to hate discovering that field XYZ was being modified in jobs that were completely unrelated to XYZ, because the programmer was too lazy to check the appropriate code out of the repository. "Why bother? I can make the change right here and it'll work just fine!"
My favorite line was "Being on a COBOL dev team is like living in a dorm."
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 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
They weren't all running in one memory space -- they were all running on one common set of files. For example, you might have a system that accepts 15 files from various other systems, processes those files against a set of master VSAM files and/or against a database, and then creates a set of 15 files that get sent out to other systems. The system itself consists of a series of JCL jobs. Each job consists of multiple COBOL programs and utilities. It's just like bash, except in a way that's nothing at all like bash....
But because any program which opens a file can change any data contained in the file, it's tempting to make tweaks wherever it's handy. Nobody claims it's good practice, but these systems have been under constant tweaking for 30 or 40 years by dozens of programmers. After the first decade nobody even knows what the programs were supposed to do in the first place. (Especially since they have names like AB1243A, where 3 of the 7 characters identify the application, leaving only 4 characters to describe what the program does.)
So the typical bug-hunt consists of noticing that a field has the wrong value, and then checking each individual intermediate file from start to finish to see which job changed it. And if you're on a system that doesn't save its intermediate files it means running all the jobs one step at a time to see where the field gets modified. And THEN you have to open the program and find out what it's doing and why.
It's not all that different from any other system that has data which is shared between various components, but somehow solving the problem using TSO makes it all seem so primitive.
(XEDIT is one of the best text editors I've ever used, though.)