The real problem was that much software had been in use *way* beyond when the programmers assumed it would be. Other issues included the programmer's stupidity (programming an exception to an exception, but not its exception :). In a lot of cases what was really scary part was that there was no source code or tools to recreate the programs companies relied on for their business. Y2K solved a lot of that as an aside.
Dude, I'm not going to take the time to go item by item, but your post was pretty damned close to COMPLETELY wrong.
I'd hate to dissagree - but Y2K was a lot of Hoopla - and extremely low actual problems.
The trafic signal scenario? Extremely easy to get around. The calendar repeats itself on a very predictable schedule - so for the rest of the lifespan of the control system a simple reset of the date to a year with the same calendar, in the same point of the schedule, is all that was required. If that year, was, for instance, 1942, there was another
58 years to go without worrying about the weekend schedules being thrown off.There was a whole lot of money made by "y2k analysts" that was a pure rip-off - call it fraud to be accurate - and a lot of fearmongering.
The only place it really ended up being any kind of an issue was on mainframe actuarial systems (big insurance companies running large databases on antiquated systems running Fortran, as an example)
Most of these systems had already oulived their design lifespan - having been programmed in the '60s and '70s, with the expectation that they would be replaced in the '80s or '90s.
For sure. I feel your pain. I just dropped a card, to join the inside track club. I'm hoping that will get me some more coupons. Should bring me multiples of the mailers.
Microdyne hired one who didn't know that XT computers didn't have a real time clock and who wanted every PC in the company replaced because most were still Win 95. The fact that most of our test software was written in the 3.1 or 95 days didn't sink in.
He, and the others in IT would wipe things off your computer without asking, including test software that was written in house "Because you don't have a license to use it on this computer!" Other things like ISP (In System Programming) modules to program circuit boards. They were passed around, since we were always short. Engineer would take them after the end of first shift, then be pissed off when you wanted them back. IT demanded that you uninstall the software from the computer you borrowed it from, even though it was available on the OEM website for free download.
The worst was when they wiped a test bed system running windows 2.0 and installed Win 95. Luckily, I had kept a couple sets of old floppy backups and managed to get it running after wasting a full day looking for files that could still be read. I'm sure that other people had similar problems with Y2K crap like that.
I had a friend who was servicing Data General minicomputers and a lot of computer terminals. Most of his customers migrated to a server & PCs rather than fool with updating their old software. The last I heard, he was repairing PCs.
Banks have to project more than 30 years. For example, 40-year mortgages exist (even if it's a stupid thing to do). That doesn't mean they paid attention. In 1970, saving two bytes several times in each record was a big deal. The mind set was still 80-column cards -- not surprising since banks used a lot of punched card equipment priori to computers. Were they given a clue? Yes. Did they act on it? Seldom -- as is evidenced by the huge amount of work banks had to do for Y2K remediation.
I'm surprised by your belief that software systems are so robust. Even if one particular subsystem is sound, it can be brought down by the subsystems around it. Flight control software may have been sound (AFAIK the stories about an airplane inverting when it crossed the equator are pure urban legend), but airplanes have several computerized systems on board, and not all are so purely involved with avionics.
I never read any such newsgroup and I'm regurgitating nothing. My opinions are based on my own experience, with perhaps a bit of input from IEEE Spectrum -- not exactly the most alarmist publication on the planet.
If the question is answered without analyzing the code, then the answer is usually wrong. Dates are found in code which one would think, based on externals, would not need dates. Or which doesn't actually need dates but has them anyway.
Which describes a frightening amount of production code, and even more so in 1990 than in 2010. I hope ...
Edward
Since you were involved, I'm sure you know that most of the code involved was custom and not available for public review. That makes references difficult. You can find some in IEEE Spectrum though.
I'm happy that the systems you were involved in were in relatively good shape. That doesn't mean they all were. I could turn your request for references back on you.
Because someone brought it up. Hey, how long you been around Usenet? You tellin' me there needs to be a REASON to rehash something? Bah.
Yes, I fear that's true. Oh, it won't be quite the same thing -- the world of DP (excuse me, IT) will have changed enormously. It will get new names about every 25 years, just to keep it fresh -- DP, IT, what next? At present everyone is being careful about dates. There will never again be the pressure to save two bytes, since storage is so cheap now. But in 50 years, no one working will have gone through it. Handwritten dates will always drop the century, and eventually this will slip into data systems. Exactly how, I don't know, but somehow it will. Have we fixed the 2039 problems yet? Not AFAIK.
(And apropos a response, I agree with "we". I won't be alive, but "we" as a profession and the human race will go through it. Those ignorant of history etc.)
Edward
Sure, as I said, lots of times the fix was easy. It was the analysis that was hard. And in your example, the analysis had to determine that the kludge that you propose (and it's clearly a kludge, not a fix) wouldn't cause any undesirable side effects. Kludges have a nasty habit of causing unforeseen problems. In addition, it could not wait until 2000-01-01, because too many systems would have needed attention all at the same time. Many simple ones could have been repaired quickly after they failed, but many failures appearing all at once would have overwhelmed the capacity to fix them.
No doubt. The DP/IT profession is as rife with opportunists and incompetents as any other. That doesn't mean that everything done is opportunistic or incompetent.
That's an extremely limited view of what happened. And in any case, ten years ago those systems ran an awful lot of what was important to business. It's dropped a lot today but hasn't gone away. Oh, and insurance companies seldom used Fortran. They mostly used COBOL. I haven't heard any recent figures, but I suspect that there's still more production code written in COBOL than in any other language. Fortran code was generally less of a problem due to its emphasis on numerical work.
But they hadn't been replaced. That's part of the point. The other point that I make, though, is that they were not designed with any such expectation. They weren't designed with a lifespan at all. In the
60s and 70s, programming on this scale was still so new that programmers weren't thinking about how long their code would last at all.Edward
If the date is not input manually and there is no real time clock in the system, then where does the code get the date?
From what I know, the only problem was subtracting dates. I wonder how much would have been a problem, even with no correction. Sounds like more trouble than I would have expected.
I'm not enough of a computer guy to know for sure. My prediction in
1999 was that we'd have about a week of glitches and rolling black outs and other problems. I'm glad we didn't have even that much trouble.
The people I know who were working in banking at the time don't seem to think so. Oh, well.
You had actual experience with "most web sites" (your phrase, not mine) that enables you to state with confidence that most of them would have gone down?
Yeah, riiiiiight.
Utter nonsense. If there's no way of putting a date into the system, it has no way of keeping track of the date and hence is unaffected by dates in any way.
In article , Edward Reid wrote: [...]
Not exactly the most informed publication, either, when it comes to IT issues, I'd imagine. Most engineers I've worked with don't have the first clue about computer software, and you obviously are no exception.
No, of course not -- because then you'd actually have to put some effort into demonstrating that. Which of course you can't. You have no idea what you're talking about.
Well, to start with, expectations. They aren't too high with HF. I buy stuff there with the expectation of short term and the hope of long term.
It's good to write a review after using a product. I look at reviews before I buy most stuff. But you have to use some discrimination. Toss out the,
"I just opened the box. It's beautiful. Color perfecty compliments my other appliances. 5 Stars!"
"Man, this is one good drill. Used it for 2 weeks now and already drilled 17 1/4" holes through the 2x4's for my new rabbit cages. Definitely 5 Stars!"
"This buffer is junk. I used my last Acme buffer to sand 3 vanities and a wardrobe. I can't even glue the sandpaper to this one. It just won't stick to the pad they use. 0 Stars!"
You get the picture. Besides, I got a couple of feelings about the reviews. People are more likely to squawk than praise. So the "rating" can be deceptive. You get a hundred reviews with half complaining. But maybe they sold 1000. That probably means the product is better than the reviews indicate. Then you got your $300 toaster. The people that pay $300 for a f**king toaster are probably too stupid to know what's making their bagels all black and real crunchy, but can still manage to type out "5 Stars!" Of course some have moments of sanity, and write a review saying "I can't believe I paid $300 for this f**king toaster." But most paying big bucks for junk will stand by their junk.
Having said all that, I bought a washing machine with pretty bad reviews. But the reviews compelled me to pay almost 200 bucks for an "instant replacement" warranty. I hardly ever buy that kind of warranty. Why did I buy that washer? It's the one my wife wanted. I figured 200 bucks was worth keeping her quiet. It almost worked. You are always rolling the dice.
--Vic
Neat. I've not seen washing machines at HF. Please post a link.
I clicked on the link followed by learn more about Jesus but it was not working but I did find a link that was benificial!
Here it is if anyone wants to learn.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required