Thank you.
In particular for such rare (but sensible) reasoning on Y2K, and even more so for Point No. 5.
Cross my palm with bitcoin, dearies, and I shall tell your fortune. Why not? Everyone else is doing it. Blogs, press releases and fashion celebrity know-nothings seem compelled to share their trend-spotting tips for the year, under the sneaky guise of making shit up. To gauge how useless these annual predictions can be, for a …
There were two distinct Y2k 'problems'.
1. (The real one.) Many (mostly) mainframe (mostly) Cobol programs held the year portion of dates as a 2-digit field. After 1/1/00, these programs could no longer reliably identify which of two dates was the earlier or calculate the period between two dates. Each program needed to be checked by hand and amended appropriately. This was done so successfully that very few obvious problems occurred, as described by Alistair.
2. (The fake one.) There was supposedly a problem with the BIOS in many PCs that would cause them to fail on 1/1/00. In reality, very few PCs (those less than 3 years old) had any problem at all. Of those that did: most booted to a date of 1900 which needed to be manually reset one single time; a few would continue to come up with an incorrect date after every reboot; and a tiny fraction would be bricked (apparently - I personally never found one of these mythical machines). This didn't stop flim-flam merchants selling pointy-haired bosses TSR programs that would 'fix' the 'problem' and computer salespeople trying to get your entire fleet replaced with new 'Y2k-proof' models. Some managers responsible for PCs may even have connived at the latter, unable to resist the lure of a nice shiny new PC on every desk.
3 - Uncertainty. I felt a pause a few times migrating Novel servers to Windows NT, asking myself if I really understood the problem myself. I still believe it was a healthy dose of humiliation, not much deserved but well-timed. It also helped me to tell the pushy sales drones to get lost for good.
Understating the problem (again).
For 1, assuming you had the source code, there were code-scanning tools that could help. For the others - just work out exactly what it does from its inputs and outputs and rewrite it. Easy eh? (Not). On the other hand, big improvements in documentation and the use of code repositories came out of the Y2K program.
For 2, PCs were relatively modern kit and had short lifecycles, so newer ones had been "fixed" by the manufacturers Y2K program. That didn't mean (bad) code hadn't been reused, but it was relatively rare.
3, many, many-one...lots - Embedded systems, firmware, compilers, libraries, tools, applications - All had to be reviewed and fixed. Apologies, I'm sure I've left many out.
In 1984 I was a newbie software developer working on apps for minicomputers; One of our 3rd-party productivity tools was a terminal handling library that managed field types etc. I noticed then that it couldn't handle 4 digit years, but was told not to worry as "no-one would be using our app in 16 years time"
The funniest one I saw was the fix on a website that displayed the date as 1/1/19100. Not uncommon, but it was a tech support site.
I certainly wasn't trying to understate the Cobol problem - many man-years of effort were spent resolving it. Though I would observe that if you have critical systems for which you have no documentation, Y2k was probably the least of your problems (and yes, I realise many organisations were and are in just this position).
Regarding 'embedded' systems - I certainly hope safety critical ones got thoroughly tested. But I must admit we didn't test every Ethernet switch on our systems, which were mostly agnostic about whether it's 1900 or 2000. Not many such systems hold dates in character format - binary counts of elapsed time units since a 'zero' date are more common, though this can give rise to Y2k-style issues too (like the year 2038 problem).
"For 1, assuming you had the source code, there were code-scanning tools that could help."
Part of the problem was, a lot of companies had no longer any source code for their executables. Sure, it's totally retarded, but staff turnover and no source mgmt in place made the problem.
"Stiffware". I was told of a guy who had been in HR for a Big Four accountant and stayed in touch with a few of the old Cobol guys after they left. He was apparently paid £140 000 for his address book by his old company.
I still have a listing and an Eprom(!) of the source and object for an embedded test system I designed thirty years ago, because I suspected that (a) it might be in use for a long time and (b) the company I was working for had terrible data security. But they obviously never needed it.
For what it's worth, I had the delightful task of liaising with the manufacturers of *every* item of broadcast video/audio equipment owned by the World Service, to ascertain
a) whether it contained any computing element
b) if so, did it contain a real time clock
c) if so, did it maintain a date
d) if so, what happened at midnight 31/12/99?
and arrange any upgrades necessary. There weren't many, as I recall.
Though in a related job, I discovered an HPUX system that definitely *would* fail, which required an OS upgrade that the hardware couldn't hack, so requiring a couple of new minicomputers.
Y2K - 5% fixing real problems that might have otherwise been a minor inconvenience -30% replying to letters from third parties worried that something we had done might cause their fridge to explode at midnight - 30% writing to third parties asking them to confirm, in their first born's blood, that they hadn't sold us anything that would cause our toasters to explode at midnight - 35% having committee meetings to ensure the boss that he could tell his boss to tell his boss that his muffin would be toasty on January 1st.
There were 3 Y2K problems, not 2.
The third one was in embedded systems such as lifts and sewage controllers. Errors around 1/1/2000 would have caused problems such as sewage outflow happening on incoming tides, or building alarm systems being day shifted so that they wouldn't allow staff in. Although individually they were not huge problems, collectively they would all have occurred at similar times so that the available maintenance staff would have been spread impossibly thin. Once something like a bank is a day late, recovery becomes progressively more difficult.
I don't agree the PC issue was fake. Fixing the date on a PC is simple at home, but the majority of office staff can't do it. Desktop support being run off their feet is all very well, but how much better just to test machines on a planned basis, identify the ones that will reset every reboot and have the time to make a fix or replace decision (as we did)? By 2000 there were already a lot of PC-based WNT servers running things like Sage in small businesses - I saw a couple - and a number of them did need replacement. Accidentally sending out invoices dated 1964 may be mildly funny to Joe Public, but customers using them as an excuse to delay payment is not funny for your small enterprise.
"1. (The real one.) Many (mostly) mainframe (mostly) Cobol programs held the year portion of dates as a 2-digit field. After 1/1/00, these programs could no longer reliably identify which of two dates was the earlier or calculate the period between two dates."
In the banking industry at least, surely this was a problem known about and attended to the first time a final mortgage payment date was given as being 1900 when a 25 or even 30 year mortgage was arranged in the '70s? Or had even the banks only fixed the relevant systems and then forgotten about it later on the assumption that even they would have replaced their systems by Y2K?
Of course the banks fixed only the relevant systems and forgot about it later on the assumption they'd have them replaced, and on the bigger assumption that management would turn down spending money to fix a problem now, when they could leave it for 20 years in the future when they would be retired.
"known about and attended to the first time a final mortgage payment date was given as being 1900 when a 25 or even 30 year mortgage was arranged"
Probably apocryphal but...
A consultancy was approached by a US state land registry for a new system. The clients specified two character dates. With Y2K fast approaching the consultancy pointed out the difficulty. The client insisted. Further analysis showed that the registry held documents going back the the C18th. At which point the consultancy declined the job.
I suppose it's the last sentence that makes it sound apocryphal.
No doubt at the time the Mortgage final payment date issue was encountered in Financial IT, the budget was allocated to fix that issue, but non-affected date procesing was left as is according to the maxim 'if it's not broke, don't fix it', thus reducing testing requirements and the risk brought on by additional changes to critical systems.
"Many (mostly) mainframe (mostly) Cobol programs held the year portion of dates as a 2-digit field."
I don't remember the language - it was a bought-in package - but the boxes were Unix.
The client had 2 of them. The newer one could have run a Y2K version of the package but the older one, a warm standby, couldn't so they bought a couple of new boxes. My gig was getting them set up, tested, cut over in the slack days between Xmas & new year and babysitting for a few weeks.
As a side issue I discovered something about the backup. Apart from tapes they backed up the main box to the standby by running cp overnight using an NFS mount. The previous admin had inserted a cron job to knock the cp process on the head if it was still running just before start of business the next day. It was ALWAYS still running just before start of business the next day. I don't know how long it had been since they had had a complete backup.
Anyway, everything was installed and tested ready to go in time. The bean counters insisted that as their financial year ended on 31 Dec we couldn't cut over at such a critical time until all their year end procedures had been run which took a couple of weeks. And yes, the Y2K bug certainly existed; we had to have the package vendors dial in several times a week to fix the problems before we could move the job over in mid-January.
My big boss, in one of her few sensible decisions, had a few of our older machines hidden away to avoid the blanket cost of Y2K proofing every damn machine, whether they mattered or not.
(Local Authority orders, every machine had to be patched!)
I few years back I found one of these. It booted perfectly, ran its Windows 3.1.and worked.
I told a manager we should use 4 digit dates on an IBM System#38 ERP project in 1987. He said no, save the bytes, besides he would be retired by then. I was a contractor, wanted to ask him if the pension programmers cared about accurate date calculations.
Vendors like IBM got the last laugh using 10, count 'em, 10 bytes for the ISO date format.
A good opportunity to retell one of my favourite jokes.
A freelance Cobol programmer had made so much money by August 1999 fixing Y2K bugs, he decided to spend some of it. So he got himself cryogenically frozen, to be woken up in 2015, when, he hoped, any Y2K issues would be well fixed and the world would be a better place to live.
He work up...and looked round. He was in a hovering bed with robots looking after him. He was massively impressed by the level of the technology. Suddenly a voice spoke to him, saying "How are you feeling?"
"Fine" he said. "But I'm amazed by the technology you'd managed to get to by 2015".
"Ah" said the voice. "Actually, it's 2096, and we're a bit concerned about a possible Y2.1K bug. So we've woken you up as you're the only Cobol programmer we can find."
Still, even if we did absolutely nothing to prepare for Y2k, it wouldn't have been The End Of Civilization that the loonier bits of the population were worrying about. The Banks and utility companies would have figured out rather quickly that we can't all have become multi-gazillionaires with century old unpaid bills overnight. The lights would have stayed on and the water would still be running. As for the other issues with PCs and embedded systems, if Sony can have their network trashed and honestly say it won't affect their bottom line... OK, they may be lying there, nevermind.
It is also worth remembering that people really did go overboard with the whole "Y2k compliance" thing - I had the joy and wonder of being in a customer site in the Tianjin TEDA in December of 1999 and could not help but notice the Y2k compliant stickers on hand tools and friggin microscopes!
All the power's in the hands
Of people rich enough to buy it
While we walk the street
Too chicken to even try it
Everybody's doing
Just what they're told to
Nobody wants
To go to jail!
White riot - I wanna riot
White riot - a riot of my own
White riot - I wanna riot
White riot - a riot of my own
:The Clash 1977
". Apparently teachers will get kids to make use of their own smartphones and tablets in the classroom. Oh lordy, as if it’s not bad enough now with the little buggers running out of ink and blunting pencils, in 2015 they’ll be claiming that they need to borrow a recharger every two fucking seconds. "
That will be a minor thing to worry about -- as they turn on their collection of devices (from the latest iWotever to the unbadged slab from eBay), the first thing the server will do is scan for nasties. By the time things have been cured, fixed, archived and some devices just plain blocked, it will be time to go home.
No they will not.
Anything built today is built using lead free solder. It will grow hairlines and short long before then.
It is not likely that there will be a repeat of clinically in(s)ane situation observed ~ 5-8 years ago in certain telecommunications operator where they had signs on doors in exchanges "do not enter" because the boards in the switching equipment would disintegrate from looking at them. The kit still worked despite the boards being just one knock short of turning to dust because the solder had lead in it. This is not likely with new kit - all lead replacements have some degree of hairline growth over time so they will short electrically before 2038.
One of the reasons I've long been eager for the IPv6 transition is so you can run your own cloud-like things. The Internet was built to be decentralized. Why should your activity be held hostage to one provider?
Now that I'm older, I see the impossibility of security updates, so I'm going to reserve the cloud-like thing to myself.
That's because they have the riches necessary to secure a supply of globally reachable IP addresses. In exchange, whenever you want your devices to communicate, Google/Amazon et al. act as pervasive men-in-the-middle.
What I want from IPv6 is the ability for my devices to communicate with each other, even if they are not on the same LAN, without designing backdoors right into the architecture, and without horrible hacks like OpenVPN.
"It’s like rewiring the dodgy electricity cables when you move into an old home in need of modernisation, and then complaining that it was a waste of money because your house hasn’t burnt down since."
From now on, I'm going to shamelessly "borrow" that one for use against every gloating smart-arse who sneers at the "failure" of the IT industry with regards to the Y2K bug.
Dabbsy - If possible, do us all a favour and publish that sentence 15 years ago? Cheers.
The conmen^h^h^h^h^h^hmarketing at several major software companies were so concerned that their Y2K "solutions" were not selling at all well in Italy that they persuaded the State Department to make a high level Diplomatic approach to the Italian government.
The Italian politicos (probably realizing there would be no money to trouser themselves) politely ignoredthese approaches. Italian business continued to ignore the aforesaid salespeople, and, by Jan 1999 Italy had the lowest Y2K spend of any developed country (and lower than some underdeveloped ones).
The tragic consequence of this negligent behavior? Well the citizens of Milan got free tram rides for a couple of days while the ticket machines were being manually rebooted, and, that was about it.
Dates were stored in 6 digits rather than eight because the record size on cobol and dbase indexed files was very limited in the 1980s as i recall. We had removable drives the size of washing machines that cost 1000's and had capacities of a few hundred k. Most dates were coded to assume <=50 is year 2000 and >50 is 1900's. For dates of birth this was ignored because we didn't deal with customers under the age of 18. The assumption was made (correct as it turned out) that a Wang VS would not be used much past the year 2018 and would be replaced.
Obviously this isnt the case for many of the large banks who are still reliant on very old systems...
This post has been deleted by its author
Ah, memories. My first job in IT was actually fixing RPG400 code for Y2K compliance for a large UK based insurance company (telecommuting from NZ using dial-up to CompuServe. Kill me).
But it paid very well and we used the simple trick of changing date fields to 3 digits rather than 4 - the year 2000 being 100 which made date calculations relatively simple, at least assuming they didn't have anyone born in 1890s or 1900 itself on their books.
Always annoys me when you get people going on about how the whole Y2K thing was a bit of a fizzer... of course it was, most code was fixed before then. While the world as we know it wouldn't have ended if nothing was done, there definitely would have been repercussions - mostly financial I suspect.
in about 1992/3, myself and a colleague wrote an MS Word macro for the hospital I worked at, using ODBC 1.0 to pull patient discharge data out of the PAS system and auto-populate the word template. We were very pleased with ourselves because neither of us were professional coders, my colleague was the Oracle DBA and I was in tech support, but it worked and was rolled out throughout the hospital. Come 3rd or 4th of January 2000, having left the hospital 4 years earlier, I got a call asking if I still had a copy of the code as none of the circa 1,500 secretaries could complete discharge letters. Our code was reporting a negative length of stay because it subtracted the admit date from discharge date. At least the error checking we added meant the code fell over gracefully!
I recall doing rather a lot of work for Y2K, as where I worked I ended up being the person who knew the most about how the HP-UX 9.x boxes did their thing, and so therefore was best placed to help drag them to HP-UX 10.20/10.30 with the help of an on-site HP bod. On that subject there was something about the automounter that didn't work on 10.20, and in the previous years HP didn't seem to interested in helping. Though as soon as we gave them a swadge of money to get a bod onsite it was sorted...
That aside the nastiest thing that cropped up was some OS/2 boxes that did something financial. I left a few months before the big day, so no idea how they got sorted. Though if I'd been there I would have volunteered for the triple time NYE shift! Where I moved to was a greenfield project, so it was pretty easy to keep Solaris 2.6/7/8 in check.