Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Open Source Programming

3 Open Source Projects For Modern COBOL Development (opensource.com) 75

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.
This discussion has been archived. No new comments can be posted.

3 Open Source Projects For Modern COBOL Development

Comments Filter:
  • by pla ( 258480 ) on Tuesday October 13, 2015 @10:09AM (#50717707) Journal
    "A modern computer without Cobol and Fortran is like a chocolate cake without the ketchup and mustard"

    (Source unknown).
    • I've often wondered if jobs for more obscure languages (such as Cobol) pay more. Any idea what a Cobol programming job typically pays compared to a C/C++ job?
      • Note that these jobs pay more not because of the rare expertise required, but for the suffering and mental damage they inflict!

      • by Anonymous Coward

        COBOL does pay a lot, but the posts are very rare and in fields the average C/C++/VB coder never gets to touch, i.e. legacy financial batch processing. Plus the locations are invariably corporate headquarters where the mainframes are located.

        • Plus the locations are invariably corporate headquarters where the mainframes are located.

          Why? So they do not have to carry the punch cards so far?

          Most COBOL programmers have an ocean between them and the mainframe since most of those jobs have been off-shored. I have run COBOL programs on half a dozen mainframes, and only one of them was less than a mile away.

      • From what I know, they pay more as there are fewer qualified applicants around. However, while there are some legacy systems, most of them are slowly being replaced with more modern ones. "Slowly" is the operative word here. Normally, the systems are being scheduled to be replaced around the retirement of the COBOL programmers that maintain them.
      • Depends on what you think your soul is worth.

      • I can't give you numbers, but my next door neighbor does COBOL consulting. He just remodeled his already-nice house and bought a convertible.
      • For a settlement agreement we had to look at old cobol and data stored on tapes. We got paid $500/hour
        • "For a settlement agreement we had to look at old cobol and data stored on tapes. We got paid $500/hour"

          Yes, we know. An anonymous precog already warned us.

    • "A modern computer without Cobol and Fortran is like a chocolate cake without the ketchup and mustard"

      As Scott Colvey, a writer for The Guardian wrote in 2009, ''Cobol is to business what the combustion engine is to motoring: it has been around so long, and installed in so many places, that doing something different would be impossibly costly.''

      Eighty percent of the world's daily business transactions rely on a 59-year-old programming language called Cobol, short for "Common Business Oriented Language." Global commerce depends so much on Cobol that if its' 220 billion lines of installed code were mysteriously erased business would be catapulted back to the "B-Commerce" era.

      As in "barter."

      If you run hardware long enough, it breaks. If you run software long enough, it works. Cobol works. As the CIO of a Fortune 350 firm who requested anonymity because he didn't want to be associated with a story about Cobol, told me, "Cobol is the most extraordinarily efficient programming language ever written."

      Cobol Is Dead. Long Live Cobol! [wsj.com]

      [Oct 2. 2014]

      • As Scott Colvey, a writer for The Guardian wrote in 2009, ''Cobol is to business what the combustion engine is to motoring: it has been around so long, and installed in so many places, that doing something different would be impossibly costly.''

        Let's see, now. The combustion engine would be extremely costly to replace, but in the mean time it's burning through non-renewable resources and irrevocably destroying the planet's life-support system. Yup, the analogy holds!

    • You shouldn't make fun of the Lords of Cobol or you'll be ejected from the Twelve Colonies and banished to an abandoned asteroid with only a malfunctioning daggit for company.
    • I've never even used Cobol or Fortran but that kind of makes me want to find or a chocolate cake recipee that actually uses those things and yet comes out good. Just to be difficult that way.

  • Yes, Visual COBOL is a real thing: http://www.microfocus.com/downloads/visual-cobol-23-datasheet-215624.aspx

    According to MF, '...supports Cloud, mobile, .NET and JVM, and a wide range of the latest environments.", so go out there and build your next Web 11.0 (we're up to that by now, right?) app in COBOL*

    * MF is not responsible for any resulting substance abuse or psychiatric issues you may experience

  • by NoNonAlphaCharsHere ( 2201864 ) on Tuesday October 13, 2015 @10:21AM (#50717813)
    How about instead we pound a wooden stake through its heart, burn the body, salt the ashes, apply holy water, weld it into an iron urn covered with runes and annointed with the boold of seven virgins and bury it at a crossroads under a full moon?
    • I'm all for that, except I'll keep the seven female virgins thank you very much.
    • by darkonc ( 47285 )
      But why? It's like replacing the Brooklyn Bridge. The thing is big, and kinda clunky and nobody would ever make something that looks like that today. ... but it's just way more expensive to replace it than it is to keep it working. That's why it's still here.

      I personally swore that I'd quite before I took on any significant programming in COBOL -- but that doesn't mean that I'd turn my nose up at someone who was willing to take on the task. As a general case, I'd apply this rule about current COBOL code

  • by Anonymous Coward

    GnuCOBOL: it translates COBOL into C and GCCs it into software. I'll skip the whole COBOL stage personally.

    OpenCOBOLIDE: it's like notepad but with COBOL highlighting rules.

    NodeCOBOL: it uses GnuCOBOL to splice the generated C-code into Node.js based programs.

    These won't keep COBOL alive or anything like that, but they might serve as a way for experienced COBOL programmers to keep using their skills for things other than maintaining old awkwardly written mainframe software.

    • by oh_my_080980980 ( 773867 ) on Tuesday October 13, 2015 @10:35AM (#50717939)
      "awkwardly written mainframe software"

      Glass houses....considering how poorly written apps are, you really want to use that canard. Mainframe programmers were real programmers - not today's cut & paste hack jobs.

      FYI there's nothing wrong with using COBOL. It fills a need that other languages have not been able to fill.
  • by xxxJonBoyxxx ( 565205 ) on Tuesday October 13, 2015 @10:33AM (#50717929)

    >> three open source projects that are keeping the language alive

    Open Source ain't keeping COBOL alive. It's IBM. If all those legacy apps could be ported off the mainframe and run at scale, they'd potentially lose billions of dollars.

  • by jacobsm ( 661831 ) on Tuesday October 13, 2015 @10:40AM (#50717973)

    If all COBOL code suddenly stopped working, well, how are your stone knives and bearskin making skills? Banks, insurance companies would fail, and then goes the rest of the interconnected economy.

    • Banks, insurance companies would fail, and then goes the rest of the interconnected economy.

      I don't think so. Banks and insurance companies mostly run on Java. They began switching away from COBOL decades ago. Few applications are still in COBOL, and even fewer of those are mission critical.

      • by jacobsm ( 661831 )

        Banks, insurance companies would fail, and then goes the rest of the interconnected economy.

        I don't think so. Banks and insurance companies mostly run on Java. They began switching away from COBOL decades ago. Few applications are still in COBOL, and even fewer of those are mission critical.

        You're so wrong. Google "amount of COBOL used today" you'll see the real story.

        "IBM estimates that more than 200 billion lines of COBOL code are still being used across industries such as banking..."

      • They began switching away from COBOL decades ago.

        I was working in banking wire transfer those "decades ago". Plain and simple, you are wrong. Mainframe code was thoroughly COBOL on mostly MVS systems with not a thought of migrating to other machines or languages. Wire transfer was COBOL with other code being machine dependent. Many larger banks not using mainframes for it used Tandem [wikipedia.org] machinery - COBOL, Tal, Tacl, with little or no Java except some terminal interface (even then, minor).

        Few applications

      • Our main policy administration system is written in COBOL along with several others. Little to no Java.
  • People still use Visual Basic and Java in their most recent incarnations, so why shouldn't we have modern versions of other terrible languages?
    • People still use Visual Basic and Java in their most recent incarnations, so why shouldn't we have modern versions of other terrible languages?

      No reason to insult Cobol in such a manner and put it on one level with Visual Basic and Java.

    • by obsess5 ( 719497 )

      When I got seriously interested in computers back in the late 1970s, among the first books I read were the late Daniel McCracken's books on Algol, Fortran, and his classic on COBOL. I actually used Algol (NU-ALGOL) in our file processing course at the University of Maryland (my fellow students used Fortran-66) and COBOL for our database course circa 1980 (to create and access network databases--Codasyl?). COBOL wasn't bad and certainly wasn't terrible (like Java, I'll agree!). Although my favorite langua

  • by kjs3 ( 601225 ) on Tuesday October 13, 2015 @10:54AM (#50718085)
    No open source project is keeping Cobol alive. The Cobol world is barely aware of open source. Cobol is being kept alive by the billions of lines of code that do things like get you your paycheck or process your insurance claim every day.
  • by ErichTheRed ( 39327 ) on Tuesday October 13, 2015 @11:04AM (#50718163)

    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.

  • by hmadrone ( 1411481 ) on Tuesday October 13, 2015 @11:08AM (#50718195)
    I had the typical ignorant disdain of COBOL until I actually worked with some. Over a short period of time, I developed respect for the language and for the disciplined, methodical programmers who wielded it. We could learn much from reading old COBOL programs, particularly for web forms, where a modern form of COBOL would be a lot more readable and maintainable than the krufty PHP and JS that infests the web.

    One small example is the COBOL institution of edit masks, which were invaluable for handling form input and output of things like phone numbers and credit card numbers. COBOL's edit masks were simple to use, readable and understandable, and powerful enough to cover common business cases. No modern web language has anything that approaches COBOL's elegance in this area, which is why entering your credit card on a web site is slow and tedious.
  • "GnuCOBOL GnuCOBOL (formerly known as OpenCOBOL) is a modern, open source, COBOL compiler. It works by translating COBOL code into C and compiling the code using GCC. "
  • by Anonymous Coward

    Those who fail to learn from history are doomed to repeat it.

    No single saying exemplifies IT or programming as much as this. When I was young I thought I was a hotshot and there was a gray hair telling me I'm not doing anything new. Now I'm a gray hair thinking the same thing and I've seem many things implemented and reimplemented in newer languages. It's a bit disheartening the lack of creativity. Essentially, if you don't think you can't learn anything from COBOL, you should probably get into ma

  • I tried to guess before reading. At least one of these projects should be f COBOL compiler. Yes.
    There are more FORTH implementations in the world, than useful programs, written in FORTH.

Beware of all enterprises that require new clothes, and not rather a new wearer of clothes. -- Henry David Thoreau

Working...