
IBM will offer free COBOL training - jacobedawson
https://www.inputmag.com/tech/ibm-will-offer-free-cobol-training-to-address-overloaded-unemployment-systems
======
watt
It's a trap.

The problem with those old codebases that governments, hospitals, big
businesses are struggling with is not really the language, it's the
engineering practices of that time with regards to constraints of old
technology. The language is not the problem - lack of comments, bad variable
naming, bad structure (little or no procedures or readability), and just sheer
volume of it, is.

It would be very interesting to see the old systems rewritten in a modern
language, with modern engineering practices, but keeping the old UI and UX
(which often is incredibly ergonomic) - so as to limit scope and not mess it
all up by trying to introduce mouse navigation and windowing mess.

~~~
zxcvbn4038
Not to mention GOTO. If your one of the people who hyperventilates when you
see a goto because you learned that it was considered harmful in programmer
school then Cobol might not be for you. ;)

You might be surprised about the comments though - depending on the age of the
codebase. Mainframes were rented back in the day, you paid by resources
consumed, terminal time was precious, and mainframes were often turned off
outside business hours.

Because of this a lot of the development actually happened between terminal
sessions in flowcharts, pseudo code, documentation, and peer review before the
programs were ever modified and run.

If you ever run across really old comp-sci books you’ll typically see them
divided into three sections - first section was usually a guide to the
author’s terminology and symbology, second part was usually a guide to flow
charting and documentation (IBM had standardized forms for developers to use),
and then the remainder of the book was the content with lots of explanations
of how to work the datasets hugely larger then the memory available to you.

But as time passed and computer time became cheaper many of those formal
development practices started to get lax.

~~~
perl4ever
The New York State Civil Service exams for IT positions (meaning anything
involving software development as well as other stuff) still have a flow chart
section.

I actually quit the interview process with an insurance company a year or two
ago after they wanted me to take a test involving reading flow charts, but now
I'm in the position of having to pass something similar if I want to get
promoted.

However, I don't _think_ people use flow charts on the job anymore, even in
state government.

~~~
codycraven
I've found that flowcharts are enormously helpful for software design and
communicating the design decided upon. Maybe in your role you don't have a
need to communicate how software should be written?

~~~
perl4ever
I like to make hierarchical text outlines.

I feel like once you need a general graph sort of structure, you're too far
down the road to spaghetti and/or excessive detail.

------
Someone1234
The IRS, treasury, and others locally are looking for COBOL programmers. I can
explain why they're struggling to find any just by looking at the pay scale:
$30,113 - $86,021 (GS-5 through GS-12, and most won't get the top end of the
GS-12 scale). The $30K GS-5 starting is almost as low as working for their
call center which is farcical.

By contrast state, county, and even city government are paying $65K - $85K
starting going all the way up to $100K at the top end. And these are jobs
where you're doing modern development, not COBOL.

People will start learning COBOL as soon as it makes rational sense. As it
stands a lot of organizations aren't looking for any COBOL developer, they're
looking for CHEAP COBOL developers. It doesn't make sense to learn when you'd
lose money for taking those jobs.

~~~
marktangotango
This is exactly true. The pay is this low because there is a glut of cheap
cobol developers in the US due to decades of off shoring. There have been
2000+ cobol developers laid off here over the past 5 years alone (medium
midwest metro).

~~~
quaquaqua1
There cannot simultaneously be a surplus of COBOL developers and a shortage of
COBOL developers.

Well, supposedly there could be one in the Midwest and one in NJ, but
theoretically those who do not have a job in the Midwest would be motivated to
move, since their only options are:

A) Remain jobless in Midwest.

B) Switch careers in Midwest.

C) Move to NJ for immediately available position.

The bigger question is why does a COBOL dev accept work for 60k when they
could make 120k in Javascript?

~~~
marktangotango
Low salaries on offer convincingly reveal the true narrative. The question is
why is the false narrative being promoted? Rather effectively at that.

------
Endlessly
Here is the official description & link to the course:

“Open Source COBOL Training – a brand new open source course designed to teach
COBOL to beginners and refresh experienced professionals. IBM worked with
clients and an institute of higher education to develop an in-depth COBOL
Programming with VSCode course that will be available next week on the public
domain at no charge to anyone. This curriculum will be made into a self-
service video course with hands-on labs and tutorials available via Coursera
and other learning platforms next month. The course will be available on IBM’s
own training platform free of charge.”

[1]
[https://github.com/openmainframeproject](https://github.com/openmainframeproject)

SOURCE: The full IBM press release is here:

[2] [https://newsroom.ibm.com/2020-04-09-IBM-and-Open-
Mainframe-P...](https://newsroom.ibm.com/2020-04-09-IBM-and-Open-Mainframe-
Project-Mobilize-to-Connect-States-with-COBOL-Skills)

~~~
johnmertic
I'll also add the Open Mainframe Project blog post here as well...

[https://www.openmainframeproject.org/blog/2020/04/09/open-
ma...](https://www.openmainframeproject.org/blog/2020/04/09/open-mainframe-
project-helps-fill-the-need-for-cobol-resources)

A few other bits to clarify things ( coming from me being Director of the Open
Mainframe Project )...

\- The coursework itself is being contributed to a new open source project
being hosted by Open Mainframe Project ( CC-BY-40 license ).

\- We would have liked it to be ready at the time of announcement, but it
literally got approved by the Open Mainframe Project TAC as a new project
about an hour before the blog post went live ;-). Have no fear, it should be
landing next week ( there will be a bit of work to come on translating docx
files to markdown, in case anyone wants to help ).

\- Right now the course work focused on VS Code as an editor, but the project
is very open to contributions that leverage other IDEs ( such as Eclipse Che,
Atom, etc )

\- Open Mainframe Project is part of the Linux Foundation, with IBM being one
of the 30+ sponsoring organizations.

\- On the notes I've seen around "hey let's rewrite all that COBOL code in
some modern language", I won't add more fuel to that fire ;-). I will however
say there is some interesting work in a project hosted by Open Mainframe
Project called Zowe ( [https://zowe.org](https://zowe.org) ), which basically
makes connecting to mainframe apps and data on z/OS much easier ( think REST
APIs, CLI interface you can use on your laptop, App framework for creating
browser based apps, etc ).

Anyways - hope this helps! Feel free to ping me if you want more details or
help getting engaged ( @jmertic on Twitter ).

------
altitudinous
My first serious computer job (early 1990's) was COBOL.

I last used it in 1997, then moved on to Oracle PL/SQL, Java, Oracle's Java
software stacks and now iOS ObjC/Swift.

Now I'm 52 years old. I have my own apps now on the store, don't need the
money but I am looking for a new challenge - something a bit more social than
working for myself.

I think I'll do this COBOL refresher. Only issue is I'm in Australia but I see
there may be some demand here too. Nothing to lose - plenty of time at the
moment to do the courses. Good for a laugh anyway.

~~~
throwaway_pdp09
Serious question, why do you use COBOL and "looking for a new challenge" in
the same post? I found it a trivial language with a syntax that goes on for
pages. It's entirely uninteresting. The only challenge is understanding any
business requirements, and that's not a language thing.

~~~
jazzyjackson
It's interesting to me that systems could be written that function correctly
once they go live and don't have to be taken offline for decades... the
architecture, not the language

~~~
altitudinous
This really, really interests me as well, and I've written my iOS apps the
same way too. They have no server side, no real dependencies, all client based
and fully automated internally - so as well as being fully contained they
schedule required notifications etc into the future without my intervention.
As long as the user runs the app once about every four months (which isn't an
issue given they get many notifications during that four months) then the app
will work for a very long time and bring in passive revenue. I consider this a
holy grail of software.

I like pure solar powered calculators for the same reason. If you were to send
one back in time it would continue to work and be useful without requiring
intervention or dying.

~~~
ghaff
>(which isn't an issue given they get many notifications during that four
months)

I assume users can turn notifications off though? Almost nothing on my iPhone
is allowed to send me notifications.

~~~
altitudinous
Yes, they certainly can. Apple allows any apps notifications to be switched
off at the OS level - it isn't optional. My users love the notifications
though, and they commonly customise to get _more_ notifications. The reason it
is 4 months is because iOS only allows 64 notifications to be scheduled in
advance for any app, and if they want users can configure to schedule that
many in a 4 month period.

------
JustARandomGuy
From the article: * State unemployment agencies are notoriously underfunded*

And there’s the problem summarized in less than a single sentence. Yes, they
need help, but it’s the same kind of “help” as in “I want a BMW but I only
have a dollar, please help”

There would be a ton more COBOL coders if companies paid the equivalent of
FANG companies - I say this as a former COBOL coder myself

~~~
ghaff
Leaving aside what they're willing to pay or not pay for COBOL developers,
does anyone seriously believe that a bunch of developers can waltz into an old
code base and speed it up by a large amount in a relevant timeframe? Which
seems to be what these articles are at least implying.

~~~
LeoTinnitus
The government doesn't know that. That's why they're calling it COBALT.

I honestly can't wait until all the old non tech people retire.

~~~
vbezhenar
Do you think that new non tech people are better?

------
guu
There are three main efforts in the official announcement[0]:

\- Forum for COBOL programmers to express interest in volunteering or
hiring[1]

\- Forum monitored by experienced COBOL programmers to help developers[2]

\- Open source COBOL training materials from IBM[3] (Available “in the coming
days”)

[0]: [https://www.openmainframeproject.org/blog/2020/04/09/open-
ma...](https://www.openmainframeproject.org/blog/2020/04/09/open-mainframe-
project-helps-fill-the-need-for-cobol-resources)

[1]: [https://community.openmainframeproject.org/c/calling-all-
cob...](https://community.openmainframeproject.org/c/calling-all-cobol-
programmers/15)

[2]: [https://community.openmainframeproject.org/c/cobol-
technical...](https://community.openmainframeproject.org/c/cobol-technical-
questions/16)

[3]:
[https://github.com/openmainframeproject](https://github.com/openmainframeproject)

~~~
silviumatei
I'm working in IBM (Europe) in a project that has the main business app in
COBOL. Using Java and jt400.jar we just expose via web services the business.
Even now we have in team COBOL programmers that creat new programs.

I find the main issue when you want to learn COBOL is the access to a machine
as close to real one an not a simulator. Maybe openmaineframeproject is the
missing link between learning and practice.

~~~
lokedhs
I agree. I have attempts to learn COBOL on a few occasions, but it's always
stopped by the fact that there are, as far as I can tell, only three ways to
do it without investing sometimes insurmountable amounts of money:

The first is GNU Cobol. It's quite functional for its intended purpose: To
port mainframe applications to Linux. However, when writing a new application
on Linux you usually want to do things like access arbitrary files (without
hardcoding the filename in the source) or make network connections. It does
have nice interactive screen support though.

The other option is to run MVS 3.8j in Hercules. This is a predecessor to the
current z/OS which runs on mainframes today. The problem with this is that
it's stuck in the 70's (which is when the last free version of MVS was
released). A lot of work has been done by the community to keep it up to date,
but the Cobol compiler is the language of 40 years ago, not modern Cobol.

None of the above options are really appealing unless you're like me and have
a thing for messing around with stuff in their non-native environment.

The third option is:
[http://mtm2019.mybluemix.net/](http://mtm2019.mybluemix.net/)

When signing up, it gives you access to a z/OS account where you have a
surprising level of access. It's probably running on an emulator (it's quite
slow) but it does give you access to modern software, including compilers for
Cobol, C, Java etc. It also has DB2 installed.

However, the purpose of this option it to learn z/OS, not necessarily learn
Cobol. And developing using the ISPF editor isn't particularly nice. They do
give you ssh access to the Unix-compatibility environment though so maybe it's
possible to edit files using Tramp in Emacs locally. I haven't tried that.

In any case, what is needed is a proper Cobol development environment that you
can run locally on your workstation. As far as I understand, that's how Cobol
developers normally work. IBM would do well by releasing such a product for
free. However, I'm not having high hopes given the fact that the mainframe
division seem to be actively hostile to any free software (look into the
difficulty the community has to get even the smallest community-made
improvements accepted by z/OS, or releasing some small tool for the MVS
community).

~~~
YeGoblynQueenne
>> They do give you ssh access to the Unix-compatibility environment though so
maybe it's possible to edit files using Tramp in Emacs locally.

It's a UNIX shell. You can always use ed :)

~~~
lokedhs
You can actually ssh into it and use vi. That's probably the easiest way to do
it. However, the edit-compile-test cycle is somewhat complicated.

You need to first edit the file, fine, you can use vi. Then you need to go
into ISPF (or TSO) on a 3270 terminal to submit the batch job that compiles
the code (and possible runs it). Then you need to go into SDSF to view the
results of the compilation.

Back in the 70's this was an acceptable way of working, but not what a modern
programmer would expect.

~~~
SuperPaintMan
You can submit jobs to JES2 from USS with a shell script. Easiest way I found
was to fuse-mount a working directory, edit everything with VSCode/Vim With
COBOL Extensions and have two shells, one constantly reading the output data
file and another for submitting job cards.

~~~
lokedhs
Thanks for the information. I assume actual mainframe developers do these
things. But can you do that from the environment provided to me you by master
the mainframe?

On the MVS 3.8j side, I can submit a job directly via the virtual card reader
and then read the results directly from the printer and feed it into Emacs.
That's the most efficient way to work with Hercules but you'll be stuck with a
very old version of Cobol.

------
withdavidli
Had to recruit for COBOL engineers 8 years ago. Almost impossible finding
someone with less than 10 years of experience. Most were 15-20+ years of
experience and about to retire. Many with COBOL experience moved to cloud tech
that would never move back to COBOL that would cause them to be outdated. New
people in the field seemingly only got trained because they were willing to
learn it at a bank.

It's a struggle to hire these people cause there are so few people and many
companies only want to hire local talent (within 20-50 miles, and don't want
to do VISAs).

There's money to be made on supporting tech this old, likely more on the
consulting side than becoming an internal employee.

------
jasonkester
This isn't the first time the world has needed lots of new COBOL programmers
to burst on a single project. I'd suggest the same solution as last time: pay
people $500-$1,000 per hour on short term contracts to do so.

~~~
dm319
As a healthcare worker who also has an interest in programming - why does this
comment not surprise me in HN? If a worldwide pandemic doesn't make you
reflect on problems in our societal structure - that our key workers are the
most poorly paid, but part of a necessary backbone of any country, and that
the most over-paid workers are often the least 'key' at times like this - then
I guess nothing will. But sure, the solution is just to pay programmers more
money, because that is all they care about.

~~~
irrational
How will you get them otherwise? There are way more jobs than qualified
developers. Why would anyone want to work on an antiquated technology stack
like Cobol? By the time they get up to speed on fixing the Cobol systems, the
pandemic will be over. The real solution is to think long term and rewrite all
of these antiquated systems so that the next time there is an emergency it
will be much simpler to find qualified developers.

~~~
YeGoblynQueenne
>> Why would anyone want to work on an antiquated technology stack like Cobol?

Because it's actually a hell of a lot of fun. I did a year in a Cobol shop as
a graduate developer at a large financial corporation. Working on a mainframe
was the most fun I had on that job. And why not? You're logging on to a
gigantic computer with millions of users and billions of transactions daily,
with a text-based user interface that looks like it was designed by Tarn
Adams. And I say that 100% as a compliment.

Seen another way, the "antiquated Cobol stack" is like a deep dive into the
history of computer science and programming languages. You can see with your
own eyes how stuff used to be done 50 years ago. And there is so much to
learn. It's not just Cobol: there's a whole bunch of other languages like Rexx
for example that is like javascript on a mainframe, or like, well, JCL which
is an absolute horror to behold of course. There's a whole new operating
system to learn, or three and there's a whole new computer architecture to
become familiar with. How is that not absolute programmer heaven?

I mean, seriously, when I first got all the permissions and so on that I
needed to work on a mainframe, I was giggling to myself like a little girl.
"Really? They gave me access to all _this_?". It was like someone had given me
the keys to the playground.

The job sure got a bit boring after a while, which is the reason I left, but
for a few months it was just sheer tomfoolery, poking at things and finding
how things worked.

>> The real solution is to think long term and rewrite all of these antiquated
systems so that the next time there is an emergency it will be much simpler to
find qualified developers.

That is not a sustainable solution. Fifty years from now people will be making
jokes about "that antiquated Python stack" and state agencies will be ringing
alarm bells for the lack of experienced young Python programmers. You can't
just keep throwing out all the old code and replacing it with whatever new
language is cool right now.

~~~
jlokier
> Fifty years from now people will be making jokes about "that antiquated
> Python stack" and state agencies will be ringing alarm bells for the lack of
> experienced young Python programmers.

I wonder how many people realise Python is more than 30 years old already.

------
BoysenberryPi
This whole recent COBOL surge reminds me of a friend I had who was upset that
he had a Bachelor's in Computer Science but still couldn't find a job while
his friend with no college degree taught himself COBOL and got a job at a
local bank.

~~~
laurentdc
Yeah, the devs I met with the most stable and laid back jobs are all AS400,
COBOL/CICS or IBM RPG experts

~~~
guessbest
That's probably because they work in isolation from newer technologies which
are constantly adding business rules. Most of the mainframe work I see
involves maintaining old code bases and handling batch processing.

~~~
lowercased
good guess. if the rest of the organization bends over backwards to ensure
that you never have to update your code to accommodate, say, more than 8 ASCII
characters in a password, or hashed passwords, and the rest of the org puts
their security at risk to make sure your codebase never has to change... yeah,
it might be a bit laid back... :)

------
lame88
"Why? Because coding a percentage in COBOL would take an estimated five
months."

Five months to code a percentage, or five months to add the calculation,
integrate that data point with other systems (does this need to be shown as
its own field on any unemployment forms or reports? etc.), test it to the
point where it has been demonstrated stable enough to be included in a
critical system, and then deliver this change?

I don't know the first thing about COBOL but the fact that government is (for
good reasons) slow to move, the stability needed in critical things like
unemployment processing, and all the other things that go into "coding a
percentage", explain that timeline a hell of a lot more than what language was
used.

------
jonhendry18
I'm sure after you finish the training you'll find all the ads looking for
people with 5 years experience.

Assuming the demand for people still exists by then.

~~~
raverbashing
No, they need senior programmers so 10+years experience.

In the same way they ask for 10+years programming experience in Swift or Rust

------
erynvorn
Young COBOL specialists are being fired here and there. They can't find a job.
They can't "volunteer" either they need to get paid at the end of the day.

I see Fiserv firing all their 3-6 years COBOL juniors (last in, first out.)
They retain only the most expensive 15-25 years pros.

------
quickthrower2
Next: COBOL 30 day bootcamp with guaranteed job at the end.

~~~
Cyberdog
I'd say yes to that in a heartbeat. Thirty days is probably not enough to
someone new to programming, but to experienced programmers in various other
languages it's probably enough to get the basics down and get over the "know
just enough to be dangerous" hump.

If these orgs desperate for devs want to put their money where their mouth is
and start a program like that, hit me up. Sure.

~~~
JustARandomGuy
I'd sign up for something like that in a heartbeat.

I used to do COBOL, but the problem is that possibilities for advancement are
very limited - there's far more jobs available - and promotion pathways - for
a Python or Java coder than there is for a COBOL coder.

In exchange for a refresher in COBOL and a guaranteed job, yes that is a much
better deal.

------
speedgoose
Personally I would like to be paid to learn such a technology.

~~~
agumonkey
There are techs people would accept pay cuts to work with and there's cobol.

------
vmh1928
I'd imagine a lot of the problems are due to the increased volume. So that
would show up as abends due to exceeding data set size definitions in JCL,
VSAM, IMS or DB2 (or even IDMS and the other database technologies in use 20 -
30 years ago.)If the unemployment system is adding a covid related
unemployment code then they would need someone to crawl through the code
looking for where the logic needed to change in calculating benefit amount,
duration of benefits and such.

------
prirun
COBOL programs are divided into paragraphs that start with a paragraph name
and have a group of statements within the paragraph. A program starts at the
first paragraph and continues sequentially through multiple paragraphs until a
STOP RUN statement is executed or it executes the last statement in the last
paragraph. Easy peasy.

Well, not so fast. If you PERFORM a paragraph, then it's like a BASIC GOSUB
statement, or "jump and store" in assembly language. Sort of like a function
call, but with no local variables.

Or you can do PERFORM A THRU B to jump to paragraph A, continuing sequentially
until the end of paragraph B.

Or you can do PERFORM A THRU B VARYING X FROM 1 BY 1 UNTIL C, which is sort of
like a for loop.

The nasty thing about all this is that looking at a paragraph (block of code),
you can't tell shit about how it gets executed. Does it fall through to the
next paragraph? You can't tell: that's determined dynamically at runtime. Is
it a loop? Can't tell. That's one of the things that makes large COBOL
programs _really_ hard to understand.

Another fun COBOL statement is ALTER:

[https://riptutorial.com/cobol/example/19820/a-contrived-
exam...](https://riptutorial.com/cobol/example/19820/a-contrived-example-
using-alter)

If you think GOTO is bad, it's a walk in the park compared to the lethal
combination of ALTER + GOTO. Basically, when you say GO TO A, it can go to
some other place based on a previous ALTER statement. Now we're having fun!

------
tekchip
All this, Cobol programmers are in short supply and now let's train new ones,
sounds like a sort of technical debt bailout.

As some have noted management has failed to look to the future and now their
business has a major problem they are struggling to deal with. Same as we
debate not bailing out, financially, companies that failed to plan for future
disaster or catastrophies I would argue we don't bail out these companies that
failed to maintain their own internal technical architectures by planning for
upgrades and future maintenance.

It's akin to the BS ISPs argue about not being able to afford to maintain it
upkeep their infrastructure. It's largely BS. Put less in the upper
managements pocket and more in the business and all of a sudden the business
works and has resiliency against unexpected events. If you don't think these
"vital" banks and hospitals can't afford it then you haven't been paying
attention.

------
safgasCVS
What other languages can we expect to see a similar surge in demand? FORTRAN?
In the data analysis space my bet is on SAS

~~~
metreo
Fortran (standardized without caps for at least the last couple decades) is
current to the 2018 release. I haven't come across anybody who cares or is
using it. You do eventually see a lot of older code in it in symbolic and
algebraic maths in the deeper code bases still because the algorithms are
complex and nobody really wants to touch someone else work if it can still be
wrapped in something like R or Python and is nearly as performant as C/++.

~~~
metreo
I guess the thing about Fortran, to circle back to your question, is that it
isn't common in critical infrastructure.

~~~
charlesap
I work at a place that writes new Fortran code today. Also c++, Python, Julia.
Scientists will choose the least impedance mismatch to a library, some needed
data set, or their brain.

~~~
metreo
To be sure. And I don't think that modern Fortran is overly obscure that you
couldn't basically pick it up over a weekend from the language specification.

Every modern Linux distribution has a current gfortran bundled.

------
say_it_as_it_is
Unemployment claims processing is something that each State does and yet each
has its own unique way of handling it. This approach is followed for every
multimillion dollar endeavor, building costly, redundant solutions to the same
problem. This has been great for the private sector but costly for the public.

------
salamanderman
It's very frustrating to me that we're even talking about these COBOL programs
today. During Y2K there was suddenly a huge demand for COBOL programmers to
come out of retirement and young programmers to frantically learn it. The
claim I remember at the time was that those systems should have already been
rewritten, but the departments were underfunded, and they were finally doing
it since it was an emergency. And yet, all they did was a little hacky patch
and 20 years later it's still running. So we're 40-60 years on with these
pieces of software. Look for whatever hacks they made for Y2K to be biting
people in the butt again in 20-40 years, and programming historians to be
pulled out of universities to patch again.

------
bobbydreamer
This month I wrote 2 Rexx stored procedures 1\. Does a db2 bind 2\. Executes
any DML, DDL, DCL and selects in Db2

These stored procedures will be triggered by REST APIs & Endevor(version
control). What makes me happy is, these will work for another 10+ years
without any upgrades or me tinkering the code again for new version.

Well if it was any web technology or cloud application, I would be getting a
mail from them saying they are going to decommission a version of language so
either you need to rebuild your code only to know it fails in new
version(every 2 years). Well that doesn't happen in mainframe.

------
metreo
Do you really want to end up in a situation where you're in a position of
maintaining someone else's ancient codebase? I guarantee you this is not a
path to anywhere but misery.

~~~
unnouinceput
As a freelancer who does this 2 out of 3 jobs, I can tell you is definitely
fun if you like challenge as in debug for 3 hours to only realize the old
coder in 80's never initialized a structure and a newer tool was used to
create the modern platform. And when you come on-board for maintenance/upgrade
you are not told this from nobody. So misery or challenge, depends on your
point of view, but the other side of the coin is..well, the coin itself, it's
huge :). You get paid handsomely.

~~~
metreo
Reportedly, there are definitely more interesting challenges. We are seeing
this in academia quite frequently where the older professors have some hard
worked program in BASIC from whenever and they try really hard to get someone
to maintain it's existence since otherwise their efforts really do disappear.
For the person taking this on it's tedious, thankless and of dubious tangible
merit to the participant who should be focused on their own contemporary work.

Have the reports of high pay been confirmed, AFAIK the push now is for
volunteers.

------
ralphc
Forget the talk about pay too high, too low. This is a way to help our
neighbors who are hurting, a way to help with our skills.

A question I'll ask is, someone like me; retired from a long development
career, experience in many languages but not COBOL. Could I take this course,
or a similar one, and be useful to prop up a rickety code base on a volunteer
basis? If yes, are any of these states allowing remote work on it?

------
geogra4
I looked out of curiosity and there are less than 10 Cobol jobs where I am (4
mln metro area, USA) seems like this is mostly marketing?

------
Aloha
I'll likely run they this course. I've always been interested in this kind of
tech, I did mastering the mainframe previously

------
thereyougo
The article mentions a training class but i don't see any link to it actually.
Would love to see this announcement from IBM

~~~
mikequinlan
[https://www.zdnet.com/article/ibm-open-mainframe-project-
lau...](https://www.zdnet.com/article/ibm-open-mainframe-project-launch-
initiative-to-help-train-cobol-coders/) seems to have more information but the
course itself ([https://github.com/openmainframeproject/cobol-programming-
co...](https://github.com/openmainframeproject/cobol-programming-course)) is
just an empty Github repository.

edit to add [https://www.openmainframeproject.org/blog/2020/04/09/open-
ma...](https://www.openmainframeproject.org/blog/2020/04/09/open-mainframe-
project-helps-fill-the-need-for-cobol-resources) is the actual announcement.

~~~
thereyougo
Thank you for this

------
ravenstine
Unless they are going to pay me way above my current pay to compensate for
dealing with an obsoslete language and the programming practices of its era,
no way.

This is a great non-monetary example of one of the biggest issues we are
seeing in our time. That is, as a civilization, we have become terrible at
investing in future contingencies. In the last few months, we have witnessed
how our biases prevented most of us(and businesses) from building up a
meaningful savings for stormy weather, and the COBOL situation is hardly
different. Banks could have invested in gradually switching from older
mainframes to modern ones with software built with any modern language, and
they were(or should have been) in one of the best positions to do this.
Instead, they said "whatever" or simply were complacent in where technology
was headed, and did little or nothing.

As a society in it's current state, we need to seriously look at ourselves in
the mirror.

------
phendrenad2
Okay so I can learn it, but can I run it? Is there a mainframe simulator out
there?

------
strategarius
I would not have attended one even if I got paid for it. Why should I flush my
career in toilet, sentencing myself to dig into piles of 50 y.o. crappy code.
Stop riding dead horse.

------
ChrisArchitect
meanwhile, in the 24th century...
[https://abstrusegoose.com/323](https://abstrusegoose.com/323)

(gonna keep posting this on all the COBOL threads haha)

------
kazinator
That's a bit like Tom Sawyer offering free fence painting.

------
arkanciscan
Let it die

------
factchecker01
The site is horrendous with ads

------
number6
I don't want to sound condescending but why can't these systems be rewritten
in a modern language? Now is obviously not the right time to do this; I am
wondering are there technical limitations to do his?

~~~
msla
Here's some simple COBOL code:

[http://www.csis.ul.ie/cobol/examples/Conditn/Conditions.htm](http://www.csis.ul.ie/cobol/examples/Conditn/Conditions.htm)

    
    
        identification division.
        program-id. letters.
        data division.
        working-storage section.
        01  Char               PIC X.
            88 Vowel           VALUE "a", "e", "i", "o", "u".
            88 Consonant       VALUE "b", "c", "d", "f", "g", "h"
                                     "j" THRU "n", "p" THRU "t", "v" THRU "z".
            88 Digit           VALUE "0" THRU "9".
            88 ValidCharacter  VALUE "a" THRU "z", "0" THRU "9".
        procedure division.
        begin.
            display "Enter lower-case character or digit. No data ends.".
            accept Char.
            perform until not ValidCharacter
                evaluate true
                    when Vowel display "The letter " Char " is a vowel."
                    when Consonant display "The letter " Char " is a consonant."
                    when Digit display Char " is a digit."
                    when other display "problems found"
                end-evaluate
            accept Char
            end-perform
            stop run.
    

(I removed some chaff which GnuCOBOL doesn't need and fixed an apparent bug.)

So... where is it actually testing what kind of character you input? Where is
the code for that? You input a specification for what a Vowel is, for example,
and you write explicit code for what to do when a Vowel is input, but where is
the code which goes through the specification and decides, yep, that's a
Vowel?

COBOL is kind of an odd language. It's verbose in some respects and quite
concise in others. Rewriting COBOL into something else would take actual human
effort if you wanted the "something else" to look like code a human wrote, as
opposed to the intermediate pass of an optimizing compiler, which is what the
C GnuCOBOL can output looks like. Re-writing the COBOL might be the best move
in some cases, or replacing it with entirely new code, but it isn't something
you'd be able to do "for free" in any sense, especially with regards to time.

~~~
YeGoblynQueenne
"when Vowel" is not very different to bog standard switch-statement magic.
Actually in this case it looks like Cobol is almost doing a kind of pattern
matching. Which is cool. Although (my Cobol is a bit rusty) I think there
might be a more elaborate way to write "when Vowel" that hides less of the
actual process? Not sure.

Cobol is really not such a bad language. It's just got a lot of ...ceremony.
All those forced divisions and sections. But that's a feature: in the olden
days, structured programming was a big thing. And an experienced Cobol
programmer can take a quick look at a big Cobol file and find where everything
is in a blink.

~~~
ptx
Java similarly imposes a lot of structure that allows you to more easily find
where everything is, but the trade-off is that there is _a lot more_ of this
everything to find, whereas in a more flexible language you would have less
code to read through and therefore less need for organizing it.

