Slashdot Mirror
3 Open Source Projects For Modern COBOL Development (opensource.com)
An anonymous reader writes: While Grace Hopper's contributions to computing are remembered, celebrated, and built upon by her successors, COBOL itself is often dismissed as a relic of earlier era of computing. To a certain extent, that is true. Most of the COBOL being written today is for maintaining legacy code, not starting new projects. However, the language is still being updated, with COBOL 2014 being the most recent standard for the language, and there are still plenty of opportunities to apply for jobs that require COBOL experience. In an article on Opensource.com, Joshua Allen Holm highlights three open source projects that are keeping the language alive.
I work in a decidedly legacy field -- airline IT. I'm not a mainframe programmer, but I do work a lot with these systems and see what it takes to care for and manage business-critical processes. I certainly wouldn't recommend learning COBOL as a primary skill these days, but having some diverse systems experience is useful. I have been very lucky and have been able to steer my IT career into very "cross-platform" companies that has given me tons of knowledge that I otherwise wouldn't have. It can't hurt to at least have some familiarity with different technology; I've gotten interviews and jobs simply because I have at least seen a few systems that employers have used and needed someone with a passing knowledge of.
Hanging out with mainframe guys, I hear the contracting job market is actually semi-decent. It's shrinking and not stable by any means, but people who really know both systems programming and a business domain can make tons of money on contracts. The problem is that, for better or worse, companies are stuck with the mainframe for quite some time to come. Ancillary stuff is being migrated off to save on processing -- IBM leases you the hardware and charges you monthly by the MIPS to use it. However, for a lot of companies, decades of business logic is buried in the core transaction processing code. Their choices are to try to pull all this COBOL logic out into something Java-y or just keep it running. Often, keeping it running is seen as cheaper and less risky. In particular, the airline stuff I work with has layers and layers of upstream stuff relying on the base system never changing. The systems integration work that will be needed to eventually pull this stuff out into a different environment is going to be enormous when it does happen, and it will be a fun project for the right kind of insane people.
That said, CIOs and the like are always trying to get rid of or offshore mainframe work. It's seen as legacy crusty stuff, not sexy like phone apps and the like. That contract market I talked about often has work for seasoned mainframe guys to come back and fix the disaster that HP or Tata or Infosys made when they took over mainframe operations, often the same people the company fired. There are also the "onshore hand-holders" that help the offshore guys when things get crazy. Regardless, there will always be pressure to get off the mainframe, and the workforce is retiring right now. The move will happen one day, but it will be extremely painful for some companies and industries. So, having a tiny bit of experience, even if it's "I've seen this before" kind of experience, can be useful in the long run. Not all of IT is exciting or cutting edge -- there are plenty of systems that are just -there- and just have to run.