5 ms·

The Inevitable return of Cobol

37 points by rvivek 11y ago

code_chimp 11y ago
I had no problem with Cobol back in the day, it was a fairly easy language to use once you got used to it. The main problem I have seen is the utter crap way its programmers were treated after the whole Y2K thing was over with. Why would anyone want to walk into a job like that when they can learn Rails and be a 'Rockstar' or any other web-based offering and at least be treated like a valuable commodity?
- cgh 11y ago
  Money. As the article states, Cobol programmers have higher starting salaries and I expect this will only increase.
  - PaulHoule 11y ago
    I might code COBOL for a defined benefit pension, but not just for more pay.
  - tolle 11y ago
    I started a CS-degree some 10 years ago. Focused more on the partying then the studying. Got my shit together. Took a COBOL class and my entry salary is way higher then full fledged masters in CS is. And the job requires no overtime at all. None of the risks you sign up for with a startup. Great benefits in lower interests on mortgages, great pension plans, lower retirement age and job security. And things I learn today will be just as relevant years from now. So no need to keep up with stuff on my spare time. Well I had some work experience as a developer from a startup doing web stuff.
    - sliverstorm 11y ago
      And things I learn today will be just as relevant years from now. So no need to keep up with stuff on my spare time. Isn't that such a weird feeling when you're in tech? :) I am not a COBOL programmer, but I imagine taking a COBOL gig is like stepping back in time to the days of IBM, mainframes and suits at the office.
    - the_af 11y ago
      I worked with COBOL during the Y2K thing. Forget for a minute about the (very valid) downsides of startups: COBOL development in institutions such as banks is utterly boring. If, like me, you got into computers because you were fascinated by programming, run like hell from COBOL and forget the money argument. Run like hell whenever someone tells you "it's not that bad", like in the article. Nothing good can come from something introduced as not being "that bad". If you're in this mostly for the money, then sure, learn COBOL.
      - kbenson 11y ago
        Or, use COBOL to pay the bills while you work on your hobby or startup on the side. Having a steady job that doesn't require overtime is sadly often underrated by our industry, but it provides quite a bit of flexibility of its own. Then again, being stuck in crappy, uninspiring code all day and then getting to use something interesting and exciting in your off time can sometimes make the day job all that much harder to handle...
        the_af 11y ago
        Yes to your second part. Working with COBOL at a bank was soul-crushing to me. I think the combination of COBOL+bank is deadly: obsolete, boring technology combined with an utterly conservative environment, unwilling to take risks. I fully agree that no overtime is great -- that's why I'm not arguing anything about startups! -- but when you realize how many hours a day you spend in your day job, working with something that sucks cannot be compensated by a hobby. For me, at least. I fully understand someone could find the trade-off acceptable.
        TylerE 11y ago
        That's a great recipe for burnout. Coding 12+ hours a day isn't healthy.
        kbenson 11y ago
        I think it depends entirely on how you view your off-time work. I used to be fairly active in developing for the Roku with a friend, and 2-3 times a week he would come over and we would work on our Roku app(s) for 3-5 hours. It felt very much like hanging out with a friend screwing around in the garage to build something, and usually left me feeling more energized than tired. I've also done (and am doing) the solo hacking on startup stuff. Getting motivated for that can be really hard.
    - tolle 11y ago
      I still fiddle around on my spare time with modern tech just for fun. I just don't have to learn every new "tech of the week" to stay relevant. But yeah, suits some better then others. I'd imagine it's the perfect area to work in if you have kids or such. Finance is however a huge field on its own. And a huge part of the work is implementing new regulations. If I end up getting bored, I know multiple other languages quite well. And if I decide to leave the finance sector, having a job as a developer on a bank is a positive thing here.
deleted 11y ago
[deleted]
steven777400 11y ago
We have quite a bit of COBOL and are seeing a similar challenge recruiting and maintaining COBOL developers. We're in talks to partner with a local workforce education center to put together some training for potential or existing employees who might be willing to transition into a COBOL role. I'm imagining that these folks would be non-programmers who are identified as having good reasoning and structural thinking, and who could receive a pay bump by moving into a development position. I don't expect that existing developers would want to move away from their current skillset trajectory and I think that route is probably not a fruitful one to pursue. It remains to be seen if this will be a successful endeavor.
- Shivetya 11y ago
  We have had a similar issue getting good talent in regards to RPG (RPGLE) on the iSeries. One issue is the language has progressed a lot and that leads to having to bring otherwise qualified candidates up to speed. Throw on that having to adjust to our standards and idiosyncrasies. We do maintain a decent amount of COBOL on the z at the same time. Take both languages and their similar platforms and throw web interfacing, transformation, and such, and you can end up training even those who know the basics. With RPG the advantage it has and disadvantage is that there is no standard; its all IBM and their developers who determine its course. Modern RPG can look at lot like C/Pascal with no fixed columns and the like. Schools tend to focus on whats cool or strictly PC centric languages but there are many sources of skill, all over seas. Some are contracted out and some come across and take positions that could have gone to local talent if they had received exposure. Large machines will never truly die out and business logic that has a great deal of investment behind it is not easy to part with. One area of COBOL and RPG; and similar older languages; is their well developed handling of business math. You know exactly what to expect.
wrsh07 11y ago
I'm not sure why transpiling away COBOL [assuming it hasn't been modernized like C++] wouldn't make the most sense.
- JoshTriplett 11y ago
  Consider the kind of shop that has large quantities of COBOL; they're unlikely to be excited about a major change that may potentially decrease the stability of their system. And what advantage would transpiling bring over just compiling? The only real reasons to transpile are either 1) if there's an environment you want to target that mandates a particular language, or 2) if you want to interoperate with code in another language that's not capable of speaking or being spoken to via some FFI or other function-call/library/IPC interface.
- ctdonath 11y ago
  Modernization has happened. I recall a reference to "Object-oriented COBOL on JAVA VM".
- fennecfoxen 11y ago
  I'm not sure why there won't just be a gradual shift to businesses offering services on a quasi-modern technology stack, and able to offer the same capabilities in a more-competitive fashion. Certainly in some industries like banking, certifying it and appeasing the auditors will be a huge deal, which is presumably why COBOL and RPG are still a big deal there today - but hey, maybe there will be other advantages when you move away from storing your records in EBCDIC, too. :P (EBCDIC - you know, the un-ASCII, designed after ASCII specifically to be backwards-compatible with the integers punched on punch cards.)
  - pjmlp 11y ago
    Because Cobol keeps getting updated to follow up with times. https://en.wikipedia.org/wiki/COBOL#COBOL_2002_and_object-oriented_COBOL https://en.wikipedia.org/wiki/COBOL#COBOL_2002_and_object-or...
- sliverstorm 11y ago
pjungwir 11y ago
Assuming I wanted to pick up COBOL and land a contract gig, what else do I need to know? A language is syntax but also libraries, patterns, and ecosystem. For instance it's hard to do Rails without knowing Git, Bash, Linux, SQL, Javascript, CSS, RSpec, Capistrano, Devise, MVC, etc. Do COBOL apps typically talk to relational databases, or is everything stored in fixed-width flat files? Do COBOL programmers use git? Am I going to need to keep an AS/400 running in my garage?
- tolle 11y ago
  All COBOL shops have developed what could be called their own frameworks from scratch over the years. Learn COBOL and DB2/SQL. If you end up working on mainframes. JCL as well. If on AS/400. RPG and ACL. Most developers don't really have to know much else then COBOL. Just type in a editor, run commands, done.
- sliverstorm 11y ago
  As far as I know, the heyday of COBOL was long before relational databases, and any VCS is likely to be RCS or CVS.
  - tolle 11y ago
    DB/2 is used quite extensively. But a lot of things are still flat files. On System I you can access DB/2 databases as if it were flat files as well. Not actually useful if you ask me but I suppose useful when the developers didn't know SQL. I'm on my phone so explaining how it works is a hassle. Endevor for version control on Z/OS.
- kbenson 11y ago
  There are COBOL repositories on Github[1], it would probably be worth looking at what they do. From that list, here's a micro web framework[2] which while it may not be indicative of what you would expect to do in COBOL if hired to work in it, is interesting. 1: https://github.com/trending?l=cobol https://github.com/trending?l=cobol 2: https://github.com/azac/cobol-on-wheelchair https://github.com/azac/cobol-on-wheelchair
- 11y ago
lurkinggrue 11y ago
I learned COBOL in the late 80s but for the life of me can't remember much of it. Is there anything like an IBM System 36 emulator out there?
- macjohnmcc 11y ago
  I wish when I worked on a System 36 that it was programming COBOL. Instead I was doing RPG II.
  - lurkinggrue 11y ago
    All I remember about RPG was hating it with a passion. When I was learning COBOL it started off on a Sperry Univac and the school transitioned to an IBM/36 so for a few months I got to code on the Sperry which at the time did feel a bit dated. Then again my Amiga at the time had about as much ram as the IBM/36.
thenipper 11y ago
My mom programmed COBOL back in the early 70s while she was doing the hippie thing back out in Berkeley. After that she learned basic and taught me that on my Apple IIc. All as a six week college dropout. I always have wondered what it would've been like if she had stuck with that instead of going off to live in the woods of New Hampshire.
- lawpoop 11y ago
  Would it have been any more exciting than your typical office worker?
revanx_ 11y ago
I don't think it's going to be an issue of finding people to take over COBOL systems, companies that are interested are simply going to round up students and give them part time jobs where they can learn COBOL and earn some side cash with a promise of a good job when they get out of college.
marpstar 11y ago
I studied at the University of Wisconsin-Platteville and was forced to take a COBOL class. Anyone in the Computer Information Systems emphasis was required to take several COBOL-centric classes. A few classmates went on to write COBOL on the job and they were definitely getting higher offers than the rest of us looking for "cool" jobs. On the other hand, the only COBOL shop in town pays meager wages and is considered to be the place where your career goes to ddie.
pjmlp 11y ago
For the unawary, the latest standard revision is actually from 2014.
- vezzy-fnord 11y ago
  I'm curious just how much is object-oriented Cobol even used in the real world. My knowledge is that new Cobol is barely written, only old COBOL codebases being maintained.
  - pjmlp 11y ago
    Most likely as much as Cobol.Net (http://www.fujitsu.com/global/products/software/developer-tool/netcobol/ http://www.fujitsu.com/global/products/software/developer-to...) and similar, but it still means companies care enough to update the language.
elorant 11y ago
This begs the question. Why haven’t ecosystems that rely on Cobol been extinct or at the very least moved on with times? I can understand that some of those are mission critical systems where you just don’t mess around but there are some very stable frameworks out there that are also modern and have first class enterprise support behind them.
- acveilleux 11y ago
  Inertia. You have a ton of one-off specialized programs running batch operations, settling transactions, extracting reports, and generating output that will be the input of a slew of other similar applications. All of that is densely packed business logic with very little other stuff. It'd be painstaking to convert to more modern paradigm, without dropping a single feature on the floor. Convert all the existing data and shim all the interfaces as you convert piece by piece. Importantly, the whole effort has no intrinsic business value, is unbounded in scope, risky and tends to paralyze the kind of on-going small maintenance that kept the system current with changes in practice, accounting rules, tax law, HR processes, etc. Finally, Gary and Sue who were the last ones who actually knew all the pieces of the stacks and how they fit retired in '97 and '03.
mkozlows 11y ago
Counter-argument: Old apps, of the sort that are written in COBOL, are often ones that there are good reasons to replace anyway. The reason they tend to still exist, where they do still exist, is that businesses don't want to dedicate the budget to the replacement. But that also means that they don't want to dedicate a huge budget to maintenance, either. If COBOL actually gets rare enough that COBOL devs start getting high-end wages, it makes the "replace this thing" option look that much more appealing, which pretty much puts a ceiling on the demand for COBOL devs. If you are a purely mercenary developer, don't learn COBOL, because it's not where the money is.
leoc 11y ago
I have to mention J. Wayne Spence's Cobol for the 80's http://www.worldcat.org/title/cobol-for-the-80s/oclc/7975830 http://www.worldcat.org/title/cobol-for-the-80s/oclc/7975830 again. Oh how I laughed when I saw it on a library shelf, back in 1995 or so...
zcdziura 11y ago
This is right up my alley; I work for a large financial firm doing COBOL work right now. The language itself isn't that bad. There are a lot of quirks given how old it is (variable names being limited in size, file name being only 8 characters long, file-based scope, etc), but once you learn them it's really not that bad. The best thing about the language is how it enforces a particular programming style. You have to define ALL variable and external data sources before you're able to use them. And when you get to the meat-and-potatoes of the program, a certain style is primarily used: open external resources (files, DB2 tables), check for IO errors, process the data, close the resources. Makes it easy to grok what's going on within a program (even if that program is older than you are). The biggest challenge that I see for new COBOL programmers is learning all of the tools you'll use for your job. On the IBM zSeries Mainframe that we use, there are a TON of tools that we use to monitor our batch/CICS online programs. But that, like everything else, will take practice.
- dejv 11y ago
  Is there any good book for learning COBOL and maybe even tools?
  - code_chimp 11y ago
    The COBOL version of K&R was Stern & Stern: http://www.amazon.com/Structured-COBOL-Programming-Nancy-Stern/dp/047113886X http://www.amazon.com/Structured-COBOL-Programming-Nancy-Ste... - I'm guessing it's probably still pretty relevant as I was playing a little with OpenCobol last year and managed to look up what I had forgotten in my old dog-eared copy of that book.
  - tolle 11y ago
    Murach's Mainframe COBOL is a decent book. GNU COBOL works for learning but database stuff is a bit of a hassle. Microfocus has a visual COBOL personal license that's free. Setting it up to work with db2 is fairly pain free.
nine_k 11y ago
Well, not as much a return as a stubborn refusal to be phased out, resulting in a trickle of new development and job offerings. Fortran is also alive and kicking, also in narrow but well-entrenched niches. Modern Fortran became a nicer language, though, then e.g. Fortran IV or 77. Bigger fun will begin when C will be universally seen as a legacy language, inexpressive, full of pitfalls and undefined behaviors, etc, but huge amounts of important C code will have to be maintained without a chance of rewriting it in a nicer language in sight.
ramgorur 11y ago
not sure about cobol, but most of the serious supercomputing simulations are written in fortran, and in my opinion, lisp is the most beautiful language ever written in computing history.
vampirechicken 11y ago
The perception is that the COBOL jobs don't pay as well as Ruby, Node, etc. It this is not the case, then the recruiters are doing a bad job winning the hearts and minds of job seekers and those try to follow hiring trends.
thecosas 11y ago
TL;DR for the comments: Idealist: Why don't enterprises move to modern and stable systems? Pragamatist: Literally billions of small programs/processes are written in this and they work reliably.

37 points by rvivek 11y ago

I had no problem with Cobol back in the day, it was a fairly easy language to use once you got used to it. The main problem I have seen is the utter crap way its programmers were treated after the whole Y2K thing was over with. Why would anyone want to walk into a job like that when they can learn Rails and be a 'Rockstar' or any other web-based offering and at least be treated like a valuable commodity?

cgh 11y ago
Money. As the article states, Cobol programmers have higher starting salaries and I expect this will only increase.
- PaulHoule 11y ago
  I might code COBOL for a defined benefit pension, but not just for more pay.
- tolle 11y ago
  I started a CS-degree some 10 years ago. Focused more on the partying then the studying. Got my shit together. Took a COBOL class and my entry salary is way higher then full fledged masters in CS is. And the job requires no overtime at all. None of the risks you sign up for with a startup. Great benefits in lower interests on mortgages, great pension plans, lower retirement age and job security. And things I learn today will be just as relevant years from now. So no need to keep up with stuff on my spare time. Well I had some work experience as a developer from a startup doing web stuff.
  - sliverstorm 11y ago
    And things I learn today will be just as relevant years from now. So no need to keep up with stuff on my spare time. Isn't that such a weird feeling when you're in tech? :) I am not a COBOL programmer, but I imagine taking a COBOL gig is like stepping back in time to the days of IBM, mainframes and suits at the office.
  - the_af 11y ago
    I worked with COBOL during the Y2K thing. Forget for a minute about the (very valid) downsides of startups: COBOL development in institutions such as banks is utterly boring. If, like me, you got into computers because you were fascinated by programming, run like hell from COBOL and forget the money argument. Run like hell whenever someone tells you "it's not that bad", like in the article. Nothing good can come from something introduced as not being "that bad". If you're in this mostly for the money, then sure, learn COBOL.
    - kbenson 11y ago
      Or, use COBOL to pay the bills while you work on your hobby or startup on the side. Having a steady job that doesn't require overtime is sadly often underrated by our industry, but it provides quite a bit of flexibility of its own. Then again, being stuck in crappy, uninspiring code all day and then getting to use something interesting and exciting in your off time can sometimes make the day job all that much harder to handle...
      - the_af 11y ago
        Yes to your second part. Working with COBOL at a bank was soul-crushing to me. I think the combination of COBOL+bank is deadly: obsolete, boring technology combined with an utterly conservative environment, unwilling to take risks. I fully agree that no overtime is great -- that's why I'm not arguing anything about startups! -- but when you realize how many hours a day you spend in your day job, working with something that sucks cannot be compensated by a hobby. For me, at least. I fully understand someone could find the trade-off acceptable.
      - TylerE 11y ago
        That's a great recipe for burnout. Coding 12+ hours a day isn't healthy.
        kbenson 11y ago
        I think it depends entirely on how you view your off-time work. I used to be fairly active in developing for the Roku with a friend, and 2-3 times a week he would come over and we would work on our Roku app(s) for 3-5 hours. It felt very much like hanging out with a friend screwing around in the garage to build something, and usually left me feeling more energized than tired. I've also done (and am doing) the solo hacking on startup stuff. Getting motivated for that can be really hard.
  - tolle 11y ago
    I still fiddle around on my spare time with modern tech just for fun. I just don't have to learn every new "tech of the week" to stay relevant. But yeah, suits some better then others. I'd imagine it's the perfect area to work in if you have kids or such. Finance is however a huge field on its own. And a huge part of the work is implementing new regulations. If I end up getting bored, I know multiple other languages quite well. And if I decide to leave the finance sector, having a job as a developer on a bank is a positive thing here.

deleted 11y ago

[deleted]

steven777400 11y ago

We have quite a bit of COBOL and are seeing a similar challenge recruiting and maintaining COBOL developers. We're in talks to partner with a local workforce education center to put together some training for potential or existing employees who might be willing to transition into a COBOL role. I'm imagining that these folks would be non-programmers who are identified as having good reasoning and structural thinking, and who could receive a pay bump by moving into a development position. I don't expect that existing developers would want to move away from their current skillset trajectory and I think that route is probably not a fruitful one to pursue. It remains to be seen if this will be a successful endeavor.

Shivetya 11y ago
We have had a similar issue getting good talent in regards to RPG (RPGLE) on the iSeries. One issue is the language has progressed a lot and that leads to having to bring otherwise qualified candidates up to speed. Throw on that having to adjust to our standards and idiosyncrasies. We do maintain a decent amount of COBOL on the z at the same time. Take both languages and their similar platforms and throw web interfacing, transformation, and such, and you can end up training even those who know the basics. With RPG the advantage it has and disadvantage is that there is no standard; its all IBM and their developers who determine its course. Modern RPG can look at lot like C/Pascal with no fixed columns and the like. Schools tend to focus on whats cool or strictly PC centric languages but there are many sources of skill, all over seas. Some are contracted out and some come across and take positions that could have gone to local talent if they had received exposure. Large machines will never truly die out and business logic that has a great deal of investment behind it is not easy to part with. One area of COBOL and RPG; and similar older languages; is their well developed handling of business math. You know exactly what to expect.

wrsh07 11y ago

I'm not sure why transpiling away COBOL [assuming it hasn't been modernized like C++] wouldn't make the most sense.

JoshTriplett 11y ago
Consider the kind of shop that has large quantities of COBOL; they're unlikely to be excited about a major change that may potentially decrease the stability of their system. And what advantage would transpiling bring over just compiling? The only real reasons to transpile are either 1) if there's an environment you want to target that mandates a particular language, or 2) if you want to interoperate with code in another language that's not capable of speaking or being spoken to via some FFI or other function-call/library/IPC interface.
ctdonath 11y ago
Modernization has happened. I recall a reference to "Object-oriented COBOL on JAVA VM".
fennecfoxen 11y ago
I'm not sure why there won't just be a gradual shift to businesses offering services on a quasi-modern technology stack, and able to offer the same capabilities in a more-competitive fashion. Certainly in some industries like banking, certifying it and appeasing the auditors will be a huge deal, which is presumably why COBOL and RPG are still a big deal there today - but hey, maybe there will be other advantages when you move away from storing your records in EBCDIC, too. :P (EBCDIC - you know, the un-ASCII, designed after ASCII specifically to be backwards-compatible with the integers punched on punch cards.)
- pjmlp 11y ago
  Because Cobol keeps getting updated to follow up with times. https://en.wikipedia.org/wiki/COBOL#COBOL_2002_and_object-oriented_COBOL https://en.wikipedia.org/wiki/COBOL#COBOL_2002_and_object-or...
sliverstorm 11y ago

pjungwir 11y ago

Assuming I wanted to pick up COBOL and land a contract gig, what else do I need to know? A language is syntax but also libraries, patterns, and ecosystem. For instance it's hard to do Rails without knowing Git, Bash, Linux, SQL, Javascript, CSS, RSpec, Capistrano, Devise, MVC, etc. Do COBOL apps typically talk to relational databases, or is everything stored in fixed-width flat files? Do COBOL programmers use git? Am I going to need to keep an AS/400 running in my garage?

tolle 11y ago
All COBOL shops have developed what could be called their own frameworks from scratch over the years. Learn COBOL and DB2/SQL. If you end up working on mainframes. JCL as well. If on AS/400. RPG and ACL. Most developers don't really have to know much else then COBOL. Just type in a editor, run commands, done.
sliverstorm 11y ago
As far as I know, the heyday of COBOL was long before relational databases, and any VCS is likely to be RCS or CVS.
- tolle 11y ago
  DB/2 is used quite extensively. But a lot of things are still flat files. On System I you can access DB/2 databases as if it were flat files as well. Not actually useful if you ask me but I suppose useful when the developers didn't know SQL. I'm on my phone so explaining how it works is a hassle. Endevor for version control on Z/OS.
kbenson 11y ago
There are COBOL repositories on Github[1], it would probably be worth looking at what they do. From that list, here's a micro web framework[2] which while it may not be indicative of what you would expect to do in COBOL if hired to work in it, is interesting. 1: https://github.com/trending?l=cobol https://github.com/trending?l=cobol 2: https://github.com/azac/cobol-on-wheelchair https://github.com/azac/cobol-on-wheelchair
11y ago

lurkinggrue 11y ago

I learned COBOL in the late 80s but for the life of me can't remember much of it. Is there anything like an IBM System 36 emulator out there?

macjohnmcc 11y ago
I wish when I worked on a System 36 that it was programming COBOL. Instead I was doing RPG II.
- lurkinggrue 11y ago
  All I remember about RPG was hating it with a passion. When I was learning COBOL it started off on a Sperry Univac and the school transitioned to an IBM/36 so for a few months I got to code on the Sperry which at the time did feel a bit dated. Then again my Amiga at the time had about as much ram as the IBM/36.

thenipper 11y ago

My mom programmed COBOL back in the early 70s while she was doing the hippie thing back out in Berkeley. After that she learned basic and taught me that on my Apple IIc. All as a six week college dropout. I always have wondered what it would've been like if she had stuck with that instead of going off to live in the woods of New Hampshire.

lawpoop 11y ago
Would it have been any more exciting than your typical office worker?

revanx_ 11y ago

I don't think it's going to be an issue of finding people to take over COBOL systems, companies that are interested are simply going to round up students and give them part time jobs where they can learn COBOL and earn some side cash with a promise of a good job when they get out of college.

marpstar 11y ago

I studied at the University of Wisconsin-Platteville and was forced to take a COBOL class. Anyone in the Computer Information Systems emphasis was required to take several COBOL-centric classes. A few classmates went on to write COBOL on the job and they were definitely getting higher offers than the rest of us looking for "cool" jobs. On the other hand, the only COBOL shop in town pays meager wages and is considered to be the place where your career goes to ddie.

pjmlp 11y ago

For the unawary, the latest standard revision is actually from 2014.

vezzy-fnord 11y ago
I'm curious just how much is object-oriented Cobol even used in the real world. My knowledge is that new Cobol is barely written, only old COBOL codebases being maintained.
- pjmlp 11y ago
  Most likely as much as Cobol.Net (http://www.fujitsu.com/global/products/software/developer-tool/netcobol/ http://www.fujitsu.com/global/products/software/developer-to...) and similar, but it still means companies care enough to update the language.

elorant 11y ago

This begs the question. Why haven’t ecosystems that rely on Cobol been extinct or at the very least moved on with times? I can understand that some of those are mission critical systems where you just don’t mess around but there are some very stable frameworks out there that are also modern and have first class enterprise support behind them.

acveilleux 11y ago
Inertia. You have a ton of one-off specialized programs running batch operations, settling transactions, extracting reports, and generating output that will be the input of a slew of other similar applications. All of that is densely packed business logic with very little other stuff. It'd be painstaking to convert to more modern paradigm, without dropping a single feature on the floor. Convert all the existing data and shim all the interfaces as you convert piece by piece. Importantly, the whole effort has no intrinsic business value, is unbounded in scope, risky and tends to paralyze the kind of on-going small maintenance that kept the system current with changes in practice, accounting rules, tax law, HR processes, etc. Finally, Gary and Sue who were the last ones who actually knew all the pieces of the stacks and how they fit retired in '97 and '03.

mkozlows 11y ago

Counter-argument: Old apps, of the sort that are written in COBOL, are often ones that there are good reasons to replace anyway. The reason they tend to still exist, where they do still exist, is that businesses don't want to dedicate the budget to the replacement. But that also means that they don't want to dedicate a huge budget to maintenance, either. If COBOL actually gets rare enough that COBOL devs start getting high-end wages, it makes the "replace this thing" option look that much more appealing, which pretty much puts a ceiling on the demand for COBOL devs. If you are a purely mercenary developer, don't learn COBOL, because it's not where the money is.

leoc 11y ago

I have to mention J. Wayne Spence's Cobol for the 80's http://www.worldcat.org/title/cobol-for-the-80s/oclc/7975830 http://www.worldcat.org/title/cobol-for-the-80s/oclc/7975830 again. Oh how I laughed when I saw it on a library shelf, back in 1995 or so...

zcdziura 11y ago

This is right up my alley; I work for a large financial firm doing COBOL work right now. The language itself isn't that bad. There are a lot of quirks given how old it is (variable names being limited in size, file name being only 8 characters long, file-based scope, etc), but once you learn them it's really not that bad. The best thing about the language is how it enforces a particular programming style. You have to define ALL variable and external data sources before you're able to use them. And when you get to the meat-and-potatoes of the program, a certain style is primarily used: open external resources (files, DB2 tables), check for IO errors, process the data, close the resources. Makes it easy to grok what's going on within a program (even if that program is older than you are). The biggest challenge that I see for new COBOL programmers is learning all of the tools you'll use for your job. On the IBM zSeries Mainframe that we use, there are a TON of tools that we use to monitor our batch/CICS online programs. But that, like everything else, will take practice.

dejv 11y ago
Is there any good book for learning COBOL and maybe even tools?
- code_chimp 11y ago
  The COBOL version of K&R was Stern & Stern: http://www.amazon.com/Structured-COBOL-Programming-Nancy-Stern/dp/047113886X http://www.amazon.com/Structured-COBOL-Programming-Nancy-Ste... - I'm guessing it's probably still pretty relevant as I was playing a little with OpenCobol last year and managed to look up what I had forgotten in my old dog-eared copy of that book.
- tolle 11y ago
  Murach's Mainframe COBOL is a decent book. GNU COBOL works for learning but database stuff is a bit of a hassle. Microfocus has a visual COBOL personal license that's free. Setting it up to work with db2 is fairly pain free.

nine_k 11y ago

Well, not as much a return as a stubborn refusal to be phased out, resulting in a trickle of new development and job offerings. Fortran is also alive and kicking, also in narrow but well-entrenched niches. Modern Fortran became a nicer language, though, then e.g. Fortran IV or 77. Bigger fun will begin when C will be universally seen as a legacy language, inexpressive, full of pitfalls and undefined behaviors, etc, but huge amounts of important C code will have to be maintained without a chance of rewriting it in a nicer language in sight.

ramgorur 11y ago

not sure about cobol, but most of the serious supercomputing simulations are written in fortran, and in my opinion, lisp is the most beautiful language ever written in computing history.

vampirechicken 11y ago

The perception is that the COBOL jobs don't pay as well as Ruby, Node, etc. It this is not the case, then the recruiters are doing a bad job winning the hearts and minds of job seekers and those try to follow hiring trends.

thecosas 11y ago

TL;DR for the comments: Idealist: Why don't enterprises move to modern and stable systems? Pragamatist: Literally billions of small programs/processes are written in this and they work reliably.