Legacy systems
06 February 2011A short whole ago I was called upon to service what is widely known as a legacy system. By legacy I refer to one which has existed since at least 1982, and I strongly suspect started its life in the 1970s. As far as I could tell the company (which will remain anonymous) was given the system royalty free sometime around 10 years ago because they had an indefinite £5,000/pa servicing contract, and my best guess is that the licensor concluded it was cheaper to waive the fee than to face a breach of contract lawsuit from their attempts to force a migration. Of course former licensor employees were drafted in freelance to fix odd bits, but perhaps understandably contact with them had long been lost.
If the above was not enough, the set-up required just to run the system on modern hardware is an Italian plumbing job. Originally designed for 1970's mainframes, the runtime environment had been ported to MS-DOS, and in turn this was running under Windows95. Of course the original (late 1990's built) Win95 box had died a few months earlier, so that system had been ghosted and was running inside a virtual VMware computer hosted on a Windows Server machine. For good measure, this Windows Server machine was head-less, and in turn had to be remotely accessed. Joy.
The point I come in is to modify the program to use the (now current) 20% VAT rate, and I am helped because I had access to files that implemented the temporary 15% VAT rate of a few years ago. I also knew the system used some hybrid of COBOL and Basic. A quick diff of the files and I would be well on my way to tracing where the changes are needed..
Binary files 15pc/UKRV and 175pc/UKRV differ
Oh great. and to top it all off the files are different sizes. Looks like the two sets of files are all just compiled binaries, and the system was not an interpreted-from-source one like Python. I didn't bother investigating whether the package included a compiler, as I would have no idea how to use it anyway. Poking around what appeared to be the source files, I could only find what seemed to be the corresponding source files for an even older version of the system, and even then I could only locate the corresponding source for some of the binaries.
Some cross-correlation between the this old source code and the binaries, coupled with some blatant guesswork, and I managed to isolate the byte sequence that appears to correspond to the VAT equations. Several searches in a hex editor later, and I have a patched set of files. And before you ask, this was done without access to a sandbox copy of the running system. I do hope the production system is well backed up..
Spin forward a bit until after some month end accounting is done, and it is time to patch. Better known as covering the eyes and pressing the button. Or rather several buttons, as the user interface is a text-based one that pre-dates windows by a considerable margin. And by pre-date its worth noting Windows v1.0 was released 1985 (i.e. three years later).
It mostly worked. Apart from two bill production processes involving the sans-source files, and in these ones the previously found byte sequence was nowhere insight. This time it was unguided searching for a byte constant, and a search pulled up a dozen possibilities. I chose the one that happened to be just after some human readable text containing "V.A.T", and it happened to work. For now..
At least I know which byte offsets need changing should the VAT rate change again.