8 Mar
2020
8 Mar
'20
10:28 p.m.
The recent post about multi-threaded NNTP for VMS (whaaay cool) jogged
my memory about something I had been wondering about.? This morning, a
large number of clocks got switched ahead an hour in the United States.?
Tops-20 did it 'relatively flawlessly' as it has done so since the early
1980's.? Back then, a lot of systems didn't.? None of our IBM systems did.
A lot of that has changed nowadays with NTP clients; even if the base
operating system doesn't support time change, an NTP client can address
that.? So all my systems advanced appropriately, as did an old radio
clock.? I'm not sure how *nix does it, but I don't remember Ultrix
having the code on our 8650 (or 8700). Tops-20 will do the change
whether or not a client exists as the code is in the monitor.
At the time (1980's), I don't believe that VMS had internal code to do
the time change and NTP did not exist as such (some network time
services existed, but I don't remember whether there was a generally
available VMS TCP/IP package; we didn't have it).? I would assume that
this is handled now.? I hesitate to ask about RSX and RSTS, but I would
assume that the C compiler for RSX (with Johnny's TCP/IP interface)
could support an NTP port.? Anyway, the question is: how does VMS handle
the time change?
By 'relatively flawlessly', I mean Galaxy.? If you submit jobs with an
/AFTER: switch, but use an elapsed time, you can get the wrong start
time.? For example, in a daily batch job to do incremental saves,
TODAY+2:00:00 means tomorrow morning at 2:00:00 AM, assuming the current
job was started at 2:00:00.? However today, the job? started at 3:00:00
AM.? No big deal.
However, this used to seriously mess up our operations, who started
shift expecting requests for tape mounts. ? I looked at the issue awhile
back in the 80's, but realized that the problem wasn't in Quasar because
it is only dealing with internal date format.? The issue had to be fixed
by putting some logic into the Exec to differentiate between a specified
time and a calculated time.? As it wasn't immediately straightforward, I
never got to it.? Maybe one of these days...
8 Mar
8 Mar
10:37 p.m.
On 2020-03-08 22:28, Thomas DeBellis wrote:
The recent post about multi-threaded NNTP for VMS
(whaaay cool) jogged
my memory about something I had been wondering about.? This morning, a
large number of clocks got switched ahead an hour in the United States.
Tops-20 did it 'relatively flawlessly' as it has done so since the early
1980's.? Back then, a lot of systems didn't.? None of our IBM systems did.
Hehe... Always a problem...
A lot of that has changed nowadays with NTP clients;
even if the base
operating system doesn't support time change, an NTP client can address
that.? So all my systems advanced appropriately, as did an old radio
clock.? I'm not sure how *nix does it, but I don't remember Ultrix
having the code on our 8650 (or 8700). Tops-20 will do the change
whether or not a client exists as the code is in the monitor.
NTP does actually not solve this at all. NTP does all time in UTC. It's
up to the local machine to figure out if DST is applicable or not, and
how to apply it.
At the time (1980's), I don't believe that VMS
had internal code to do
the time change and NTP did not exist as such (some network time
services existed, but I don't remember whether there was a generally
available VMS TCP/IP package; we didn't have it).? I would assume that
this is handled now.? I hesitate to ask about RSX and RSTS, but I would
assume that the C compiler for RSX (with Johnny's TCP/IP interface)
could support an NTP port.? Anyway, the question is: how does VMS handle
the time change?
As far as I know, VMS still use local time. The TCP/IP package have some
handling of time zones and automatic DST. Exactly how it does it,
though, I don't know. I suspect it might change the system time.
In RSX, it's all local time, for sure. I do have an NTP client already.
I use a couple of logical names to tell what the offset from UTC is, and
NTP makes use of that. And then I have a batch job which runs twice a
year, at the time of the change between DST a not. And that batch job
then changes the logical name values, as well as change the clock.
My NTP client, by the way, is in fact written in C. But it is my own
implementation, and not something picked up from somewhere else.
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
11:42 p.m.
Got an NTP related question re: Multinet on OpenVMS.
The MultiNet Installation and Administrator's Guide describes the NTPDATE
utility:
"The NTPDATE utility sets the local date and time, by polling the NTP
servers given as the server
arguments, to determine the correct time." "The NTPDATE utility can be run
manually as necessary
to set the host clock, or it can be run from the system startup command
file to set the clock at boot time."
Is anyone using this utility? Seems like a good option...but NTPDATE.EXE
doesn't exist in
the Multinet program folders. No specific option in the installation
procedure, only
"* Do you want to install the TCP/IP applications [YES]? RETURN" which is
what was done.
Thanks,
Jason
11:43 p.m.
As far as I know, VMS still use local time.
VMS has had time zones and automatic daylight savings time adjustment since 7.3 or so.
Actually, when the name changed from VMS to OpenVMS it was because DEC made some
attempts to add Posix compatibility. That brought in a whole bunch of concepts, including
time zones. I believe that's also when we got STREAM-LF and STREAM-CR file
organization too.
Bob
9 Mar
9 Mar
1:53 a.m.
On 2020-03-08 23:43, Robert Armstrong wrote:
Are you sure about that?
I must admit I haven't looked beyond 7.3, since I usually play on VAXen,
but I seem to remember clear signs that time is internally still really
localtime.
Also interesting to note is that in a cluster, all machines must have
the same local time, same offset to UTC defined (TDC) and same timezone.
Which strongly suggests that things are not running on UTC.
But I do see that Alpha and Integrity servers have had some further
improvements compared to 7.3 on VAXen. At least changing to/from DST is
more automated.
And there are definitely logical names defined which tells the offset to
UTC, and what rules to use. But of course, that does not tell us for
sure if the time is actually kept in UTC or localtime. And VMS also
seems to like to use the batch system to change between DST and not, at
least on VAX with OpenVMS V7.3.
(Just reading some 8.4 manuals actually, but they do also contain
information about VAXen and 7.3.)
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
As far as I know, VMS still use local time.
VMS has had time zones and automatic daylight savings time adjustment since 7.3 or
so.
Actually, when the name changed from VMS to OpenVMS it was because DEC made some
attempts to add Posix compatibility. That brought in a whole bunch of concepts, including
time zones. I believe that's also when we got STREAM-LF and STREAM-CR file
organization too.
2:10 a.m.
I must admit I haven't looked beyond 7.3, since I
usually play on VAXen,
but I seem to remember clear signs that time is internally still really
localtime.
I never said that it wasn't Johnny. All I said was that a) VMS
automatically adjusts for daylight savings time, and b) VMS knows what time
zone it's in. Anything you inferred beyond that is your own issue.
LEGATO automatically adjusted for DST last night. I didn't touch a thing.
Bob
2:13 a.m.
On 2020-03-09 02:10, Robert Armstrong wrote:
But I never said it didn't, or couldn't adjust automatically. I just
said it was using local time internally.
I did also point out that there was some automatic handling of DST, as
well as some awareness of time zones in VMS... So it would appear we
were saying the same thing?
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
I must admit I
haven't looked beyond 7.3, since I usually play on VAXen,
but I seem to remember clear signs that time is internally still really
localtime.
I never said that it wasn't Johnny. All I said was that a) VMS
automatically adjusts for daylight savings time, and b) VMS knows what time
zone it's in. Anything you inferred beyond that is your own issue.
LEGATO automatically adjusted for DST last night. I didn't touch a thing.
2:11 a.m.
On 2020-03-09 01:53, Johnny Billquist wrote:
On 2020-03-08 23:43, Robert Armstrong wrote:
Are you sure about that?
I must admit I haven't looked beyond 7.3, since I usually play on VAXen,
but I seem to remember clear signs that time is internally still really
localtime.
Actually, looking at the 8.4 manuals, I would say it still keeps the
system on local time.
The $BINUTC system call, for example, which is used to get a UTC time,
states clearly in the manual that it applies the TDC factor to local
time in order to get the UTC time, while $BINTIM just says it gets the time.
Additionally, system calls like $SETIMR and $SCHDWK takes local time,
not UTC time, as the time when something is supposed to wake up or cause
something to happen. Which even more strongly points to that internally
VMS is at localtime.
But I'd be happy to be proven wrong.
By the way, Stream-LF and Stream-CR have been around longer than this, I
believe. Not sure when those first showed up. NFT in RSX certainly knows
about them, and have since the early 90s I think.
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
As far as I know, VMS still use local time.
?? VMS has had time zones and automatic daylight savings time
adjustment since 7.3 or so.
?? Actually, when the name changed from VMS to OpenVMS it was because
DEC made some attempts to add Posix compatibility.? That brought in a
whole bunch of concepts, including time zones.? I believe that's also
when we got STREAM-LF and STREAM-CR file organization too. 
2:41 a.m.
On 3/8/20 9:11 PM, Johnny Billquist wrote:
On 2020-03-09 01:53, Johnny Billquist wrote:
IIRC the stream-LF and stuff was in late 3.x and if I'm wrong it was in
before 4.2 when I left VMS work in Field Service.?? I often had files
going between Unix and VMS and I now it was available...
Interesting how Unix seems to have done the most with Timezone
handling.? My guess is it's because of the Bell Systems interest in
record keeping of CDR's (Call-Detail-Records) for phone billing per
minute charges or message units.? They probably kept the records in GMT
and just wrote the local time of call and length on the bills when
processing.
Does anyone know if the assumption is true?
Bill Pechter
On 2020-03-08 23:43, Robert Armstrong wrote:
Are you sure about that?
I must admit I haven't looked beyond 7.3, since I usually play on
VAXen, but I seem to remember clear signs that time is internally
still really localtime.
Actually, looking at the 8.4 manuals, I would say it still keeps the
system on local time.
The $BINUTC system call, for example, which is used to get a UTC time,
states clearly in the manual that it applies the TDC factor to local
time in order to get the UTC time, while $BINTIM just says it gets the
time.
Additionally, system calls like $SETIMR and $SCHDWK takes local time,
not UTC time, as the time when something is supposed to wake up or
cause something to happen. Which even more strongly points to that
internally VMS is at localtime.
But I'd be happy to be proven wrong.
By the way, Stream-LF and Stream-CR have been around longer than this,
I believe. Not sure when those first showed up. NFT in RSX certainly
knows about them, and have since the early 90s I think.
? Johnny
As far as I know, VMS still use local time.
?? VMS has had time zones and automatic daylight savings time
adjustment since 7.3 or so.
?? Actually, when the name changed from VMS to OpenVMS it was
because DEC made some attempts to add Posix compatibility. That
brought in a whole bunch of concepts, including time zones.? I
believe that's also when we got STREAM-LF and STREAM-CR file
organization too. 
11:40 a.m.
On Sun, Mar 8, 2020, 9:42 PM William Pechter <pechter at gmail.com> wrote:
[snip]
Interesting how Unix seems to have done the most with Timezone
handling. My guess is it's because of the Bell Systems interest in
record keeping of CDR's (Call-Detail-Records) for phone billing per
minute charges or message units. They probably kept the records in GMT
and just wrote the local time of call and length on the bills when
processing.
Does anyone know if the assumption is true?
I've never heard that before but I doubt it's true. Most of the interesting
timezone-related work on Unix was done outside of the labs. I think in the
research Unix days it was rather more primitive, and besides, that group
was not focused on telephone billing.
- Dan C.
8:17 p.m.
I agree with Dan.? I'm not aware of William's speculation being true and
I strongly suspect it isn't true, although the point about time
formatting might be.? I don't remember enough about parsing time to have
an informed opinion on Unix.
I first used Unix in the early winter of 1978 on a PDP-11/05 in WPI's CS
lab where I was an operator.? A C class was being taught by an early
Unix enthusiast.? We were impressed by certain things yet remained
underwhelmed.? The performance was less than compelling, some of the
facilities appeared primitive and the defaults for job control and
editing characters weren't anything like what we were used to.? Unix was
mostly never booted in favor of running RSX or RT.
I don't remember any particular special handling of time or date nor do
I recall the C library of the time having any support for the richness
that exists today.? Given the limitations of the machines of the time, a
significant portion of us couldn't understand why you wouldn't want to
use assembler.? For myself, I stuck with RT-11 on a PDP-11/40 in the
Mechanical Engineering lab (where I was also an operator).? The 11/40
was a far faster machine and it also had a GT40 on it.? Very nice.
I don't see how the Unix on any 11 of the time (pre-11/70) would have
had the storage or bandwidth to do the processing William is talking
about.? A careful examination of a Bell bill of time (to see how we
could reduce costs) led us to speculate that an IBM mainframe running
MVS was probably being used to do the billing. That would have been one
of the few systems around with the kind of capacity to handle the
datasets in question.
What's more likely has happened with respect to time formattong is
cross-fertilization.? Operating systems have lifted ideas from each other.
1. Sun OS, Linux and Windows took the memory mapped file paradigm from
TENEX/Tops-20.
2. Tab recognition for shells is right out of COMND% on Tops-20 (except
all native Tops-20 programs have it).
3. Tops-20 almost, but didn't quite have pipes and didn't have relative
directory specifications.? It now has pipes, but the relative
directory specification needs a buff and polish. That's clearly from
Unix.
4. Some good ideas have come from Multics, too.
With regards to time, as far as I am aware (meaning I don't know about
Multics), from its beginning, TENEX had the richest time handling.? The
time was stored internally as two 18 bit half words, the left half being
the elapsed dates since midnight-GMT November 17th, 1858 (this conforms
with (the Smithsonian Astronomical Date Standard).? The right halfword
is the number of seconds elapsed since midnight.? TENEX had a number of
JSYI to both parse, convert and print time using the local timezone.? It
also has a certain amount of code to handle daylight savings time and
has had it since at least 1971.
Tops-20 has certain improvements and minor changes.? Tops-20 has a table
to account for what year is being used in order to know when the start
and end of DST is (for example, double war time in WWII).? This was
either written by or improved by MRC in the 1980's and allows us to
handle the number of changes that happened to the legislated start and
end of DST over the years (particularly during the energy crisis of the
1970's).
There is an interesting incompatibility in internal formats.? It will be
noted that the number of seconds in a day can be stored in 17 bits,
whereas the right halfword is 18 bits.? DEC changed the internal format
for the elapsed time to be the binary fraction of 1/2**18, or about 1/3
of a second.? This allows for simpler arithmetic operations, which can
essentially be done on a 36 bit fixed point number.? Unfortunately, it
means that, when transferring special pages between TENEX and Tops-20
using FTP, you have to format the times in ASCII.? Tops-20 will run out
of time on 7-Aug-2576 19:59:59, a sad day indeed.
Having nicer time output just seems like a logical progression of nice
ideas.? It's hard to tell where Unix got it from.? I think it probably
showed up in the C library first, but I don't know why. It could have
been from Tops-20, but maybe VMS beat Unix to the punch and Unix got it
from there.? There was a certain amount of cross-fertilization between
Ultrix and Tops-20, less so between VMS and Tops-20, which is unfortunate.
------------------------------------------------------------------------
On 3/9/20 6:40 AM, Dan Cross wrote:
I've never heard that before but I doubt it's true. Most of the
interesting timezone-related work on Unix was done outside of the
labs. I think in the research Unix days it was rather more primitive,
and besides, that group was not focused on telephone billing.
? ? ? ? - Dan C.
------------------------------------------------------------------------
On Sun, Mar 8, 2020, 9:42 PM William Pechter <pechter at gmail.com
<mailto:pechter at gmail.com>> wrote:
Interesting how Unix seems to have done the most with Timezone
handling.? My guess is it's because of the Bell Systems interest
in record keeping of CDR's (Call-Detail-Records) for phone billing
per minute charges or message units.? They probably kept the
records in GMT and just wrote the local time of call and length on
the bills when processing.
Does anyone know if the assumption is true?
8:22 p.m.
On Mar 9, 2020, at 3:17 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
...
What's more likely has happened with respect to time formattong is
cross-fertilization. Operating systems have lifted ideas from each other.
... ? Tab recognition for shells is right out of COMND% on Tops-20 (except all native
Tops-20 programs have it).
I wonder if the CDC 6000 series console was an inspiration for that. It had some fairly
long commands, but it would autocomplete unconditionally, supplying the next character
whenever there was only one possibility at that point in the string.
So the command "check point system." would require only "che", the
software would supply the rest. Oh yes, and whenever the command was complete (CR allowed
at this point) the display would "ripple intensify", brightening every 4th
character in a ripple pattern.
All this was in NOS 1 and I'm pretty sure goes back a ways further, so to early 1970s
if not earlier.
paul
8:43 p.m.
Difficult to say; TENEX was put officially on the air on June 15, 1970.?
This is a year after the PDP-7 version of Unix was online in 1969.? The
PDP-11 C port was essentially complete in 1971.? The CDC 6600 proceeds
both by coming online in 1964.? NOS very well could have had it first.
TENEX's recognition based parsing was first only built into the EXEC.?
Tops-20 fully regularized this along with file name recognition in both
GTJFN% and COMND%.? To my knowledge, it is still the only platform where
this functionality is a system function and is available to all
programs.? In fact, the control fork of my extended mode FTP server uses
it to parse for RFC959 verbs.
As both the 6600 and TENEX were on the ARPAnet, it is completely
plausible that they cross-fertilized each other.? The 6600 was an
amazing machine; we were still studying the ground breaking architecture
in the 1980's; register score boarding and everything.? Wow.
When we moved off of Tops-20 to Ultrix, one of the first things we did
was to re-implement COMND% in C and you can see it in use in Columbia
C-MM (mail manager) program.? I don't believe the library was ever
generally released, which is a shame.? I think I still have a copy of it
/somewhere/.? Hmm...
------------------------------------------------------------------------
On 3/9/20 3:22 PM, Paul Koning wrote:
I wonder if the CDC 6000 series console was an inspiration for that. It had some fairly
long commands, but it would autocomplete unconditionally, supplying the next character
whenever there was only one possibility at that point in the string.
So the command "check point system." would require only "che", the
software would supply the rest. Oh yes, and whenever the command was complete (CR allowed
at this point) the display would "ripple intensify", brightening every 4th
character in a ripple pattern.
All this was in NOS 1 and I'm pretty sure goes back a ways further, so to early 1970s
if not earlier.
paul
> ------------------------------------------------------------------------
> On Mar 9, 2020, at 3:17 PM, Thomas DeBellis <tommytimesharing at gmail.com>
wrote:
>
> ...
> What's more likely has happened with respect to time formattong is
cross-fertilization. Operating systems have lifted ideas from each other.
>
> ... ? Tab recognition for shells is right out of COMND% on Tops-20 (except all native
Tops-20 programs have it).
8:35 p.m.
On 3/9/20 3:29 PM, Thomas DeBellis wrote:
Just curious, do you know what the time frame of the
7.3 release was?
> On 3/8/20 6:43 PM, Robert Armstrong wrote:
>
>> As far as I know, VMS still use local time.
> ?? VMS has had time zones and automatic daylight savings time
> adjustment since 7.3 or so.
> [snip]
>
> Bob
>
According to google:
http://h30266.www3.hpe.com/odl/vax/opsys/vmsos73/vmsos73/6637/6637pro.html
OpenVMS Version 7.3 Release Notes
*Order Number:*AA--QSBTD--TE
------------------------------------------------------------------------
April 2001
This manual describes changes to the software; installation, upgrade,
and compatibility information; new and existing software problems and
restrictions; and software and documentation corrections.
*Revision/Update Information:*This is a new manual.
*Software Version:*OpenVMS Alpha Version 7.3
OpenVMS VAX Version 7.3
8:48 p.m.
I see, that explains a (now out of date) comment in some of the Tops-20
source noting that VMS didn't have the DST functionality; it's from 1989.
I had imagined that VMS had finally gotten it, but had idly wondered why
the comment was never changed.
On 3/9/20 3:35 PM, William Pechter wrote:
On 3/9/20 3:29 PM, Thomas DeBellis wrote:
Just curious, do you know what the time frame of
the 7.3 release was?
> On 3/8/20 6:43 PM, Robert Armstrong wrote:
>
>> As far as I know, VMS still use local time.
> ?? VMS has had time zones and automatic daylight savings time
> adjustment since 7.3 or so.
> [snip]
>
> Bob
>
According to google:
http://h30266.www3.hpe.com/odl/vax/opsys/vmsos73/vmsos73/6637/6637pro.html
OpenVMS Version 7.3 Release Notes
*Order Number:*AA--QSBTD--TE
------------------------------------------------------------------------
April 2001
This manual describes changes to the software; installation, upgrade,
and compatibility information; new and existing software problems and
restrictions; and software and documentation corrections.
*Revision/Update Information:*This is a new manual.
*Software Version:*OpenVMS Alpha Version 7.3
OpenVMS VAX Version 7.3
8:29 p.m.
Yes, I've thought about it some more; you have to be right.
I had to do some research into Tops-20's internal date and time format
in order to do special pages right for FTP (see previous) and I went
back to the DAYTIME module in the monitor to see what's going on.? What
happens is that the internal date and time isn't changed at all; a table
triggers a formatting change to switch to Daylight Saving Time.? Given
what I knew about the EXEC, I should have remembered that.? Oh well.
It follows that this is what the C library is probably be doing.? If you
change the internal system time, then you can get either a gap or
overlap in accounting records which can drive billing systems crazy.
------------------------------------------------------------------------
On 3/8/20 5:37 PM, Johnny Billquist wrote:
NTP does actually not solve this at all. NTP does all time in UTC.
It's up to the local machine to figure out if DST is applicable or
not, and how to apply it.
> ------------------------------------------------------------------------
> On 2020-03-08 22:28, Thomas DeBellis wrote:
>
> A lot of that has changed nowadays with NTP clients; even if the base
> operating system doesn't support time change, an NTP client can
> address that.? So all my systems advanced appropriately, as did an
> old radio clock.? I'm not sure how *nix does it, but I don't remember
> Ultrix having the code on our 8650 (or 8700). Tops-20 will do the
> change whether or not a client exists as the code is in the monitor.
May I ask
what version of NTP do you support and do you handle
authenticated connections?? The 20 has an Internet time synchronization
program, but is quite primitive (the algorithm first being supported by
ITS).? I'm not dissatisfied enough to write my own NTP.? Yet...
------------------------------------------------------------------------
My NTP client, by the way, is in fact written in C. But it is my own
implementation, and not something picked up from somewhere else.
? Johnny
9:52 p.m.
On 2020-03-09 20:29, Thomas DeBellis wrote:
May I ask what version of NTP do you support and do
you handle
authenticated connections?? The 20 has an Internet time synchronization
program, but is quite primitive (the algorithm first being supported by
ITS).? I'm not dissatisfied enough to write my own NTP.? Yet...
Oh, I'm sure you are not going to be interested in my implementation.
First of all, it uses NTPv3. However, no, I don't care about
authenticated data.
And since RSX don't have anything equivalent of adjtime(), all I can do
is do hard changes, so I only adjust if the delta is becoming too big
(which in my case is lots of seconds). And since I have such lousy
requirements on precision, I also do not try to actually get a very
accurate time to start with. So it simply drags a timestamp out of an
NTP server, and then I set the time based on that.
It's very simple. But it's good enough for the things I want it for. :-)
It's about 200 lines of C in total. And that is with all the twiddling
of RSX.
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
12:32 a.m.
On Sun, Mar 8, 2020 at 5:29 PM Thomas DeBellis <tommytimesharing at gmail.com>
wrote:
[snip]
A lot of that has changed nowadays with NTP clients; even if the base
operating system doesn't support time change, an
NTP client can address
that. So all my systems advanced appropriately, as did an old radio
clock. I'm not sure how *nix does it, but I don't remember Ultrix
having the code on our 8650 (or 8700). Tops-20 will do the change
whether or not a client exists as the code is in the monitor.
Unix usually maintains time internally in UTC, and conversions into a
specific timezone are handled by a userspace library and configuration
files. That's obviously not how it was done historically (time would have
been manually set by some system administrator on early systems), but it's
how it's been done since the late 80s or early 90s. The upshot however, is
that "Unix" doesn't do anything, in the sense that the kernel doesn't
care;
processes that deal with time are data driven and handle time changes
internally.
- Dan C.
1532
days inactive
1533
days old
19 comments
7 participants
participants (7)
-
bob＠jfcl.com -
bqt＠softjar.se -
crossd＠gmail.com -
jrbrady65＠gmail.com -
paulkoning＠comcast.net -
pechter＠gmail.com -
tommytimesharing＠gmail.com