Boots, BST and the time of day

Whilst it’s been 9 years since I worked there, I’d bet good money that Boots The Chemist’s POS (Point of Sale) system hasn’t changed. In which case, every time it changes from GMT to BST or back again, all the staff have me to thank me for the fact they don’t have to manually change the time on their POS server. Or indeed, just have to correct it at any other time too.

Let me explain.

Boots, as with many other retailers, uses the IBM (now Toshiba) 4690 Operating System. It’s a hardened but rather ancient OS.

The server in each store runs the tills, and the time at the till is provided by that same server. Store staff can manually adjust the time (and date), but nothing happens automatically. It doesn’t even sync to any kind of time server so it’s not always accurate and it certainly doesn’t change for daylight savings time (or back again).

Fixing Daylight Savings

Twice a year, Boots would tell their store staff to manually change their server time. Inevitably one of the following happened in many instances…

1. No-one in a store remembered
2. No-one knew how to do it, despite very specific instructions being sent to them
3. For some reason no-one in store had access to do it
4. Someone did it and someone how got time completely wrong – either changing it by an hour in the other direction, or getting confused by the 24 hour clock
5. Someone did it and somehow managed to change the date. No, I don’t know how either, but it always happened

Or something else. And, twice a year, there was at least one example of each of these. It seems that leaving it to Maureen, aged 65 and never having used a computer before (and I have some great stories about this more generally too – a future post), was not a great idea.

But nobody in the business had the appetite to do anything about it. At this point everything was internally charged, so if the development team made any changes it’s because a part of the business wanted to pay for it. Really it only affected the IT Help Desk and they had no budget for this.

I was part of a support team, all of whom had development chops and the ability to make changes, so I decided enough-was-enough and did something about it. As it turned out, it’s not difficult, but quadruple checking the rules of time changes did mean I now have a lifelong knowledge of the proper rules of when it occurs and in what way.

There’s a program called Sleeper, which was our equivalent of Cron, which runs tasks at specific cadences. Every day a new program runs. It checks if the criteria has been met for the clocks to be adjusted by an hour. If so, it executes an assembly program. This is because changing the clock is not otherwise an accessible function – you have to tap into the OS at assembly level to actually do this. Anyway, this does the equivalent of going into command line and executing a clock change request.

And, you know, it works.

But one thing did need some thought. When the clocks go forward, it does so at 1am. If they go back, it does so at 2am. This runs once a day, right? Okay, so maybe it doesn’t. First thing I did was get the program to run at both times and to pass in a parameter to it knows which run it is (using the time is not a good idea – if a run gets delayed, this could lead to further confusion, so a specific parameter to dictate which runs is meant it the best option here). The next issue is that if it’s time for the clocks to go back, it runs at 2am, puts the clock back and then gets run a second time. So, yes, checks to make it ignore further runs has to be taken into account. Otherwise you hit Groundhog Day quite quickly.

A big time sync

Of course, adjusting by an hour twice a year is one thing but actually having a proper time sync in place is something else entirely, and this was another phase of me correcting the time issues.

Without a proper time sync, even the best digital clocks go out. And, yes, again, giving stores access to adjust it themselves was not helping either.

So, a way to implement a time sync was needed, which I did eventually do (again, requiring assembly level instructions to bypass the OS to achieve) by syncing with the mainframe computer back at Head Office. That did have a properly sync’d time, so running another program to run daily, grab the time from the mainframe and change the server date and time, was the fix.

After the first year or two of implementation, a change had to be made after it turned out that DST adjustment on the mainframe is also manual, and one year, they were late doing it. As a result, after my first program ran and adjusted it, the mainframe sync ran and put it back again. The fix was simple – the sync won’t do anything on the same day as a successful run of the DST program.

I did want to remove access to staff changing the time or date at all, which would have reduced a lot of remaining issues, but it wasn’t something that could be achieved easily. That never happened before I left, but was something I was interested in doing.