Cobol Web Development
infogoal.com
infogoal.com
Can 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...
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.
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.