Update on Y2K failure of credit card machinesgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
Thursday, 30 December, 1999, 08:33 GMT Retailers braced for bug
Businesses were braced for further millennium bug problems on Thursday following difficulties with thousands of credit card swipe machines which failed to recognise the year 2000.
The government says it cannot rule out further glitches after problems affecting 5% of swipe card terminals in shops were identified on Wednesday.
HSBC, which issued 14,000 card swipe machines to retailers, says the machines will be working by 1 January.
A software problem has meant that since Tuesday many credit card terminals have not accepted transactions from credit and debit cards, such as Switch, Mastercard and Visa.
Credit card transactions are stored on a central computer which covers a four-day period. Hence any transactions which took place since Tuesday have covered the 1 January date.
Since the problem emerged, many retailers have resorted to pen and paper to complete credit and debit transactions.
The HSBC spokeswoman said: "Customers can still pay. The problem is a minor one and can be fixed by pressing a series of keys."
She said the problem would disappear on 1 January.
Racal, which makes the terminals, apologised to customers for the "short-term minor technical difficulty".
"We are sorry for the temporary glitch. We can only apologise to customers for any inconvenience," a spokesman said.
But many shops and restaurants, who are having one of their busiest periods, are furious at the software problems and wonder why they were not anticipated.
Don Cruickshank, chairman for Action 2000, the government body set up to warn about millennium computer problems, said: "We have been expecting niggles like this - inconvenient for the shoppers and retailers affected and I'm disappointed at the banks, particularly HSBC, for not picking this one up."
Speaking to Radio 4's Today programme, Mr Cruickshank added: "We will see, particularly on 4 January, a number of similar inconveniences but the key thing is essential services, such as banks, have teams in place to cope."
The so-called millennium bug may strike computers which recognise the year by just two digits.
The fear is that when 1999 becomes 2000, the computer will read the switch from '99 to '00 and think it is 1900 rather than 2000.
The fault will renew worries that the Y2K bug will bring the UK grinding to a halt, despite persistent claims by business and government that key computer systems are compliant
-- Old Git (email@example.com), December 30, 1999
"niggles like this"...?! new tech term...? must be a UK thing huh....??? ;)
-- KatInSeattle (YouC@ntSpamMe.com), December 30, 1999.
Y2K problems occuring before Y2K bother me out of proportion to their seriousness. I've always expounded (without any expertise on the matter) that nothing noticeable would happen prior to Y2K. Something like this wouldn't be noticeable to me if I wasn't reading this forum, but it still bothers me.
-- Gus (firstname.lastname@example.org), December 30, 1999.
This story raises another interesting point. Using 2-digit years works as well as it ever did, provided all dates under consideration agree on the 2 digits. So if two years being compared are both 00, we're back where we've been for 4 decades!
Makes you wonder how many unremediated systems will fix themselves once "century-span" date calculations have passed. Yes, they might display or print "1900" on screens and forms, but the code logic will be correct. I suspect more than half of all transactions have a "lifespan" of only a few days or less.
-- Flint (email@example.com), December 30, 1999.
Gawd, Flint, I think you raise a valid point!!! I'm amazed that I don't think that I have ever read of anyone suggesting this before. Interestingly enough, if it holds, then comparing Y2K to a storm of a few day's duration might actually be a reasonable thing.
-- King of Spain (firstname.lastname@example.org), December 30, 1999.
This must be the dreaded FOUR day storm. Duh!
Niggle this you freaking idiots!
But it's probably not interfering with commerce eh?
-- Gordon (email@example.com), December 30, 1999.
KoS wrote: "...comparing Y2K to a storm of a few day's duration might actually be a reasonable thing."
Have you forgotten the embedded issue, KoS? We might want to wait until after the rollover to declare Kosky, Flint, et al to be right on this one...
-- Nabi (firstname.lastname@example.org), December 30, 1999.
I'm not sure about this. I remember a tech article posted here, which stated code could not compute with just "00". But then, what do I know.
At last, we will know the truth soon. Glad to see you back! Have a great year. And I mean it!
-- Tommy Rogers (Been there@Just a Thought.com), December 30, 1999.
I think Dale Way raised the same point in one of his expostulations.
-- Bill Byars (email@example.com), December 30, 1999.
The main problem here is that most places can't just "start from scratch", with everything starting in the year 2000 (or, if you prefer, 1900). Y2K problems are multifaceted -- what happens, for instance, when the operating system is running in 1900 but all of the files in the file-system have dates in the "future"? How does this work with license management software over a network? Even if the 1999-to-2000 "transistion" were to last just a few days, what would be the effect of any problems encountered; what cumulative effect might there be on data with historical significance? Etc., etc.
This is why Stage Two of a Y2K project (with Stage One being "awareness") was supposed to have been to do a full and complete inventory of all hardware, software and firmware, to determine just how sensitive to Y2K they were, and what to do to ensure Y2K compliance. (The Last Stage was, of course, that "full year of testing".) Unfortunately, too much to do in too little time.
-- Jack (jsprat@eld.~net), December 30, 1999.
In this final day of the countdown I would like to offer my appreciation for your simple,concise,bold tag that occupies all your posts. In some strange way during the ambiguity of it all, that simple statement has continued to be a beacon for preparation.
Happy New year Sir!!!! to you and yours
-- d.......... (firstname.lastname@example.org), December 30, 1999.
The Y2K bug could have easily been delayed by creating a leap decade. This could have given us time to decide on a new calendar based in another number system besides the Gregorian choice of base 10 Roman Numerals.
-- Dooglas P.I. (email@example.com), December 30, 1999.
Thank you, d, same to you and yours.
Hope for the best, prepare for the worst.
-- Jack (jsprat@eld.~net), December 30, 1999.
Flint and King of Spain
How about those pesky things like the date of birth or the date your mortgage was taken out or your date of hire at your employer. Nothing like having all of that be in the future and not actually having happened yet EH? Don't kid yourself about stuff fixing itself. I talked to a guy at the end of October who was converting the entire database for the State Employee Retirement System of a Midwest state. He used our software to figure out why the conversion software was running so slow. At that time (the end of October) he estimated the program doing the conversion would take 90 days. He used software from our company to determine why his conversion code was slow and now has the job done.
This is just one of many databases that won't fix themselves and must be fixed because things that have already happened shouldn't be moved in to the future by the rollover.
-- Willy Boy (Willy@home.in.bed), December 31, 1999.
Willy Boy (and everyone else): I am sure that there are zillions of things that won't "shake out" Y2K problems after a few days. But my point was that here we have a major, highly visible snafu that supposedly WILL. And, until Flint pointed it out, I don't think that I had ever seen anyone else even mention this possibility.
-- King of Spain (firstname.lastname@example.org), December 31, 1999.