You might want to consider the cost of not upgrading legacy tech, UK's Department for Work and Pensions told Brit MPs have told the Department for Work and Pensions (DWP) it should factor in the cost of not upgrading a 34-year-old legacy system when reviewing tech investments after it contributed to a £1bn pension shortfall. The department should consider whether there are "cost-effective ways to upgrade its IT systems and enhance …
Indeed. I also fail to see how using an old mainframe contributed to the problems.... as far as I can see it's not a technological problem... more an organisational problem.
We had automation and system integration from ICL mainframes to PC and UNIX based systems when I worked on them in the late 80s/early 90s. I remember my manager at the time drumming it into my young self that we should automate as much as possible (partly because he didn't like the operators :-) ).
So, if the current lot in charge can't manage to automate and integrate what they've got now I don't hold out much hope for them doing it with new toys.
I remember Fujitsu announcing that ICL's VME/B OS had been ported to X86 hardware, and for certain that hardware will have more memory and be a lot faster than a 2900 OCP ever was.
In fact, VME/B and applications written for it should be relatively easy to port to modern hardware because the microcode needed to virtualise it already exists: VME/B on a 2966 sat on top of microcode executed by a 2MHz Motorola 6809 MPU, so just rewrite that for ARM or X86 hardware and job done. I got the full detail on how all that worked as part of an in-house BBC course on 2900 internals in 1978.
Bottom line: I see little excuse for the mess that Fujitsu and the other usual suspects are making of supporting HMG departmental systems, though I suppose charging for keeping the existing systems running while HMG's departmental heads endlessly bicker over priorities for implementing poorly defined system requirements is both more profitable and much easier than actually getting stuck in and doing the work needed to provide modern systems on time and to budget.
Well what isn't totally clear is whether the DWP actually have one or more ICL 2900's still in their production environment. Or whether everything has been rehosted on to modern hardware, so the problem is more about maintaining a software system designed and coded using 1980s mainframe paradigms.
Fair comment.
Its certainly true that the personal tax and pension stuff has been on ICL kit for an inordinately long time: I remember being told, around 1970, when I worked for ICL, that 1900 COBOL's then newly added ability to hold a collection of previously used overlays in memory rather than reading them from disk each time they were executed had been implemented when ICL Dataskill had been asked to implement DWP's first automated payroll & pension tax system.
The story went that, when the ICL team rocked up at DWP and the team leader asked for the project definition, the civil servants simply dumped a set of thick books, which contained the salary and pension legislation, on a desk and said 'Program all this'.
It wasn't long before the team's technical manager realized that the programs, which were to be written in COBOL, would be far too big to be loaded into even a 22AM address space (8M 24bit words), and so would have to be overlaid and that, as handling almost every taxpayer's details would require at least one overlay swap, the system would be tooth-achingly slow if each overlay had to be read from disk each time it was executed.
Hence a high priority COBOL development program to allow the most used overlays to be automatically held in memory where they could be executed without even the overhead of moving them about in memory: simply copy call data into copies of the parameters in the overlay's address space and then switch control to it. Exit from that overlay when it had done its thing was equally simple: copy the result from the overlay's output parameters into the calling program's corresponding variables and pass control back.
All this only needed changes to the COBOL compiler and its runtime support library since the required memory protection and ability to switch control between processes that were already in memory was a standard feature of 1900 architecture.
Given that back history, its scarcely surprising that what must be a pretty large complex, and frequently amended rule set might be something that people tiptoe round and avoid, whenever possible, making anything other than minimal changes to.
IT might be worth exploring what's meant by "1980s mainframe paradigms". I'm aware that applications paradigms have shifted in 30 years or so but that doesn't mean that an upgrade needs this shift. If its just a problem with maintaining obsolete hardware then it should be fairly easy to emulate that hardware using a commodity processor. Its the same with the peripherals; these are probably the part of the old system that not only needs the most maintenance but is the one that's most trouble to repair.
Replacing a set of aging hardware so an existing software suite can continue to be used is probably a lot cheaper than rewriting the entire system from the ground up. The rewrite introduces all sorts of extra work and uncertainty plus the obvious 'mission creep' which is why people might be skeptical that it could be completed successfully in a specified timescale.
(I'm an engineer so while I like new and interesting things I also subscribe to the notion that "If it works, don't mess with it".)
Well there might have been a 6809 running some microcode. But that’s not how the 2966 rolled now is it?
It is ridiculous to suggest that VME/B is virtualised - for one thing, VME moved on a bit since you had a course on 2966 … no one has used VME/B since VME/K was killed in the early 80s. Oh, and the “x86” virtualisation is really Xeon hosted (in other words IA64) and utilises specialised microcode in the Xeons to get VME to work well on the micros. In simple terms, it’s a bit more than instruction set emulation.
The DWP systems were written in the standard Range COBOL and used the usual IDMS / TPMS TP combo.
There have been solutions to migrating these programs/systems without rewriting them for over 25 years.
The reason VME is still doing the pension job is simply due to DWP self interest …
Why? If the systems are rewritten, they will need less people to administer them. The union and management don’t like that …
It’s the DWP that is broken, not VME.
I suspect what will actually happen is one or more cabinet ministers will have a mate who is a dab hand at installing large scale computer systems for government, despite being a one person company who works part time while owning the minister's local pub. The contract for this will be in the 10s of billions of pounds, and it will, of course, be awarded without any scrutiny, or a tendering process..
Either that, or it will go to one of the government's favoured IT contractors, with those billions going to the company, with some being returned to cabinet ministers in the form of "donations".
As the PAC report makes clear the management of the DWP is to blame for responding to changes by building ever more layers of complexity rather than changing or replacing the underlying systems. However, some of the blame must surely lie with politicians who add ever more rules (and exceptions to those rules) to existing regulations and policy rather and never simplifying things. Reforming and simplifying is complex and takes time and the politician looking for short term headlines will always prefer to add their initiatives on top of existing processes as they will be long gone before the benefits of a systematic review are felt.
Indeed, most of the fault lies with politcians trying to buy votes from an ever more precise segment of the population. Or whatever the Daily Mail printed this morning.
As for new systems being better than old systems, let's just consider a few headlines over the years - see ElRegs passim.
I've never done that, but I have this feeling that it doesn't work that way. It seems to me that you're just as likely to get fired, but if you are, things go really badly for the company that fired you in that case. For you not to be fired would rely on the people making the decision knowing that what you do is hard for others to take on and hard to improve quickly, but that information rarely seems well-understood by those who don't do the processes themselves.
DWP advertised for a role, mentioned they're on the Disability Confident scheme. With a decade of experience in the role I apply, indicate that I'm also disabled. They refuse me an interview. Their scoring of my application? They didn't read my CV.
It's reasonable to assume my reaction.
Am I surprised to find out that their approach to IT is horrific? It's reasonable to assume my reaction.
A couple of Raspberry Pi's, a few large-capacity SD cards, & a copy of the Libre Office version of Excel in which to store all the data.
It'll take, what, about fifteen minutes to slap it all together & get the bugs worked out, plus another five to ten minutes to make it pretty for the manglement, so perhaps half an hour tops?
I'll be a hero!
*Stands in a dramatic super hero pose, wind in my hair, lights reflecting in my eyes, and because of my name, my cape billowing around me from the front because I'm wearing the bloody thing arse-backwards*
=-D
Indeed VME is doing a very good job of supporting things far beyond its anticipated life on platforms that didn’t exist when it was first designed. The systems that were built on top of VME are a different matter. Many of those are long overdue updates that would have prevented the reported problems. With judicious tweaking CHIEF, a VME hosted system, has kept HMRC’s Customs processing going at far greater volumes and for far longer than it was ever designed for while its replacement has been reworked several times beyond its expected delivery date.
I dunno if it's all run by the same system[s] but...
When I optioned to pull in my pensions at 55 (7 years ago), my 2nd P45 from Civil Service Pension had my name and address correct with the right telephone contact/numbers, BUT somebody else's NI number and payment details (and there was no way our address and names could be mistaken for each other)!
After a lengthy phone call to them (it took ages to explain to the girl what I was on about) I received an updated P45 about 3 months later. This time all was correct on the headers, including my NI number but it still had the other person's payment details!
Another lengthy phone call.
Sixish months later another P45 arived with the other persons details BUT my payment details... dear god.
Finally after, what 13 months, they finally got it right.
What a mess.
There is no spaghetti code like the spaghetti code that results form decades of changing government requirements, but the complexity and difficulty of dealing with it should never be allowed to be an excuse. All major systems are complex; if people followed this department's methodology, nothing would ever be upgraded because it is "too hard."
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
