11 ms·

Ask HN: How do I learn real-world COBOL?

108 points by unsupp0rted 4y ago

COBOL devs are a specialized niche these days and they get paid accordingly. I can learn COBOL from a book in general terms, but where would I practice with real-world legacy COBOL systems? It's not as though I can do a COBOL side-project to learn... or can I? How does one go about learning COBOL in 2022 (from "scratch", while already being a working dev) in order to niche down as a COBOL specialist dev?

bencollier49 4y ago
Depends on your country, but I do know for a fact that if you're in the UK, there are government departments which will teach you modern development practices alongside COBOL, if you're near one of the relevant hubs.
Group_B 4y ago
It’s honestly not worth your time to learn this for the money. https://www.reddit.com/r/learnprogramming/comments/g5zvpa/psa_dont_try_to_learn_cobol/ https://www.reddit.com/r/learnprogramming/comments/g5zvpa/ps...
- jjp 4y ago
  https://old.reddit.com/r/learnprogramming/comments/g5zvpa/psa_dont_try_to_learn_cobol/fo7453r/ https://old.reddit.com/r/learnprogramming/comments/g5zvpa/ps... - is probably the most succinct from that thread. Your challenge isn't just learning Cobol - that's relatively simple. It's all the surrounding infrastructure that is also very different - different OS, different file system, different database, front-end is 80x24 green and then you get into source control, build and devops which will all be different.
  - pbhjpbhj 4y ago
    Either side of the millennium my job involved daily use of a terminal interface (on WinNT IIRC) to a green-screen, to me it was just like using pico (which was supersedes by nano) through konsole. But I was just a user, and grew up with monochrome VDUs. Can you run an AS400 under emulation?? Wouldn't you be developing under a regular IDE with modern tooling [, testing under emulation?] and then transferring to production just like you might with any other system? On the question of whether it's worth it financially, presumably demand will increase--are people retiring faster than the systems they support or vice versa?
- mwt 4y ago
  There's also an issue of community/people you'd work with. (Fair or not) there's a strong perception that the current COBOL devs are people that are close to retirement and not exactly eager to take a junior dev under their wing and give the sort of mentorship that one can't get from textbooks and hobby projects. I'm not a COBOL dev or part of the community at all, but I doubt it compares at all to the language-based communities that people around here are more familiar with. There have been some other recent threads on similar subs from people who actually tried to make the jump to a COBOL role in the past year and the social aspects were brought up again and again, on top of the technical issues ... I can dig a few up if people are at all skeptical.
  - pbhjpbhj 4y ago
    I know two people who started as COBOL devs, not sure what they're doing right now but they're both in their 40s. They were part of a big bank recruitment in the noughties.
  - kjs3 4y ago
    I have found on the occasions I've had to travel to mainframe-world, our COBOL devs (we have many) are very interested in mentoring younger people, and have had some success recruiting them. They understand extremely well that they have a lot to pass on and limited time to do it. I'm sure not all shops are like that (like any insular tech community), but there's probably some selection bias around folks who's response is to run to a sub to complain.
    - mwt 4y ago
      I don't doubt there's some people like this, but if I cut my teeth on mainframes 2-3 decades ago and was nearing retirement, I'm not sure I'd have the patience needed to be a good mentor. (I'm sure I *should*, but as a personal limitation I might not, and I'm probably not alone.)
      - kjs3 4y ago
        That's...sad? We try to cultivate a mentor culture. We have internal mentorship, college internships and organized internal cross-training. You can even do extended cross-training in other teams and try out new jobs (within certain limits). And the fact of the matter is we're terrible at it; should be more organized, easier to access, have more objective outcomes, with even more mentors. I bet an unfortunate fraction of our people don't even know we have formal programs. But very large numbers of folks here want it to work, and keep helping out, keep volunteering. I could pick up the phone right now and probably get a dozen or so greybeards from the mainframe group who would say "sure, I'll show a new kid the ropes". But you're certainly not an anomaly...there's clearly more people who would say "screw 'em...I got mine" than consider helping someone down the ladder.
JohnDeHope 4y ago
TL;DR; find a way to work in a mainframe environment. I think this is true of a lot of things, but starting in 2022, it's definitely true for learning cobol. The thing is, cobol is not just a programming language. Living and working in a mainframe environment is it's own whole thing. There is so much you'll have to learn. It's like the difference between linux and windows, but I'd argue is easily x2 to x5 as jarring. Just learning ebcdic instead of ascii is a thing. And navigating a green screen is as foreign to a modern pc user as, say, going from being a programmer in a high level language (like say java or c#) to using assembly language. It's not that you can't learn it, but it's that your whole brain has to be tilted to the side just to understand what's going on. A mainframe is a completely different world from modern pcs. The cobol programming language is 1/10th of it.
sulam 4y ago
I think you’d have to actively seek a job somewhere that has running COBOL and then express interest in picking it up. They’d probably be happy to have you, but you wouldn’t be making the big bucks. That would have to wait until you had a decade of experience and then venture out on your own as a consultant or get hired by a specialized outsourcing firm.
pcurve 4y ago
Many industries are still running on COBOL including healthcare. We think COBOL will still be around 30 years from now, so we're training college grads. No cobol experience? I don't think it will be a problem if you already know another language well. https://www.indeed.com/jobs?q=Healthcare%20Mainframe%20Cobol&redirected=1&vjk=ae24fbd62a3d8afc https://www.indeed.com/jobs?q=Healthcare%20Mainframe%20Cobol...
- jpindar 4y ago
  Looks to me like all of those require experience.
  - pcurve 4y ago
    Many do, but some don't. Contractor positions would most likely require experience, but full time positions would include more entry level. They're willing to make the investment to FTE.
- Rochus 4y ago
  How about MUMPS (ANSI-M)? Is it still used in healthcare, or did they manage to replace all systems?
  - rodface 4y ago
    MUMPS and derivatives are still the basis for the major EMRs in use today. https://www.elys.com/blog/mumps-the-arcane-database-language-behind-our-electronic-medical-records https://www.elys.com/blog/mumps-the-arcane-database-language... EPIC has about 1/3 US market share, and the VA--the largest healthcare system in the country--has its homegrown VistA CPRS. So MUMPS isn't going anywhere :)
    - Rochus 4y ago
      Is this still up-to-date? Wasn't VISTA replaced by a COTS product by Cerner? And isn't EPIC implemented in Caché and its Object Script (i.e. not in M)?
scktt 4y ago
learn universe or any of its flavours (i started out on pick basic at 19, now 34) its not as obscure but niche enough that with time&skill you can find yourself in demand quite readily
- deleted 4y ago
  [deleted]
eatonphil 4y ago
Not that salary alone should stop you, but if you look on glassdoor for the range of salaries of COBOL devs vs react or Go, the median is lower and the ceiling is also lower. If you just want to have fun with older tech that's totally fair.
- commandlinefan 4y ago
  Yeah, I don't think they're "paid accordingly" - if you're looking for money, just learn Java, it's easier to find resources on and it pays WAY better.
  - mettamage 4y ago
    Do you have some good resources? I have some industry experience with Java, but not enough.
  - ElectricalUnion 4y ago
    > just learn java Java pays well because handling legacy Java is awful, full of foot guns and a pain to maintain. Possibly more that COBOL.
- the_only_law 4y ago
  My understanding has been, if you're highly experienced, you can make some serious money as a consultant, without that you can also get stuck as a code-monkey at crap salaries.
  - nickelpro 4y ago
    You can say this about almost any technology. You can say this about a sufficiently skilled plumber.
    - gunapologist99 4y ago
      Also a willingness to consult (be a contractor) and/or relocate to where the best jobs are. Not everything is Zoom-able. Programming, in theory, can be done anywhere, but in practice that's not true, especially for old-school jobs where skillfully interacting in the (technical, people, etc) environment can be more than 50% of the actual job. In the U.S., sometimes those jobs are in silicon valley or New York, but sometimes it's Omaha or Charlotte. If you are mobile or even slightly mobile, make a list of places you are willing to relocate to and then pursue those roles. If you're willing to travel internationally, even better. Most of the limiting factors that make you say "oh, I'd never want to live there" can be assuaged by saying, ".. unless I was making enough money and it wasn't going to be forever." The combination of willingness to travel and experience/skills in something really esoteric is a rare-enough combination that you'll always have a good job, even in a recession, and often you'll have your choice of excellent jobs. Like your point, this definitely applies for plumbers, too; it's really hard to do highly paid plumbing gigs in Tokyo or NYC over Zoom. Remember, unlike most startups, with consulting or jobs, you only have to sell one product: you. So, how unusual the need is doesn't matter. There might be only one job in the world for that. What matters is that you are one of the very few people who can fill that need. When it comes to consulting, niche thyself.
defined 4y ago
You could learn some mainframe stuff using the Hercules emulator[1], but you'd have to find some z/OS installation media somewhere, and I'm not sure if that might infringe copyright or something. Also, JCL is absolutely horrible IMO. [1] http://www.hercules-390.org/ http://www.hercules-390.org/
brakmic 4y ago
Start from here: http://www.hercules-390.org/ http://www.hercules-390.org/ This is Hercules, an emulator for old mainframes. They also have COBOL and other important languages like JCL, the job control language. Here the "turnkey" distribution that installs everything for you: https://wotho.ethz.ch/tk4-/ https://wotho.ethz.ch/tk4-/ A mainframe community from youtube: https://www.youtube.com/c/moshix https://www.youtube.com/c/moshix Have fun.
- reaperducer 4y ago
  If you are starting from zero COBOL experience, a mainframe environment may be too big of a learning curve. Maybe start small. There were COBOL implementations for pretty much every 8-bit computer in the 80's. Think Commodore 64, Apple ][, or whatever emulated environment works for you. Because they were designed for complete beginners, they often came with very detailed, very easy to comprehend manuals. Many of which are available as PDFs online today. And there was no end of third-party books to help you along, which may be available from Biblio, or whatever your favorite used book source is. Getting a feel for COBOL from these baby steps can help you decide if you want to advance into full big iron COBOL development. This also applies to FORTRAN, APL, and other older languages.
  - hermitdev 4y ago
    > a mainframe environment may be too big of a learning curve Yeah, "curve" might be a little generous here. It's more like a cliff from what limited I remember of my short lived mainframe stint.
    - hyperman1 4y ago
      In my experience, a cliff is exactly what makes you learn fast and deep. Start from nothing, and make tiny baby steps. Target a short term milestone. Learn how to use the documentation. Even if you start slower than people who take shortcuts,you end up being faster because you have a much deeper undestanding
  - themadturk 4y ago
prionassembly 4y ago
Parallel question: what would be better to learn job market wise right now, Cobol, C# or Java?
- KronisLV 4y ago
  Honestly, C# and Java are vaguely similar (GC languages, lots of OOP, with some FP sprinkled in, like LINQ/Streams) and some of the more popular frameworks, such as ASP.NET and Spring Boot shouldn't be too hard to pick up - so personally I'd go for both. COBOL or FORTRAN or older languages might be okay if you want to specifically take advantage of that niche, but won't make you quite as hireable everywhere else.
  - prionassembly 4y ago
    Modern Fortran is easy to learn if you have Matlab muscles; there's a few additional concepts to learn because it's a "static" language, but much much easier than, say, Rust.
    - KronisLV 4y ago
      > if you have Matlab muscles Heh, I recall the most recent Stack Overflow Developer Survey list MATLAB as one of the most hated languages: https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-wanted https://survey.stackoverflow.co/2022/#technology-most-loved-... Loved: 19.16% Dreaded: 80.84% That's not to say that it doesn't have a place or anything, it was just interesting to behold such a clear trend.
      - prionassembly 4y ago
        Matlab has OO concepts that make for much cleaner concepts. Also: Matlab OO is hellishly slow, like having to go on a 5-hour plane trip and mistaking the Ambien you planned to take for a Ritalin.
  - mywittyname 4y ago
    FORTRAN is for scientists who use computers to do their science. IMHE, it's not really a language used by generic software engineers, you would be expected to understand how to apply complicated math to some sophisticated problems. The place I worked for had a pipeline to turn PhDs into FORTRAN developers; CS/SE people filled the support roles and mostly wrote C & shell scripts.
jhugo 4y ago
You think that those people are getting paid the big bucks because they know COBOL, but the reality is that they are getting paid the big bucks because they have decades of experience with all the legacy systems that surround that COBOL. Learning COBOL, even in a "real" environment, isn't going to be the jumpstart that you're hoping for by itself.
- ejb999 4y ago
  this is the best answer.
- hugg 4y ago
  Yeah, this is what I learned too from working at a big government pension office
- agumonkey 4y ago
  the few I've seen, COBOL legacy is its own kind. It meshes decades of users, practices, tools and paradigms. We've been shown code that blend old original code with 3GL crude code generator with 4GL custom COBOL transpiled DSLs with monkey patching. It was really not pretty (to stay polite).
  - hermitdev 4y ago
    My last project as an intern was to rewrite an old batch processed COBOL app into a simple webform in C#/ASP.Net. The COBOL app was nothing special, really. From what I recall, it was around 65 pages printed. Took me a while to comprehend what was going on, but the first 80% or so was basically just hard-coded rules to take action on based upon user input. Things like when "B", generate "X" & "Y". When "A", generate "X", "Y" & "Z" sort of thing. Nothing fancy, at all. Once I figured out what was going on, I basically just ran the COBOL through some regexs, transformed into an XML doc (don't judge me - it was early 2000s) and wrote the rules engine in maybe one or two screenfuls of C#. I did learn one thing, and that was COBOL has one up on 'goto'. Check out the control flow statement: MOVE NEXT SENTENCE. It's basically a goto, but it doesn't jump to a label, per se. Instead, it jumps to the next period in the source. Yes, in a big, blocky, verbose language like COBOL, where everything is in UPPER CASE, you're now looking for a teeny tiny period that is easily lost in the verbiage. Hands down, my least favorite programming language construct ever.
tapland 4y ago
> COBOL devs are a specialized niche these days and they get paid accordingly. In my experience the well paid COBOL devs are those with 20+ years of experience, often in one specific system, often bumped by being re-hired a bunch of times for the same position. I've been doing COBOL since 2018 and younger devs my age (late 20s, early 30s) with a few years of experience make decent money, but the average is bumped by the teams having a lot of devs near retirement age. If you want to learn: The language isn't very complicated. I'd recommend grabbing the Visual Cobol for Windows trial just to get coding (and then shunning anything MicroFocus when you are done ;) ) https://www.microfocus.com/en-us/products/visual-cobol/overview https://www.microfocus.com/en-us/products/visual-cobol/overv... If you want to/will end up tinkering with IBM systems, check out Jan Sądek's Mainframe Playground: https://mainframeplayground.neocities.org/ https://mainframeplayground.neocities.org/ For running COBOL on VMS, comp.os.vms is a common place to hang out https://groups.google.com/g/comp.os.vms?pli=1 https://groups.google.com/g/comp.os.vms?pli=1 A dev named Remy documented his first steps on OpenVMS and it was a great help when starting out: https://raymii.org/s/tags/vms.html https://raymii.org/s/tags/vms.html There is some actual training material from firms specializing in COBOL training floating around, but they are mostly IBM and/or MicroFocus documentation with some suggested example programs. I hope the resources above are useful and good luck!
- jandrese 4y ago
  Of course the COBOL community is on Usenet. It's so obvious in retrospect.
  - dingosity 4y ago
    Yes. COBOL and Usenet are both simple tools that just work and are unlikely to be used by Facebook.
    - goodpoint 4y ago
      With the difference that COBOL is clunky and unpleasant while Usenet works very well and it's lightweight.
commandlinefan 4y ago
> It's not as though I can do a COBOL side-project to learn... or can I? My first job out of college - around '94 or so - was working for an accounting software company that sold an accounting package written entirely in RM Cobol for DOS. The entire UI and the backend were all written in Cobol. Poking around a bit, it does look like GnuCobol (https://gnucobol.sourceforge.io/doc/gnucobol.html https://gnucobol.sourceforge.io/doc/gnucobol.html) allows for some screen I/O… so you could put something together on your own machine.
- JD1967 4y ago
  I'm a little older, but similar. My first professional job was in 1985, programming in Cobol on Unix systems, on an accounting package. MS-DOS and IBM PC's were just becoming important, and we did later port to DOS, then Windows. We used Acucobol, and yes, everything was in Cobol. Acucobol had the SCREEN SECTION and you could put up nice text UI forms on terminals. I did a lot of cool things with cursor-point-and-click menu systems, etc. Once ported to Windows, and Acucobol's GUI controls, you couldn't tell the difference between a VB6 program and our Cobol programs. All native Windows controls.
l0ngtimepgmr 4y ago
COBOL is available on many platforms. Health care, Banking, Government and many more. There are many ways to get started with COBOL, pick an emulator/internet site to get some experience with it. If you still are interested get one of the many free accounts on actual hardware/OS and learn the environment.
johnbellone 4y ago
I'll hire you if you want to learn COBOL.
- carapace 4y ago
  "You interest me strangely, sir." Is this a general thing or just for @unsupp0rted?
- jpindar 4y ago
  Really? I'll learn anything if I can get a remote job doing it.
  - johnbellone 4y ago
    If you really want to learn COBOL we're are looking for people all the time. You can drop me an e-mail.
guessbest 4y ago
I work at a place that uses an extensive amount of JCL, COBOL, REX, MK4, VSAM, DB2, and more, and I would say that learning the language is only a small portion of learning the system, batch processing and the database. Learning COBOL without learning how the mainframe works in its entirety is leaving out the major portion of what the language is used for. It would be like using a C64 your whole life and then learning Java from a book, but not having a system to apply it to. The leap is just too great without immersing yourself in ISPF and all the associated proprietary software your shop.
ohm 4y ago
It's not real life but doing COBOL CTF was fun intro https://samsclass.info/129S/COBOL.shtml https://samsclass.info/129S/COBOL.shtml
mkovach 4y ago
Have spent a couple years about 20 years ago dealing with a COBOL applications, I can tell you. Pick up COBOL (GNUCobol is fine) and a book. It isn't that hard of a language to pick up. Then, learn about mainframes since most of the COBOL in the wild is running on z/OS or the like. IBM use to offer a free Mainframe course. You would also want to learn JCL, REXX, and a few other mainframe related tools. The apps are no different then most things now (inventory, accounting, etc.) is is the legacy processes that will most people that biggest problems. And checkout a YouTube Channel by moshix. Lots of great mainframe info there. That would get you started on the path.
- Aloha 4y ago
  I'd argue it's quite an easy language to learn, even. Though there are things what show its Batch background, I used it on z/OS and the fact that the application did none of its own IO was weird for me.
  - mkovach 4y ago
    Yea, it has it quirks (every language does) and does show it's age in things. I didn't mind the language itself, but the application I worked on was inventory related, which was mind-numbingly boring.
atum47 4y ago
I don't know if this could be considered "learning" in the sense that you mean, but I chose code that I wrote in a familiar language and re-wrote it in Cobol. It was fun and I end up learning a lot. https://github.com/victorqribeiro/perceptronCobol https://github.com/victorqribeiro/perceptronCobol
nonamenoslogan 4y ago
I did this a few years ago to support an HP3000 in a new job. Spent a year working with COBOL enough to get semi proficient and feel confident running and editing programs. We eventually turned the system down in favor of web+SQL and I'll likely never COBOL again, but the truth is COBOL is a pretty straightforward and fun language to work with if you're not already stuck in the C/C++ mode of thinking. Its pretty easy to read and decipher.
perakojotgenije 4y ago
Do COBOL programmers really get paid that much? I have more than 10 years of experience with COBOL, and I've left it long time ago because I hated the language. But now I wonder where could I find some of those well paid COBOL jobs (and of course - remote)?
- mywittyname 4y ago
  Not from the evidence available on glassdoor and whatnot. Which makes sense, if job-hopping is the way to level up one's salary, then getting a job where there's like one or two employers in a region is going to keep your salary at the same level. Even if you got a job paying in the 90th percentile in 2010, you'd have a pretty average salary now if you received the standard big corp 2% annual raise given that market adjustments have been in the 8-12% pa range.
michaelsbradley 4y ago
The GnuCobol FAQ and How To might be helpful: http://opencobol.add1tocobol.com/gnucobol/ http://opencobol.add1tocobol.com/gnucobol/ Note that web page is truly massive, it may take some time to load completely.
drugstorecowboy 4y ago
As stated elsewhere, learning COBOL really isn't that hard. It's a different paradigm than you are likely used to but once that clicks you can be relatively proficient in basic COBOL in a few weeks. After getting some confidence you will be ready to begin your first COBOL job where you will open up the codebase to try and get familiar and immediately realize with shock and horror what you have committed to do. The hell and chaos of real world legacy COBOL all consuming. You then sit there, day after day, counting characters and cursing your predecessor for not having that foresight to realize that a number might grow beyond 999. Daydreaming of a time when you didn't know so much about fixed length records, a time when you were happy.
- wpietri 4y ago
  Agreed on most of that, but this is not always right: "cursing your predecessor for not having that foresight to realize that a number might grow beyond 999" My dad was a COBOL developer in the 60s and 70s, and I asked him about this during the Y2K panic. Back then, the cost per byte was extremely high. Even if they had thought people would be foolish enough to keep systems running for decades, they still would have gone with 2 digits for the year because they needed those bits for other things. Looking up the numbers now, in 1969 IBM was selling magnetic disk drives for circa $1/KB[1] at a time when programmers were making ~$200/week[2]. Top data speed was something like 300KB/s. The CPUs processing the data cost the equivalent of 5-10 programmer's salaries to rent. So throwing out the century, a 25% savings on date data storage, was a no-brainer. Not just for the tech people, but from a management perspective. Imagine asking, "How about we fire a couple of our developers so we can buy another drive and make sure this is easy to develop on 50 years from now?" [1] https://www.ibm.com/ibm/history/exhibits/storage/storage_2314.html https://www.ibm.com/ibm/history/exhibits/storage/storage_231... [2] https://fraser.stlouisfed.org/title/industry-wage-survey-life-insurance-4608/industry-wage-survey-life-insurance-december-1971-499009 https://fraser.stlouisfed.org/title/industry-wage-survey-lif...
- thr0wawayf00 4y ago
  > The hell and chaos of real world legacy COBOL all consuming. This is 100000% true. Any decades-old private codebase is going to be a horror show. A friend of mine works for a COBOL-based payment processor and it sounds like the seventh layer of hell working there. More power to those that want to chase the money (which isn't really that great tbh, the mean COBOL developer brings home less than 100k[0].) , but go into eyes wide open. If you're gonna sell your soul for the paycheck, Amazon pays much better. 0: https://www.ziprecruiter.com/Salaries/Cobol-Programmer-Salary https://www.ziprecruiter.com/Salaries/Cobol-Programmer-Salar...
tgflynn 4y ago
IBM offers a free set of courses here: https://ibmzxplore.influitive.com https://ibmzxplore.influitive.com. I played around with it a few months ago. As far as I know it's still available. It doesn't cover COBOL in great depth but does touch on various pieces of the zOS ecosystem and gives you some access to a real mainframe. There's also this COBOL course: https://github.com/openmainframeproject/cobol-programming-course https://github.com/openmainframeproject/cobol-programming-co... I haven't tried the later and I'm not entirely clear on how you get access to a mainframe environment for it.
mindcrime 4y ago
You might get some mileage out of posting on /r/cobol on Reddit. There's a small but somewhat active community of COBOL folks on there.
kjs3 4y ago
There are a number of schools that have mainframe oriented CS programs if you're really serious and have the time/money. Columbus State University has one created in partnership with IBM[1]. They apparently have a pretty extensive corporate outreach program and the folks I've talked to who were in the program were set up post graduation job-wise. That said, I will N-th the caveat that knowing COBOL isn't the job/hard part; it's knowing the extensive ecosystem that COBOL orchestrates. [1] https://catalog.columbusstate.edu/academic-units/business/computer-science/computer-science-bs-enterprise-computing-track/ https://catalog.columbusstate.edu/academic-units/business/co...
pixl97 4y ago
The real question you want to ask is "do I want to work for a bank, Healthcare, or government". I work with these industries, not directly for them, and seemingly the people that work in them seem more miserable than those in other industries. You are dealing with large amounts of regulations and inner organization bureaucracy. Coding, unless you're a contractor is a tiny part of the job, and process is a huge part of the job.
ecshafer 4y ago
I worked 5 years at a large financial services firm with several $T in assets, and as such I have worked with Cobol Developers, though I have not worked with Cobol much directly. They had it splits between Cobol developers on one hand and then the AWS/Java/Javascript developers on the other. There are a few issues with this idea. One is that there is some new Cobol code being written where necessary, but the big firms are trying to get rid of these people. The companies still with a lot of Cobol do want to get off of it, and while this is probably a 20-40 year project, this is not a growing industry, which I think is risky. There are a lot of cobol devs being trained up by the contracting services, which are used by the types of places that still use cobol, so I don't think salaries will ever compete with just being a developer in tech. There is a ton of bureaucracy in the orgs that use cobol, and especially around mainframes in those orgs, so that drives a lot of developers away. Since Cobol devs are often supporting 1-5 systems that they are the only ones that know how they work, and cobol mainframe jobs are typically batch processes, expect to be woken up pretty often in the middle of the night as you are supporting flaky 20 year old code that breaks often, the cobol devs I work with were all doing middle of the night work 1-2 weeks a month. Even if Cobol salary is great I don't think its worth it. The only point I could see it would be good is as a consultant that specializes in moving off of Cobol. I think a Consultant that could sell to these banks that you know how to migrate systems off of Cobol / JCL / DB2 / Sybase / Oracle -> Java / C# / Postgresql, Now that is where the money would be.
Sudharsana 4y ago
A great learning resource for COBOL is the Open Mainframe Project's COBOL Programming Course. The content is self-paced with labs and the best part is you get to do the labs on a real Mainframe. Check it out: https://github.com/openmainframeproject/cobol-programming-course/ https://github.com/openmainframeproject/cobol-programming-co...
Sudharsana 4y ago
The content is also available in video format on IBM Learning platform. You get to do the labs through the video course as well and earn a badge. You can check that out here: https://learn.ibm.com/course/view.php?id=7552 https://learn.ibm.com/course/view.php?id=7552
tlrobinson 4y ago
Related question: what's the modern COBOL, meaning the thing that will require well-paid niche programmers to maintain in 30 years?
apohn 4y ago
>COBOL devs are a specialized niche these days and they get paid accordingly. Tell that to all the people in outsourcing Firms (e.g. Infosys) who end up coming to the US from India to work on COBOL Mainframes as contractors. The large companies hiring those outsourcing companies are doing that because they don't want to pay top dollar for a COBOL devs. I don't think they even want to deal with evaluating and hiring COBOL Devs. I know somebody who was in that situation. Was paid decently, but nothing special you couldn't get from any other Dev job.
dontbenebby 4y ago
Check if the University of Pittsburgh School of Information Science is still offering their course, and if it's offered online if you aren't blessed enough to live in the "Paris of Appalachia". (I regret not taking it when I was an undergraduate. That, screenwriting with the guy who wrote snakes on a plane, and a creative nonfiction class are things I'll be forever regretful I skipped to take infosec courses that simply certified things I'd known since before I had finished puberty.)
ddlittle 4y ago
I went to a computer conference in the mid 80’s for my first job after college - where COBOL, IBM/360 assembly language and FORTRAN were required CsC courses - and the international attendees used COBOL as a common speaking language. So conversations like IF HUNGRY PERFORM EATING were common. haha.

Stampo00 4y ago

The old pros are continuing to age out and retire or die. Places with COBOL systems want to keep their applications limping along instead of replacing them. The shortage of devs is only going to get worse. Remember when lock down started and some government systems built on COBOL started straining under the load? Rather than being dismissive, I'd encourage those with any interest at all to try to pick it up. We need folks to maintain it.

thr0wawayf00 4y ago
> We need folks to maintain it. Beware, maintaining those systems is absolute hell and the companies experiencing exodus are working their people into the ground because the workload is crushing them and they can't find replacements. A good friend of mine is an engineering director at a company that runs a massive COBOL mainframe platform and he always half jokes with me about picking it up. The money isn't that great at his company and the problems they have maintaining the system just blow my mind. The entire company sounds fundamentally unsustainable long term but they're running critical payments infrastructure.
- masukomi 4y ago
  as an outsider (and thus potentially ignorant of pitfalls): I'm a big fan of the strategy to add transpilers to modern languages so that we can start writing new code in them, have them output COBOL, and then eventually have enough of the codebase written in the new lang to swap over to it instead. I'm thinking of the Elixir->COBOL like this: https://github.com/TheFirstAvenger/cobol_to_elixir https://github.com/TheFirstAvenger/cobol_to_elixir Was speaking with the author about a year ago and he was having really good success with it.
  - jhugo 4y ago
    This again focuses on the language rather than the environment. The real issue is all the legacy integrations, and the runtime environment, not the language. A transpiler is solving the easiest part while leaving all the difficult problems unaddressed.
  - ElectricalUnion 4y ago
    A transpiler/compatibility layer is usually fine, but what you (probably) want instead is a IBM VSAM, IBM JCL, and IBM CICS transpiler/compatibility layer instead - COBOL by itself is very simple and we have working compilers for it already; JCL, VSAM and CICS however, not - that's where the real complex, distributed and hard to reason about parts are.
  - p_l 4y ago
    The big issue is that for considerable portion of extant COBOL software, you have to deal with entrenched runtime environment. Purely batch processing COBOL might be easier to move to newer languages... And possibly was already picked for rewrite. Where you're going to hit major issue is with COBOL running under the likes of CICS or IMS, where sure, you can use some more recent languages, but what you'll get in the end will be possibly even worse because now you'll have to find Java programmer who knows CICS. And CICS or IMS aren't that easy to replace.
  - karmakaze 4y ago
    The example link goes COBOL->Elixir. I like this idea of writing Elixir and outputting COBOL. That way it can interface with the operating environment (CICS, IMS) exactly as a natively written COBOL program does. Not that COBOL syntax is particularly hard to learn one by one, but as a whole isn't very memorable. Why learn a programming language with peculiarities like a natural language when I can use something concise that translates to it? There may not need to be a step to eliminate the COBOL output step any more than a language that uses C or js as a target. I've only seen two kinds of CICS programs in the wild: 1. screen I/O using preformatted BMS maps, 2. transactional with input buffer and output buffer. A third kind was one I wrote for sending dynamically generated terminal stream data for a hypertext online documentation system. Any of these could be written in Elixir with appropriate libraries and translators. The company I worked at generated the BMS maps and COBOL source from assembling program components with an inclusion/override macro processor and wysiwyg editors--think Visual Basic for mainframes targeting both CICS and IMS.
- nebula8804 4y ago
  >running critical payments infrastructure Please tell me its not a payroll company.
  - thr0wawayf00 4y ago
    No, it's one of the largest credit card processors in the country.
    - krylon 4y ago
      I'm not sure if that makes me feel better.
BLO716 4y ago
Banks. Period.
- bidirectional 4y ago
  Working on incredibly boring retail banking systems which are a maintenance nightmare. If you want to work in a bank you'd get paid more working on front office software at an investment bank.
- logical_ferry 4y ago
  I don't work with COBOL but.I had my fair share of old legacy codebases. I sometimes think about how this crappy codebase first started out. Somebody somewhere had to write the first line of code. Was it exciting for them? Was it a sunny day? What did their office look like? Then I look at the codebase again and all this sentimentalism vanishes.
thaumaturgy 4y ago
I do remember that, and as I pointed out in the thread at the time, New Jersey was asking for volunteers: https://www.cnbc.com/2020/04/06/new-jersey-seeks-cobol-programmers-to-fix-unemployment-system.html https://www.cnbc.com/2020/04/06/new-jersey-seeks-cobol-progr... My first dev job was COBOL on a Unisys mainframe. When the volume of "omg we need COBOL devs" articles got loud, I looked into what was available. The compensation graph for COBOL positions approximately matches those of any other dev job. You can do as well (or better) as a Python dev or Node dev or whatever. The key to making more money is in specialization. The highest-paying jobs are looking for experience with specific combinations of technologies. But being a Python dev has the added advantage of not having to deal with COBOL. ...speaking as someone who used Unisys' STRING/UNSTRING OS functions to implement input variable interpolation in COBOL because it has no native string operators or data type.

shireboy 4y ago

This is true, but the niche should be a dev who knows COBOL IRL enough to translate to something newer. Much of the COBOL I've seen would be trivial to rewrite, just nobody wants to tackle it. A person who 1) Can read cobol 2) can communicate well with stakeholders and 3) can translate to NodeJS/Python/.NET should be able to fit this niche pretty well. I've done this before - translate green screen apps to ASP.NET. In my case, the company had (retiring) IT staff read the cobol and give us good "plain english". The actual ASP.NET code was trivial. That said, my one caveat is I don't feel like any language today has the longevity of these systems. That code was ASP.NET 3 MVC - new at the time, but outdated now. What stack do I pick today that will still be running in 30 years? HTML+JS+NodeJS seems the most likely candidate IMO, but then you get into the various frameworks-du-jur and it sort of falls apart. Would love HN opinions.

goodpoint 4y ago
Some banks tried to jump on the Java bandwagon when it was the hyped up thing of the moment and now many are going back to COBOL. > HTML+JS+NodeJS seems the most likely candidate IMO So that my bank can run npm install leftpad on their payment processors. Please tell me this is parody.
- shireboy 4y ago
  Hah, well, right. I just meant from a longevity standpoint. What stack can I use today that is and will continue to be well supported for 30+ years?
  - canon123456 4y ago
  - jhugo 4y ago
    C, C++, probably Rust, various other relatively boring languages. If Node.js is even still used in 30 years it won't look anything like today's Node.js.
  - djbusby 4y ago
    I've converted some legacy apps into, not a joke, PHP3. In like 2006-8. So, PHP3 still works this many years later (in VMs). Currently working to migrate to PHP7. It's just moving business data into and out of, in many cases still file based records (but maybe we can upscale to SQL). So, if you can read the COBOl and implement correctly in the next blessed language (with tests). Harder part is to meet the folks that can get you those gigs than actually doing the gigs.
  - goodpoint 4y ago
    Come on, are you serious? COBOL is still being used exactly because it does not have a high-churn ecosystem. Same for C and C++. Of all languages, js is by far the most volatile.
- absove 4y ago
  > Some banks tried to jump on the Java bandwagon when it was the hyped up thing of the moment and now many are going back to COBOL. What's wrong with Java that COBOL doesn't suffer from exactly?
goatlover 4y ago
What makes you think HTML/JS/Node will be anything like it is today 30 years from now?
- jazzyjackson 4y ago
  they are good enough same reason we are flying 737 aircraft and chinook helicopters, well after we tried concordes and space shuttles. see "Web Design: the first 100 years" for more: https://idlewords.com/talks/web_design_first_100_years.htm https://idlewords.com/talks/web_design_first_100_years.htm
pc86 4y ago
> What stack do I pick today that will still be running in 30 years? This is such a backward mindset, though. Software evolves. Ecosystems evolve. Perhaps most importantly, security risks and surface areas evolve (which in part necessitates the prior points). There is no good reason for systems to stagnate over three decades. Software isn't construction, it's gardening, and it requires constant maintenance and attention.
- ElectricalUnion 4y ago
  > Software isn't construction, it's gardening, and it requires constant maintenance and attention. Software is like construction, you don't demolish everything and start from scratch just because it's a little, or very old. Discarding everything and rewriting in another language is a expensive and error prone process. To cite the excellent Joel blog: > the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  - pc86 4y ago
    Where did I suggest rewriting things from scratch?
hyperman1 4y ago
Some killers here are the data model and the unknown edge cases. And the size. The data model is fixed width flatfiles with very specific access and index methods. There are 50 years of workarounds applied in there. Whatever code you end up with will still need to communicate with all the other stuff, so the data model can't change untill you got everything touching it in the new language. The edge cases are a second problem. The code runs well in a very practical sense, as every major bug relevant for the end user has been fixed or worked around ages ago. Or it became the correct behaviour by sheer overwhelming force. You replace something insane, then find out you broke another system that had counterbalancing insanity. Worst case, it will run for a few months, silently corrupting data. Next tax round or year end, some report says something strange, and subsequent troubleshooting uncovers major doodoo. No, the taxman wont wait on your bugfix. Then there is the sheer volume of code. 10 million lines is small scale. You can spend your whole carreer rewriting everything in the most trivial way, and 40 year later find you're not even close to done. There will be multiple failed rewrites in there, causing massive lavaflow architecture problems.