
Cobol Web Development - gscott
http://www.infogoal.com/cbd/cbdweb.htm
======
tolle
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.

~~~
numlock86
> But it's less of a hassle than the various "tools" [...] which always have
> horrible browser based configuration interfaces and stupid limitations.

Can you share what exact "tools" you are talking about?

~~~
tolle
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...](https://www.ibm.com/support/pages/integrated-web-services-ibm-i-web-
services-made-easy)), 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](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.

------
arvidkahl
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).

[https://www.redhat.com/en/command-line-
heroes/season-3/the-i...](https://www.redhat.com/en/command-line-
heroes/season-3/the-infrastructure-effect)

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.

~~~
non-entity
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

~~~
cmiles74
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.

~~~
OGWhales
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

------
bencollier49
I put together a REST API for COBOL a while back:

[https://www.bencollier.info/cobol/programming/projects/fun/r...](https://www.bencollier.info/cobol/programming/projects/fun/retrocomputing/2019/03/26/cobol-60-give-
rest-framework-birthday.html)

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...

------
ozzmotik
I'm certainly surprised I don't see a mention of
[http://www.coboloncogs.org/INDEX.HTM](http://www.coboloncogs.org/INDEX.HTM)
anywhere.

~~~
etaioinshrdlu
Also: [https://github.com/azac/cobol-on-
wheelchair](https://github.com/azac/cobol-on-wheelchair)

~~~
ASalazarMX
I'm in a mix of offense and amusement because __COBOL on Cogs __is the joke
and __COBOL on Wheelchair __is the serious one.

~~~
ozzmotik
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.

------
exabrial
COBOL is a loose abstraction over assembly. Don't laugh, it's fast, and it'll
outlive you.

~~~
msla
COBOL is jq for column-oriented data.

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.

------
Bnshsysjab
I’m gonna save this link for when my dev friends complain about their jobs

~~~
gchamonlive
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.

------
perspective1
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.

------
scrp
A great history of web designs in the links (for those that still works) in
that page

~~~
tudelo
I find this one interesting: [http://www.ils-
international.com/goldmine/webcobol.htm](http://www.ils-
international.com/goldmine/webcobol.htm)

~~~
jrumbut
I would really like to hear more from the author of these pages:

[http://www.cobolgoldmine.com/](http://www.cobolgoldmine.com/)

[http://www.coboloncloud.com/](http://www.coboloncloud.com/)

------
ivanhoe
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?

~~~
bdavis__
Although there is perceived demand, COBOL jobs pay very poorly. Like $50K.

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.

~~~
sigzero
This is the first post I have ever read that stated: "COBOL jobs pay very
poorly".

~~~
the_af
If it helps, it's my experience as well.

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.

~~~
ivanhoe
There's also a lot more competition. Question is just how hard is it to get
outsourcing contracts in COBOL world?

~~~
the_af
Young people tend to prefer excitement to lack of competition.

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.

