From: Brent on
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
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
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
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
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