Mainframes Are Having a Moment

https://spectrum.ieee.org/tech-talk/computing/software/mainframes-programming-language-cobol-news-coronavirus

by jbkavungal • 6 years ago

57 64 6 years ago

spectrum.ieee.org

nulbyte• 6 years ago

Mainframes have been having a moment. Or, perhaps more accurately, certain enterprises are finally waking up to the fact that firing all those mainframers wasn't the best idea for the long-term. The current problem isn't the lack of interest of availability of training; both would be there if it weren't for the fact that enterprises are more interested in having their code written by consulting companies in India than by domestic employees.

heisenbit• 6 years ago

It is not only lay offs it is also retirements. And the pressure is mounting with baby boomers gone soon. I was once in a discussion taking over the maintenance of a system and the picture was grim. The crew running the system was so thin it was hard to imagine them having the time handing it over. Besides they barely understood all the details as the system had been build by people 30 years ago all gone a long time ago. A big bowl of spaghetti in a core part of their enterprise. We decided not to try to take this on - too much risk.

rtempaccount14• 6 years ago

I was at a talk about mainframe security recently where the state of play with one company was, there were three users in their admins group for the mainframe, two had retired, and the third was past retirement age...

When you combine retirements with decades of under-documented code doing critical functions, it's not a recipe for good long term success...

DebtDeflation• 6 years ago

The surge in demand is being driven almost entirely by state unemployment systems. Most of these systems haven't seen a surge in unemployment claims since the 2009 recession and haven't had to change the underlying rules governing eligibility in even longer. Once the systems are patched and/or the surge in new claims subsides, 90% of this sudden demand for "Cobalt programmers" will evaporate. It's one thing for retired mainframe programmers to come out of retirement and work as consultants for a few months, it's quite another to start changing CS curricula nationwide along with launching mainframe bootcamps for career changers. I'd urge caution.

carlmr• 6 years ago

Whenever you see "urgent need" in headlines it's too late to profit from this crisis.

If anything learn COBOL in about 10 years for the next crisis.

TAForObvReasons• 6 years ago

There were pre-crisis efforts to address this. NJ for example awarded a contract to Electronic Data Systems (now HP) which fell by the wayside [1]. Given the complexities of total rewrites compared to patchwork, I'd bet there will still be demand in the future.

[1] https://www.nj.com/politics/2014/11/nj_ends_118_million_cont...

zeckalpha• 6 years ago

Maybe the 2038 problem?

vageli• 6 years ago

The surge in demand is being driven almost entirely by state unemployment systems. Most of these systems haven't seen a surge in unemployment claims since the 2009 recession and haven't had to change the underlying rules governing eligibility in even longer. Once the systems are patched and/or the surge in new claims subsides, 90% of this sudden demand for "Cobalt programmers" will evaporate.

I generally agree but I also believe that this whole exercise might be an impetus for some states to migrate these services to more modern languages to prevent this type of crisis in the future.

jasonjayr• 6 years ago

If you had to chose an environment or programming language that you expect to survive, in regards to talent pool + tech availability for 30+ years today, what would you choose?

chachachoney• 6 years ago

Is Cobalt an obscure dialect of Cobol?

gwern• 6 years ago

And at such low pay, too:

As recently as this week, jobs boards such as Indeed and Dice.com listed hundreds or in some cases thousands of openings for mainframe positions at all levels. Advertised pay ranges from $30 to $35 an hour for a junior mainframe developer to well over $150,000 a year for a mainframe database administration manager.

If you are talented and patient enough to do software archeology which will affect millions of people, I think you can make (a lot) more elsewhere.

eggy• 6 years ago

I used to work at an environmental law firm in downtown Manhattan and accounting and other core financial systems were running on a VAX OpenVMS mainframe, and the document creation and storage was on PCs over a Token Ring, Banyan VINES network. The DOD was using VINES at the time. Memories of playing DOOM in 1994 downloaded from an FTP server somewhere while working the night shift to make backups on huge tape cartridges. The VAX system was pretty reliable and easy to deal with IIRC. A good thing from a hardware/help desk angle is that you didn't really need to troubleshoot terminals; they broke (keys or monitor) and required replacing. The mainframe was in the climate-controlled room, all in one place for any hardware servicing. I think Token Ring primarily was replaced because cheap, twisted-pair wiring made Ethernet less expensive. Token Ring had these twist-on bulky connectors. In a way we almost went there with Chromebooks basically being pared-down PCs and being served by a virtual mainframe, the cloud ("Spenser Confidential" movie "Give me the cloud scene" is hilarious).

tgflynn4• 6 years ago

VAX's were minicomputers, not mainframes.

m4633• 6 years ago

You're correct, although they did frequently have some of the hallmarks of "mainframes" like raised floors/cooling.

It's amusing to look up "mainframe" on wikipedia and see what appears to be compact server racks. Shouldn't a mainframe take up a room, or even a whole floor?

Zenst3• 6 years ago

https://en.wikipedia.org/wiki/VAX_9000 "The VAX 9000, code named Aridus or Aquarius, was a family of supercomputer and mainframe computers developed and manufactured by Digital Equipment Corporation (DEC) using processors implementing the VAX instruction set architecture (ISA)."

Zenst3• 6 years ago

I lived thru that era and in all that time, still managed to never encounter "Banyan VINES", and it was always some network driver that many knew of as What the heck is that crazy thing. To which somebody would say, oh some banks use it.

Though encountering Token Ring at a company in early 2000, that was...interesting. Though dare say, that somewhere out there in the world, a token ring network still exists and is running even as I type. Legacy sure does have some strange corners when it comes to many walks of life.

hvs• 6 years ago

VMS's command line is... verbose. It has nice completion and is well documented, though. And you can see where the '/' style of parameters came from.

e.g.

    DIR/SINCE="1-FEB-1994 17:00"

kbr2000• 6 years ago

Datapoint's ARCnet (token bus) similarly also had to make place for Ethernet [0], while initially less expensive. An interesting networking technology still used in industrial fieldbus applications (wind turbines & robots for example), its deterministic nature making it well-suited for realtime requirements. Flexible wiring topologies and good signal resilience too.

It was used as a basis for Datapoint's minicomputer clustering technology (called ARCNET too, programmed using DATABUS), and later VAXcluster [1] as I just found out.

[0] https://en.wikipedia.org/wiki/ARCNET

[1] https://en.wikipedia.org/wiki/History_of_computer_clusters

rubatuga• 6 years ago

Link to the cloud scene:

https://www.youtube.com/watch?v=8GRPArTor7w

djohnston• 6 years ago

is the inertia of rewriting these systems in a modern stack so great that it's cheaper to keep finding COBOL specialists forever? why not just sit down and rewrite these systems?

cultus2• 6 years ago

COBOL is unstructured. It doesn't even have functions. When you've got some million+ line tangled mass that has all kinds of undocumented behavior, it's really better just to add more duct tape and punt it off to the poor bastard who actually has to fix it in 20 years.

neverartful• 6 years ago

COBOL for IBM mainframe running z/OS does have subroutines. (I don't know if you're making a distinction between procedures and functions.)

pjmlp2• 6 years ago

Since 1985 that COBOL can be structured, and since 2002 object oriented as well, with the latest ISO update being done in 2014

Besides compiling to native code, there are compilers that target JVM and CLR as well.

kryptiskt• 6 years ago

It has been done many times, sometimes successfully. Other times it ends up costing hundreds of millions over budget before the effort is abandoned and there is nothing to show for it.

leoc• 6 years ago

As late as 2014, at least, the US federal government was still processing its retirement claims on paper, in a decently large and rather nice-looking cave in Pennsylvania: https://www.dailymail.co.uk/news/article-2587305/Crazy-Cave-... .

rtempaccount14• 6 years ago

In many cases (e.g. banks) these systems have been running for decades, they're often badly documented and have had a lot of fixes applied for issues that arise.

Re-writing that, is going to be a nightmare, as you've got no spec. to work from and mistakes may not show up immediately (think monthly or annual payment processes)

It's a very high risk endevour with little immediate reward for the team doing it. If it goes perfectly, no-one notices, if it goes badly it could seriously impact your whole company.

Twisell• 6 years ago

Same logic apply to climate change issues.

There is little immediate reward so let this dumpster fire explode on our kids...

It doesn't necessarily mean that it's a good logic. We desperately need more long term thinking.

RickJWagner• 6 years ago

COBOL is living proof of the power of incumbency.

Once technology is entrenched, it becomes self-sufficient and very, very difficult to replace. I remember when mainframe/COBOL apps were being re-written for the client/server era, often using tools like Tuxedo/c++ for the backend and Visual Basic for the front-end. Where are those re-writes now? (Probably replaced a couple of times again, where the COBOL-remainers are still in place.)

I think the days of higher-paying COBOL gigs are still ahead of us. When the greybeards actually go away, there will be a strong need to fill.

m4633• 6 years ago

COBOL might just be software properly amortized.

wyldfire• 6 years ago

IMO the hard part isn't learning COBOL -- that's just another programming language. It's learning the whole operating environment that comes with it -- mainframes. Stuff like JCL, EBCDIC, PDS. I did this for a year or so back in 1999. It felt very ancient back then. If you invest your time in gaining expertise with these technologies, you are not doing your career any favors.

0x445442• 6 years ago

Depends on your point of reference. If you buy into the ecology you could build a sane career where experience actually meant something instead of being level set every two years by the new shiny tech stack that's going to save the industry.

annoyingnoob• 6 years ago

Mainframes - the original cloud computers.

I started on mini-mainframes but then worked mostly with networks of PCs. The old mainframes guys used to say 'just you wait the pendulum will swing back to centralized computing'. In the age of cloud computing they were right, and those mainframes are still there too.

dfboyd• 6 years ago

I think this is just an IBM PR piece. It ticks all the boxes: quotes from IBM customers, quotes from IBM staff, mentions the "Master the Mainframe" contest. You can tell because when it says "mainframe" it doesn't mean "any large computer", it means "Something descended from the IBM 360".

tgflynn4• 6 years ago

Yes, because that's what the word "mainframe" means today, simply because all other machine architectures that were considered mainframes are now extinct.

I'm not saying it's not IBM PR, though.

AnimalMuppet2• 6 years ago

Unisys's ClearPath series are considered to be mainframes (or so says Wikipedia). The most recent ClearPath Dorado model was introduced in 2015.

As for the article: This may be what Paul Graham called a "submarine".

qwerty456127• 6 years ago

Unemployment applications are fairly small structured text records requiring some rather simple logic to process. I believe a single server built on a most powerful x86 CPU available today running an MS SQL Server instance (or Postrges perhaps, but I don't have experience with it) is more than enough to process all the unemployment applications on the whole fereakin planet. Why do they insist on using an ancient mainframe? That sounds fun but bizarrely irrational.

louiechristie• 6 years ago

COBOL in 100 seconds: https://www.youtube.com/watch?v=7d7-etf-wNI

Mainframes Are Having a Moment

Related Stories