Does anyone knows a job board for people interested to work with COBOL?
I have been interested in this language for quite some time, moved to a different country just to try to find a job where I could learn more about it and build up a career, unfortunately the city that I chose doesn't seems to be have many offers. Most of the jobs require several years of experience doing low level programming, and although I work with system programming languages (C++, Go) I don't have relevant experience working with COBOL which seems to be killing my opportunities.
It's like the chicken or the egg causality dilemma, I want a COBOL job but everyone requires someone with relevant experience, but how can I get experience if no one hires me to work with COBOL? LOL — I am willing to take a junior-intermediate position if necessary, if anyone has a suggestion (company names, job boards, etc).
Thank you in advance.
EDIT: I am in Vancouver, BC, Canada if anyone is interested.
Here in Jacksonville, FL the COBOL market is very much in demand. There are companies like transportation, financial, and insurance companies here that have mainframes using COBOL and hire COBOL developers. I believe I remember hearing that these companies have even funded a COBOL program at one of our local universities so they have more talent available, which means they are open to entry-level developers. I don't want to mention any of the company names on the chance that I might misrepresent them (and some of them are my customers), but you can easily find them by searching job boards like Indeed. I'm sure if you mentioned to a recruiter with national/international connections that you wanted a COBOL job you could find one, although you might have to move.
What are these companies like culture wise? When I think COBOL I think of companies requiring a suit and tie in a Dilbert esq company, is that the case? This puts my off more than the language itself.
The people I've met coding Cobol are all stuck in strict 8-17 jobs, with no flex time and weekend stints, with really rigid bosses who do not allow you to take family leave.
The money seems ok though, but flextime and two hours less per day is worth a lot of money to me.
> I have been interested in this language for quite some time
Out of curiosity: do you mean you find the job prospects interesting, or the language itself? Because I'd understand if it's a money thing, but... I used to work with COBOL and I wouldn't wish the language on anyone.
> I used to work with COBOL and I wouldn't wish the language on anyone.
There are worse things. I'd rather work on Cobol than in PHP4, or in a project where I have to deal with front-end stuff done using JS and back-end stuff that relies on the NPM package ecosystem.
When I used to ride the train to work a few years ago, one of the happiest appearing people I met on the train was a young (30 something) COBOL programmer. He was examining a green-bar fan-fold printout of COBOL code that was part of the back-end of a gas station point-of-sale system. He told me that there had been an issue with a transaction the night before and he was going to try to solve it that day.
Sure, I spent my time figuring out COBOL code (thankfully, code printouts were already going out of fashion back in 1998, when I had that job. I can't for the life of me picture someone reading a printout today. Then again, I still occasionally see middle-aged people reading printed emails in the subway. Go figure) and of course solving problems is exhilarating!
I'm just saying being forced to use COBOL sucks, because it's uninteresting and outdated technology, and mostly nobody would choose it of their own volition, so most COBOL use falls in the category of "being forced to use it". Interest in retrocomputing aside... and there's better retro stuff to be interested in, anyway!
I think the greenbar fanfold was a great way to review code. Instead of being limited to ~100 lines on the screen, you could see the entire file at once, jumping from piece to piece, and annotating it with a pen.
> (thankfully, code printouts were already going out of fashion back in 1998, when I had that job. I can't for the life of me picture someone reading a printout today.
For me, the best way to review source code is to have it printed, where it is easy to annotate.
In fact i think i will buy me a printer at home for the very same purpose.
I cast a +1 one-upmanship spell and invoke the line printer. Those things probably had lead ingots in the bottom so that they wouldn't walk across the room.
It's easy to annotate code using modern interactive tools, and even easier to share these annotations with other people. Plus, modern tools also let you inspect the code, analyze usage, etc.
I think the best way to get into this area will be through networking. Perhaps work on finding a good conference or meetup group where you're likely to meet a Cobol developer.
Now, as the exactly what sorts of events you're likely to meet a stereotypical Cobol developer at....I'm not sure. Perhaps look up your local shuffleboard and canasta clubs and go from there. :)
I'd love to give it a shot. I'm a retrocomputing enthusiast (don't get me wrong, COBOL crowd) and I'd love to get to know more about how mainframes, their care and feeding.
Put it on your LinkedIn and you will be contacted. This is the reason I removed every reference to it (not because of the language perse, more because of the culture of the companies & departments that will wanted to hire me). Expect to only be allowed to work 9 to 5, on prem, have the stricktest of duty segregations, sit at an old desk and lunch with 'the team' from 11:27 till 11:49 sharp. Where COBOL coding will not get you a date, it will pay rather decent.
not ever been a mainframe guy, but also part of the thing is not so much cobol but understanding all of the various mainframe arcana for whichever system is used.. you might try to 'sneak in the back door' e.g. via java-on-mainframes and get systems experience on the big iron, then step slowly over to the cobol side of things..
>"After almost 7 years of continual improvement and refinements since
OpenCOBOL version 1.1 and 3 years after the release of GnuCOBOL 1.1,
the GnuCOBOL team is proud to announce the formal release of
GnuCOBOL 2.2."
They took 7 years to go up to GnuCobol 2.2; congratulations for this task. My congratulations are sincere; COBOL compilers are very expensive (MicroFocus, anyone?), so it is great to have a GNU compiler.
GnuCOBOL also has the single most comprehensive FAQ in existence. Their docs are amazing. I haven't worked with the tool directly but its helped me solve problem in other languages.
To those who are curious - Most of the COBOL jobs would be on the Enterprise side. Banks , Insurance , Retails , Automobile , Airlines , Utility Companies , US Government , etc. Mainly hosted on Mainframes
It's not for everybody. You cant do all those cool shit (compared to modern languages and tech stacks) - it has its own stack. One of the main barrier to entry is access to a Mainframe. Sure there are emulators , but nothing beats playing around with the real thing. If IBM really wanted to secure talent , they should really address this. People are willing to pay for access as long as it doesnt burn a hole in one's pocket.
I would also love to see a z/OS hobbyist program. Sadly, I doubt IBM is ever going to do it (but you never know).
In the meantime, anyone can download and run the public domain MVS 3.8J, it is ancient but it includes a lot of the basic technologies of z/OS (JCL, JES2, VSAM, VTAM, TSO, 3270, etc), just in much older versions (essentially 1970s vintage).
I believe TK4- includes the MVT COBOL compiler from 1972 (which was the last COBOL compiler version IBM released into the public domain), although I've never tried it myself.
I was always a bit mystified by the opencobol -> gnucobol transition. I vaguely recall reading something about for profit, third parties not playing nice and extending opencobol and then not opening their code or contributing back to opencobol. And opencobol's move to gnu was in part a way to get more muscle for license enforcement. Does anyone reading have more information on that situation? Did I imagine it?
This information is outdated, SourceForge at the time was owned by a company that tried to squeeze everything out of it but it was bought last year by some people who seem interested in restoring its reputation and functionality. The first thing they did when they bought the site was to remove all that stuff, cancel the DevShare program and install automatic malware detection software (based on BitDefender and ESET). They also removed all the misleading ads and disable them for logged in users.
> This information is outdated, SourceForge at the time was owned by a company that tried to squeeze everything out of it but it was bought last year by some people who seem interested in restoring its reputation and functionality.
It's worth remembering that the company that initially tried to do the squeezing spent many years being a decent FLOSS citizen. That's the reason so many open source projects were hosted on Sourceforge in the first place.
Honestly, can you think of a more appropriate platform to host a COBOL compiler? Google Code maybe? A Gopher site somewhere? Telnet into a BBS to download it?
I keep meaning to find the time to write something useful in COBOL. I've got a few ideas on useful things that would be a good fit for COBOL, but I haven't found the time to do so.
I mainly want to do this for the learning experience. New languages/frameworks/etc are cool, but old ones are special in their own way too.
Reports. Batch processing. Business logic in desktop applications, provided you have a good framework and a compiler that works for your target environment. (I can't get into too many details for contractual reasons.)
COBOL is English and generally easy to read, and the worst pitfalls are well known. As a result it's also easy to teach to anyone that has the slightest concept of logic. Especially managers, accountants, or other typically non-tech folks that ask for such reports or applications. It's much nicer to write software for folks that understand the limits of the tools being used to create it.
The obvious answer is banking - A quick search of jobs in Toronto tells me that at least three of Canada's big five banks are running COBOL. It wouldn't surprise me if the rest of the big five were as well, they just didn't have any jobs on the first page of listings.
Whether it shines or not in comparison to more modern languages is another matter.
never worked in it, so cant actually say,
but reading on the language periodically it seems to me actually kind of cool since it is so minimal and so designed around storing and retrieving data records and doing basic processing on them.. in a sense it is kind of like a minimalist programmable database engine that compiles to machine code..
Having used COBOL when I first started working, I can assure you "minimal" is not a word I'd usually think of in relation to this programming language. "Verbose" and "cumbersome" are more like it :)
Disclosure: Starte career as a COBOL programmer for NCR in 1982.
COBOL is a great language for its intended purpose. As it C, python, Lisp, .....name any language in top 50 on TIOBE index.... These days i think of it as a DSL for business transactions.
To those people having a hard time getting a job the biggest hurdles are in the runtime environments. COBOL is so simple you can learn it in a weekend assuming you know programming basics and concepts well. However....runtimes are a different thing. What the hirers are trying to find is people with knowledge in VRx, CICS, JCS and various other obtuse and arcane environments for running COBOL programs and no books are going to give you that. My observation is that why people with no experience in the language get turned away.
However if you do want to use the language it was one of the very first to embrace the concept of transactions and using queues as an ESB for load balancing and true modular, scalable systems. Modular COBOL systems read next item on the que to which they subscribe, get the message content, and then process it, and putting an output message onto another queue. I remember working with a retail system in NZ in mid 80s and it was doing millions of transactions per hour, using tape reels for and those old washing machine disk drives. So called "modern" tools and architectures struggle with such loads. There are banks, airline systems, finance systems the world over that were built with this stuff, and its still running not just because it works, but because nothing better (when one looks holistically at the system) has come along. Mentions in HN, loads of stars on github do not a failsafe financial system make.
i code in python for own projects and c# at work(Im a product manager so im dabbling not full-tilt product dev) and frequently groan at how modern languages make simple things so hard. Yes I knows its a function of environment but sorry, I was programming systems in early 80s that did more, were more reliable, stored data safely on devices that now look only marginally better than stone tablets, and they worked. Business got done.
Also bemoan my loss of productivity as i got sucked into the change-compile-rinse-repeat mentality that pc brought to the world. In old days i could get 1000 line and up COBOl programs working from scratch(no templates, no COPY) within 4 compiles and couple of days max, just by paying attention to what and how i wrote the code.
End of rant.
Im a huge fan of COBOL, Pascal, C#, Python, javascript, Perl, PHP when used for the right things. I have even been known to write some VB when it was the right tool for the job.
Last comment - best wishes with your job hunt. As other posters have suggested, look as far afield as you need to, be brave, take a plunge, and make sure you know your fundamentals so that if COBOL doesnt work for you, you can switch to another 'dialect' of computing and try again.
Late 80s, I started professionally on Unisys 1100 systems and ohmygod. The runtime environment was such a disaster. Like half a days work to set up a runstream to compile your damn program. The printout, which you could pick up 45 minutes later at the central printer. It was not all bad: You really worked hard on avoiding syntax errors, before sending your code off for compilation.
It was also strongly advisable not to forget your (if I emember correctly uppercase, up to 8 characters and numbers) file names. Hierarchical directory structures? That's probably for Sissies.
Anyway, when I moved to VAX/VMS and after writing my first program I asked a colleague.
"So, how do I comile that?"
"Well, you type:"
cobol $program (or COBOL $PROGRAM, VMS is case agnostic)
I thought he was making fun of me after the Unisys experience, but nope. That was it. (Ok, you then had to link it, which wasn't really more complicated).
To this day I think VMS is the best OS I have ever worked with.
Ahh, you bring back so many great and not so great memories... :)
I have been interested in this language for quite some time, moved to a different country just to try to find a job where I could learn more about it and build up a career, unfortunately the city that I chose doesn't seems to be have many offers. Most of the jobs require several years of experience doing low level programming, and although I work with system programming languages (C++, Go) I don't have relevant experience working with COBOL which seems to be killing my opportunities.
It's like the chicken or the egg causality dilemma, I want a COBOL job but everyone requires someone with relevant experience, but how can I get experience if no one hires me to work with COBOL? LOL — I am willing to take a junior-intermediate position if necessary, if anyone has a suggestion (company names, job boards, etc).
Thank you in advance.
EDIT: I am in Vancouver, BC, Canada if anyone is interested.