It's COBOL all the way down

[RS Wood]

https://increment.com/programming-languages/cobol-all-the-way-down/

//--clip
Sixty years later, you’d expect COBOL to be the stuff of looping
narrative videos at computer-history museums (in fact, there’s part of
a floor devoted to mainframes at Seattle’s Living Computers museum,
where you can see the old giants in action); maybe you’d hear the name
COBOL used in an introductory lecture on computer science to explain
how far we’ve come, and chuckle.

Instead, COBOL remains widely and actively used across the financial
system, with no good plan for transitioning to modern codebases, nor
for keeping a viable coder workforce active. That’s a problem, because
while some schools still teach COBOL and many outsourcing firms train
employees in it to meet their employers’ needs, it’s not enough.
Someone has to maintain an estimated hundreds of billions of lines of
COBOL that remain in use, with billions more being written each year
for maintenance and new features.

Companies involved in keeping COBOL-based systems working say that 95
percent of ATM transactions pass through COBOL programs, 80 percent of
in-person transactions rely on them, and over 40 percent of banks still
use COBOL as the foundation of their systems. “Our COBOL business is
bigger than it has ever been,” said Chris Livesey, senior vice
president and general manager at Micro Focus, a company that offers
modern COBOL coding and development frameworks.

The Bank of New York Mellon told Computerworld in 2012 that it had
112,500 COBOL programs representing 343 million lines of code in active
use. (And, yes, they’re still hiring COBOL coders in 2018.) The U.S.
Social Security Administration (SSA) noted in a 2014 report that it
“currently has roughly 60 million lines of COBOL in production that
support the agency’s high transaction volume and enable the agency to
meet its regulatory, benefit, and reporting requirements.” Starting in
2012, the Commonwealth Bank of Australia spent a reported US$750
million and five years migrating its core software away from COBOL on a
mainframe to a modern platform (it’s not clear how that effort ended).
//--clip

[Huge]

Post by RS Wood
https://increment.com/programming-languages/cobol-all-the-way-down/
//--clip
Sixty years later, you’d expect COBOL to be the stuff of looping
narrative videos at computer-history museums (in fact, there’s part of
a floor devoted to mainframes at Seattle’s Living Computers museum,
where you can see the old giants in action); maybe you’d hear the name
COBOL used in an introductory lecture on computer science to explain
how far we’ve come, and chuckle.
Instead, COBOL remains widely and actively used across the financial
system, with no good plan for transitioning to modern codebases,

(Currently talking about this on the 'nixUsers group on Facebook)

Why do you need a "good plan for transitioning to modern
codebases"? Indeed, why do you need any plan at all? This stuff works,
it works well, it does the job, in most cases with massive reliability
("we" (*) routinely had uptimes in excess of 99.99% in $(MEGABANK)'s
data centre. CICS, z/OS, DB2, COBOL). IMNHO, the computer industry's
obsession with "New! Shiny!" is in many cases positively harmful. Look
at the shambles of Javascript frameworks for a good example.

What "we"(*) do need is people prepared to support this stuff. And that's
simply dealt with; pay them more money.

(* Despite having been retired for coming up for 3 years, I still think
of it as "we".)

[Kees Nuyt]

Post by Huge

Post by RS Wood
https://increment.com/programming-languages/cobol-all-the-way-down/
//--clip
Sixty years later, you’d expect COBOL to be the stuff of looping
narrative videos at computer-history museums (in fact, there’s part of
a floor devoted to mainframes at Seattle’s Living Computers museum,
where you can see the old giants in action); maybe you’d hear the name
COBOL used in an introductory lecture on computer science to explain
how far we’ve come, and chuckle.
Instead, COBOL remains widely and actively used across the financial
system, with no good plan for transitioning to modern codebases,

(Currently talking about this on the 'nixUsers group on Facebook)
Why do you need a "good plan for transitioning to modern
codebases"? Indeed, why do you need any plan at all? This stuff works,
it works well, it does the job, in most cases with massive reliability

I agree. An argument could be made that, being a relatively
straightforward language, COBOL can be coded by people who concentrate
on the business logic, and don't necessarily need a PhD in computer
science.
The code is more easy to verify by accountants and even clients.

Post by Huge
("we" (*) routinely had uptimes in excess of 99.99% in $(MEGABANK)'s
data centre. CICS, z/OS, DB2, COBOL). IMNHO, the computer industry's
obsession with "New! Shiny!" is in many cases positively harmful. Look
at the shambles of Javascript frameworks for a good example.
What "we"(*) do need is people prepared to support this stuff. And that's
simply dealt with; pay them more money.
(* Despite having been retired for coming up for 3 years, I still think
of it as "we".)

Disclaimer: Last time I coded in COBOL for a living was in the 1980's. I
moved on to other endeavors.

[Huge]

[31 lines snipped]

Post by Kees Nuyt

Post by Huge
What "we"(*) do need is people prepared to support this stuff. And that's
simply dealt with; pay them more money.
(* Despite having been retired for coming up for 3 years, I still think
of it as "we".)

Disclaimer: Last time I coded in COBOL for a living was in the 1980's. I
moved on to other endeavors.

I've never written any COBOL, or indeed programmed anything on a
mainframe. But at $(MEGABANK), in essence everything came back to
the core banking systems running on the mainframe eventually, at
least for retail banking, and I spent several years getting the use
of test data on the development machine under control, so ended
up learning a lot about them.

[Theo]

Post by Huge
I've never written any COBOL, or indeed programmed anything on a
mainframe. But at $(MEGABANK), in essence everything came back to
the core banking systems running on the mainframe eventually, at
least for retail banking, and I spent several years getting the use
of test data on the development machine under control, so ended
up learning a lot about them.

Out of curiosity, how well does COBOL lend itself to regression testing etc?
Can you automatedly run your test dataset (eg last week's transactions)
through the mainframe and check it always does the right thing?
Are COBOL developers writing tests at the same time as they're working on
the code?

Theo

[Huge]

Post by Theo

Post by Huge
I've never written any COBOL, or indeed programmed anything on a
mainframe. But at $(MEGABANK), in essence everything came back to
the core banking systems running on the mainframe eventually, at
least for retail banking, and I spent several years getting the use
of test data on the development machine under control, so ended
up learning a lot about them.

Out of curiosity, how well does COBOL lend itself to regression testing etc?

No more or less than any other programming language.

Post by Theo
Can you automatedly run your test dataset (eg last week's transactions)
through the mainframe and check it always does the right thing?

That's what the test environment is for!

Post by Theo
Are COBOL developers writing tests at the same time as they're working on
the code?

They should be.

[Bruce Horrocks]

Post by Theo
Are COBOL developers writing tests at the same time as they're working on
the code?

Remember that what you describe is very much the modern approach.

The approach to testing when COBOL was in its heyday was that *testers*
wrote tests using the same *requirements* that the programmers used to
write code from.

There are pros and cons to both approaches, of course, but if I had to
wholesale re-adopt COBOL then I wouldn't necessarily want to try and
shoehorn it into a modern devops stack.

[Paul Sture]

Post by Theo

Post by Huge
I've never written any COBOL, or indeed programmed anything on a
mainframe. But at $(MEGABANK), in essence everything came back to
the core banking systems running on the mainframe eventually, at
least for retail banking, and I spent several years getting the use
of test data on the development machine under control, so ended
up learning a lot about them.

Out of curiosity, how well does COBOL lend itself to regression testing etc?
Can you automatedly run your test dataset (eg last week's transactions)
through the mainframe and check it always does the right thing?

Well, going back to 1977 here... When we implemented a new accounts
package on a shiny new ICL mainframe we dumped the old data from the
magnetic ledger cards from the old Burroughs system to punched cards and
fed those into the new system. That accounts package featured a punched
card at the beginning of each job with the "accounting run date", and
all programs used that rather than the system date for reporting
purposes, which was quite a neat idea.

We ran the whole of the previous year's accounts through the new system
in order to to compare the results, and once happy with those, could go
live with a reasonable level of confidence.

Back in the day, when electronic media such as disk and tape were so
expensive, punch cards represented an economic and relatively compact
way of storing transaction data. Program test packs of punch cards
could be re-used until they showed signs of physical wear, and it was a
piece of cake to duplicate them onto fresh cards, given the kit
available at the time.

[Paul Sture]

Post by Paul Sture
We ran the whole of the previous year's accounts through the new system
in order to to compare the results, and once happy with those, could go
live with a reasonable level of confidence.

FWIW we used to call that practice a "parallel run".

[Bob Eager]

Post by Huge
[31 lines snipped]

Post by Kees Nuyt

Post by Huge
What "we"(*) do need is people prepared to support this stuff. And
that's simply dealt with; pay them more money.
(* Despite having been retired for coming up for 3 years, I still
think of it as "we".)

Disclaimer: Last time I coded in COBOL for a living was in the 1980's.
I moved on to other endeavors.

I've never written any COBOL, or indeed programmed anything on a
mainframe. But at $(MEGABANK), in essence everything came back to the
core banking systems running on the mainframe eventually, at least for
retail banking, and I spent several years getting the use of test data
on the development machine under control, so ended up learning a lot
about them.

SWMBO is a good COBOL programmer, altough she hasn't used it in angwer
for a while. I keep telling her she should give up teaching and get out
there!

I have never written COBOL, but I once converted a compiler and run-time
system from COBOL to something that generated native code instead of code
that was interpreted by a COBOL program. I got quite a lot of money for
that.

[Huge]

Post by Bob Eager

Post by Huge
[31 lines snipped]

Post by Kees Nuyt

Post by Huge
What "we"(*) do need is people prepared to support this stuff. And
that's simply dealt with; pay them more money.
(* Despite having been retired for coming up for 3 years, I still
think of it as "we".)

Disclaimer: Last time I coded in COBOL for a living was in the 1980's.
I moved on to other endeavors.

I've never written any COBOL, or indeed programmed anything on a
mainframe. But at $(MEGABANK), in essence everything came back to the
core banking systems running on the mainframe eventually, at least for
retail banking, and I spent several years getting the use of test data
on the development machine under control, so ended up learning a lot
about them.

SWMBO is a good COBOL programmer, altough she hasn't used it in angwer
for a while. I keep telling her she should give up teaching and get out
there!

No idea what contract rates are like at the moment, but they're only
going to go in one direction.