There's notthing so enjoyable as rightful smugness
Especially when it makes your accusers look stupid.
Even more so when they are supposed to be the experts.
Welcome to Y2K, The Register's trip down the memory lane of the fear generated by those two naughty digits, and the cash flung at contractors to deal with them. Today's story comes from a reader the Y2K-anonomatic has decided to call "Liam" and is a reminder of the unexpected surprises uncovered while all those bugs got fixed …
“ As for the day itself, Liam and co were fully prepared. Nothing else crawled out of the woodwork and the team "printed out some 'millennium bugs' to hide around the office so we could fill some time on Jan 1st tracking them down, and went home at lunchtime."
I was struck reading this at the end of the article. It’s almost a past echo of Brexit Gammon’s claiming Y2K was another manifestation of and demonstrable evidence of ‘Project Fear’.
They'd been over-billing customers for years, due to the way they measured the length of phone calls, essentially adding the time it'd take a call to get connected, and charging for that.
I don't know what happened about that in the end - one amusing aside was the fact the raid array hosting the old systems (which were kept running, while the company figured out what to do about said issue) was constantly failing into worse and worse state (think not only out of support, but out of manufacturing of the chips used in the thing). It eventually did fall over, costing a pretty penny to recover the data, and then a few weeks later my boss and I discovered it was STILL being run off the old system instead of the new one.
I left shortly after...
I had an underbilling experience when working at a small telecom. We billed based on 32 byte call record where each bit was significant. Some genius decided that since one bit's use was not documented due to a prior genius's laziness it was free game and he started using it. Unfortunately, the bit turned out to indicate calls that ran over 24 hours (generally computer to computer modem links). All of a sudden call revenue dropped and I was tasked with fixing it. The genius who had failed to document the use of the bit had left the company by then so I was denied any measure of revenge but the revenue loss would have paid my salary for years. It definitely prepared me for the Y2K kerfuffle later in my life.
Reminder me of a lovely BT loop hole from the 90's.
If you diverted a landline to an international number, the divert to the International number was never charged. Have 2 landlines, divert the first to your international number and call the first from the second...hey presto international calls at local rates.
A similar trick: At the students' union at the Technical Uni of DK there were phones that were blocked for use outside the region (more or less the island of Zealand). But if you used one of the allowed prefixes and then the number you wanted outside, hey presto! We tried some photo store in the US, just for testing.
Back in the ‘80s in New Zealand the Telecom Co would let you charge the cost of your call on another number WITHOUT Checking. Every time you got a phone bill you had to scrutinise it carefully and periodically ring up and deny the cost and get it rectified.
People would just give out some number they made up and often use one then iterate it. The process was not personal, just dickheads being cheapskates. People with more money than sense wouldn’t bother but we were married students with spawn so every cent counted.
When challenged the cost was rebounded to the original number. Since back then any call outside the local area was classed as a toll call so calling your Mum up in Auckland was a toll call.
In the summer we were apart before we got married I was in Auckland she was in Invercargill right at the bottom of the South Island. I would call her once a week and write snailmail letters. My father came to me with the bill in some dudgeon. I calmly asked if he would accept a cheque or needed cash. I think he realised it was serious at that point.
In the summer we were apart before we got married I was in Auckland she was in Invercargill right at the bottom of the South Island. I would call her once a week and write snailmail letters.
Hmm... Ever miss-call and get a lady in another town?
I remember my mom used to occasionally get calls from a bloke in Auckland (at uni even IIRC) supposedly calling his girlfriend who was somewhere in the south island. Used to be we'd get this call every 6-8 weeks for a year or so, I think just after we went to STD rather than having the ladies in the exchanges help us out (who never ever ever under any circumstances on a quiet night kept their headset connected to the call for any reason... :) )
Wouldn't possibly have been you would it? I realise the chances are fairly low, however at the time there probably weren't that many people calling around the nation on such a regular basis - I do remember how expensive it was even to call school friends just in the next town! Odds may actually be better than 1/100, maybe even better than 1/20 when you really think about how expensive communicating was back then!
Ah yes, very easy to create when the need arose to export data in a 'database' format. Mysteriously unsupported in Access 2013 (but supported before and ever since). Still in use in multiples applications around my company (one of the top-5 banks in the world).
It was out of date in the 1980s. Well DBase 3 was.
The better products from mainly Nantucket and also a bit Fox.
I used Clipper (Nantucket) for years, later on Client Server, and yes there is recent software out there still compatible. Clipper was a PCode compiler but introduced lots of features into the XBase world.
Fox never hit the same heights. But its main legacy is DBF CDX FPT file format.
XBase is only dying now as the programmers retire and .NET programmers appear to be filling the gap.
Comparing Dbase to say Visual Objects would be weird but they are the same code family (VO was from the same team as Clipper).
So it is possible to take an old database and make it run client server with no data changes. And with the right compiler even compile the old code into a WIN32 console proggy.
There are numerous cases in the x86 land that you need to replicate the bugs to be able to sell HW IP. If I remember right, There is a uart bug that you need to replicate to be compliant. Since everyone as coded for the bug, you you attempt to create new HW without the bug, all of the legacy SW will fail. Part of life...
Not just X86 land. Most software, particularly firmware and driver code, will end up with handlers for quirks and differing behaviours of hardware.
I had a dodgy API where the result was 'off by one' but no one thought about filing a bug report, simply worked around it. The pragmatic, least costly, least confusing, solution when adding a related API was to code in the same bug.
not quite y2k - but 9/9/99 was significant for alarm systems (commonly used as a test date)
As was (iirc) about 5 Jan 1997 (Some SNTP date representations rolled over into 1s complement for implementations which were using signed numbers - this broke a LOT of Allied Telesyn routers worldwide - I spotted what'd happened and saved them about $80million in lost contracts - did they give me any credit for it? Noooooo)
At least one UNIX[tm] implementation simply can't handle booting up beyond 31 December 1999 and requires the clock be manually set at each start
Around the same time I was working with a very large Italian government IT service organisation that had 70 million lines of Cobol in production. They were less concerned with Y2K, and more so about Italy joining the Euro... if you can remember how many large number of digits typically followed any exchange rate for the Lira against any major currency then moving to the Euro had one key point of difficulty... more specifically a decimal point, previously not needed or implemented in many numeric fields where large integer values were just fine....
I recall one of my colleagues (at a big 5 employer) telling me that a Euro-compliancy audit piece of work on a core bank system had been really easy because they discovered that every point where account calculations were done had already been replaced by calls to one standardised procedure. The reason? It had been done when the UK decimalised in 1971 and pounds, shillings and pence were replaced with pounds and pence.
I wonder if the original £sd calculation was done by a single procedure and it was just replaced by another in '71. Non-decimal calculations aren't always straight-forward as legitimate inputs might well violate expectations. It wouldn't be unusual to see prices quotes as, for instance, 30s so I can imagine a routine having to accept that.
It makes handling historic data - err - fun, especially as I've seen amounts quoted along such lines as "and three parts of a penny". What parts? Land measurements are also interesting. Fortunately I haven't yet had to deal with weights. Fortunately because you can't rely on a stone being 14lbs.
9/9/99 was significant for alarm systems
And not just those. Someone wrote to RISKS (if memory serves) to report correcting firmware for a dialysis machine which went into cleaning mode if the current date was entered as 9/9/99. That one would have made the Theravac UI error look minor in comparison.
We used the SCO version of Fox Software Foxbase+ for SCO Xenix for years and then used MICROSOFT FoxPro Unix. Yes you read that correctly. We even had MS Word for Unix. Now we use Harbour Compiler, a cross platform, open source version of Clipper. It's awesome, by the way.
Not that SCO, the original one.
Clipper was a great product, I used it for quite a few years.
You may be thinking of Visual Objects, a native compiler for WIN32, I am competent with it.
So why did these two languages last for so long?
1) Quick to write in.
2) Native data handling.
I know of 50+ seat VO systems running 24/7 with high reliability and performance, handling GB of data.
I bet DBase would not last a day without issues.
Fire up an XP PC and Clipper executables can join in the fun as well, Vista started the removal of DOS modes and the essential WIN16 mode for data handling for IP.
I started my working life as an independent professional (I won't say which discipline) before going to the dark side (airline pilot, never mind I had never intended to become one but that's a different story).
People did not like my fees. They were three to five times what the natives charged and I always made it clear that after I finished things could go your way or against, depending on my findings.
I went to see this client, and as he was signing the cheque (remember those?) prior to my handing over my report, I mentioned the amount of tax he had been overpaying for the last fifteen years and how to claim it back. This wasn't what I had originally been hired for but when I saw this, it only took a little extra to put together the documentation for the guy to make his claim.
Effectively, he earned himself a very nice second pension, apart from paying many times over for my work. After the initial incredulity passed, the guy burst into tears of joy.
"I started my working life as an independent professional (I won't say which discipline)"
Clearly a mercenary.
"People did not like my fees. They were three to five times what the natives charged and I always made it clear that after I finished things could go your way or against, depending on my findings."
Possibly even an assassin.
"I went to see this client, and as he was signing the cheque (remember those?) prior to my handing over my report, I mentioned the amount of tax he had been overpaying for the last fifteen years and how to claim it back."
"This wasn't what I had originally been hired for but when I saw this, it only took a little extra to put together the documentation for the guy to make his claim."
Ah Ha! Accountant who became a mercenary. Possibly after fighting his way out of compliance wit a spike made from a rolled up financial times.
When reviewing our Y2K Inventory we were looking for systems we didn't "need" anymore. We found one system which had run daily at lunchtime since 1971 which checked in case we had any pre-decimal LSD-denominated Invoices come in, to convert them to decimal. This was discovered in 1998 - 27 years later × 5 x 52 = 7,000 unnecessary executions.
I once worked on a system for Scotland Yard that allowed a team of data entry staff to transcribe criminal records from paper and microfiche into a database for uploading into the Police National Computer. Included was a routine which would take monetary amounts (usually fines) in pre-decimal format and convert to a decimal equivalent. This worked by taking the each unit (Guineas, pounds, shillings and pence), converting each to pennies, adding them all up and dividing by 240. Luckily I was old enough to have been a teenager on D Day (decimalisation day, not the invasion of Normandy) and could remember how to do it.
A couple of years later I had a call from somebody working for another company - they had been hired by Scotland Yard to write a similar system for different records and had nobody on staff who had even heard of a Guinea, let alone knew that each was worth 252 pence!
I was the testing manager at an outfit that used various means to try to catch irregularities in financial transactions. I had just started with the company, and hired a database testing expert to put the underlying database through its paces.
He came to me after a week or so and told me, "The program doesn't work." Oh, how so?
The program had variables "vol" and "val" to hold the number of transactions and the value of each transaction. You guessed it: it put the number of transactions into "val" and the value into "vol". This was why it consistently came out with wrong results.
We quietly corrected it.
Where in the process of tracking down issues that I found the existing system had been configured wrong or producing incorrect results for ages. While the higher ups rightly blame IT for something that was configured wrong when installed and never caught during any subsequent maintenance, they have no leg to stand on for producing incorrect results. It is up to the business owners to verify that they are getting correct results from systems they depend on, and it was made obvious in a few cases that that was never done when it could be shown the wrong results were present from day one (yay for not deleting obsolete data from databases!)
A customer would submit a job to do calculations for designing turbine blades. It only happened once in a while - so the precautionary practice was to do a test re-run of their previous data first. On one occasion the new test results didn't match the old live results. Eventually it was proved that the new run's results were correct - and the old live run had been faulty.
Biting the hand that feeds IT © 1998–2020