While it's been nearly 5 years since I toiled in COBOL, I can assure you that much of the information infastructure you deal with on a daily basis still runs on legacy mainframe hardware with COBOL programs being fed your charge card data, airline reservations, utility usage, pharmaceutical claim adjudications, etc....
There are plenty of COBOL Programmers out there, the problem is nobody in IT wants to hire old people.
True. Or the "hire" would be at a rate of 50-60% of what that same programmer made previously. I still get soliciations for mainframe COBOL work and the rates and salaries advertised to me are an absolute joke.
The problem is not lack of Programmers. The problem is managers who think a developer needs many years of experience with a specific language or technology to be able to work with it. I am sure many programmers would be willing to work on their COBOL systems, but without the required "10 years of experience with COBOL" on their resume, they would never be hired.
Well, code is code, but I would caution that:
- More essential is experience with the legacy platform that those COBOL programs are running on. Are you familiar with the vagaries of S0C4 or S0C7 ABENDs? Do you JCL? Can you read an MVS dump? Do you know how to allocate a file?
- Grizzled veterans can pinpoint root cause in short order while it may take an inexperienced crew days, if not weeks, to troubleshoot a problem. It's not about being smarter, it's knowing where to look, with the cruder, less evolved diagnostic tools.
Wow, if this is a COBOL system, you mean no one took the time and energy to document the system and all of its glorious parameters during the ramp-up to Y2K? I'm shocked...SHOCKED to hear that a bureaucracy would waste such a golden opportunity as the Y2K scare to look long-term and decide that hey, as long as we're in the process of vetting code, why don't we document it as well?
And yes, there are already those out there jumping up and down pointing out that fixing a year from a two digit to a four digit format is way different than figuring out how to reprogram an ancient computer language. Gotta love the State Government, home to Silicon Valley, too myopic to even consider upgrading something as non-essential as a payroll system.
Most of the Y2K effort focused simply on alleviating eventual issues with two digit dates by "windowing". No expansion of existing database fields -- as much of the processing in legacy world on a fixed column basis, and lengthening the field was considered "out of scope" -- just a simple if statement to test if it was the 20th or 21st century. And regarding documentation, you're being glib, right? As staffs are downsized, support and application teams siphoned off to India or replaced by imported non-immigrant visa holders, documentation, which never was a top priority, has been given even shorter shrift.
This sounds like a typical "we have to re-write everything" attitude I hear from a lot of programmers who have to work with legacy code.
They have an application that calculates the salary. They don't need to change anything in the existing application, all they need is to "decorate" the app with an additional wrapper that rolls back the salary the appropriate amount.
A rather naive assertion. In legacy systems much of the business logic is embedded deep within the bowels of the code. There may be a "business analyst" who is the overseer, but they are totally reliant on somebody else who can actually read code. And it will be far from straightforward, even for a gifted wizard, as the code in question may be decades old, and littered with patches and interfaces placed on top of all the cruft.
I'll give $3 to the first person who can explain to me why on Earth you need to edit the software to change people's salary (Ok, I probably won't give anyone money even if you do come up with a decent reason). Even if they had to individually change each entry, it just doesn't make sense; if you put 100 people (seems like a reasonable number to me) working full time on the project in 6 months you have about 100,000 work hours. So they're trying to say it takes a half hour to change one person's salary? I don't care how antequated the system is, that is unnacceptable.
Somewhere, the current program is storing the salary data in some kind of file. Hire a high school CS student to parse the file, edit it, and save it back. I'm willing to bet a competent programmer could find some solution to this problem within a week. This is just the state controller trying to stick up for his employees; unfortunatly, he's too much of a wuss to do it the legal way and has instead turned to blattant lies that most people are too uninformed to see through.
Sigh. If it were that easy, it would be done already.
But this reminds me of a utility company that I worked for about a decade ago that embarked upon a mass conversion (from mainframe PL/I system based on hierarchical database with nines complement YYMM date keys TO a mainframe COBOL DB2 system). The rollover was such a mess that thousands (tens of thousands actually) of customers did not receive bills for many months, some for over a year. There was a team of a couple dozen (maybe a little less, a little more, I don't recall exactly) that spent their workdays manually editing database records for all those customers.
If your people have been saying for a very long time the system needs to be replaced, and you don't replace it, when it falls apart, that's hardly surprising.
Big corporate IT is trying to move away from these dinosaur systems but these project efforts have been colossal nightmare death walks, doomed from the start, and even when implemented years after the planned install date, too feeble to accomodate business needs, compared to the legacy code that is handling the job.
Additionally, most of the expertise on these systems is in India now, or in the heads of imported non-immigrant visa workers. The few Americans that have experience assume the role of "subject matter experts", manning bridge calls when things break, supervising the offshore/onshore vendor supplied programmers, writing emails to explain to their code clueless bosses what broke and who's fixing it, etc....
