back to article Retiring greybeards force firms to retrain Java, .NET bods as mainframe sysadmins

New IT grads and Java and .NET jockies are being re-trained to run mainframes by big companies desperate to replace a generation of IT staff giving up work. That’s according to Compuware, who has released a study that says CIOs are growing concerned about the looming skills shortage in their mainframe rooms. They are …

COMMENTS

This topic is closed for new posts.
Pirate

Hey, at least it's not Object.RPG with OpenGL extensions...

1
0
Silver badge

Spaces significant??

"We already have a trendy language (Python) that is following the 1960's FORTRAN mistake convention of making whitespace significant"

I'm sorry, but in Fortran the only place spaces are significant is in strings. You can leave them out in all other cases. In fact many Fortran compilers did just that as a first pass of the source code. It made for smaller intermediate files, when secondary storage was at a premium. Of course in PL/1 you had whitespace, but there you could use keywords as identifiers and the context would sort it out.

Yes, a parser for Fortran is a wild beast.

1
1

This post has been deleted by its author

Gold badge
Unhappy

PPirate Dave

"Hey, at least it's not Object.RPG with OpenGL extensions..."

You do realize there are probably 4 people who read this that know what you're talking about?

0
0
Silver badge

Re: PPirate Dave

Yes, I had a chuckle. My first job out of University forced me to learn RPG II, after I had been taught PL/1, APL and 6502 assembler (it was a long time ago) and taught myself C.

In my acrimonious exit interview (they did not offer me any pay rise - not even a cost-of-living one after my first year, even though I had become the most effective programmer in RPG in the department measured by speed to completed correctly functioning program, and it was not just me saying that), I likened RPG to a rather restricted assembler language. And in hindsight, I think that I was being generous!

Still, I'm grateful, as I moved on to be a long-term UNIX admin, which is what I am still doing.

1
0
Silver badge

Re: Spaces significant??

> in Fortran the only place spaces are significant is in strings

Tenses.

That may well be the case now, but I made a point of saying 1960s FORTRAN. In the case of F4 (from personal memory) the first 6 columns were reserved for label numbers and if column 1 contained a "C" that line was deemed a comment.

0
1
Gold badge
Unhappy

@Peter Gathercote

" I likened RPG to a rather restricted assembler language. And in hindsight, I think that I was being generous!"

Historically RPG was a language for programmers whose only previous experience was assembler language.

Fixed format upper case 5 character "opcodes" is exactly how a lot of assemblers have been laid out.

BTW 3 address instructions with conditional execution flags --> ARM Assembler.

RPG IV is meant to be much nicer, free format, lower case allowed, external subroutines etc.

0
0
Silver badge

Re: Spaces significant?? @Pete 2

That was imposed as much from the physical media being used to contain the program as anything else.

In the 1960's, everyone programmed on punched-card. You absolutely wanted to have card numbers on the card (not labels), and in a standard format, so that when you dropped your 500 card deck and the elastic band broke, you could stuff it through a card-sorter to put them back in sequence. The next column was, as you point out, a comment indicator. The rest of the card image was free-form, although with only 72 characters to play with, you could not really afford to be too generous with the use of spaces.

It was not only Fortran that did this. Pretty much any language from the era did the same, and COBOL and RPG were even more strict about which columns things should be in.

2
0
Silver badge
Alert

Re: @Peter Gathercote @John Smith

Fortunately, I've never had to work with RPG again. In fact, I do so little programming now other than shell and awk that I have to think hard about writing anything.

I have no problem with using condition flags like RPG and pretty much every assembler I've ever used. But at the time I was being told that RPG was a high level language superior to PL/1 or C, and that is why I made the comparison with such scorn.

I think I still have my RPG II programmers card somewhere which lays out, at the same pitch as an 80 character card, all of the different phase card layouts (Aaaaargh - suddenly remembered about the input exception phase - The Horror!)

1
0

Re: PPirate Dave

"4 people who read this that know what you're talking about?"

Judging from the comments, there's only 3... ;)

I did some RPG in a class back in the late 80's, and touched it again very briefly in the late 90's. Can't say I liked it either time. I guess it's good for what it was designed for, but brrr<shiver>, not my style at all. COBOL, however, I liked. Go figure. I could work as a COBOL programmer and not feel like I was missing out. And I've got 20 years until retirement. Maybe I should polish my resume and leave my Ivory Tower...there might be good money to be made.

2
0
Gold badge
Unhappy

Re: @Peter Gathercote @John Smith

"But at the time I was being told that RPG was a high level language superior to PL/1 or C, and that is why I made the comparison with such scorn."

That really was a LOL moment.

TBH with time I have come to realize there is a simple truth.

If your support tools are flexible enough any language can be a viable development environment.

The trouble is that there seem to be very few tools that a)Language neutral enough and b)powerful enough to be applied to any language.

0
0
Silver badge

Rename it to object.Cobol and start writing games in it.

COBOL has been an OO language since the mid-1990s.

I admit I am aware of few games written in it, though.

1
0
Gold badge
Happy

Re: PPirate Dave

""4 people who read this that know what you're talking about?"

Judging from the comments, there's only 3... ;)"

Well I did say "probably."

Guess I was a bit over optimistic.

1
0

I admit I am aware of few games written in it, though.

Catch the Wumpus?

0
0

I'd love to do that

I started out doing COBOL, now I'm a Java jockey. Moving back to mainframes would mean getting away from all the MS shit that I have to deal with day-in, day-out.

Where do I sign up?

14
0

Re: I'd love to do that

"Moving back to mainframes would mean getting away from all the MS shit that I have to deal with day-in, day-out."

Wrong. All the front end pieces are java. You'll be spending all your time figuring out what is going wrong with the Rube Goldberg connection system this time...

1
0
Silver badge

The story here is that companies are training people themselves. I nearly fell of my chair when I read that.

7
0

Software rot is a business expense

Nobody seems to take the fact that software isn't like traditional machinery, it needs to be constantly evolved and updated. Of course machinery needs maintainence (and eventual replacement) too, but typically of the "oil this, replace that worn out part" sort.

Businesses usually take the limited life of machinery into account, but not the limited life of software. That's an attitude that needs to change, there needs to be plans in place to keep software up to date and if necessary ported to new platforms, otherwise this is the exact situation you'll end up with.

4
1
Silver badge

Re: Software rot is a business expense

Nobody seems to take the fact that software isn't like traditional machinery, it needs to be constantly evolved and updated.

Actually, it is. There are many manufacturing techniques that were once state of the art but have gone the way of the dodo. For example, if you want to manufacture a spare for that aircraft component designed in the 50s, you might be horrified to find that you need to emulate something called a rubber press, or a drop-hammer, or even electron-beam welding. The difference with software is that within living memory it's gone from being regarded as something ephemeral that would be replaced with the next product, to something baked-in to systems that are expected to last for decades.

7
0
Thumb Up

Life in the old dog eh?

I got my first job as a trainee programmer 35 years ago this summer and learned COBOL on an ICL mainframe, later transferring to IBM mainframes. I remember in my second week at work picking up a copy of "Computing" and reading the banner headlines that COBOL was dead and soon nobody would be using it. I wondered seriously if I'd made a big mistake.

Time passed. COBOL became un-sexy and was never mentioned. Then the world woke up to the "Millennium Bug" and suddenly grey-haired COBOL programmers were coming out of retirement and earning mahoosive amounts of money. And now this article...

When Commander Grace Hopper "built" a language she built it to last!

10
0
Anonymous Coward

I was in a university not so many years ago (3? 4?), and one of the option modules was on IBM mainframes with JCL and COBOL. IIRC the course was funded by IBM, so that shows that they're trying to build up at least a little bit of exposure to the set-up.

It didn't seem to be as dire a language as everyone was making out; but I think as someone said above -- if you can't draw pretty pictures on the screen with it you're not going to attract the kids who all think they want to work in the games industry.

Seeing other people who took that module with me on LinkedIn, etc. though -- none of them appear to have moved into that market. The jobs don't seem to be their in the same scale as those for C#, Java, etc. -- and those I did see offered ridiculously low salaries (18-20k for graduate).

4
0
Gold badge

I suspect this is a big problem. Companies have been using the same people for years to keep the stuff maintained. Probably paying them quite well, as when they threaten to leave, it's suddenly realised how much of the system documentation is in their heads.

But not bothering to renew the resource by taking on anyone young. You can always poach a greybeard from someone else. So why bother getting 20 year-olds in, who you'll have to pay to train? Now they're finding out the answer.

Sainsbury's tried to outsource all that messy mainframe stuff a few years ago. It was a horribly expensive mistake they had to reverse. The problem is that your stock control and POS stuff is complex, interlinked and totally vital to a retailer. If you're out of stock of the thing someone needs, they'll often go to a shop that does have it - and then buy the rest of their shopping their too.

A smaller retailer I used to work for went for the worst of both worlds. All the COBOL type people were contractors. Great for the headcount, but I suspect it meant that there were no permanent employees with a picture in their head of what the mainframes were actually doing. Which is madness. It seems pretty brave to have no in-house control of systems that if they fail would destroy the business in a month.

4
0
Anonymous Coward

IBM itself needs new blood for mainframes

They just don't want to train them themselves (not that they could - no IBM internal training resources any more).

IBM is constantly trying to find reasons for the older, experienced and expensive people to leave the company, but now find that they don't have the skill in-house to support their customers. It's all going to end very badly if you ask me!

In my view, COBOL suited many business processes really well, and in a way that object oriented languages really can't, at least not efficiently. I never liked it myself, but I only worked in business programming for a year or so, and even then not in COBOL.

0
0

Re: IBM itself needs new blood for mainframes

"COBOL suited many business processes really well,"

It was there in the very Nane of the language: COmmon Business Oriented Language.

Grace Hopper's design objectives were met better with COBOL than any language since.

As far as I've ever been able to tell, most of the "Object Oriented" had One of several primary design objectives:

"Make the Designer Famous."

"Get the Designer a PHD."

"Make the Designer a Tenured Professor."

Occasionally all 3 objectives came into play.

1
0

Searching CWJobs for 'COBOL' returns around 10 positions. Most of them either high-level or short-term contract. Searching for JCL returned 0.

Searching for C#, you get over a thousand.

Not really surprising people aren't being attracted to it, so picking a few of your new batch of Java or .Net bodies is probably the only way to get people into this field.

Which is a little sad. I'd quite like to go back to COBOL / IBM mainframes -- but #### me if I'm going to apply to be a Java or C# developer.

5
0

CWJobs may not be the best place to search for COBOL Jobs.

There are other sites with Hundreds of listings.

The people who Post job listings tend to "cluster" on sites where the same set of job skills they are looking for show up in other people's listings.

0
0
Thumb Down

It shouldn't take more than a couple of days...

"What does Richards suggest CIOs should do to address the shortage in a more coordinated manner? First, profile your IT people by age, skills and the applications and systems they are responsible for. Next, capture and record their knowledge so it can be passed on to new people..."

So years and decades of mainframe experience can be captured and recorded, in a sort of rapid "job handover" process? Mr Richards, you have found the secret of the universe.

2
0

Re: in a sort of rapid "job handover" process?

Business use to have a decent planned handover process. Of course there was nothing "rapid" about it, but it worked fairly reliably. The old hand took on an apprentice for a number of years and brought him up to speed. When the old hand retired, the apprentice became the old hand and at some point sought out a new apprentice.

4
0

Re: in a sort of rapid "job handover" process?

Always two, there are. A master, and an apprentice.

10
0
Silver badge

@Anonymous IV

Sorry, but I fail to see where it is said that the process should only take a few days.

Capture and record means meetings with the people working the processes, lengthy Q&A sessions to ensure that everything said is taken down, extensive review of the notes to produce a proper process detail report, and review and quality checks to ensure that the report mirrors reality.

Anybody with a brain can see that the whole thing is going to take time.

What I find very interesting is to find out that the accountants and MBAs/Senior Whatchamacallits didn't notice that they needed to ensure proper training for their personnel. COBOL has had the reputation of the dodo for decades already, it's not new. So how could these extremely (self-)important people NOT see this coming ?

These are bankers. The first rule of making money is that you sometimes have to spend some to make some, and sometimes you have to spend some to keep making more. It would seem that banks (like many big-name companies that have gone astray in the past 2 decades - looking at you HP) have also been taken over by pure accountants, the kind who break out in hives as soon as they see an invoice or an expense report, and start shivering if the next quarterly report is not better than the last.

It is time those kind of accountants go back to where they belong : dungeons. Let them sit on piles of gold and see if it gets more comfortable with time.

8
0
Alien

Re: in a sort of rapid "job handover" process?

COBOL really is the "dark side" then.

1
0
Silver badge
Thumb Up

Re: It shouldn't take more than a couple of days...

@Anon4: Spot on. I vaguely remember "knowledge engineering" in expert systems classes I had to do in the 1980s. Problem seemed to be the issue of meta-knowledge. Most experts don't know what and how they know. Only BS merhcants claim that. How do you capture and record knowledge that no-one knows exists ? All those little quirks for historical reasons. Personal programmer idiosyncrasies. Unauthorized changes made at 02:40 to get critical system going again in emergency fix, forgotten about after falling asleep from 30 hour day.. Not to mention staff who know they will be dumped the moment the PHBs smell a bonus, so things get forgotten. Finally, is documentation up to date and read ? . Fully documented and available in correct location and staff bother to read it.

ITIL is not part of the solution, it is part of the problem as currently implemented in most organisations. Make change process tedious, process ridden, slow, managed by rude process droids obsessed with their process, unable to seethe organisational needs will result in undocumented quick fixes because it is just too hard.to do change control.

Finally, years of bitter experience give job longevity a great advantage. Corporate and technical knowledge give the owner an unappreciated understanding that no document can, no matter how clever the reader.

1
0
Silver badge

As Nelson Muntz says

har haar!

0
0
Gold badge

Re: As Nelson Muntz says

My brain insisted on reading that as Nelson Mandela.

I was confused for a few moments, until sanity re-asserted itself. One of these days I really must learn to read...

1
0
Silver badge
Pint

Mainframe Sysadmins?

Is it just me?

I though mainframe *programmers* wrote in COBOL.

[Which used to be at least partly self documenting because of the 'simple everyday words' syntax.]

Sysadmins often have to know more arcane stuff - although it is {mumble} decades since I was system support for ICL mainframes.

Just out of interest I Googled 'IBM Sysadmin' and found

"The IBM DB2 System Administrator job role skill set specializes in problem determination and problem source identification of DB2 Databases and Instances, issues on Unix, Linux and Windows operating system. Skills and Responsibilities include: Technical knowledge of DB2 Engine commands and their applications on system level , Unix, Linux, and Windows Operating System commands, functions and capabilities; ability of addressing technical aspects of DB2 engine issues. Experience in iSeries/DB2 developer/DBA, iSeries operating system and architecture knowledge, Command Language Programming (CLP) on the iSeries, Implementer (iSeries change control tool), DB2 and SQL."

No mention of JCL or COBOL.

Perhaps the DB2 malarkey doesn't run on mainframes?

Then again

"Must know COBOL, JCL, CICS , Db2. Experience in Unix, MF Cobol (execution of COBOL programs in UNIX environment) is preferable."

So exhuming crusty old COBOL programmers with a smattering of CICS and JCL may not be the full requirement (unfortunately, should I ever get bored of retirement).

Still, no explicit mention of .NET and C#.

Anyway, nearly time for my warm drink and nap.

Beer, because that is what being retired is all about :-)

2
0

How many of the hot shot gui programmers are going to want to work on boring mainframes?

That's the real question.

0
0
Anonymous Coward

"How many of the hot shot gui programmers are going to want to work on boring mainframes?"

Now I have picked myself up from the floor, and wiped tears of laughter from my cheeks ...

That question presupposes that there exist "hot shot gui programmers".

In my experience, that is not even close to a statement of truth.

5
0
Trollface

re: hot shot gui programmers

Arn't they the people who couldn't make it as Graphic Designers, and didn't want to take a job as a barista?

7
0

I had my tongue in my cheek while posting that.

0
0
Silver badge

On the benefits of keeping knowledge in your own head

Far away and long ago (in the mid '90s actually) I was working with a bought-in package that interfaced an ATM network to a bank's accounting system. The system worked well but its documentation was, ahem, sparse, and so we relied on our accumulated experience with using it and with reading the code to customise it for new sites.

Much of the code carried the name of one particular programmer who was obviously rather good at cutting code and distinctly less so at documenting it. In due course we ran into a difficulty on one installation that resulted in this programmer appearing on site. He turned out to be a really nice guy with a proper enthusiasm for beer, top programming skills and had been in the business a long time. I got to know him fairly well and once asked him about the documentation. He had an excellent reason for its deficiencies: he was due to retire in 2-3 years and told me there was no way he was going to rewrite the documentation any time soon because he knew he'd be tossed out the door by his money-grubbing American management the moment he'd completed it.

6
0
Anonymous Coward

Re: On the benefits of keeping knowledge in your own head

what an ar$ehole.

0
9
Go

Re: On the benefits of keeping knowledge in your own head

That expertise represents a working lifetime of training, experience and insight. Do you think that would matter to most managers looking to cut headcount or outsource? Not a bit.

There are arseholes in play, but you have failed to identify the right ones. Stick to your .net toys if that gives you pleasure, and let the grownups run the real systems.

4
0

Re: On the benefits of keeping knowledge in your own head

A personal favorite was a problem we had that was causing Multiple crashes over several days. The old "Stay all night, go home and crash for 3 hours, take a shower and come back for another 24 hours" sort of problem.

Eventually, we narrowed the problem down to a 3rd party vendor product that had run over the weekend where the 3rd shift operator had Changed a run time parameter from what was documented. We looked in the manual to find out What the changed parameter was supposed to do. It Wasn't Documented. So, we got the Vendor Rep on the phone. He found the Programmer because their Internal docs didn't cover it either. One of the Questions that came up was "How Much data can this product handle?"

The answer that came back was:

"It shouldn't be a problem, we tested it with Huge Files."

"How Huge?"

"3 Million entries"

"We have 30 Million and Growing."

A moment of silence. "Oh."

We finally came up with the answer but we never Did get the Revised User Manual they promised us.

0
0

In the old days (70's in my case), IBM ran a really good educational system on a regional basis for all things mainframe. In some courses (thinking Basic Assembly Language for starters) there was a serious reading assignment and an exam on the first day - fail and they would send you home. There were even specialized schools for specific industry segments such as Financial.

If IBM wants to keep their Z-series relevant, they need to bring those courses back (with some updates, of course -- we learned SNA, not IP in those days!).

john

2
0

Put BAL on your CV and put it out there ... you might be surprised how many calls you get!

1
0

System z training

Interestingly, IBM is no longer in the business of directly providing training. If you go to their training and education website you'll find the courses are offered through several vendors, but not IBM. They have a university initiative which provides prepared curriculum and system access to enable schools to offer courses is assembler, COBOL, DB2 and the like. I suspect that the results are mixed as I'm seeing some of these programs being shuttered. SHARE has its own zGen inititive. In a recent web conference the 20 somethings had some interesting insights. All mentioned that they thought a college education was not necessary to the job of sysadmin (sysprog) and as I recall at least one and maybe more stated that they prefered working with the green screen rather than a GUI, in part for the arcane nature of it, but also its efficiency.

1
0
Gold badge
Unhappy

@Philip Lewis

I remember seeing one of the "Shaums Outline Series" on "IBM Assembler Language Programming".

Presumed it meant IBM PC programming.

Actually was 360/370 BAL.

I suspect it's a topic with few 3rd party textbooks.

0
0

Re: @Philip Lewis

"I suspect it's a topic with few 3rd party textbooks."

Older programmers who Still Have some of those older textbooks and manuals can often sell them for more than they cost New, thanks to Inflation and the "out of Print" nature of the subject matter.

0
0
Trollface

upgrade to XP already!

1
0
Silver badge

capture and record their knowledge

(1) not that easy

(2) as soon as some mucky-muck thinks they have it, i'll be booted and some minioni off-shore will get my job at a tithe.

(3) you're not going to distill 40 years experience into a training manual for some newbie. I've probably forgotten more than most will ever learn

PL/1, Cobol, Unisys assembler, Mapper 4GL ECL, JCL - - - don't do any of that stuff any more

1
0
This topic is closed for new posts.

Forums

Biting the hand that feeds IT © 1998–2018