Takes from the taxpayer, gives to the old – by squishing a bug in Thatcherite benefits system What's the saying? The more things change, the more they stay the same. Welcome to On Call and an account from nearly 40 years ago when one hard pressed engineer was dealing with a ham-fisted response to the policies of the UK's Thatcher government. Today's tale of public sector woe comes from a reader dubbed "Andrew" by the …
It's not the desktops, or even the servers that will be the problem, it's embedded systems which have been sat quietly humming away for decades watching their clock ever tick onwards.
Those devices, when their clock ticks backwards - that's the unknown consequence.
Whether that be building control systems, or more obviously life critical (and less obviously time critical) systems in vehicles, or medical equipment - some of which I'm sure is yet to be developed, but they'll pick up their old kernel because "It's been tested and certified, and it's never connecting to a network anyway"...
There are very few embedded systems that make use of date & time to fulfil their main functions, though they may have a RTC for auxilliary functions. For example your microwave oven has a RTC, but it won't stop cooking your meals if it misinterprets the date. Heating control systems need to know the time and day of the week, but the year is of little importance.
Last year I became a Trustee for a Will Trust originally established by my grandfather who died in 1966. Not much money involved but there is now a requirement to register such Trusts with HMRC.
Went to register on HMRC portal and had two problems.... 1) Date of Birth of the person whose Will established the Trust... Errr That'd be 1891.... Oooops cannot accept any date earlier than 1900. 2) Postcode of the place they were living when the Trust was established.... Errr in 1966 postcodes hadn't been fully rolled out, and further the house where he lived was demolished in the 1970s - whole area been a car park since!! Thank goodness NI number was optional!
Fortunately HRMC were quick with the advice - use 1/1/1900 as the date, and my current postcode.
Come on AC, are you really opining that people with serious illnesses and disabilities are bullies who are stealing money off you?
Injury and illness can happen to anybody, and most people who claim from the national insurance scheme have paid into it for years.
That's not a nice way to describe your pension. And before you (or anyone else) say you've earned it remember your payments went to the pensioners when you were working, now your pension is being paid for by the rest of us.
Now to improve the economy we could stop pensions -- after all the old are definitely not helping our society (stealing money, voting for brexit). Think of what we could do with that. We could afford an education system that servers ALL children -- our future. I mean, we could even give them all a laptop AND an Internet connection.
And you? With no pension? Sell your house! You will be able to live off that for the rest of your life.
And then everyone will gain. :-)
So ... sounds like you believe we'd be better off if we got rid of everyone who has retired and so no longer contributing to society. Probably best to do it by stealth rather than an announced policy. Perhaps we could secretly release some sort of virus that mainly kills old people ...
Oh dear, someone is confusing "earned one's pension" (which people claiming them most certainly have absent any evidence of years of skiving off) and "funded one's pension" which works the way described.
The social contract was struck. One agreed to fund tomorrow's retirees if one's own pension was funded.
Breaking that contract should involve financial penalties and payments, just like in real life.
>if there was some other similarly monikered language around in the late seventies.
Intel had PL/M and Zilog PL/Z. Both were designed for embedded applications. PL/M is what I used a lot before we had a 'C' compiler and in many ways it was superior to C since it didn't allow you to play fast and loose with pointers (it used references). (The Intel linker was also superior to many linkers because you could control what symbols were exported from linkable modules.)
PL/Z was an outstanding language, again 'C' like but with a couple of twists that made it very useful. One was being able to return more than one value from a function. The other is that it included a sort of P-code interpreter -- you could choose to either compile modules to Z80 assembler or to this more compact code which would be interpreted by a supplied module. This allowed you to make optimum use of the available memory space.
As a FYI -- Did you know that PL/I was available for CP./M? I've still got the manual somewhere. Its a remarkable achievement since I doubt if the manual would fit into 56K, let alone a multipass compiler.
Yeah.
I was taught P L One.
Good language and had streaming elements and other stuff that I remembered when I picked up C, many years later.
Got stuffed because I Bring Manuals were all too Cobolly (IMHO of course).
Mine has the OS/VS1 Programmers Reference Digest in the pocket.
More years ago than I care to recall, I worked for Prime (aka Pr1me) Computers.
Their original systems programming language (I kid you not) was Fortran, but later was supplanted by two stripped-down PL/1 variants called PL/P and SPL. I seem to recall that they were actually fairly pleasant languages.
We had an HP mainframe around that time - I think it was an HP3000 - and it was utilised with Fortran.
It sat in an air-conditioned room - the only one on the entire 279 acre site - and the Winchester drives clacked away as they did.
Fortran was the best option for what it was used for - controlling a hydraulic tablet compression simulator. It was amusing in a way in later years when the same equipment was controlled by a PC sat next to it. The speed of operation went from one compression cycle every 5 minutes to one every few seconds.
PL/1 .... used it a couple of times for large financial systems, on an IBM S/38[*] fault-tolerant box (a national inter-bank funds transfer system), and again on an AS/400 (calculating multicurrency future values).
I wasn't all that fond of PL/1, partly because it was rather a bastard mixture of COBOL data structures and Algol/60-like procedural syntax with exception handlers thrown in got good measure.
But my real beef was its use of exception handlers to trap common occurrences like end of file, indexed record not found, etc and this was annoying because the exception handlers didn't fit nicely into the program flaw - the COBOL statement "READ filename AT END do something." usually makes the logic easy to read because the AT END clause is part of the READ statement while the PL/1 file exception handler is usually outside the file processing loop and IIRC could catch a raft of logically unrelated exceptions - that is to say, unrelated to the program logic flow even the exceptions could all be thrown by the same file.
* The IBM S/38 was a rebadged Stratus system. IIRC the VOS operating system was written in PL/1. PL/1 was also the default programming language for the systems they ran. A nice machine apart from the programming language and, IME more reliable than the better-known Tandem NonStop boxen.
One of my bosses told me that his date of birth was mis-recorded in the corporate HR database 06/071950 instead of 06/06/1950. As your data of birth does not change, there was no support in the application to change it. He said it didnt really matter - it just pushed his retirement date out by 1 month.
There was a different database which was used by people all over the world. If you pressed help for a date field, it gave you an example "02/03/2004". Is this 02/March or 03/Feb? 01/26/2004 would have been cleared.
Some years ago now, on visiting the local swimming pool I was asked how old I was. I told them to then learn I was eligible for OAP membership i.e. half price membership upgrade.
Win for me.
A few years on and again I was asked how old I was. "You're not old enough to get half price!". I told them to change it back then - "We can't".
Still winning, still not old enough. Pity the pools are closed....
Personally, I prefer the ISO standard of 2021/12/31.
We need to ditch local stupidity and get with the program.
I have wasted way too many days of my life programming around every one else's petty preferences.
Did you know that there are some monsters who write their dates as 12.31.2021 ?
Monsters.
2021-12-31 or go home.
If you are talking about a date and time, then 2021-12-31T12:34:56Z or 2021-12-31T12:34:56+00:00 if you need a time zone. The T is optional, and the time doesn't need to include seconds (which can be fractional if you like)
https://en.wikipedia.org/wiki/ISO_8601
I mean, if you can't agree on a standard way to tell machines what the date is, what hope do you have with fleshbags?
"I mean, if you can't agree on a standard way to tell machines what the date is"
We have a standard way. Remember, computers don't know day from night, or even hours or minutes. All they can do is count. So the date is a number.
You post was dated 1611927961
"what hope do you have with fleshbags?"
I've pretty much given up all hope. Humans are fucking stupid. (Individuals can be absolutely brilliant, and many are worth having a conversation with ... but as a whole? Fageddaboudit.)
HTH
So the date is a number
Nice try, but that number is an offset of [unspecified units] from [unspecified base date].
Computer dates are a complete Whack-a-Mole. For confirmation, see the way Java has kept on introducing novel ways to encode and manipulate dates. It's now reached the point where you get a date returned from some function and have to spend 15 minutes reading the API docs to find several other functions you can feed it through to get the right kind of date for the next function.
ISO 8601 requires that the separator be a dash: 2021-12-31<p>
So that some of your SQL statements will execute the subtract signs, and others will assume the resultant number is a Unix date.This way undetectable bugs will be born intermittently, ensuring programmers will always be employed.
Deciding on what format to write the date is one thing. Deciding what the date actually is is something else. There are many different calendars in use throughout the World.
In the UK today is 1st February 2021 (February is month 2 out of 12)
In Nepal it is 19th Magh 2077 (Magh is month 10 out of 12)
The Hebrew date today is 19th Sh'vt 5781 (Sh'vt is month 11 out of 14)
In China today is 20th Wu-Yin 4718 (Wu-Yin is month 12 out of 12)
That's just 4 different systems - there are a great many more. Nor is date conversion that straightforward, because different calendars have different ways to insert a leap year (if at all).
I was asked to provide a csv with a date in it. I asked what date format they wanted, and receiving no answer I supplied 2021-01-29T10:58:00. I got yelled at by the database guy, "Take out the T, what's that for?" He's half my age and from India. I thought it was us old fogeys from the USA who couldn't get with the times? I've never even used Sql Server, still I'm sure it would take me no more than five minutes to figure out how to get the import wizard to accept the "T". And then I would know forever. But I kept my mouth zipped and gave them a space.
Still waiting for someone to send me YYYY-DD-MM, I'm sure it will happen eventually.
"Still waiting for someone to send me YYYY-DD-MM, I'm sure it will happen eventually."
I've seen that! There are emails I've received that contain attachments with names like: LabReport__2019-01-5--15-17-17.doc -- that's for a report sent on May 1. The inconsistent zero-padding and "__" vs "--" punctuation are in the original too. *Shudder*
"Did you know that there are some monsters who write their dates as 12.31.2021 ?"
I had a web page trawling program to extract events and dates. By the time it was running fairly smoothly there were something like twenty different date format algorithms.
The most memorable two were:
The use of a Roman numeral month eg 7 XI 2018
References to university academic terms - something like "Monday in third week of Michaelmas Term"
has a Pl/1 version available IIRC and there are some seriously good resources on the internet thingy these days. I remember trying to learn it from a shitty old a5 manual with that smell of old computer manuals. Now you can get youtube videos! I may have to make sure I watch them in B&W!
"[...] so that I didn't have to put my cigarette down"
Except in some cases to change temporarily to the pipe sitting in the desk ashtray.
It's difficult for youngsters now to appreciate that it was clouds tobacco smoke everywhere. Yellowing paintwork would be the history - together with the distinctive stale smell trapped in furnishings and clothing.
At home; the school staff room; offices; workplace; cafes; restaurants; doctors' surgeries; hospital wards; buses; trains; planes. Cinemas were an iconic case as the projection beam highlighted the swirls of smoke from the audience
Dennis Moore, Dennis Moore, Galloping through the sward
Dennis Moore, Dennis Moore, And his horse concorde
He steals from the rich, And gives to the poor, Mr Moore, Mr Moore, Mr Moore
--
Dennis Moore, Dennis Moore, Dum dum dum the night
Dennis Moore, Dennis Moore, Dum de dum dum plight
He steals dum dum dum, And dum dum dum dee, Dennis dum, Dennis dee, Dum dum dum
--
Dennis Moore, Dennis Moore, Riding through the land
Dennis Moore, Dennis Moore, Without a merry band
He steals from the poor, And gives to the rich, Stupid Bitch.
"Blimey, this redistribution of wealth is trickier than I thought."
Our company wrote a system for a large housing association that produced gift cards for tennants who had kept up with their rents throughout the year. They sent us Excel spreadsheets with the tennant detains - name, address etc and the amount to be paid and we created prepaid gift cards loaded with the said amount and mailed them out to the recipients.
When I was doing some testing prior to the live production of the cards, I was scanning through a list of recipients and noticed people with names like "Mr John Smith - DECEASED" and "Mrs Mary Jones - DECEASED". They had no way on their system of marking tennants who had died, so just tagged the text to their surnames and later exported the data to us!
I pointed out to the clients that some people might be upset to receive letters addressed to their dead loved ones, plus the fact that dead people don't tend to use gift cards. There were some red faces, but I did receive thanks for saving them both embarrasment and money.
Back in the mid 90's I wrote a bulk delete program for a company I was consulting with. You could delete anything older than a certain date as one of the options.
I left them in the late 90's. As Y2K came around I just did a quick check. Big oops. Yes, 2 date formatting was rife in it. So, an emergency call to the company IT manager (who was new and didn't know me) to ask him to please delete the program quickly as it could have unintended consequences....
Shortly after that, the company went into financial troubles. I assume it wasn't my fault
Alan
"As Y2K came around I just did a quick check. Big oops. Yes, 2 date formatting was rife in it."
I think those of us who are old enough had one or more of those ... not necessarily a fault of the programmer, but rather because of the constraints we worked under.
"I assume it wasn't my fault"
It wasn't, because you no longer worked there. Or so my lawyer (brother) told me at the time.
The first mainframe I worked on was an ICL1901T. It physically had 32 Kwords of memory, but only 24 Kwords were available because it was cheaper that way. Rumour had it that paying extra got the jumper moved across to get a higher clock speed.
I suggested a coin-in -the-slot arrangement so that operators who wanted an early finish could temporarily enhance the iron.
As a former 4300 series system programmer, I am sure that the lack of a century year in dates could be entirely assigned to the desire to minimize the amount of disk space used as the drives attached to that system (3370 and 3380s) which were very limited in storage (576 MB for the 3370, 2.52 GB/unit for the 3380), so every byte counted.
If you're worried about storage, why store dates as a 6 byte string, rather than an 8 byte one, when a 3-byte integer (a standard 32 bit integer with the most significant byte thrown away) storing days since the beginning of the Julian calendar on 01/01/1753 is good for the next 45,000 years and uses half the storage? I reckon a library function for conversion would probably only run to a few hundred bytes tops, the most complicated bit is working out how many days in a leap year. Plus, it makes date comparisons easier if you just convert today's date and subtract.
I suppose it depends on what you value more - disk space or program space in memory.
Might be a problem in countries that were Catholic in the 16th century...where the calendar change to place in 1582. Or in countries that were Orthodox...Greece didn't switch until 1923.
(Favorite trick question, though a bit dated now: Can someone claiming to have been born on 29 February 1900 be telling the truth? Yes, if it was in--among other places--Russia.)
That would be the officially oldest living person. There are all sorts of complications with birth records from a number of countries and a number of claims to be older, of varying levels of plausibility, that aren't backed by documentation so aren't recognised. IIRC, the oldest living person on record died at the age of 121 (I could google it, but I'm supposed to be working...) so it's just about plausible that there are still one or two people around who were born in the last few years of Queen Victoria's reign.
If I were writing software today which could be guaranteed to only concern itself with living people, and space constraints were an issue (they are now unlikely to be of course), I'd probably store the birth date as an offset from 01/01/1900. In the 1980s, this would be an unsafe assumption to make! These days, of course, we optimise our software for other things, if we need to at all, such as speed and network efficiency, and nobody in their right mind would think of trying to save a few bytes here and there through the most efficient storage method for a date. In fact, the main thing we should all be "optimising for" is maintainability, which often comes at the expense of the other things.
In and around 1980, I worked for Honeywell on a team that specialized in porting customers' existing code to run on the spiffy new mainframes we'd just sold them.
The first such project I was assigned to involved a bunch of early-60s-vintage(?) COBOL. One oddity we had to deal with was years that were stored as a single digit -- this year would be "1". Seriously.
This was a batch job stream, and most of the files were stored on tape -- too big for the disks of the day -- but I have some hazy memory that perhaps, back in the olden days, the file in question had been stored on punched cards -- punched by one program, then read back in again by the next one. So bumming every last character, well, wasn't a good idea but must have seemed like one at the time.
I don't recall -- if I ever knew -- how they dealt with the rollover every decade.
On that same project, in one program I encountered a bizarre COBOL paragraph label whose name had no connection at all to what the program did -- it was just totally out of left field. (Something about "horses" and "around", I think -- and this wasn't a racetrack operator.) Not that it mattered to my job, but what the heck was that about? As it turned out, the code's original author, from almost two decades before, no longer worked for the customer whose code it was; he was now on our little porting team. I could simply walk across the office and ask him. Small world!
...decided to store the date of birth with only two digits for the year.
Dunno about PL/1, but in RPG dates are natively six digit. So, while you can define an eight digit field to hold a date, the system supplied dates are all in six so you were making work for yourself on comparisons.
My bet is that RPG was on a '36 somewhere[1] and not on the mainframe and that's where the core data was coming from.
[1] Because for data entry and validation, 5250 block mode beat the shit out of 3270 and serial for efficiency until quite recently. So, if you gave a rat's arse about your hardware budget, that's what you did.
Somewhat along the lines of this story...
Every danish citizen has a unique identity-number issued at birth. System was designed in the 1960's, so obviously had to carefully consider how much data to store - meaning they ended up with a number including the date of birth in the DDMMYY format: DDMMYY-NNNN, the last 4 digits being a sequence number.
Except it wasn't quite a sequence number, because some bright fellow decided that it would be nice to distinguish between men and women, so the last digit is odd for men and even for women. (You can guess how the transgenders feel about that). Another bright fellow discovered that in 1960 they actually had grandparents born in the 1800's, so the first digit of the sequence number was used to encode the century: 0-4 if you were born in the 1900's, and 5-9 for the old people from the 1800's. Guess how that worked once year 2000 turned up, and we still had some people alive from the 1800's.
As the final twist, the sequence number also acted as a checksum of the entire identity number, with each digit multiplied by a specific factor, added together, and the sum had to be divisible by 11. Bizarre, and with the additional "feature" that you can only have about 250 people born on any one day. This wasn't really a problem until people started arriving from countries where you really don't care much about when you were born, so a third bright fellow decided that if the date of birth was unknown, assume Jan 1st of a year that seems plausible. Guess what happened when a surge of asylum seekers arrived one day...
So the checksumming was abandoned. But the identity number is used by every single public and private sector business, so quite a bit of scrambling when they had to remove that check from the customer entry forms.
Public sector IT disasters - you cannot make them up, they are for real.
Back in Y2K times I read about a large insurance company whose software could handle birth and current date in two different centuries, but not in three centuries. They scanned their database and found they were paying pensions to 14 people born in the 1800’s. Instead of changing code and database, these 14 were removed from the database and some guy was tasked to handle them manually.
Now there's a language you don't often hear of nowadays.
The company I worked for ran it on the "personal computing" MVS IBM mainframe (VM 370) to generate reports before these IBM PC things were available. I'd forgotten about its existence. I had to maintain a program in it once when the ageing writer and "owner" (an end user not a programme) was on long term illness. Must have been the best part of 40 years ago. I think at the time we had 3 mainframes - one for IMS, one for MVS and one for development. He could do things with filetab programs nobody else could (including the suppliers experts it was alleged). It was decision table based if I remember correctly. Nothing like the COBOL I was used to.
One of my earliest commercial "languages". It was actually a very flexible environment. It was designed around the concept of producing printed reports based on an input file. Secondary files could be a bit harder to deal with though. If you wanted to, say, read this year's file and produce totals, then read last year's file and produce totals, and THEN print the two side by side, you had some hoops to jump through, and the code was more difficult to maintain.
I actually learned its full-language successor first - FTL6. It was a very good method of producing code, and could produce proper binaries, rather than just being interpreted like TABN (FileTab 5). It also made a decent job of running TABN code, and you could save binaries from them, too.
I once spent 5 minutes at a hand punch and produced a deck to summarise a customer's data. When he saw the printout, only 15 minutes after he had entered the building with his problem, he asked for that report to be run every month. Another dead tree, but as a bureau, we were happy too.
The simplest FileTab program:
*GO
I was unlucky enough to work in local government in 1999 and we were still coming across systems using two digit year. Some of which had cludges in place to try to compensate for such things as residents born before 1900. You know rather than just changing to a four digit year.
However the best cock up wasn't based upon a two digit year, but the tax bands in the payroll system. There was a file containing each of the tax bands. For some reason this particular local authority paid some of its staff weekly, some four weekly and some monthly. Just to add confusion rather than storing the tax band information annually and calculating the monthly thresholds for each payroll period for that the file stored the thresholds for each tax band based upon the pay frequency. So for each tax band there was a record each for weekly, four weekly and monthly. Each of these records contained an upper and lower threshold. Why you needed an upper and lower threshold I know not. Surely just storing the lower threshold for each tax band was enough, but the system was probably decades old and had also probably been recoded in different languages each time the hardware was refreshed.
Anyway one thing that had been overlooked was that the record for the upper tax band had an upper threshold. And that threshold was never changed. When the record was first created the value that some numpty decided to enter for the upper threshold probably seemed an impossible amount to earn in a month. But obviously pay increases over time and here we were in the late nineties and one particular senior employee not only had a very high monthly salary, but was also due some extra taxable pay which took them over the threshold. The payroll system was so brilliantly coded that when the monthly pay went above that upper threshold the system just basically shat itself resulting in that very senior officer getting paid absolutely nothing.
Of course nobody realised that the above was the cause until one morning the payroll manager got a call from a very irate senior officer who had just received a pay slip covered in zeros. Which quickly resulted in a very irate payroll manager calling the IT department. The programmer who found the error corrected the problem not by recoding but by increasing the value of the upper threshold. He then couldn't work out why nobody was willing to accept his solution of simply paying the senior officer two months salary the following month.
As it was the payroll department had to manually run a bank transfer for the correct salary, plus of course they had to manually adjust the tax paid. And then we had to scrutinise everything very carefully to ensure everything tied up correctly at year end between the payroll system and reality.
And of course then the system had to be recoded in order to ensure that there was no repeat of the debacle.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
