INTERVIEW
Retired IT engineer Richard Hassett discusses how he faced the Y2K bug
We’ve decided to take a step back and look at perhaps the computing world’s most complex technological predicament—the Y2K bug. You can read all about that on page 32, but we wanted to take it further, and interview a man who was on the ground through it all.
Richard Hassett was working with large and mid-range
IBM machines in the run-up to the millennium that were interacted with through a network of dumb terminals. As part of the enormous effort required to “fix” the Y2K problem, he spent a lot of time making sure they were ready for the transition.
MPC: Hi Richard. We know what happened in theory, with integer overflows making life hard for any computations that relied on dates, but what was your experience of Y2K?
Richard Hassett: I only became aware of it a few years before the millennium, but it goes back a bit beyond that. We were told in the 70s that a program you write today will last about eight years or so. As it happened, it didn’t work out that way because basically, you’d take a program, update it, and keep a lot of the old code in there, but some became redundant… That’s why old programs were still being used when we got to 2000.
You could do all sorts of mathematics with dates.
If you had a date which is
normally stored “year, year, month, month, day, day,” you could subtract one from another if you want to check if something’s older than something else, or if you want to sort a list into order. Now that’s fine until you get to 1999, but it will have a problem when you get to the year 00, which is 2000. It’s lower than the older year. So instead of subtracting 97 from 99. You’re subtracting 97 from 0.
If you’re talking about shares, then perhaps you want to know what the share price was on a given date. And if all of a sudden it’s not in sequence, it’s going to look a bit odd. That’s what the problem was. So basically we had to go through all the program code to make sure we were storing it with four digits for the year instead of two.
On IBM mainframes a record on a file is a string of data. Each individual program states where on the record each field starts, and for how many characters and decimal places, if numeric. If you change the year data from two to four bytes then all the fields that follow have to be changed, adding two bytes for
each changed date field. This is compounded by overlapping fields—you may only want the YY data but you may also want a field to contain YYMMDD. Because you can select data in this way, you could store the dates in other formats such as DDMMYY, which I have seen.
I was working on an AS/400 iSeries computer, which uses a database where each field on a file is described and named individually when the database is created. It can therefore be changed at any time, and the changes will be reflected in the program. This makes it much easier to change not only the code, but also the data in the file. You only have to change the fields containing the year.
MPC: There’s so much that depends on dates, then?
RH: Yeah, anything that needs sequencing, or if you need to do something once a week or once a month, then you can work that out by the date… Once you get to the stage where you can’t subtract one from the other to find out, you’re in trouble.
MPC: So when it came to actually working out all the
kinks and the bugs with Y2K, what type of machines did you find yourself working on?
RH: I was working on the
IBM AS/400 mainly. That had two predecessors, System 36 and System 38, which were merged together. And then it became the iSeries. There are lots of variations of it. It came out in 1988, and later there were different versions of the machine, with IBM RS64 CPUs.
Small to medium companies could run on one. Places like American Express and Cable and Wireless had several. It was called a mid-range. It wasn’t a mainframe, but it wasn’t a PC. It was in between, but towards the end they just got so big that they were almost mainframes.
It sat in a room somewhere, and people accessed it through dumb EBCDIC terminals— which weren’t like ASCII terminals, they were much chunkier and heavier—or PCs that had an emulator of the access software on them as an application. PCs were about $5,000 in the early 80s. And we were using a $5,000 PC to emulate a $1,000 terminal. But of course that was only one of its functions.
MPC: Okay, that’s a new one for us. So what even is EBCDIC exactly?
RH: EBCDIC—I can’t remember what it stands for now, I don’t know if I ever knew! [Extended Binary Coded Decimal Interchange Code, an eight-bit character-encoding system descended from the punch-card codes of the 1950s, now superseded by Unicode like ASCII.] It was like IBM’s version of ASCII, which is what we were using on the PCs.
It was very robust. The network was a thing called a token ring. We didn’t have the Ethernet networks then. It used twinaxial cables, like coaxial but with two lines going down it. And basically, instead of broadcasting to everyone on the network, and the machine that wanted the data would pick it up, it sent it around the network. There was a token going round that had an address on it, and it dropped it off where it was required.
MPC: Sounds… slow and complex. So in order to update one of those machines to be Y2K compliant, what exactly did that entail, and how did you go about doing it?
RH: You had the programming language, which was on that particular machine. I think some were COBOL, but most were RPG III. It stood for Report Program Generator, and I worked on RPG II and III.
It was a lovely language, it actually was really good. I enjoyed working with that one. [This was IBM’s high-level language dating from 1959.
Its latest version, RPG IV, was last updated in October 2020.] It was literally a case of getting the source code from all the programs you wanted to run on the thing, and going through each one individually, finding any code that involved dates and changing it, then testing it, making sure it works. This is what people these days don’t do—they just put it live, wait for the customer to find it and then call them up and say there’s a problem with their program.
Well, you know, when I was programming and that happened, the programmer would have his balls broken chronically by his workmates. But now that seems to be the way to do it.
MPC: We couldn’t possibly comment on that. Were you changing the programs to support a four-digit date code? Or were you saving time by windowing, and just kicking the can further down the road?
RH: Some people did that, and I said, “Well, hang about, we gotta future-proof this.” It just seems ridiculous to me, so I didn’t do it, because I was a programming manager at the time, so you know, my stuff is the way that we decided was the best way to do it—[we] future-proofed it.
I think it all goes back to this idea that programs don’t last more than eight years, but I expect some of those AS/400s might still be running. I gave this all up in 2007, but they may
still be making them as the iSeries, unless they’ve changed the name again. [They’re called Power Systems these days, with 4GHz, 14nm Power 9 processors with 12 or 24 cores since 2017. The cores are up to eight-way multithreaded.]
There’s not so much RPG code these days, it’s all that awful Unix, which was never nearly as good. The thing is, they said it’s got to be more accessible to people, and things were getting easier with computing. Then the universities got hold of it, and with these university boys, if it’s not complicated, then it’s not worth doing. So it started getting really complex.
Unix is an absolutely dreadful operating system, but… people grew up using it, and that’s how it got into the business world.
Computing changed a lot once the PC came along. Standards fell a lot. People wanted stuff cheap so they got it cheap. Before, computing had been very expensive, so the PC made it cheaper, but the software was expensive because it was done by people and it was tested thoroughly. Well, they don’t do that anymore, because they can’t afford to. They’d rather put something out there that doesn’t work than have it working and not out there.
MPC: That’s certainly an interesting perspective, thank you very much for your time.