Compuware promises mainframe DevOps as old programmers croak

Compuware is attempting to bring big iron software into the 21st century by allowing developers to use DevOps tools to manage mainframe code. It’s literally a life or death issue, as the industry fears that people who really know about mainframe code are about to retire – if they haven’t already expired altogether. Meanwhile, …

[Destroy All Monsters]

What the fuckety fuck am I even reading and what has any of this to with "Object Orientated" programming? Or even JavaScript?

COBOL is a tool. It is an unwieldy tool from back when machines had memory in KByte sizes and a single KHz CPU and three terminals, structured programming was starting to be considered a neat idea and when most everyone had no idea what adequate program syntax might look like, even less what types were (dependent, OO or otherwise) and how a compiler could check code. Time to retire the crap.

And if you program program your mainframe in assembler... well ...

[Mike 16]

I resemble that remark

Don't think I ever used a single-kHz CPU. Did start out on an IBM 1401 at just under 90 kHz (with 16kB memory, using a term that had just been invented by 1965). We only had one terminal, but there was what would now be called a word-processing system available that could handle something like a dozen concurrent users, keeping most of each document on disk (1 or 2 MB). An early (first?) compiler-compiler was written on/for a 1401, as was a FORTRAN compiler.

Besides grumping, I wrote this comment to mention that COBOL was the first language I ever saw (and still one of very few) that made a clear distinction between external and internal representations of data, with the compiler taking care of what in more modern languages is all too often left to complex, ad-hoc, buggy marshalling code, or more likely by vomiting C-like structs (Pascal records) onto a disk or wire and expecting that all will continue to work well when CPU or OS changes invalidate the "well it work on mys system" assumptions.

It's not COBOL (or 360 assembly) that is the missing skill. It is knowing what resource and operational constraints are, how to plan for updates (and recovery), and how to badger upper manglement into giving a damn about their commitments to customers.

That said, a friend accidentally let her employer know she had done some 360 assembly back in the day and found herself maintaining a library whose documentation should have been shelved next to the Necronomicon.

[QuiteEvilGraham]

Well, I've written code (in assembler) which built dynamic hooks (modelled in assembler), then dropped them into VSAM record management (also written in assembler), so I guess I have "program program"'ed in assembler; possibly even a program program program. Amazing the things we do for money. Those fellows who wrote z/VM, z/VSE and z/OS also seem to get some traction out the assembler on the mainframe, although they mostly cheat when it comes to writing a program program and use macros.

That aside, what's your point exactly?

[M.Zaccone]

Plenty of people out there, just not at the price industry wants to pay.

I'd hazard a guess that the reason some companies are having trouble recruiting is that they go to their favourite outsource partner such as IBM, HPE or Accenture and find that they don't have any offshore staff that can write for mainframes.

There are plenty of FORTAN and COBOL programmers out there with plenty of years of work left in them and we also know how to write lots of new whizzy stuff like c++, python , java and whatever other languages are flavour of the month. I just tend to keep quiet about the older stuff because employers don't seem to be recruiting for the older languages.

And I expect that the outsource partners have plenty of UK based people that can code for mainframes but keep quiet about it because they have had "to move up the value chain" and take PM, scrum master and other similar salary preserving roles as coding jobs have been shipped offshore.

[Anonymous Coward]

Re: Plenty of people out there, just not at the price industry wants to pay.

The only Cobol programmer I know is now 70. Mind you, she did move out of day to day programming, to training others, and then a more management role before retiring from industry.

[M.Zaccone]

Re: Plenty of people out there, just not at the price industry wants to pay.

"The only Cobol programmer I know is now 70."

I know plenty in their mid to late forties. Mere whipper-snappers , ankle biters, rug rats!

[Anonymous Coward]

Re: Plenty of people out there, just not at the price industry wants to pay.

I see where you're going and I agree, but I also think there is just a shortage of COBOL (and other legacy z interworkings, CICS, IMS, etc) skill. Every COBOL/z programmer I know, at active mainframe shops, is pushing retirement age and many have likely already retired. I know of one organization in the US who just decided to move off of mainframe because the only people who knew anything about it or the code that was developed are going to retire. That is the real issue here.... It isn't that young whipper snappers refuse to learn COBOL because COBOL isn't cool (if you pay them enough, they'll learn it). It is that most of these COBOL apps on z are undocumented with no architectural organization... just line after line of procedural code which apparently works. If the person who developed it over the last 30 years hits the door, that is a significant risk. Probably best to just move this to a modern language on a new platform. It will be a huge hassle to port or rewrite the code, tens or hundreds of millions in some cases of expense, but at least you will have a handle on the apps. There is probably an ROI in there too. Mainframes and related software are extremely costly... extremely costly. I know there are the die hards out there who say that mainframe being expensive is a myth. You can run Linux with some open source stack on mainframe and it is no more expensive than x86. The problem is that no one does that. They all run z/OS with a ton of expensive IBM/CA/Compuware/BMC software. If you are running mainframe the way that 98% of the user base runs mainframe, it is clearly the most expensive platform.

[peyton?]

Did you leave out C on purpose?

Very widely used, frequently not object-oriented...

Or does it fail to meet some narrow definition of "real code"?

[martinusher]

Its a bigger problem than just legacy bank systems

Object Oriented programming -- or rather, languages that are targeted towards this -- are very powerful tools but they are now seen as the only solution to a problem. The result of trying to push this methodology into places it doesn't belong -- hard real time, for example -- is very ugly, bloated and non-deterministic code. Most programmers don't understand this, they keep trying to churn the same stuff out, and they're very resistant to any external ideas, especially if they're what they perceive as old-fashioned.

Its difficult to explain to most programmers that you really don't need an 85MByte runtime image running on what would have been called a supercomputer not that long ago just to read your email.

[Erik4872]

Ops discipline is what's missing

I'm not a mainframer but work in an industry that is very dependent on them at the core. In the push for Agile and DevOps, the thing that's missing is the discipline that the mainframe world has. It's hard to find new COBOL coders, true, but it's also hard to find IT operations people who aren't enamored by the cowboy mentality of "just make it work, we're at web scale." So, I'm not sure how they're going to merge DevOps culture with mainframes; it will be interesting to see how much of this is marketing.

It's not even cloud vs. on premises. You can have cowboy admins in the cloud also, or you can design cloud systems that have discipline as well. The mainframe world is way more conservative than, say, a web server farm supporting the back end of a smartphone app that no one will gripe about. Code changes, patches, upgrades, etc. are not taken lightly because anything that still lives on a mainframe is likely to be any or all of (a) business critical, (b) brittle enough that it's dangerous to touch, or (c) disastrous to tons of upline systems and software that assumes the core never changes.

That said, too much conservatism and process is bad too. Any systems guy in IT has learned to hate the acronym ITIL for example, because it _usually_ means a bureaucratic nightmare implemented by consultants that drowns IT in process to the point where changing anything is a royal pain.

[Amorous Cowherder]

I've seen more Cobol video training courses appearing on some sites. I'd never tried it before so I had a wee play and I quite like Cobol. Yes it's an ugly bugger but my first serious coding experience was with procedural SQL code about 20 years ago, so Cobol doesn't scare me at all, not like it might scare those who've only ever prayed at the alter of OOP.

[Steve Aubrey]

Errrm - altar. The "alter" of OOP is part of what's being discussed in the article.

[John Sanders]

I'd say

Marketing-crap

Also I'd say the banks got big bucks, they can afford to train people if the issue is so serious.

Not affecting my sleep.

[Dwarf]

Re: I'd say

Until your bank can't process your account and you can't buy food...then you might have a different view

Good things came from mainframe - today's virtualisation as an example. Good change process as another. We all owe a lot to what it's given the industry, even if there are still some dinosaurs lurking there.

Perhaps the way forward is to blend the good bits from modern technologies upstream ?

[a_yank_lurker]

Real Problem

The real problem is not the lack of COBOL programs, that is solvable, but the lack of knowledge of the system. To be blunt, a competent program should be able to learn any language no matter what its paradigm is. But with retirements, lack of documentation, and lack of history any new programmer will be in trouble because they are not fully aware of the nuances of the system.

[Where not exists]

Re: Real Problem

What you seem to be saying is the new kid on the block suffers from a lack of corporate knowledge and doesn't know the often undocumented business rules that lie deep within the code. In the "good ol' days" (whenever that was) the newbie was mentored extensively. Now however with limited staff the few people who remain, even if they want to mentor, simply can't. They don't have the cycles to spare. The overlap that mentoring requires simply doesn't happen anymore. It's a "luxury" of a glorious past. Experienced personnel get shown the door on one day, and recent budget hirings come in the next. Wash, rinse and repeat...

[Anonymous Coward]

Re: Real Problem

Agree, it is a problem in every field. Companies underestimate the value of company specific knowledge and very few take the time to bring anyone up to speed or give them the incentive to stay. There are companies who bring in entry level hires and mentor them or train them extensively, IBM is one of them, but, like IBM, they then pay them a fraction of what their market rate will be and a few years after their training they all leave for a higher salary. It used to be that it would be odd if you could go get a competitive offer for more than you were making at your current company (assuming we are talking apples to apples, large company to large company). It made sense. Why would another company want to pay you more to come in and learn a bunch of things and why wouldn't your current company pay you top dollar as you are moving at MACH5 speed at that company and know the processes inside and out. Along the way though companies decided they would just stop increasing salaries in line with market rates. It was a bet that employees would not go out and get a new job even if they could make more money because getting a new job is stressful, takes a lot of initiative and is risky. Brilliant move as they are ensuring that only the most motivated and driven employees leave while the "whatever, it's a paycheck" crowd stays.

[quattroprorocked]

They'll retire like pop stars

Returning as soon as it goes wrong for X times previous salary.

Saw it happen to a neighbour. He had coded nuclear power station stuff for Magnox facilities in some 50's language and 6 months later got a begging letter and and an invitation to write his own cheque until he had either delivered "start from scratch documentation" or the station was shut down, which was on the cards then and has happened now.

When he first retired he had a nice pension and his house paid off. When he next retired a few years later he also had a place in Spain, a narrowboat, and the resources to flit between them as the mood took.

[Anonymous Coward]

Re: They'll retire like pop stars

I know a situation where that has happened. A mainframe programmer retired and the CIO asked the department manager "Who is X's back-up?".... crickets. They hired him back on a part time basis as an hourly contractor. I think he probably makes more as a contractor working part time than he made as a full time employee.

[Laura Kerr]

Disciplines of the old mainframe world might not go amiss in less mature organisations

Oh boy, ain't that the case. The horror stories! The horror stories!

[ultimate_noobie]

A "good" programmer solves problems with the tools available, no matter how much they hate them or the problem. In my job, we've used everything from ancient assembler on processors that existed 30 years before I was born, military one-off languages where the idea of "documentation" was something that had to be delivered in the same binder with the punch cards to debugging whole systems where every function but main was an inline in some C++ 'derived' language for embedded use. The issue from where I sit is that the companies that want a specific skill set often A) never know what actual skills they need beyond the name of a language/compiler/OS and B) aren't willing to pay above an entry level for these 'desperately' needed skills. Most try to outsource or hope someone is willing to take an underbid and run screaming about how the sky is falling when neither works...

[knorth]

Reality check on COBOL

What's the state of COBOL today? IBM mainframe COBOL compilers are not the only game in town.

The zCOBOL, Raincode and GnuCOBOL compilers are free. GT Software and Micro Focus sell COBOL compilers. Raincode, GT NetCOBOL and Micro Focus VisualCOBOL can generate code for .NET assemblies.

Veryant isCOBOL executes with the Java runtime environment. The GT and Micro Focus compilers can also generate code for execution by the Java VM.

Micro Focus has 1 million licensees for its Visual COBOL product and sales increased by 91% in 2014.

[WG]

Due to 'keep the educational curriculum up to date', most young programmers are lacking:

* Knowledge of anything besides JAVA, Ruby, Python, Perl, probably C++ or C (or any other language that requires compilation and linking).

* Knowledge of any OS besides Linux and probably Windows and IOS

* Knowledge of any other programming environment than Eclipse and other IDE-environments

* willingness to do 'non-fancy' stuff (the part of business logic that is 'invisible')

* interest on what goes on behind the scenes: System management, system design)

* Discipline required to work in a near 100% uptime environment (so no reboots unless required)

* Discipline required top develop and code systems that will be around for decades (I stead of being 'replaced' every 3 to 5 years).

Of course, this is an exaggeration..

It is not just the financial environment that struggles with this problem. It's very much the same in other environments where is invested in projects that have to last decades. This requires a specific mindset that you can only get when trained and mentored over a number of years.

Management ahs another role in this - they usually have no clue whatsoever what goes on in the data center, and how much the company relies of it - and they are only focusing on the (direct) cost when hardware and software needs to be purchased of developed. Never on the the cost in the long run.

Therefore, you get these problems...