COBOL – Still standing the test of time

Some common lines you hear from mainframers.

Deprecation is a new term in mainframe.

Don't fix what's not broken

------

It's a common saying that mainframers don't try to learn new tech. Well that saying goes two ways, person saying has really tried to learning mainframe and work on it for a month. Actually there isn't much to learn other than couple of languages COBOL, REXX, JCL and SAS. Other than that it's just ISPF interfaces.

Mainframers actually have to learn tech once and then go on to learn business logics and business domain. Isnt that actually good when comparing to always learning new tech and writing migrating programs to support existing interface in new Lang but not too much about business you are working on.

On the other hand mainframers do spend on learning and upskilling but in mainframe itself. There are lots of IBM Usergroups like IDUG for instance which is related to Db2, being a DBA that's a very useful training programme for me.

COBOL codes are highly modularized to do one or couple of functions to my knowledge and there are definitely coding standards each shop maintains.

Having a bunch of nodeJs cloud functions i get an email from Google saying that I need to migrate my NodeJs or it will stop functioning and while trying to migrate i find couple of modules are not longer supported and I need recode. Here I am not adding any new features just trying to make it work as before with new library which I have to find, learn, test and analyse does it suit then recode. All this costs time which you don't have to do in mainframe. You can say why not run in a VM, then what's the point running in cloud.

Mainframe is not a legacy system. IBM introduces a new machine every 3-4 years and send their sales team to visit corps and run presentations :) . Currently IBM has changed their billing style, it's not flat or peak hour, it's custom. It's the smallest footprint in your data center.

What mainframe actually did is, job separation. So in a career a person will sort of become an expert in their line or software. He will know all the ins and outs. For example a RACF security person will not know about Db2 and how it functions only part he knows is what interfaces with RACF. Same with CICS, MQ.... From application/dev team they get to know business like in a requirement meeting when business talks devs will be mapping business with program modules they had to make a change.

In mainframe people get to specialize.

> The Cobol code is mostly handling transactions that result in money going from one account to another. The people who own that money tend to scrutinize this very carefully!

In my experience that's only true for a minority of them. The likes of e.g. VAR calculations were often straight-up wrong. And even for monetary transactions, you only have to look at the UK post office lawsuits where the code was simply wrong but rather than checking the code they spent years assuming that any discrepancies were the results of employee theft.

> This doesn't mean that every function in the code works correctly for arbitrary inputs that appear to be allowed by the function interface (formally a bug!) but it does the right thing for the inputs that have historically been provided (in practice very stable and reliable).

It's stable and reliable as long as nothing changes. But the world is always changing.

> That kind of reliability makes it hard to rewrite the code. There are cases for historically unused input combinations where you have no particular reason to believe the old code is bug free. So when your rewrite produces a different result in an obscure case, it is a long and painful business logic task to decide which version is right.

Right, but in practice you get an absurd double-standard. The old code is just as likely to be wrong as the new code, but no-one cares about the business logic, they only care about whether the result is the same as the old code.