From: Brent on 6 Nov 2009 20:47 On 2009-11-07, Bill Putney <bptn(a)kinez.net> wrote: > Brent wrote: > >> ...Practically any critical system could have been put back in operation by >> having the date set to something like 1-1-1970. The data to be fixed >> could easily be identified by the date and fixed later once patches were >> done... > > I have no opinion or knowledge on if it was real or not, but it would > seem obvious to me that if it was real, your statement would be wrong > about, say, the banking industry. Can you imagine the world calamity if > interest calculations were all screwed up - even for a day? Stock > market...? 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! :)
From: Brent on 6 Nov 2009 20:50 On 2009-11-07, Joe Pfeiffer <pfeiffer(a)cs.nmsu.edu> wrote: > Brent <tetraethylleadREMOVETHIS(a)yahoo.com> writes: >> >> Practically any critical system could have been put back in operation by >> having the date set to something like 1-1-1970. The data to be fixed >> could easily be identified by the date and fixed later once patches were >> done. > > Like banking systems, where the rules to apply depend on the date? Set > back to 1970, and refigure retirement year maybe? 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. >> Now the real event comes in 2038 ;) time() returns 2147483647 >> ( http://en.wikipedia.org/wiki/Year_2038_problem ) > Both from picking 1970, and from mentioning the Y38K problem, it sounds > like you're a Unix guy (as am I, by the way, which is why I'm quoting > statistics rather than regaling you with war stories) -- very few of the > serious problems were in the sort of scientific and server enviroments > where Unix is commonly used. It was in legacy databases. 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.
From: Joe Pfeiffer on 6 Nov 2009 21:32 Brent <tetraethylleadREMOVETHIS(a)yahoo.com> writes: > On 2009-11-07, Joe Pfeiffer <pfeiffer(a)cs.nmsu.edu> wrote: >> Brent <tetraethylleadREMOVETHIS(a)yahoo.com> writes: >>> >>> Practically any critical system could have been put back in operation by >>> having the date set to something like 1-1-1970. The data to be fixed >>> could easily be identified by the date and fixed later once patches were >>> done. >> >> Like banking systems, where the rules to apply depend on the date? Set >> back to 1970, and refigure retirement year maybe? > > 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. 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). >>> Now the real event comes in 2038 ;) time() returns 2147483647 >>> ( http://en.wikipedia.org/wiki/Year_2038_problem ) > >> Both from picking 1970, and from mentioning the Y38K problem, it sounds >> like you're a Unix guy (as am I, by the way, which is why I'm quoting >> statistics rather than regaling you with war stories) -- very few of the >> serious problems were in the sort of scientific and server enviroments >> where Unix is commonly used. It was in legacy databases. > > 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. 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. -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)
From: Bill Putney on 6 Nov 2009 21:42 jim wrote: > > Bill Putney wrote: >> jim wrote: >> >>> ...the breaker point ignition always meant that the engine >>> spent a considerable amount of its life with late timing due to breaker >>> points wearing down... >> Hmmm - Being that the spark occurs when the points *open*, worn breaker >> points would make the timing advanced (reduced dwell, but advanced >> timing). Unless you're going to say that the wear block wears down >> faster than the points burn back - which I don't think is generally the >> case. > > I see what your saying, but it doesn't work that way. > > Try checking the timing on an engine with well used set of points. 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. > Or > just observe the gap of a worn set of points - is the gap wider or > narrower? And yes I suppose wear to the rubbing block accounts for most > of it - transfer of metal plays a role too. > -jim 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. >> That's my buttal. Do you have a rebuttal? >> >> -- >> Bill Putney >> (To reply by e-mail, replace the last letter of the alphabet in my >> address with the letter 'x') -- Bill Putney (To reply by e-mail, replace the last letter of the alphabet in my address with the letter 'x')
From: Vic Smith on 6 Nov 2009 21:53
On Fri, 06 Nov 2009 18:37:34 -0700, Joe Pfeiffer <pfeiffer(a)cs.nmsu.edu> wrote: > >For a programmer in the 1960s, trying to save space (which cost lots of >both money and time) in a program *today* was important. The idea that >the same code might really still be in use in 2000 -- when the >programmer would be long retired -- was remote enough not to worry >about. I haven't seen any real figures on percentage of new code >needing fixes, but I expect somewhere around 1980 it probably started to >decline, and aroung 1990 to decline sharply. Any programmer who wrote >anything after about 1995 that needed to be fixed should be taken out >back and shot. 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 |