Date: Sun, 31 Jan 93 04:30:10 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #31
To: tcp-group-digest
TCP-Group Digest Sun, 31 Jan 93 Volume 93 : Issue 31
Today's Topics:
Domain Name Server ( DNS ) question
Ohio DNS updates
RDATE questions and comments
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Sat, 30 Jan 93 11:00:45 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: Domain Name Server ( DNS ) question
To: Jack Snodgrass <kf5mg@vnet.ibm.com>
If you are using the code that I wrote for KA9Q three years ago, there
are two kinds of entries.
1) an entry without a time-to-live can be added by hand, and is
"permanent" (until you change it). These gradually float to the
bottom of the file so that they can be superceded by dynamic
entries.
ray.lloyd.com. IN A 158.222.1.2
simtel20. IN CNAME wsmr-simtel20.army.mil.
2) an entry added automatically by KA9Q has a time-to-live field,
in seconds, which causes the entry to expire.
vela.acs.oakland.edu. 172593 IN A 141.210.10.2
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: Sun, 31 Jan 93 02:00:42 EST
From: ron@chaos.eng.wayne.edu (Ron Atkinson - N8FOW)
Subject: Ohio DNS updates
To: tcp-group@ucsd.edu
Could someone get hold of the Ohio TCP/IP coordinator and see about putting
in Ohio in the UCSD.EDU DNS server? I only have in a few *known* 24 hour
Northwest Ohio station in the Detroit hamgates DNS and just realized that I
can't find any Ohio stations from any other name servers.
Not sure if Windsor, Ontario is in there too, but if not maybe the
coordinator (isn't that you Barry?) can send that too?
Ron N8FOW
(Detroit can get to 44.70.16/24, slow, but kinda there. Will be
more reliable and quicker soon. Also a direct link to 44.135.83/24)
------------------------------
Date: Sat, 30 Jan 1993 11:38:50 -0600
From: miltonm@inetnode.austin.ibm.com (Milton Miller)
Subject: RDATE questions and comments
To: crompton@NADC.NAVY.MIL, tcp-group@ucsd.edu
The most likely reason for at commands triggering when they should not is
the bios time count moving backwards. When NOS detects the present value
is less than the previous value, it assumes a day has passed.
This is one of the problems observed with OS/2 VDMs. Aparently, the
time in low memory is not monotonic increasing at all times, resulting
in days being insterted. Mike Bilow (N1BEE) check that the time went
backwards by more than about 1/3 day before incrementing the day, but that
patch caused the system to ignore midnight rollover and crash quickly.
I used the same basic idea, except I (1) read upper, lower, upper
in a loop until the upper value was stable (instead of calling biostime
under os/2 and dpmi), and (2) ignore backwards time of <0x10000 ticks by
holding the existing time rather than moving the time backwards. This
seems to work better.
------------------------------
End of TCP-Group Digest V93 #31
******************************
******************************