[Coco] Y2K fixes ever developed or posted?

[Gene Heskett]

On Tuesday 16 December 2003 00:23, Theodore (Alex) Evans wrote:
>On Dec 15, 2003, at 6:20 PM, Robert Gault wrote:
>> The argument that there is no room in the file descriptor for
>> another byte is specious. While it would not be backwards
>> compatible, the obvious answer is to redefine the file descriptor
>> by increasing the number of bytes that represent the year.
>
>Since the file descriptor is the primary place where the date would
>actually be preserved for the future there not being room there is
>hardly specious.  I guess that one could reduce the maximum number
> of segments in a file to 47 and grab five bytes that way.  The last
> segment being the location used.

Nope, won't fly.  I tried that with the BackAr fixes, which turned out 
to be a disk wipeing disaster for those that weren't aware of it.  
Bad, bad idea and one I wouldn't, after the last fiasco, touch again 
with a 500 foot piece of rope let alone the infamous 10 foot pole.

>> While this issue is moot for a Coco, it is not so for our records
>> in general. If humanity expects to exist past any particular year,
>> it needs to use records that permit representation of that year.
>> Otherwise sooner or later (sooner in the case of Y2K) there will
>> be major problems.
>
>We are talking about the issue as relates to the coco.  If we were
>talking about UNIX systems, the fact that signed 32-bit dates
> overflow in 2038 and unsigned in 2106, however that system is
> already in the process of being supplanted by 64-bit dates which
> will not overflow until around 292,277,026,596 A.D.
>
>> What do you think is going to happen in the year 2226 (not that
>> far away) if all computer systems stick with the current patches
>> used for Y2K of 1970+256 or something similar.
>>
>> We will all be dead, yes, but I repeat that reasoning is why Y2K
>> happened in the first place.

Yes, we'll all be dead, and so will the hardware Alex.  We are now 
getting into the far end of the bathtub curve that represents the 
dependability of an IC.  For instance, I think I've lost a gate in my 
disto SC-II, it now thinks drive 2 is drive 0 and drive 3 is drive 1.  
Other controllers I've tried don't have that problem.  In another 30 
years, the survival rate of our beloved coco's will be down to sub 
one percent of the original production.

>If you are worried about a date system being sufficient that it can
>continue to be used into the foreseeable future overflowing in the
> year 10,000 A.D. may not be sufficient.  There are calendar systems
> in use that are already over halfway there.  While it is very
> likely that our date system will have changed by then, it is hardly
> a foregone conclusion.

Another reason for us, the living, not to worry about it excessively.
That particular wheel will have to be redesigned at that time anyway, 
and as we don't exactly have a spec sheet on it today, hey, my magic 
crystal ball just clouded comletely up.. :)

-- 
Cheers, Gene
AMD K6-III at 500mhz 320M
Athlon1600XP at 1400mhz  512M
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.