Well I was speaking of life and death systems such as air traffic control and the like. Systems that really don't need to know what year it is. Banks would have had an entire holiday to come up with some sort of patch for business on the 2nd. I really didn't think the world as we knew it would have ended. Although, I wish I had stocked up gold and silver then... look at the price today! :)
I guess I just don't consider that a critical system that couldn't be fixed later. I'm talking about planes crashing into each other, traffic lights going green for all directions at the same time, etc... things that could get people killed, not a day or two without working ATMs.
I know. unix had little problem with Y2K. Although I needed to patch up my NeXT boxes. I think the patch was mostly to be able to set the correct date and stuff like that. I don't think anything major would have stopped working.
Different industry, different priorities. Almost none of the Y2K problem was in control systems, embedded systems, or the like (a mailling list I'm on was considering creating "Certified Y2K compliant" stickers to put on our pre-electronic engine management cars. We were also considering "Warning: this automobile has not been tested for Y2K compliance" stickers to put on cars on used-car lots, but I digress). It was almost all in the financial, insurance, and government-regulatory etc areas.
But even given that, I'm not quite sure why you think waiting until your bank was suddenly in regulatory non-compliance on 1/1/2000 and starting to fix it then would have been better than spending a couple of years getting it fixed so the customers (and more importantly, the regulators) didn't notice -- the fixes had to happen in any event, the only issue was when and how panicked.
As for your ATM example: if you'd been the manager in charge of the software for those machines for your bank and they'd quit working on
1/1/2000, you'd have been looking for work by some time early that morning. And firing you would have been the vice-president you report to's last official act (with probably several layers of severed heads in between) as well. The only things more important than keeping uptime for customers are backup and regulatory compliance (and in banking, regulatory compliance includes backups).Nor on my machines. But (1) my machines don't have anything major on them by the standards I'm describing, and (2) everything had been fixed in advance -- which is the point.
Hah! If you can show me where to find one. Except, I do own a 1942 Gravely that has points in the magneto - never used a timing light on it
- always followed the book on statically timing it.
Of course, as you no doubt know, when you get metal transfer, you get peaks and valleys on the points and then feeler gages (or a 3x5 card) don't tell you anything with any accuracy.
The problem was the many data files that still contained a 2 digit year. All those files had to be converted. And any program reading them had to changed and compiled or assembled to accommodate the new file format. Even if the program did nothing with the date. Yes, there were - and probably still are - assembler programs running in major apps. I was called recently about taking an assembler job. If you think about how much of business data contains a start date - birthday, policy, account, etc, etc, etc, and the old data files with
2 digit years, it's pretty easy to see the scope of the problem. Those data files had to plugged with 19 before the calendar flipped to 20, and of course everything had to be tested up the yazoo first. Most stuff was addressed well before crunch time, but there was plenty to do in the last 2 years when push came to shove. DB2 - the major mainframe database - was designed with 8 digit dates, so presented no problem. It was all the old tape and disk files and the programs that touched them that posed the problem.--Vic
Yeah I haven't put a timing light on a small engine much either and I'm not sure if points and magneto behave the same as points and coil as far as wear patterns.
Well i did say observe not use a feeler gauge. Also i expect to some extent the metal transfer also produces some porosity which takes up more space than the original metal and may account for some of the closing of the gap.
-jim
That was my impression, though I admit I haven't researched the issue thoroughly.
Yep. The fact that those in the business knew it was coming long before the public caught on didn't hurt either. Now the "general wisdom" is that Y2K was a "boy who cried wolf" scenario, when actually the wolf DID arrive, only to find wolf-proof brick walls and cranky called-out-of-retirement COBOL programmers with shotguns :-) (they're mostly safely back in retirement now, in a better position for the Y2K money...)
Not going to be a big problem. The time_t type is 64-bits on any modern Unix system. Even Windows uses 64 bits.
I make no promises for Y10k.
And said fix will be a bulb which relies on the incandescence of an electrically heated metal filament immersed in an inert gas sealed in a glass envelope. Sure, it uses a little more energy, but it's SAFER, and more ENVIRONMENTALLY FRIENDLY don't you know :-)
Unfortunately GE gave up their research into high-efficiency incandescents. I think Phillips is still working on theirs, though, both the quartz-capsule HIRs inside a standard bulb envelope and exotic filament treaatments.
Unix systems got bit, just not as much. I ran into one... a version control system which would corrupt the database if it was ever run after Y2K. Repairing that (proprietary and undocumented) database to the point where we could get the code out of it was not fun. I wish I remembered the name of the VCS so I could denigrate it properly, but the company is long since out of business anyway.
I think your date of 2012 is correct for the Maya predictions. There was another prediction recently which claimed a disaster event for 11-11-09. On that date I will watch "Law and Order", most likely, and go to bed.
I did some cleanup work for some people who had a realtime factory automation system written in COBOL running on a VMS machine. Don't ask how it got that way.
Updating VMS to V5.5 fixed all of the OS-related Y2K issues, none of which really mattered anyway since none of the code used the system date. The code, however, accepted a human-entered Julian date in the form of two digits for the year, then three digits for the number of days since Jan 1. It treated the Julian date number as an integer and the only acceptance testing it did on the date was that it couldn't be lower than 85000. Which of course was a problem when the date turned to 00001.
Nobody had any of the source code for this mess, so I patched the binary so it compared it with 0 instead of 85000. Problem solved. Actual coding time about 10 minutes, time to figure out what the code actually did (a combination of the operators really having no clue how the system worked and a lack of documentation) about two weeks.
If I'd had the source code, it wouldn't have been a big deal to fix it so it calculated the actual Julian date from the system date, but I really didn't want to work with this stuff any more than necessary.
--scott
I have HIR's in one of my Concordes. Apparently they haven't caught on yet. I think they even quit making the hi beam (9006) bulb in it. But I do have a spare on the shelf (actually was planning on putting that in my second Concorde, but haven't gotten aroundtuit since the headlight assembly has to be modified slightly to accept angle-based bulbs).
Hah! Yeah - that one's really got me worried. Something tells me there will be bigger things to be worried about by then - or maybe all problems will be over by then.
Well that whole theory that a tankful of leaded fuel protected the valves forever was crafted in hindsight, after it became clear that old engines were not burning valves with unleaded gasoline as had been predicted. If you do research you might look at the studies done by those who build engines designed to run on LPG. What those studies demonstrated is that soot makes some difference in wear on valves. Hardened valves were used in LPG engines long before they were used in gasoline engines because LPG engines eat valves more than gasoline engines. The reason LP gas engines erode valves faster is because they burn so cleanly. The valves erode because of the clean metal on metal contact. Tests have shown that you can counter the valve wear problem in LPG engines by just burning a tiny amount of oil along with the LPG. The soot produced protects the valves. It should be obvious that 1960's gasoline engines did not have this problem of burning fuel too cleanly.
If you do your research you will note that the tests that showed the benefit of lead were all done under very extreme conditions where engines were run at extremely high rpm high load conditions. It has never been demonstrated that lead makes a noticeable difference in valve wear under normal driving conditions.
Where TEL did make a clear difference was in oil refinery economics. It allowed the oil companies to produce and sell the mix of products that maximized profits. In simple terms, it was a way to increase demand plus lower production cost.
Another big difference that has resulted from removing lead from gasoline is engines last longer without lead, oil change intervals can be made longer and spark plugs last considerably longer. Those changes have been documented in side by side comparisons of the same engines on the 2 types of fuel. Those differences are directly related to removing lead from the fuel and not changes in engine design or changes in materials used.
-jim
The major disaster that will happen on 11-11-09 is that almost everyone will forget the anniversary of the armistice. People need to remember what happens when countries get embroiled in badly-thought-out wars. That's what the day is all about...
--scott
My personal feeling, based on observation, is that the world was and is at much greater risk due to unspec'd, untested & unverified software being hacked out in third world countries than anything we could ever conceive related to two digit date years. All that Y2K hype sure did keep a bunch of SW people employed for a year or so though.
What the Y2K hype did was cause a lot of people to go back and go through some of their old code and do documentation and maintenance work that was years if not decades overdue.
People who get badly-designed and badly-tested code from the lowest bidder are indeed a problem. But people who think they don't need to do spend money to properly document what they have, and don't think they need to spend money to keep what they have up to date, they're just as much of one.
--scott
MotorsForum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.