21 Oct
1998
21 Oct
'98
10:58 a.m.
< I'm still skeptical. I'd love to hear more first-hand reports of
< the oldest code still running as-is. Come on, code from the 50s
< that's never been replaced? Running on what? Under an emulator?
Ok, howabout a Brigeport milling machine with the PDP-8E it was purchased
with in 1975, still running the same code.
code from the 50s would likely be fortran or Cobol and yes it would be
portable enough to go from one machine to the next with only a compile
(no edits). Code from the late 60s era machine could still be running
oth either native hardware or later machines that had to support old
code.
What is missed is code is expensive and hard to maintain so if you have
something good and known you run it for a long time. I'm still running
8080/z80 code from the late 70s early 80s! If it aint broke don't fix
it and the system that it was genned on is also 20 years old last March.
So it's very easy for old code to linger.
Allison
22 Oct
22 Oct
2:55 a.m.
New subject: Y2K and immortal executables
At 06:58 PM 10/21/98 -0400, Allison J Parent wrote:
< I'm still skeptical.
Ok, howabout a Brigeport milling machine with the PDP-8E it was purchased
with in 1975, still running the same code.
Sure, I can imagine that. But I can't imagine it will stop working
on January 1, 2000, or that the clock couldn't be set back to 1975
without affecting the milling.
code from the 50s would likely be fortran or Cobol and
yes it would be
portable enough to go from one machine to the next with only a compile
(no edits). Code from the late 60s era machine could still be running
oth either native hardware or later machines that had to support old
code.
Wait a minute - we history-buffs can certainly place dates for the
creation of COBOL and FORTRAN, as well as the period in which those
languages became popular for business. What's a reasonable period
for the start of popularization of FORTRAN and COBOL?
If the source code has existed in some form since the late 50s or
early 60s, no programmer since its creation has tinkered with it?
I can imagine a slightly more plausible situation in which the source
was written in 1961, recompiled and tweaked throughout the Sixties,
and somehow the source was lost after recompilation in the Seventies
so only the executable remains, and that it's been running in some
kind of emulation box since then - but again, I find it hard to
believe that almost all date-dependent programs haven't had some
*other* reason to be changed in all those intervening years, requiring
their replacement or re-creation (in new source code) since then.
It's not that I'm denying Y2K - it's that I think it's overblown,
especially when it comes to antique computers.
- John
6:03 a.m.
New subject: Y2K and immortal executables
At 09:55 AM 10/22/98 -0500, John wrote:
Sure, I can imagine that. But I can't imagine it
will stop working
on January 1, 2000, or that the clock couldn't be set back to 1975
without affecting the milling.
Now I'm going to be ill. Look out world, here comes "Millenium Savings
Time." Yes boys and girls, at midnight on December 31st 1999 we are all
going to turn back our calenders to 1990 and the date will officially be 1,
Jan, 1990 _again_. This will give the world another 10 years to fix their
problems and then on December 31st 1999 (MST) we turn the calendar
_forward_ 10 years.
Remember, you heard it hear first!
--Chuck
7:19 a.m.
New subject: Y2K and immortal executables
Chuck McManis <cmcmanis(a)freegate.com> wrote:
Now I'm going to be ill. Look out world, here
comes "Millenium Savings
Time." Yes boys and girls, at midnight on December 31st 1999 we are all
going to turn back our calenders to 1990 and the date will officially be 1,
Jan, 1990 _again_. This will give the world another 10 years to fix their
problems and then on December 31st 1999 (MST) we turn the calendar
_forward_ 10 years.
Actually it should be 28 years rather than 10, so that the day of the week
and leap year cycle remain correct. That will give us plenty of time to
fix the problem. Of course, then no one will work on the problem for another
26 years.
Lots of people will be unhappy when they suddenly find themselves below the
legal ages for voting, driving, drinking, etc.
The Internet Software Consortium (the people that develop and maintain
BIND, DHCP, etc.) have a nice web page describing their strategy for dealing
with the Unix Y2038 problem:
http://www.isc.org/y2k.html/
(Don't hold your breath.)
7:46 a.m.
New subject: 1972 (was: Y2K and immortal executables
Chuck McManis <cmcmanis(a)freegate.com> wrote:
On 22 Oct 1998, Eric Smith wrote:
Now I'm
going to be ill. Look out world, here comes "Millenium Savings
Time." Yes boys and girls, at midnight on December 31st 1999 we are all
going to turn back our calenders to 1990 and the date will officially be 1,
Jan, 1990 _again_. This will give the world another 10 years to fix their
problems and then on December 31st 1999 (MST) we turn the calendar
_forward_ 10 years.
Actually it should be 28 years rather than 10, so that
the day of the week
and leap year cycle remain correct. That will give us plenty of time to
fix the problem. Of course, then no one will work on the problem for another
26 years.
Lots of people will be unhappy when they suddenly find themselves below the
legal ages for voting, driving, drinking, etc.
Ohmigod! We would keep going back over and over and over to 1972?!?
(Like "Ground Hog Day") How many times would we need to repeat those 28
years before we get it right?
THIS time I'll take that job offer in Albuquerque, not get involved with
what's-her-name, release XenoCopy with Phillipe Kahn instead of Vertex,
keep the Honda S-800, . . .
I think that I'd still prefer to do the sixties instead. Even without
microcomputers they were a lot more fun.
--
Fred Cisin cisin(a)xenosoft.com
XenoSoft http://www.xenosoft.com
2210 Sixth St. (510) 644-9366
Berkeley, CA 94710-2219
9559
days inactive
9560
days old
4 comments
5 participants
participants (5)
-
allisonp＠world.std.com -
cisin＠xenosoft.com -
cmcmanis＠freegate.com -
eric＠brouhaha.com -
jfoust＠threedee.com