I've done COBOL based web stuff on the IBM i/AS400. Nothing particularly tricky about it, wouldn't really recommend it for anything super complex. But it's less of a hassle then the various "tools" that's ment to make it easier, which always have horrible browser based configuration interfaces and stupid limitations. Just point Apache to a binary, read environmental variables and print to stdout. Using it doesn't really make sense as such, but developers who only know COBOL can just write regular programs and be done with it.
Well, tools is probably not the right wording. But solutions for making systems accessible over web APIs. There's usually in-house solutions. But IBMs own, "IWS"(https://www.ibm.com/support/pages/integrated-web-services-ib...), is probably the main one I've heard of. I can't really remember all the solutions to serve up html pages.
It works. You pass stuff in and out through what would best be described as ARGV. Some Java middleware and so on analyzes the program to determine the amount, name and length of in and out variabels.
The process is that you choose to deploy a service, choose between SOAP and "REST" and point to your program. You then get to specify the resource name, description and a regexp for your path. The resource name becomes a part of the URL. You then specify which variables are input and which are output. And after that assign some generic settings and choose which variabels are sent in as a part of the path and not and so on.
Works sorta nice. Some drawbacks are that you'll still need to add rewrite rules to get actual restful URLs, since the URL of your service will be along the lines of http://example.com/web/services/<resource name/<your regexp>. If your program is written in COBOL instead of RPG, all variable names will be in all cap. There's a max size to how much data you can send in or return that's not super small, but around a few MB unless my memory fails me.
I mean it's almost there, just not really good if you ask me. It could use some love. Also anything you're unsure of results in you having to dig into the hell hole that is IBMs website. Not exactly made easier by some buffoon naming the platform as such into a three letter name of one of the worlds biggest companies followed by a space and a single letter. So google is worse than useless.
I've found most in-house solutions to be more reliable.
Redhat's "Command Line Heroes" podcast has a very insightful episode about COBOL and Go, talking about legacy languages, and how all languages may or may not become legacy, and their impact on new paradigms like the web (and vice versa).
My takeaway is that particularly with COBOL, there is a vested interest in the finance industry to find and retain COBOL talent, and making efforts to popularizing a language for the web is essentially a recruiting tactic more than anything else.
I wonder how the market for that is now, and how it will be a decade from now. I imagine a lot of the people with significant experience working with COBOL and mainframes are getting older and retiring
Eventually companies will pay people to get up to speed on older technology like RPG and COBOL. For sure, they are fighting it hard, but I don't see a lot of other options. It's harder for me to imagine all of this legacy software being replaced with new code.
It is substantially cheaper to train people and training people in COBOL is easy. Some businesses are starting to realize and even try to encourage IBM to do more to promote their products.
As another user said, allowing people to spin up z/OS would be awesome. As of now, it's not really practical to learn without direct access to mainframes. So all the cost is on the business to train devs. Which is not as important in other dev positions
I used to work in a medium sized college town in the midwest that basically had 4 places for software developers to work. The university, the "fun" software company (where I worked), and a couple insurance companies.
We hired a lot of people from the insurance companies and they all basically said that they would hire anyone with a science type degree that was willing to learn COBOL.
I actually know a bank with an office close to me that still recruits COBOL developers to maintain some of their old legacy systems, while they slowly transition to newer tech. These people get paid pretty well by the way.
Since COBOL usage seems to be heavily tied to high transaction volume mainframes (I'm deliberately ignoring the i Series here), which currently mean IBM zOS-based machines, a good approach would be to make zOS easily accessible to hobbyists and students. IBM has a couple products in their cloud that are running on Linux under zVM. It'd be great if I could bring up a small zOS VM and play with it the same way I can make a small x86 Linux VM on just about any cloud provider.
Oh... And the same applies to Linux on POWER (which is more accessible), AIX on POWER (which is less accessible) and Solaris or Linux on SPARC (Oracle could offer their machines on their public cloud).
There is a huge amount of coolness outside the x86 server space. We should ask for the companies who make it to create more onboarding routes for those machines, unless they want the market to think they are internally considered dead ends (I'm looking at you, Larry Ellison).
The blogpost describes how to get the web stuff done, then moves on to API routing. This post has reminded me that I need to write part two of the article which covers parameter handling and so on...
Sure, there is always going to be someone working a less comfortable job, but that should not keep people from pursuing better working conditions.
On the contrary, those working in less favorable conditions should be the ones to take other jobs as an example and precedent to make their job better.
oh man after actually looking at the website again, I realized that I had the two confused for some reason and posted the wrong one. at least someone came through and gave the proper one.
What are the actual business opportunities for cobol programmers? Are there chances for remote work, freelance consulting per project, etc. ? Or it's just office jobs in banks?
COBOL consultancy is a niche, but one that pays poorly (against what internet common sense would have you believe). All the COBOL consultants I know are not doing particularly well; they are mostly old guys who naturally ended up in that role. They occasionally must switch jobs when their services are no longer needed. The new jobs don't pay well either. They usually do not want or can learn new skills.
There is young blood learning COBOL, but really, they don't stay long doing that. If you're young and in tech, there's a world of more exciting opportunities out there.
Understatement of the year! (lol) Joke aside, 100% with you on this. Not sure about the pay, here in Luxembourg (lots of banks) it seems alright compared to other domains of programming.
It's easier when your problem space has been relatively identified for the past 20 years or so. Quite a different conundrum for e.g. Python or the (in)famous Js situation-s (coughTs)
I tend to have respect and admire historical 'niches' like COBOL systems when they speak of such amazingly sustainable designs, resilience that outlive human careers, lives even — like big old trees. There's something noble about working these, me thinks. How will it feel to interact with a centennial system come 2100-ish? I'd wager mind-numbingly tedious and a privilege all at once. (unless we've solved "legacy" by then, who's with me? ok, Go :=)
I suspect you're right that the median is low-ish, but if you're able to convince any of the major banks or bank-IT firms in the US that you're reasonably able to solve their problems with COBOL, there's no shortage of jobs in the $150-200k range -- which is insanely high for engineering jobs on the east coast.
I got hired as a COBOL dev just recently, in a low cost of living area, fresh out of college, for 55k. Salary will certainly go up. I see average in my state as 70-90k/year with some experience.
I agree cobol dev's salary aren't absurd, it is slightly below other dev positions. There is an opportunity for lots of money, but it comes with immense experience and understanding of specific business logic. Overall, it's not bad pay for having a pretty easy and consistent workflow. And no fads to deal with.
Animated gifs, grey backgrounds, tables for layout, frames & sub 100Kb page sizes. I remember those days fondly. A lot of web development was much easier back then but could also be very frustrating trying to get the simplest things to work.
I wonder how long this could last in a container on kubernetes with a million other microservices. Could the author develop something so rock-solid nobody looked at it until after they left? Then imagine the face on the intern asked to add feature X years later after they dig into the code.
COBOL is a loose abstraction over 1950s assembly languages. You know, the ones with built-in support for decimal arithmetic and no support for recursion.
34 comments
[ 1.8 ms ] story [ 56.2 ms ] threadCan you share what exact "tools" you are talking about?
It works. You pass stuff in and out through what would best be described as ARGV. Some Java middleware and so on analyzes the program to determine the amount, name and length of in and out variabels.
The process is that you choose to deploy a service, choose between SOAP and "REST" and point to your program. You then get to specify the resource name, description and a regexp for your path. The resource name becomes a part of the URL. You then specify which variables are input and which are output. And after that assign some generic settings and choose which variabels are sent in as a part of the path and not and so on.
Works sorta nice. Some drawbacks are that you'll still need to add rewrite rules to get actual restful URLs, since the URL of your service will be along the lines of http://example.com/web/services/<resource name/<your regexp>. If your program is written in COBOL instead of RPG, all variable names will be in all cap. There's a max size to how much data you can send in or return that's not super small, but around a few MB unless my memory fails me.
I mean it's almost there, just not really good if you ask me. It could use some love. Also anything you're unsure of results in you having to dig into the hell hole that is IBMs website. Not exactly made easier by some buffoon naming the platform as such into a three letter name of one of the worlds biggest companies followed by a space and a single letter. So google is worse than useless.
I've found most in-house solutions to be more reliable.
I think it really does just come down to what language you're most familiar with.
https://www.redhat.com/en/command-line-heroes/season-3/the-i...
My takeaway is that particularly with COBOL, there is a vested interest in the finance industry to find and retain COBOL talent, and making efforts to popularizing a language for the web is essentially a recruiting tactic more than anything else.
As another user said, allowing people to spin up z/OS would be awesome. As of now, it's not really practical to learn without direct access to mainframes. So all the cost is on the business to train devs. Which is not as important in other dev positions
We hired a lot of people from the insurance companies and they all basically said that they would hire anyone with a science type degree that was willing to learn COBOL.
Oh... And the same applies to Linux on POWER (which is more accessible), AIX on POWER (which is less accessible) and Solaris or Linux on SPARC (Oracle could offer their machines on their public cloud).
There is a huge amount of coolness outside the x86 server space. We should ask for the companies who make it to create more onboarding routes for those machines, unless they want the market to think they are internally considered dead ends (I'm looking at you, Larry Ellison).
https://www.bencollier.info/cobol/programming/projects/fun/r...
The blogpost describes how to get the web stuff done, then moves on to API routing. This post has reminded me that I need to write part two of the article which covers parameter handling and so on...
On the contrary, those working in less favorable conditions should be the ones to take other jobs as an example and precedent to make their job better.
Exception of course for consultants with a following, and customers that believe you have 'unicorn' skills.
One advantage is the software stack is mature and not subject to fads and fashion.
COBOL consultancy is a niche, but one that pays poorly (against what internet common sense would have you believe). All the COBOL consultants I know are not doing particularly well; they are mostly old guys who naturally ended up in that role. They occasionally must switch jobs when their services are no longer needed. The new jobs don't pay well either. They usually do not want or can learn new skills.
There is young blood learning COBOL, but really, they don't stay long doing that. If you're young and in tech, there's a world of more exciting opportunities out there.
COBOL has a terrible rap, so the kind of young people who would still work with it are a self-selecting group... in a bad way.
Understatement of the year! (lol) Joke aside, 100% with you on this. Not sure about the pay, here in Luxembourg (lots of banks) it seems alright compared to other domains of programming.
It's easier when your problem space has been relatively identified for the past 20 years or so. Quite a different conundrum for e.g. Python or the (in)famous Js situation-s (coughTs)
I tend to have respect and admire historical 'niches' like COBOL systems when they speak of such amazingly sustainable designs, resilience that outlive human careers, lives even — like big old trees. There's something noble about working these, me thinks. How will it feel to interact with a centennial system come 2100-ish? I'd wager mind-numbingly tedious and a privilege all at once. (unless we've solved "legacy" by then, who's with me? ok, Go :=)
I agree cobol dev's salary aren't absurd, it is slightly below other dev positions. There is an opportunity for lots of money, but it comes with immense experience and understanding of specific business logic. Overall, it's not bad pay for having a pretty easy and consistent workflow. And no fads to deal with.
http://www.cobolgoldmine.com/
http://www.coboloncloud.com/
SQL is COBOL for relational data.
COBOL is a loose abstraction over 1950s assembly languages. You know, the ones with built-in support for decimal arithmetic and no support for recursion.