18 Jan
2022
18 Jan
'22
8:05 p.m.
Check it out:
@_uptiME.EXE.2_
TOMMYT up for 1 Year, 2 Days, 16 Hours, 36 Minutes, 26 Seconds and
582 Milliseconds
@_timET2.EXE.4 _
Tops-20 was booted on Saturday, January 16, 2021 8:46:38PM-EST.
It will crash with an UP2LNG BUGHLT on Friday, February 18, 2022
1:08:57PM-EST.
@
UPTIME and TIMET2 are two programs that I wrote several years; ago,
UPTIME in 2017 and TIMET2 in 2006.? I wrote them because I found the
hours format given by SYSTAT SYSTEM and INFORMATION MONITOR-STATISTICS
to be a little opaque and they didn't have the information I wanted, viz:
@_sysTAT sySTEM_
?Tue 18-Jan-2022 13:28:45? Up *8800:42:07!!!!!!!!*
?4+7 Jobs?? Load av?? 0.01?? 0.02?? 0.02
?No operator in attendance
@_iNFORMATION (ABOUT) monITOR-STATISTICS_
?Up *8800:42:10!!!!!!!!*
?Idle 99%? Waiting 0%? Sched ovh 0%? Pager traps 0%
?Swap reads 28049 Writes 385176? File reads 4643699 Writes 3677925
?8092 Pages of user memory
?4259771001 Term wakeups? 1255 Term interrupts
?NBAL av?? 0.32? NRUN av?? 0.02
?Runtime of jobs on sched queues 0-6 (sec)
?? ?143964??? 16409??? 14494??? 1012??? 1756 4846??? 4215
@
I wrote TIMET2 because I needed to know when to set a shutdown. If you
don't do that and you hit the uptime limit, then the machine simple
crashes with an UP2LNG BUGHLT. This happens because the uptime
millisecond counter is a signed 36 bit integer, which will roll over and
become negative after 1 Year, 4 Weeks, 5 Days, 16 Hours, 22 Minutes, 18
Seconds and 367 Milliseconds.? You would think the code would self-set a
'graceful' shutdown, but it doesn't...? Maybe I'll do that one of these
days; it's easy enough.
Since the PDP-10 does not have unsigned compares, fixing this would
involve changing a rather large number of comparisons. Assuming you kept
the storage at a single word, going unsigned would get you out to 2
Years, 9 Weeks, 4 Days, 8 Hours, 44 Minutes, 36 Seconds and 735
Milliseconds.? That's probably still not that great given today's hardware.
Going to an unsigned double word format would obviously get you a far
larger uptime.? However, the current arithmetic that I use can 'only'?
handle a maximum uptime of 34,359,738,367,999 of milliseconds.? This
works out to be 1092 Years, 27 Weeks, 5 Days, 3 Hours, 46 Minutes, 7
Seconds and 999 Milliseconds.? Since the time of day counter expires in
7-Aug-2576 7:59:59 PM EDT, I used a faster instruction...? Otherwise,
going over a millennium between reboots seemed reasonable unless you
find yourself in a significantly sub-luminal spacecraft going someplace
inter-galactic...
I know that XKL fixed at least part of the uptime problem, but I don't
remember what that limit is.? What are the limits for other systems?
18 Jan
18 Jan
8:15 p.m.
On Jan 18, 2022, at 2:05 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
...
I wrote TIMET2 because I needed to know when to set a shutdown. If you don't do that
and you hit the uptime limit, then the machine simple crashes with an UP2LNG BUGHLT.
Oops.
I know that XKL fixed at least part of the uptime
problem, but I don't remember what that limit is. What are the limits for other
systems?
It's not overly strange that designers of mainframe systems, where planned shutdowns
(say, for preventive maintenance) were a regular occurrence) would overlook silly bugs
like that. It feels like the sort of thing that minicomputer software, especially real
time systems, would never do. For example, RSTS has no uptime limit.
Another mainframe system that had weird behavior, though not an actual hard limit like
this, is the CDC 6000 mainframe NOS system. The one I worked on (University of Illinois
PLATO) was shut down for PM every weekday morning, so normal uptime was less than a day.
But the Cyber1 system, running that OS in emulation, was up for months on end until we
instituted weekly backups. That exposed a leap year bug: if the system was started in
January of a leap year, it would mishandle February as 28 days rather than 29. It would
do it right if started in February, or before January. I wrote a patch for it, just for
completeness.
paul
8:26 p.m.
On 2022-01-18 20:15, Paul Koning wrote:
Ooops indeed. This is a bit of a surprising limitation in Tops-20 for me.
Neither have RSX. However, I do know that VMS have an uptime problem. Or
rather a time problem. Because of the way time is represented,
everything will fail catastrophically somewhere around the year 31000.
VMS represents time as a signed quad. 100ns resolution, and offset from
1858 (or whenever it was). Anyway, the important bit is that it is
signed, and it has to be positive.
Because negative time values are considered to be relative (delta)
times. And so, when the time actually wraps over, things will go totally
bonkers in VMS.
Of course, other things will probably start causing problems long before
then, like when years start needing 5 digits...
With RSX, I am not aware of anything that will cause fatal problems.
Time representation might get a bit broken around the year 33000 or so,
but I don't think anything catastrophic will break. Years are just a 16
bit value with an offset of 1900. But very few things even use it for
anything, except printing it out. So signedness or not might cause
things to look funny depending on the code, but most software itself
will not care.
Various subsystems will probably have issues long before then, like time
stamps on files will wrap, queue manager time handling will break/wrap,
and of course DECnet time representation can't deal with it. But the OS
itself will probably just continue chugging along, as will most software.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 18, 2022, at 2:05 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
...
I wrote TIMET2 because I needed to know when to set a shutdown. If you don't do that
and you hit the uptime limit, then the machine simple crashes with an UP2LNG BUGHLT.
Oops. I know that
XKL fixed at least part of the uptime problem, but I don't remember what that limit
is. What are the limits for other systems?
It's not overly strange that designers of mainframe systems, where planned shutdowns
(say, for preventive maintenance) were a regular occurrence) would overlook silly bugs
like that. It feels like the sort of thing that minicomputer software, especially real
time systems, would never do. For example, RSTS has no uptime limit.
8:43 p.m.
On Jan 18, 2022, at 2:26 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2022-01-18 20:15, Paul Koning wrote:
Neither have RSX. However, I do know that VMS have an uptime problem. Or rather a time
problem. Because of the way time is represented, everything will fail catastrophically
somewhere around the year 31000. VMS represents time as a signed quad. 100ns resolution,
and offset from 1858 (or whenever it was). Anyway, the important bit is that it is signed,
and it has to be positive.
Because negative time values are considered to be relative (delta) times. And so, when
the time actually wraps over, things will go totally bonkers in VMS.
Of course, other things will probably start causing problems long before then, like when
years start needing 5 digits...
With RSX, I am not aware of anything that will cause fatal problems. Time representation
might get a bit broken around the year 33000 or so, but I don't think anything
catastrophic will break. Years are just a 16 bit value with an offset of 1900. But very
few things even use it for anything, except printing it out. So signedness or not might
cause things to look funny depending on the code, but most software itself will not care.
Various subsystems will probably have issues long before then, like time stamps on files
will wrap, queue manager time handling will break/wrap, and of course DECnet time
representation can't deal with it. But the OS itself will probably just continue
chugging along, as will most software.
Time stamps are interesting. DECnet event timestamps ran out of bits recently, unless you
ignore the spec's statement that the 16-bit field is signed. If treated as unsigned
you've got until 2038 or so.
RSTS timestamps overflow in 2035. RT-11 ran into trouble before Y2K though I think there
are workarounds for that -- which are not implemented everywhere. DOS-11 format DECtape
ran into trouble in April of 1974 (12 bit timestamps), I remember creating a RSTS patch
for that in college and sending it to DEC. :-)
paul
> ...
I know
that XKL fixed at least part of the uptime problem, but I don't remember what that
limit is. What are the limits for other systems?
It's not overly strange that
designers of mainframe systems, where planned shutdowns (say, for preventive maintenance)
were a regular occurrence) would overlook silly bugs like that. It feels like the sort of
thing that minicomputer software, especially real time systems, would never do. For
example, RSTS has no uptime limit. 
19 Jan
19 Jan
1:44 a.m.
An HTML attachment was scrubbed...
URL:
<https://lists.sonic.net/mailman/private/hecnet-list/attachments/20220118/8064759c/attachment.htm>
1:48 a.m.
By then, we probably also need to look at/revise how we compute leap
years... It's well known that the current algorithm will slowly get us
out of phase again...
Johnny
On 2022-01-19 01:44, Mike Kostersitz wrote:
Cool thread, reminds of many leap year issues we fixed
in All-In-One a
long, long time ago. I think at the year 33000 there will be other
issues to tend with than RSX or other Digital Equipment software going
bonkers ? Unless of course the Metaverse runs on RSX then of course all
bets are off ?
Mike
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
*From: *Paul Koning <mailto:paulkoning at comcast.net>
*Sent: *Tuesday, January 18, 2022 11:43 AM
*To: *hecnet at update.uu.se <mailto:hecnet at update.uu.se>
*Subject: *Re: [HECnet] How long has your 20 been up?
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 18, 2022, at 2:26 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2022-01-18 20:15, Paul Koning wrote:
>> ..
>> I know that XKL fixed at least part of
the uptime problem, but I
don't remember what that limit is.? What are the
limits for other systems?
> It's not overly strange that designers of
mainframe systems, where
planned shutdowns (say, for preventive maintenance) were
a regular
occurrence) would overlook silly bugs like that.? It feels like the sort
of thing that minicomputer software, especially real time systems, would
never do.? For example, RSTS has no uptime limit.
Neither have RSX. However, I do know that VMS
have an uptime problem.
Or rather a time problem. Because of the way time is
represented,
everything will fail catastrophically somewhere around the year 31000.
VMS represents time as a signed quad. 100ns resolution, and offset from
1858 (or whenever it was). Anyway, the important bit is that it is
signed, and it has to be positive.
Because negative time values are considered to be
relative (delta)
times. And so, when the time actually wraps over, things will go
totally
bonkers in VMS.
Of course, other things will probably start
causing problems long
before then, like when years start needing 5 digits...
With RSX, I am not aware of anything that will
cause fatal problems.
Time representation might get a bit broken around the year
33000 or so,
but I don't think anything catastrophic will break. Years are just a 16
bit value with an offset of 1900. But very few things even use it for
anything, except printing it out. So signedness or not might cause
things to look funny depending on the code, but most software itself
will not care.
Various subsystems will probably have issues long
before then, like
time stamps on files will wrap, queue manager time handling will
break/wrap, and of course DECnet time representation can't deal with it.
But the OS itself will probably just continue chugging along, as will
most software.
Time stamps are interesting.? DECnet event timestamps ran out of bits
recently, unless you ignore the spec's statement that the 16-bit field
is signed.? If treated as unsigned you've got until 2038 or so.
RSTS timestamps overflow in 2035.? RT-11 ran into trouble before Y2K
though I think there are workarounds for that -- which are not
implemented everywhere.? DOS-11 format DECtape ran into trouble in April
of 1974 (12 bit timestamps), I remember creating a RSTS patch for that
in college and sending it to DEC.? :-)
??????????????? paul
1:50 a.m.
An HTML attachment was scrubbed...
URL:
<https://lists.sonic.net/mailman/private/hecnet-list/attachments/20220118/23198509/attachment-0001.htm>
1:57 a.m.
On Jan 18, 2022, at 7:48 PM, Johnny Billquist <bqt
at softjar.se> wrote:
By then, we probably also need to look at/revise how we compute leap years... It's
well known that the current algorithm will slowly get us out of phase again...
The Gregorian algorithm is amazingly accurate, I wonder if the earth rotation slowing down
is the bigger issue. Then again, I suspect a whole lot of computer date algorithms will
get 2100 wrong; I know RSTS has the Julian leap year rule. Not that it really matters
given the Y2035 issue...
paul
2:04 a.m.
On 2022-01-19 01:57, Paul Koning wrote:
It is fairly good, but not perfect. I think it have been brought up that
there should be a 3200 year rule, beyond the 100 and 400 rule. The
Wikipedia article says it should be a 4000 year rule
(https://en.wikipedia.org/wiki/Gregorian_calendar#Accuracy). So either
I'm misremembering, or else there are some different ideas about this...
RSX will deal correctly with the 4/100/400 rules (which means we're
talking Gregorian). I think pretty much everything in RSX is secured up
until 2155, and before then I think the only problem is DECnet, and
things like FLX which deals with RT-11 filesystems.
Beyond 2155, a few more things will cause problems, but nothing
catastrophic.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 18, 2022, at 7:48 PM, Johnny Billquist
<bqt at softjar.se> wrote:
By then, we probably also need to look at/revise how we compute leap years... It's
well known that the current algorithm will slowly get us out of phase again...
The Gregorian algorithm is amazingly accurate, I wonder if the earth rotation slowing
down is the bigger issue. Then again, I suspect a whole lot of computer date algorithms
will get 2100 wrong; I know RSTS has the Julian leap year rule. Not that it really
matters given the Y2035 issue... 
4:21 a.m.
Johnny,
I got to wondering, on RSX, when in the future does my favorite Easter Egg break?
time /roman
Januarius XVIII, Anno Domini MMXXII
XXI:XVIII
The moon is waning gibbous. Today is Tuesday.
Happy New Year,
Mark
On Jan 18, 2022, at 1:26 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2022-01-18 20:15, Paul Koning wrote:
Ooops indeed. This is a bit of a surprising limitation in Tops-20 for me.
Neither have RSX. However, I do know that VMS have an uptime problem. Or rather a time
problem. Because of the way time is represented, everything will fail catastrophically
somewhere around the year 31000. VMS represents time as a signed quad. 100ns resolution,
and offset from 1858 (or whenever it was). Anyway, the important bit is that it is signed,
and it has to be positive.
Because negative time values are considered to be relative (delta) times. And so, when
the time actually wraps over, things will go totally bonkers in VMS.
Of course, other things will probably start causing problems long before then, like when
years start needing 5 digits...
With RSX, I am not aware of anything that will cause fatal problems. Time representation
might get a bit broken around the year 33000 or so, but I don't think anything
catastrophic will break. Years are just a 16 bit value with an offset of 1900. But very
few things even use it for anything, except printing it out. So signedness or not might
cause things to look funny depending on the code, but most software itself will not care.
Various subsystems will probably have issues long before then, like time stamps on files
will wrap, queue manager time handling will break/wrap, and of course DECnet time
representation can't deal with it. But the OS itself will probably just continue
chugging along, as will most software.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan
18, 2022, at 2:05 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
...
I wrote TIMET2 because I needed to know when to set a shutdown. If you don't do that
and you hit the uptime limit, then the machine simple crashes with an UP2LNG BUGHLT.
Oops. I know
that XKL fixed at least part of the uptime problem, but I don't remember what that
limit is. What are the limits for other systems?
It's not overly strange that
designers of mainframe systems, where planned shutdowns (say, for preventive maintenance)
were a regular occurrence) would overlook silly bugs like that. It feels like the sort of
thing that minicomputer software, especially real time systems, would never do. For
example, RSTS has no uptime limit.
1 p.m.
Yeah, I love that one too.
I'm sure it will break at some point, but I have not looked at it in
quite a while, so not sure exactly what the limits are there.
Probably might break around the year 4000. And I'm sure the moon phase
calculation will eventually get out of phase.
Johnny
On 2022-01-19 04:21, Mark Matlock wrote:
Johnny,
I got to wondering, on RSX, when in the future does my favorite Easter Egg break?
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
time /roman
Januarius XVIII, Anno Domini
MMXXII XXI:XVIII
The moon is waning gibbous. Today is Tuesday.
Happy New Year,
Mark
On Jan 18, 2022, at 1:26 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2022-01-18 20:15, Paul Koning wrote:
Ooops indeed. This is a bit of a surprising limitation in Tops-20 for me.
Neither have RSX. However, I do know that VMS have an uptime problem. Or rather a time
problem. Because of the way time is represented, everything will fail catastrophically
somewhere around the year 31000. VMS represents time as a signed quad. 100ns resolution,
and offset from 1858 (or whenever it was). Anyway, the important bit is that it is signed,
and it has to be positive.
Because negative time values are considered to be relative (delta) times. And so, when
the time actually wraps over, things will go totally bonkers in VMS.
Of course, other things will probably start causing problems long before then, like when
years start needing 5 digits...
With RSX, I am not aware of anything that will cause fatal problems. Time representation
might get a bit broken around the year 33000 or so, but I don't think anything
catastrophic will break. Years are just a 16 bit value with an offset of 1900. But very
few things even use it for anything, except printing it out. So signedness or not might
cause things to look funny depending on the code, but most software itself will not care.
Various subsystems will probably have issues long before then, like time stamps on files
will wrap, queue manager time handling will break/wrap, and of course DECnet time
representation can't deal with it. But the OS itself will probably just continue
chugging along, as will most software.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan
18, 2022, at 2:05 PM, Thomas DeBellis <tommytimesharing at gmail.com> wrote:
...
I wrote TIMET2 because I needed to know when to set a shutdown. If you don't do that
and you hit the uptime limit, then the machine simple crashes with an UP2LNG BUGHLT.
Oops. I know
that XKL fixed at least part of the uptime problem, but I don't remember what that
limit is. What are the limits for other systems?
It's not overly strange that
designers of mainframe systems, where planned shutdowns (say, for preventive maintenance)
were a regular occurrence) would overlook silly bugs like that. It feels like the sort of
thing that minicomputer software, especially real time systems, would never do. For
example, RSTS has no uptime limit. 
1:31 p.m.
Januarius XVIII isn?t strictly correct since days were reckoned relative to three keys
days in the month, so
Ante diem quattuordecimum kalendas februarius
Might be better.
On 19 Jan 2022, at 12:00, Johnny Billquist <bqt at
softjar.se> wrote:
?Yeah, I love that one too.
I'm sure it will break at some point, but I have not looked at it in quite a while,
so not sure exactly what the limits are there.
Probably might break around the year 4000. And I'm sure the moon phase calculation
will eventually get out of phase.
Johnny
On 2022-01-19 04:21, Mark Matlock wrote:
Johnny,
I got to wondering, on RSX, when in the future does my favorite Easter Egg break?
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol time /roman
Januarius XVIII, Anno Domini
MMXXII XXI:XVIII
The moon is waning gibbous. Today is Tuesday.
Happy New Year,
Mark
>> On Jan 18, 2022, at 1:26 PM, Johnny Billquist <bqt at softjar.se> wrote:
>
>
>
> On 2022-01-18 20:15, Paul Koning wrote:
>>> On Jan 18, 2022, at 2:05 PM, Thomas DeBellis <tommytimesharing at
gmail.com> wrote:
>>>
>>> ...
>>> I wrote TIMET2 because I needed to know when to set a shutdown. If you
don't do that and you hit the uptime limit, then the machine simple crashes with an
UP2LNG BUGHLT.
>> Oops.
>
> Ooops indeed. This is a bit of a surprising limitation in Tops-20 for me.
>
>>> I know that XKL fixed at least part of the uptime problem, but I don't
remember what that limit is. What are the limits for other systems?
>> It's not overly strange that designers of mainframe systems, where planned
shutdowns (say, for preventive maintenance) were a regular occurrence) would overlook
silly bugs like that. It feels like the sort of thing that minicomputer software,
especially real time systems, would never do. For example, RSTS has no uptime limit.
>
> Neither have RSX. However, I do know that VMS have an uptime problem. Or rather a
time problem. Because of the way time is represented, everything will fail
catastrophically somewhere around the year 31000. VMS represents time as a signed quad.
100ns resolution, and offset from 1858 (or whenever it was). Anyway, the important bit is
that it is signed, and it has to be positive.
> Because negative time values are considered to be relative (delta) times. And so,
when the time actually wraps over, things will go totally bonkers in VMS.
> Of course, other things will probably start causing problems long before then, like
when years start needing 5 digits...
>
> With RSX, I am not aware of anything that will cause fatal problems. Time
representation might get a bit broken around the year 33000 or so, but I don't think
anything catastrophic will break. Years are just a 16 bit value with an offset of 1900.
But very few things even use it for anything, except printing it out. So signedness or not
might cause things to look funny depending on the code, but most software itself will not
care.
>
> Various subsystems will probably have issues long before then, like time stamps on
files will wrap, queue manager time handling will break/wrap, and of course DECnet time
representation can't deal with it. But the OS itself will probably just continue
chugging along, as will most software.
>
> Johnny
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt at softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
1:54 p.m.
All RSX does is just a rewrite of the normal date with roman numerals
and texts. :-)
If you were to do proper roman dates, I guess you should also use the
Julian calendar, which would make things rather confusing...
Johnny
On 2022-01-19 13:31, Keith Halewood wrote:
Januarius XVIII isn?t strictly correct since days were
reckoned relative to three keys days in the month, so
Ante diem quattuordecimum kalendas februarius
Might be better.
> On 19 Jan 2022, at 12:00, Johnny Billquist <bqt at softjar.se> wrote:
>
> ?Yeah, I love that one too.
>
> I'm sure it will break at some point, but I have not looked at it in quite a
while, so not sure exactly what the limits are there.
>
> Probably might break around the year 4000. And I'm sure the moon phase
calculation will eventually get out of phase.
>
> Johnny
>
>> On 2022-01-19 04:21, Mark Matlock wrote:
>> Johnny,
>> I got to wondering, on RSX, when in the future does my favorite Easter Egg
break?
>>> time /roman
>> Januarius XVIII, Anno Domini MMXXII XXI:XVIII
>> The moon is waning gibbous. Today is Tuesday.
>> Happy New Year,
>> Mark
>>>> On Jan 18, 2022, at 1:26 PM, Johnny Billquist <bqt at softjar.se>
wrote:
>>>
>>>
>>>
>>> On 2022-01-18 20:15, Paul Koning wrote:
>>>>> On Jan 18, 2022, at 2:05 PM, Thomas DeBellis <tommytimesharing at
gmail.com> wrote:
>>>>>
>>>>> ...
>>>>> I wrote TIMET2 because I needed to know when to set a shutdown. If
you don't do that and you hit the uptime limit, then the machine simple crashes with
an UP2LNG BUGHLT.
>>>> Oops.
>>>
>>> Ooops indeed. This is a bit of a surprising limitation in Tops-20 for me.
>>>
>>>>> I know that XKL fixed at least part of the uptime problem, but I
don't remember what that limit is. What are the limits for other systems?
>>>> It's not overly strange that designers of mainframe systems, where
planned shutdowns (say, for preventive maintenance) were a regular occurrence) would
overlook silly bugs like that. It feels like the sort of thing that minicomputer
software, especially real time systems, would never do. For example, RSTS has no uptime
limit.
>>>
>>> Neither have RSX. However, I do know that VMS have an uptime problem. Or
rather a time problem. Because of the way time is represented, everything will fail
catastrophically somewhere around the year 31000. VMS represents time as a signed quad.
100ns resolution, and offset from 1858 (or whenever it was). Anyway, the important bit is
that it is signed, and it has to be positive.
>>> Because negative time values are considered to be relative (delta) times. And
so, when the time actually wraps over, things will go totally bonkers in VMS.
>>> Of course, other things will probably start causing problems long before
then, like when years start needing 5 digits...
>>>
>>> With RSX, I am not aware of anything that will cause fatal problems. Time
representation might get a bit broken around the year 33000 or so, but I don't think
anything catastrophic will break. Years are just a 16 bit value with an offset of 1900.
But very few things even use it for anything, except printing it out. So signedness or not
might cause things to look funny depending on the code, but most software itself will not
care.
>>>
>>> Various subsystems will probably have issues long before then, like time
stamps on files will wrap, queue manager time handling will break/wrap, and of course
DECnet time representation can't deal with it. But the OS itself will probably just
continue chugging along, as will most software.
>>>
>>> Johnny
>>>
>>> --
>>> Johnny Billquist || "I'm on a bus
>>> || on a psychedelic trip
>>> email: bqt at softjar.se || Reading murder books
>>> pdp is alive! || tryin' to stay hip" - B. Idol
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt at softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
848
days inactive
849
days old
12 comments
6 participants
participants (6)
-
bqt＠softjar.se -
Keith.Halewood＠pitbulluk.org -
mark＠matlockfamily.com -
mikekostersitz＠gmail.com -
paulkoning＠comcast.net -
tommytimesharing＠gmail.com