That is an interesting question. Is it your job as a college prof to train students in the application programming language du jour, or to turn out students who know how to program computers? I would like to imagine that, in an ideal world, someone competent who knows COBOL-2014 well could figure out how to update a COBOL-68 program. And that if a student did learn C in the 1970s, that person could still figure out how to code in Java later.
I am impressed that those old mainframes are still happily whirring along-- I guess they were a good buy, but, yes, at some point you would think the power consumption would make it worth upgrading to a slightly newer model.
Replacing a big system like that is very expensive. The old system still works. Why are you wanting to waste the taxpayer’s money to replace a working system, just because you think you deserve the latest toys? [/s]
In all seriousness, implementing exciting new programs gets publicity; replacing boring old infrastructure with more boring infrastructure doesn’t. Nobody cares about old computer systems until they don’t work anymore. There are always more needs than the budget can be stretched to cover, and something that isn’t glamorous and hasn’t absolutely failed can always be put off to next year (lather, rinse, repeat). There are a lot of 1970s and 80s-era computer systems in federal and state government offices; parts of the IRS system date back to the Kennedy administration.
There are lots and lots of jobs that require FORTRAN programming, though the job description is likely to be scientist rather than programmer. Most of the code run on supercomputers to this day is in Fortran, from weather prediction to physics and chemistry modeling. If you’re writing code to do very complicated math, Fortran is still the language of choice.
I was writing FORTRAN code in 2004 and after several discussions and with much gnashing of teeth managed to get my boss to agree to let me use Fortran 90 commands and thus have code that was no longer fully FORTRAN 77 compatible. (How could we possibly not be compatible with the language version from 1977? Heresy!) The codebase we were working with had functions that had been written long enough ago that they were formatted for punchcards(with comments from the 70s!)
“I don’t know what the language of the year 2000 will look like, but I know it will be called Fortran.” —Tony Hoare, winner of the 1980 Turing Award, in 1982.
In at least some government agencies, you also have to account for the costs of moving data over - my agency still keeps data in something from 1985 or so. To update, you’d have to move nearly 40 years of data over, because we still use those old records.
I’m a mainframe security analyst. We still run decades-old code because it works, and it’s stable as you could ever hope for. And it’s FAST.
We actually have in-house education programs to train people in FORTRAN and COBOL. Unlike New Jersey, our mainframes are only about two or three years old - believe most of our processors are z13 or z14. IBM still builds them - they released the z15 last September.
I suspect they are not literally using 40-year-old mainframe hardware, like an actual System/370, but can certainly believe that the applications software is that old. IBM’s business model for mainframes back in those days was mostly oriented around leasing rather than outright purchases, so as tech improved there was incentive to either move up to higher performance at similar cost or similar performance at lower cost. I’ll take a WAG that the cost of maintaining a 40-year-old mainframe would be prohibitive if it was possible at all, and that you could lease a modern backwards-compatible z/Architecture system for less than the maintenance costs alone. But I can well believe that the applications are written in a long-obsolete version of COBOL and that much of it hasn’t been touched in 40 years!
Hardware needn’t be a show stopper. The old systems were fairly simple and well documented, so emulation at the machine-code level wouldn’t be hard at all, and modern hardware is so fast that the emulations would run rings around the legacy hardware…even running several machines at once. It might actually be a problem if something depended on the old hardware running slowly, but this is far less likely for biz software than, say, gaming.
There are tons of emulations of legacy hardware running retro games. I run an emulator of my old HP-41 programmable calculator because I used the vintage one so much that it became second nature, and modern calculators just frustrate the buhjezzus out of me. If anyone ever offers big bucks for a HP-41 coder, sign me up!
You can download a old COBOL program and use a good PC program like Microfocus COBOL. It’s backward compatible to COBOL-68. You get a much friendlier development platform. A IDE interface with full screen editor, compiler and debugger.
I used to create test data files for the PC. I could edit,debug and fully test the programs on the PC. Then upload the finished work to the 40 year old mainframe.
I found it to be a big time saver. It may require working with the Operations Center to transfer the code. Most mainframes run FTP, or Kermit or some terminal emulator that can download.
I have a good job and wouldn’t relocate to New Jersey.
The article repeatedly mentions these 40-year-old mainframes, though, unless that’s bullshit. Another question: are they planning to pay these “volunteers” $1000/hr?
I’m not sure there is anything surprising or problematic about using COBOL itself, or not rushing to re-write all the software (how cost effective would it be, and what language would you pick to get another 40 years out of it?).
FORTRAN was certainly business software, before it was replaced by BASIC. The accounting system at one of my big city hospitals was a FORTRAN package running on a VAX. (And by then the business school I was associated with was PICK)
I could help them out with COBOL (COBOL is easy), but without looking, what they actually need is people familiar with their screen manager and file system. Then as now, 90% of any implementation is the interface.
90% likely that the mere presence of COBOL is not the main problem. The main problem is that there are critical processes running where no one currently employed knows how they work. Even if the code was written in a more commonly-used language, a pile of undocumented spaghetti logic is not going to be easy to work with.
I teach Computer Science at a small community college. For their final project I have students choose an area in which to code something like an mobile app or something in AI. However, this semester our schedule got compressed, so I’m having them explore a combination of new languages such as Swift, Go, Kotlin, and the like.
I had one student ask if she could learn COBOL, based on what she’s seeing about New Jersey (such as The Hill - New Jersey COBOL programmers - make sure you read the comments!) I told her the reason to learn a variety of languages is to see how they differ and how they are the same, and learning COBOL would certainly be an interesting comparison.