
--------------------------------------------------------------------------
NOV-TIM1.DOC -- 19970610 -- Email thread on NetWare & Time Synchronization
--------------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




SYNC.NLM will sync a 3.x server to any other 3.x or 4.x server.  RDATE.NLM
will sync a server over tcp/ip to a Unix time reference standard like the
Naval Observatory or the NIST.  I set up a 4.1 server as my 'primary' time
server and run RDATE on it, and use SYNC to sync my 3.x servers to it.  Of
course all the other 4.1 servers also sync to the primary time server.

SYNC.NLM is available on Netwire at:
ftp.novell.com/netwire/novuser/07/sync.zip.

RDATE.NLM is available at:
risc.ua.edu/pub/network/misc/novell/rdate.zip.

if you don't have a direct ip connection between your server and the
Internet, there are many shareware/freeware programs available that download
the time via modem to your workstation and, if you are
supervisor-equivalent, will set the time on the server.

To use RDATE, you will also need some "magic numbers"...

192.5.41.40    tick.usno.navy.mil (Naval Observatory)
192.5.41.41    tock.usno.navy.mil
132.163.135.130     time-A.timefreq.bldrdoc.gov (NIST)

I did notice a small glitch  - if RDATE polls the Unix server at 23:59, it
briefly sets the time to 1978, then back to the correct time again on the
next poll.  One workaround is to load RDATE in the middle of the afternoon,
and set it to update only every 12 hours, so it won't ever update at
midnight.

BTW, a good URL for finding out all you ever wanted to know about time:
http://www.usno.navy.mil

Jim Rugh
jrugh@infosvcs.tmh.tmc.edu

------------------------------

Date: Wed, 15 Nov 1995 14:33:12 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: login restrictions

>The correct solution: change the server time.  When we clicked from
>PDT to PST, I logged into the server, ran FCONSOLE, went down, and
>adjusted the server time manually.  All time restrictions now work
>properly.
>
>Of course it would be nice if Netware did the UNIXism of handling
>the time changes on its own.  It does not, but the fix only needs
>to be implemented in one place and takes less than 1 minute/server.
>No big deal.

	No deal at all actually. My campus makes the changeover twice
per year with no human intervention and no trouble. How? Simple: use
Brad Clement's RDATE.NLM to synchronize to a local master time reference.
Let *that* machine deal with timezones and DST dates and whatnot, as
well as providing accurate time of day. We have several such local
standards, each touching three "stratum 1" national standards but as
overlapping sets. Rdate points to the local triad. This way we even
track "leap seconds" as they occur.
	RDATE is widely available so visit a Novell mirror site near
you (dir misc on netlab2.usu.edu).
	Here is a snapshot seen from my Unix machine, slaved to a local
triad plus falling back on the internal PC clock. xntpd does fancier
queries than rdate but the time is the same result.

$ ntpq
ntpq> lpeers
     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
+doober.usu.edu  time-A.timefreq  2 u  548 1024  377    -0.46   39.081   12.53
*watzit.usu.edu  norad-fix-e.arc  2 u  530 1024  377    -0.84   43.344   25.27
+thingy.usu.edu  tick.usno.navy.  2 u  673 1024  377    -0.41   55.241   48.51
 LOCAL(0)        LOCAL(0)        10 l   57   64  377     0.00    0.000   10.48
ntpq> q
$

>As a sidebar, Daylight Savings is not stable.  There is the proposed
>'new' daylight savings that will extend DST on one end.  A couple of
>years back we extended the spring start day forward.  Many UNIX machines
>still handle the switch using the old rules for when DST begins, so
>they need to be tweaked manually.  So there is no one set of rules a
>programmer can use to determine when DST starts/ends, since the rules
>keep changing.

	Here you are likely to stir up the UK/Oz folks on the matter of
politically correct dates. DST is not algorithmic, nor even rational.
	Joe D.

------------------------------

Date: Thu, 23 Nov 1995 12:44:08 +0000
From: "Mr. R. Coates" <roysan@LIVERPOOL.AC.UK>
Subject: Re: Setting the Time from a Work Station

>I have a routine that regularly dials the Naval Observatory for the
>correct time and updates the computer.  I do this from most of my work
>stations.
>
>I know that when first logging into my server the stations are set
>for the time of the server.  Can someone advise me of a way to set the
>server to the time of one of the stations that have just been fine tuned
>with the correct time?  Also, is there a way to get the time from the
>server without having to reload the vlm program.  This way I can use one
>station to call the Naval Observation.  Then this machine will set the
>server.  Then all the other work stations will get the correct time from
>the server.

setstime.exe can be used to set the server clock from a workstation.

	ftp://ftp.mechnet.liv.ac.uk/novell/freeware/setstime.zip

synctime.exe will force the pc clock to be updated from the server.

	ftp://ftp.mechnet.liv.ac.uk/novell/freeware/synctime.zip

Both are freeware.

---------

Date: Sat, 2 Dec 1995 16:47:44 +1300
From: J.Baird@ONO.LINCOLN.AC.NZ
Subject: Re: Q: NETX synchronising PC clock with server clock

>I just realized that NETX ( v3.32 (941122) ) is resetting our
>workstation clocks to match the server clock. We discovered the
>"problem" after some peoples workstations reported the clock was
>advancing an hour from the correct time after every reboot (the time
>on one of servers had not been reset at the daylight savings
>changeover).
>
>Here is the bizarre question: Any way to prevent this? Maybe a few of
>our users don't *want* their workstations synchronized with the server
>everyday.

You need to do two things to prevent this:

1. Place "set station time = off" in net.cfg
2. Place "set_time off" in the login script.

John Baird

------------------------------

Date: Fri, 9 Feb 1996 15:59:52 -0600
From: "Corey D. Stinson" <mucds@UXA.ECN.BGU.EDU>
Subject: Re: Atomic clock time synching

>Our primary 4.1 fileserver is a Single Reference time source. We need
>this server to be absolutley bang on with UK GMT+0000, and provide an
>accurate time source for our other primary and secondary servers. At
>the moment it is relying completely on its internal clock ( and me
>looking at my watch! :)

My company (W Clark & Associates, Ltd) makes just the product you need.
We have a time code generator (the GPS-100) which generates SMPTE time code
accurate to < 100us UK GMT (UTC) time.  We also have a PC 16-bit SMPTE time
code reader card which reads the SMPTE time code.  In addition we have an
NLM driver for the card to lock a primary server to the time source.

>I have heard people talk about synching with external time sources,
>but I have a couple of questions.
>
>1. Is the ability to synchronize a reference 4.1 server with an
>external atomic time source built into 4.1?

I don't believe that TIMESYNC.NLM knows anything about external time
sources.  If anytime, it might have the capability to dial-out to
get time from an external source but the Novell documentation makes
no mention of such features.

>2. Are there 'public domain' atomic time sources? Is there normally a
>charge?

The only thing I have seen in the public domain are the dial-out
programs mentioned above and they were not for a Novell fileserver
(although they might exist).

>3. Does anyone have a good source of information on the procedures for
>setting this up?

We have many clients already using our product to do just what you are
describing.  CBS Radio in NY is currently evaluating our system on
a mirroed 4.1 fileserver.

If you are interested in more information about our products, contact us!

W Clark & Associates, Ltd.
email: wmclark@cencom.net
phone: 309-837-2244
fax:   309-833-5175

------------------------------

Date: Fri, 1 Mar 1996 00:49:57 -0800
From: Marcus Williamson <71333.1665@COMPUSERVE.COM>
Subject: Re: cron for 4.10

>Any one have cron for 4.10? I know there was one for 3.12...

See TIMESG.TXT or TIMESG.HTM at :

http://ourworld.compuserve.com/homepages/marcus_williamson/

------------------------------

Date: Mon, 11 Mar 1996 12:38:10 -0600
From: David Kobbervig <DKOBBERV@MAIL.STATE.WI.US>
Subject: Re: setting time -nw4.1

>How does one set time correctly on 4.1 servers. I understand that
>changing time at the server console can be hazardous to NDS. Til now I
>have downed the servers and set ime at the computers BIOS, then bring
>up Novell...
>
>How does this work for SFT III 4.10. Do both engines have something to
>do with time determination?

Don't down your server to reset the time, use TIMESYNC. On your reference
time server type: (This is right out of Dynatext)

SET TIMESYNC Time Adjustment=[+|-] hour:minute:second at month/day/year
hour:minute:second [AM|PM] <Enter>

Eg,

  SET TIMESYNC Time Adjustment=-00:10:00 at 5/1/95 2:00:00 AM

Let it do it's thing at night while the servers are least busy since all
servers must synchronize.

------------------------------

Date: Thu, 21 Mar 1996 02:14:56 GMT+0001
From: "Szekeres Bela, Jr." <SZEKERES@EVT.BME.HU>
Subject: Re: Novell 4.1 timesync question

>We set up a 4.1 single server with a single time reference.  After it was
>installed we noticed that the date was set to August instead of March. One
>of our techs shut the machine down and adjusted the date in the BIOS.  Now
>it beeps at a regular interval and displays   synthetic time is being
>issued on partition "SERVER_NAME".  The date and time are correct, when it
>displays the time.  If you go into the BIOS and set the date back then try
>to use the SET TIMESYNC TIME ADJUSTMEMT =  to try to reync the time it
>comes back with  UNABLE TO SET TIMESYNC...

Your NDS contains time stamps referring to a future date.

Load dsrepair and select
  Advanced Options
    Replica and Partition Operations
      Repair Time Stamps and Declare a New Epoch

This will set all future time stamps to the current date and rebuild
the master replica. As you have a single server, you should be ok
with this.

I'm not quite sure what do you want to synchronise, as you have a
single server. It should be enough, if you change the date and time.

------------------------------

Date: Mon, 25 Mar 1996 15:42:23 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: RDATE

>There was a recent posting in which someone was having a problem with
>RDATE returning with a value greater than 3660. I cannot find the
>solution that was posted but was wondering if anyone else has come
>across this before. I have timezone set for CDT6 and it is loading
>before clib in the autoexec.ncf. I am loading RDATE with the
>following string:
>
>	LOAD RDATE /P 720 /V 10 146.138.1.178 146.138.4.10
>
>The time is always off by over 1 hour.
-----------
	The problem is most often with the machine doing the time serving.
Try telnet to port 13 (daytime) and see what it says in English, as the
first step to sorting out the muddle.
	Recall that NetWare seems to use the following algorithm when
parsing the timezone string:
	Find the digit, with optional sign, and consider that to be the
fundamental timezone. Positive means westward (opposite of good science).
If letters surround the digit then presume Daylight Saving Time can be
used. If no trailing letters then no DST. Notice that your string is
backward, CST6CDT would be a proper one. The letters are not understood
as other than placeholders.
	I trust not to the NW SET command so I supplement it by telling
CLIB explicity which TZ to use. Please see my example autoexec.ncf file
in the list's FAQ. Don't let something autoload CLIB before you can
give those command line arguments (CONLOG autoloads CLIB).
	Joe D.

------------------------------

Date: Tue, 26 Mar 1996 22:18:43 +0000
From: Chuck Foster <chuck@PIPEX.NET>
Subject: Re: Time Zones

>Also note that the correct time zone format for Pegasus Mail will
>be -0500 for your time zone.  I believe it is critical to enter it
>in this form; failure to do so will cause unpredictable sorting of
>incoming e-mail.

One should also note that using anything other that +hhmm or -hhmm could
well lead to mail being junked by some systems that analyse the date
field - this is especially important with RFC1327 gateways, like ourselves,
where X400 MTAs are far more fussy with date formats.

The most common problems I see coming through our MTA are:
	+-100   - seems to be quite popular
	+1      - very popular with David's Mercury it seems?
	+01:00  - the : shouldn't be there!
	+2500   - they must want the weekend to arrive earlier!

The other problem seems to be people not configuring Windows 95 properly
- we had a large breakout of PST's recently :-)

For general info, the Time Zones we currently recognise are below - note
the ambiguities, like BST!

	"B",    -200,
	"BST",  100,    /* British Summer Time, also Brasil Std Time (-300)
			   and Bering Strait Time (-1100) */
	"BT",   -1100,  /* Bering Time also Baghdad Time (+200) */
	"C",    -300,
	"CAT",  -1000,  /* Central Alaska Time */
	"CCT",  800,    /* China Coast Time, USSR Zone 7 */
	"CDT",  -500,
	"CET",  100,    /* Central European Time */
	"CST",  -600,   /* Central Std Time */
	"D",    -400,
	"E",    -500,
	"EDT",  -400,
	"EET",  200,    /* Eastern European Time, USSR Zone 1 */
	"EST",  -500,   /* Eastern Std Time */
	"F",    -600,
	"G",    -700,
	"GMT",  0,
	"GST",  1000,   /* Guam Std Time, USSR Zone 9 */
	"H",    -800,
	"HST",  -1030,  /* Hawaiian Std Time */
	"I",    -900,
	"IDLE", 1200,   /* International Date Line, East */
	"IDLW", -1200,  /* International Date Line, West */
	"IST",  530,    /* Indian Standard Time */
	"IT",   300,    /* Iran Time */
	"JST",  900,    /* Japan Std Time, USSR Zone 8 */
	"JT",   730,    /* Java Time */
	"K",    -1000,
	"L",    -1100,
	"M",    -1200,
	"MDT",  -600,
	"MESZ", 200,    /* Middle European Time Summer Time*/
	"MET DST", 200, /* Middle European Time Daylight saving time */
	"MET",  100,    /* Middle European Time */
	"METDST", 200,  /* Middle European Time Daylight saving time */
	"METZ", 200,    /* Middle European Time Summer Time*/
	"MEZ",  200,    /* Middle European Time Summer Time*/
	"MST",  -700,   /* Mountain Std Time */
	"MT",   830,    /* Moluccas Time */
	"N",    100,
	"NT",   -1100,  /* Nome Time */
	"NFT",        -330,   /* Newfoundland Time */
	"NST",  630,    /* North Sumatra Time */
	"NZT",  1130,   /* New Zealand Time */
	"O",    200,
	"P",    300,
	"PDT",  -700,
	"PST",  -800,   /* Paciific Std Time */
	"Q",    400,
	"R",    500,
	"S",    600,
	"SAST", 930,    /* South Australia Std Time */
	"SST",  700,    /* South Sumatra Time */
	"T",    700,
	"U",    800,
	"UT",   0,
	"UTC",  0,
	"V",    900,
	"W",    1000,
	"WAT",  -100,   /* West Africa Time */
	"WDT",  100,
	"WET",  0,      /* Western European Time */
	"X",    1100,
	"Y",    1200,
	"YST",  -900,   /* Yukon Std Time */
	"Z",    0,

The numbers are integers, based on 100 x hr + min.
Its also interesting to see the B-Z zones (no -0100 :-))

------------------------------

Date: Fri, 19 Apr 1996 08:50:05 GMT
From: Keith <kwyatt@FIX.NET>
Subject: Re: Time zone settings

>Hi, small problem with time zones, but first a question: Is it Internet
>std to set US Eastern TZ to -0400 when daylight savings kicks in?  GMT
>doesn't change does it?

All Users of ms-dos machine can solve this problem the following way!

Add this line to your autoexec.bat file and your worries are over!

     SET TZ= (Put the line below that matches your time zone):

For Los Angeles:  SET TZ=PST8PDT
For Denver:       SET TZ=MST7MDT
For Arizona:      SET TZ=MST7
   (Arizona never uses daylight savings time)
For Chicago:      SET TZ=CST6CDT
For New York:     SET TZ=EST5EDT
For London:       SET TZ=GMT0BST
For Amsterdam:    SET TZ=MET-1DST
For Moscow:       SET TZ=MSK-3MSD
For Aukland:      SET TZ=NZT-13

For Example I live in CA so I add the following line to
my autoexec.bat file.

SET TZ=PST8PDT

Now when the time changes my time zone is
automatically set.

------------------------------

Date: Thu, 23 May 1996 09:29:28 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: strange time/synchronization problems

>We're having some strange time/synchronization problems on our Netware
>4.1 servers. It all started when one of our servers started issuing
>synthetic time errors after it had lost its NDS partition and the NDS had
>to be reinstalled (yes, it was a nightmare). I tried the dsrepair's
>synchronize time option and it always reported success. I also checked
>the Report Time Synchronization and it reported success as well.
>
>To attempt to fix the synthetic time error, someone suggested using the
>advanced option "Repair time stamps and declare a new epoch". It sounded
>like a reasonable thing to do so I gave it a try. However, it failed with:
>
>	An error occured scheduling the operation, error number -621.
>
>Things now seem to be worse than before. When I now try to run Report
>Time Sync option, I get the following results:
>
>Netware 4.1 Directory Services Repair 4.35 , DS 4.89
>Log file for server "ACE.Academic.Acadia" in tree "ACADIA"
>Start:  Thursday, May 23, 1996   9:21:40 am Local Time
>Retrieve replica status
>
>Partition: [Root]
>  Replica: ADMIN.Admin.Acadia                  96/05/23 07:58:59
>    Server: CN=AXE.OU=Student.O=Acadia         96/05/23 09:21:37  -621
>    Remote
>  Replica: ACE.Academic.Acadia                 96/05/23 07:58:05
>    Server: CN=AXE.OU=Student.O=Acadia         96/05/23 09:20:54  -621
>    Remote
>  Replica: AXE.Student.Acadia                  96/05/23 07:58:24
>All servers synchronized up to time:           96/05/23 07:58:05
>
>Various other time sync operations also report this error -621. Does
>anyone have any ideas what might be going on?
>
>On a similar topic, or it may be related, there are several user objects
>in one context associated with server AXE that give the following error
>when I try to delete them:
>
>  Object <whatever>.student.acadia was not found. It has either been
>  deleted, or a rename, move or create operation on it is not complete or
>  has not been synchronized across all necessary replicas.
>
>Undoubtedly this error has something to do with the whole problem.
--------
	I'd suggest visiting each server in person, down it, set the Bios
time of day correctly, reboot. Once the underlying time system is rational
then the network time stuff stands a chance of working. You can widen the
catch basket of NDS time syncing via a console SET command.
	We presume your time distribution heirarchy is sensible. The top of
that time-tree should reference a very stable source, for which RDATE.NLM
will work fine to the outside world.
	Joe D.

---------

Date: Thu, 23 May 1996 08:53:36 -0800
From: Mark Schoonover <schoonom@CCMAIL.SGO.SONY.COM>
Subject: Re: strange time/synchronization problems

The -621 NDS error indicates that Transaction Tracking has been
disabled for the server on which NDS operations is taking place. Try
enabling TTS on the SYS volume, or possibly SYS is full so purge. Are
you able to login to the server?? If not, then run vrepair on the SYS
volume and select purge deleted files, then try enabling TTS. This may
explain why running dsrepair failed, since TTS is needed to modify the
database (NDS). If it is diabled, then any modifications to NDS won't
happen.

---------

-621 errors indicate that Transaction Tracking (TTS) is turned off on a
server. It appears from your error message that server AXE.Student.Acadia
is no longer supporting TTS. You need to type ENABLE TTS at the server
console to enable it. If it's turned off because of lack of space on the
SYS volume, you need to login and delete some files to make space.

Debbie Becker

---------

>We're having some strange time/synchronization problems on our Netware
>4.1 servers. It all started when one of our servers started issuing
>synthetic time errors after it had lost its NDS partition and the NDS had
>to be reinstalled (yes, it was a nightmare). I tried the dsrepair's
>synchronize time option and it always reported success. I also checked
>the Report Time Synchronization and it reported success as well.

Whenever you are working with NDS make *sure* the time on the envolved
fileservers is about right. Watching for timezone's etc. Use "time".
You can say NDS is somewhat timecritical. Why do you think you need
to have time synchronization?

Furthermore, NDS operations need time to complete.
So give it that time and don't issue synchronization operations one
after another.

And it can help if you start DSREPAIR on the server that is having
trouble. Don't look at the replicas on another server.

>To attempt to fix the synthetic time error, someone suggested using the
>advanced option "Repair time stamps and declare a new epoch". It sounded
>like a reasonable thing to do so I gave it a try. However, it failed with
>the
>       An error occured scheduling the operation, error number -621.
>Things now seem to be worse than before. When I now try to run Report
>Time Sync option, I get the following results:
>
>Netware 4.1 Directory Services Repair 4.35 , DS 4.89
>Log file for server "ACE.Academic.Acadia" in tree "ACADIA"
>Start:  Thursday, May 23, 1996   9:21:40 am Local Time
>Retrieve replica status

Isn't there a newer DSREPAIR version?

>Partition: [Root]
>  Replica: ADMIN.Admin.Acadia                  96/05/23 07:58:59
>    Server: CN=AXE.OU=Student.O=Acadia         96/05/23 09:21:37  -621
>    Remote
>  Replica: ACE.Academic.Acadia                 96/05/23 07:58:05
>    Server: CN=AXE.OU=Student.O=Acadia         96/05/23 09:20:54  -621
>    Remote
>  Replica: AXE.Student.Acadia                  96/05/23 07:58:24

Server object gone?

>All servers synchronized up to time:           96/05/23 07:58:05
>
>Various other time sync operations also report this error -621. Does
>anyone have any ideas what might be going on?
>
>On a similar topic, and ir may be related, there are several user objects
>in one context associated with server AXE that give the following error
>when I try to delete them:
>
>  Object <whatever>.student.acadia was not found. It has either been
>  deleted, or a rename, move or create operation on it is not complete or
>  has not been synchronized across all necessary replicas.

It's the last one.

>Undoubtedly this error has something to do with the whole problem.

Checking the time synchronization will only give you info on the
communication and the general time of the NDS database.
It will not show details on every single record within it.

Check that SET TIMESYNC DIRECTORY TREE MODE=OFF
if your network has more then one directory tree.

Get the newest DSREPAIR and other needed files/patches.
First check that the time is OK on every server.
Then make sure time synchronization is up and running on every server.
Then check that all servers have valid and confirmed server ID's
from eachother. Yes, visit them all.
Then do a local repair on the not responding server. Wait a while.
Check time synchronization again. If OK you can try synchronization again.

NDS is nothing more then a small database on each server.
Before you can synchronize between those databases you must first
make sure that the structure and recorded information within each
database is valid. Then if the time is synchronized you can
synchronize the databases.

As a very *drastic* and *final* option you could use:
LOAD INSTALL -DSREMOVE and get rid of the faulty NDS.
Then reinstall NDS on that server and built from scratch.
Just in case somehow your NDS is really messed.

Arthur B.

------------------------------

Date: Wed, 19 Jun 1996 06:00:00 CDT
From: Larry Dolinar <LARRYD@BLDG1.CROUTE.COM>
Subject: Re: SERVER WON'T KEEP ACCURATE TIME

>Our Server, an 'oldie', 486 DX33, running Novell 3.12, has never kept
>accurate time and seems to be getting worse! It loses at least an hour
>each week now. This causes problems with access times for some users.

PCs have never been great timekeepers: this topic has been knocked about
on the list, but not frequently.  Assuming you keep your Novell patches
reasonably up to date, are you using the SYNCTIME patch?  Rather moot if
your hardware clock is unreliable, though..

Are you on a TCP/IP network?  If so, do you have any unix hosts on it?
If yes to both, sync one of them to a reliable timesource (like
apple.com), and use RDATE.NLM to sync your server to it.

(excerpts from RDATE's README):

MurkWorks has provided this NLM to the Novell user community at no charge.

Purpose:
    The RDATE NLM allows the supervisor to synchronize the time
    of a Novell NW386 file server with the time of a nearby
    Unix host (or any other host which supports the time protocol).

Usage:

    load rdate  [/c] [/p nn] [/u] [/v nn] [/q] servername ...

    Where           Means

    /c          Just check the time and report the difference
		Does not set the file server time.
    /p nn           Continually poll the server every nn minutes
		and update the server time accordingly.
		The nlm may be unloaded with the UNLOAD
		command.
    /u          Use UDP instead of TCP
    /v nn           Don't change the server time unless the
		time difference is more than nn seconds.
    /q          Don't report when the time has been changed
		on the server.

    servername      The IP name or IP address of the host(s)
		running the time server, you may specify
		multiple servers.

    If the /p option is not used, the NLM unloads itself when it
    is done.

NOTE:
    You MUST set the timezone on the server before CLIB.LIB is loaded:

	set timezone EST5EDT

Check out (the) FTP archive on

    ftp.msen.com:pub/vendor/murkworks

------------------------------

Date: Thu, 20 Jun 1996 15:37:20 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NW4.1 Dial-Up to Time Sources?

>I have a customer with a NW4.1 network. They need time accuracy to
>+ or - 30 seconds. They do NOT have any Internet connectivity.
>
>I know I have seen dial-up time source products advertised in
>the trade rags, but looking through some old issues I can't
>find any right now.
>
>Is anyone using such a product who can give me company
>names. phone numbers and/or web page addresses?
--------------
	Bypassing the question of +/- 30 seconds with respect to nothing
else, the font of much timekeeping wisdom and software (NTP) is
louie.udel.edu. Think GPS receivers for the ultimate low cost solution.
A Unix PC to run xntp is cheaper than the receiver. WWV shortwave clocks
are available from Heath Co, dial up service to national timekeepers is
mentioned on louie too. Also see comp.protocols.ntp in NEWS.
	Joe D.

---------

Date: Sun, 23 Jun 1996 21:18:02 EDT
From: James E Borchart <James_E_Borchart@NOTES.SEAGATE.COM>
Subject: Re: NW4.1 Dial-Up to Time Sources?

The only problem with this solution is that there are *no* NTP clients for
NetWare Servers of any kind available anywhere.

------------------------------

Date: Thu, 15 Aug 1996 10:41:48 -0400
From: David Spigelman <dspigelm@ACP.ORG>
Subject: TimeSync via TCP/IP?

The US Naval Observatory has some of those absolute time clock
things. The time is available over the internet. I'm wondering if there's
any way to set THAT clock as our reference clock for NDS?

If you're interested, the web page is at:
http://tycho.usno.navy.mil/time.html

------------------------------

Date: Thu, 15 Aug 1996 16:55:57 MST
From: Christopher Diebold <cdiebold@CI.ENGLEWOOD.CO.US>
Subject: Re: RDATE and TIMESYNCH

>Read the FAQ, but still have questions.  We have 3 servers, 2 of them 4.1
>and a 3.12 (Communications).  Timesynch is active between the two 4.1
>servers (production and test).  We would like to be a bit better with
>keeping correct time (esp. before doc mngmnt).
>
>Appears that RDATE (from Murkworks) is for 3.x only, and the Timesynch
>is 4.1 only.  Can I load RDATE on the 3.12 server, have it be the
>Reference server, and THEN Timesynch between the 4.1 servers?  Or do
>I have it all wrong?

I am running rdate.nlm on a 4.1 server (the reference time server)
providing time to the other 4.1 servers (two primary and one secondary
time servers) without any problems.

------------------------------

Date: Fri, 16 Aug 1996 14:01:28 -0400
From: Greg Nyce <GNYCE@SKGF.COM>
Subject: U.S. Naval Obs. Time Clock IP Addresses

Here is an email that I received from the US. Naval Observatory a few days
ago...

HTH

___________

	U.S. NAVAL OBSERVATORY MASTER CLOCK NETWORK TIME SERVICES

	  See our Web pages: http://tycho.usno.navy.mil/ntp.html

EASTERN TIMEZONE

	The U.S. Naval Observatory operates two stratum 1 NTP  network
time servers located in Washington, DC, which are linked to the USNO
Master Clock
#1 (hydrogen maser):

	tick.usno.navy.mil      192.5.41.40
	tock.usno.navy.mil      192.5.41.41

	Operated jointly with the Massachusetts Institute of Technology:

	navobs1.mit.edu (tick.mit.edu)  18.145.0.30  (GPS)


MOUNTAIN TIMEZONE

   We also  operate two  stratum-1 servers from our alternate Master Clock
site  at Falcon AFB near Colorado Springs, CO.  These servers are linked
to the USNO
Alternate Master Clock (hydrogen maser):

	navobs1.usnogps.navy.mil   204.34.198.40 (CNAME tick.usnogps.navy.mil)
	navobs2.usnogps.navy.mil   204.34.198.41 (CNAME tock.usnogps.navy.mil)


CENTRAL TIMEZONE

    A USNO GPS network time server is now in operation at Washington
University, in St. Louis, Missouri. This is an open-access stratum-1 for the
Central Timezone:

	navobs1.wustl.edu       128.252.19.1 (CNAME tick.wustl.edu)


PACIFIC TIMEZONE

    A USNO GPS network time server is now in operation at Digital
Equipment
Corporation, Palo Alto, CA This is an open-access stratum-1 for the Pacific
Timezone:

	usno.pa-x.dec.com        204.123.2.72


These time servers are part of a Naval Observatory program to provide
accurate  and reliable network time servers at strategic locations across
the U.S.

Additional time servers will soon come on line in Los Angeles and Boston.
At present, access is unrestricted. WE STRONGLY RECOMMEND THAT
YOU CHOSE ONE OR MORE SERVERS CLOSE TO YOU, AND IN ADDITION SELECT OTHER
SERVERS FOR REDUNDANCY.


	You are invited to send questions or comments to:

Richard Schmidt, Time Service                   res@tuttle.usno.navy.mil
U.S. Naval Observatory, Wash., DC 20392         (202)-653-0487; Fax
653-0909

------------------------------

Date: Mon, 7 Oct 1996 14:12:22 -0400
From: Chris Brown <CBROWN@SEITZ.COM>
Subject: Re: Cadence Time Synching software

>Does anyone have any comments (good or bad) about using Cadence Time
>Synching software in a 3.12 environment?  Our need is for a package that
>will update the time on multiple servers for workstations that run time
>and attendance software.

Don't know anything about Cadence, but I'm really happy with our
solution (and it can be used in pieces);

1. We have one old clunkly AT class machine which is our time
standard. It uses TIMESET.EXE  to call NBS then uses S2S.EXE to set
the time on one of our servers (the time master). The call is done
once weekly.

2. A freeware program called SYNC.NLM  is used on the slave servers
to sync there times to the "time master" server.

3. A really great program called NOVSYNC.SYS is installed in each
workstation CONFIG.SYS. This program keeps the workstations in sync
with the server they are attached to.

4. Also, any time critical work with 3.12 servers requires the Novell
patch to fix the server's clock. That patch is included with the
latest patch file 312pt9 from Novell. Without the patch I've seen
servers drift over 30 minutes in one day.

------------------------------

Date: Mon, 7 Oct 1996 16:30:53 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Setting Time Zone (TZ) on Clients/Servers

>I haven't been as concerned as I probably should have regarding the
>setting of Time Zone SET parameters on my Servers and clients. I
>primarily run NetWare 3.12 Servers (though hope to move to 4.1x in the
>future). I primarily run NETX clients (though hope to move to Client 32 in
>the future).
>
>1) Should I set the TIMEZONE variable on all my 3.12 servers? Where is
>best - AUTOEXEC.NCF or STARTUP.NCF? Other?

	Please see the example autoexec.ncf file in the list's FAQ.

>2) Should I set the TZ variable on all my workstations? Where is best -
>System Login Script? AUTOEXEC.BAT? STARTNET.BAT? Other?

	Why? Workstations normally don't use it at all (DOS does not either).

>3) What is the syntax for setting the variable on the workstation? it the
>same as the for the Servers, e.g. SET TZ=EST5EDT?
	See 2) above
	Joe D.

------------------------------

Date: Fri, 11 Oct 1996 11:22:34 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: SYNCTIME.NLM

>can anyone please tell me how to use SYNCTIME.NLM (ver4.07 May 3
>1994), I would ideally like to sync our 3.11 & 3.12 servers to our
>NDS. I have only just come across this file (while checking through
>some recent downloads) & have no documentation whatsoever.
>
>We have 2 4.1 servers happily syncronized & I am assuming that there
>is some way to get the 3x servers sync'd as well.
>While we're about it my programming teams could do with a way sync to
>our HP unix, SCO unix, AIX & AS400 sytems!
------------
	I can't help with synctime since I've never had a reason to even
look at it.
	Recommendations:
	Use RDATE.NLM on your NW 3 servers. Point at site master time
keepers. Use RDATE.NLM on the top level NW 4 server, pointing to the same.
On the site master keepers run xntpd, Unix, to Internet standards sites.
See louie.udel.edu for xntpd; see netlab2.usu.edu, cd misc, for rdate.zip.
See NEWS group comp.protocols.ntp for xntpd discussions.
	Joe D.

------------------------------

Date: Fri, 11 Oct 1996 18:11:47 -0400
From: Chris Brown <CBROWN@SEITZ.COM>
Subject: Re: SYNCTIME.NLM

>Can anyone please tell me how to use SYNCTIME.NLM (ver4.07 May 3
>1994), I would ideally like to sync our 3.11 & 3.12 servers to our
>NDS. I have only just come across this file (while checking through
>some recent downloads) & have no documentation whatsoever.
>
>We have 2 4.1 servers happily syncronized & I am assuming that there
>is some way to get the 3x servers sync'd as well.

First off SYNCTIME.NLM  is not for synchronizing servers together. It
is a standard patch for ALL 3.11 /3.12 servers. It comes in the
standard patch file for servers 312pt9.exe it should be applied to
all servers. This NLM synchronizes the server's time keeping with the
crystal clock on the motherboard rather than the interrupt drive
clock which is very inaccurate.

To synchronize 3.12 servers together there is a great little
FREEware NLM called SYNC.NLM. I've just started using it. Got it
from the CompuServe NovUsers forum.

Here is information from the Novell patch file read me, and the
SYNC.NLM doc files;

SYNCTIME NLM
============

     SYMPTOM:

       The file server may gain or loose time, after a operating
       for a while.

     CAUSE:

       The FileServer time is by default taken from the software
       clock which is subject to lost timer ticks which may cause
       the server to loose time.

     SOLUTION:

     Apply SYNCTIME NLM         1,948  05-03-94  5:03p


       The  SYNCTIME.NLM file in the SYNC3XFT.EXE patch file causes
       the server to update its' time periodically from the
       hardware clock.

     Installation Instructions:

       1. Copy the SYNCTIME.NLM file to the SYSTEM directory or the
       NetWare boot directory.

       2. The appropriate PATCHMAN must first be loaded. (PM312.NLM
       of v3.11 PATCHMAN.NLM for 3.11 and PMIO311.NLM for 3.11
       SFT3).

       3  Then load the patch from the console for NetWare 3.11 and
       3.12 or from the IOENGINE screen for 3.11 SFT3 NetWare, by
       entering the following command:

	  LOAD SYNCTIME

       4. You may also load the file in the IOSTART.NCF for 3.11
       SFT3 or in the AUTOEXEC.NCF file for NetWare 3.11 and 3.12.


SYNC.NLM  -  NLM to synchronize network time   (v1.02 - Feb 94)
	     Freeware written by Wolfgang Schreiber

Usage:      'LOAD SYNC <time source> [/TZ=<time diff>] [/I=<min>]

Purpose:
    SYNC.NLM will check the specified time source server every 5
    minutes (default) and update the time of the local server. This
    guarantees synchronized time on the multi-server network.

Platforms:
    NetWare v3.x, v4.x

Operation:
    If the target server is not available or an invalid server name
    was specified, SYNC will continue to look for the target server
    every minute. It will continue normally after the connection was
    re-established.
    The same effect will occur if the target server does not have a
    free connection slot.  SYNC will retry until it gets a
    connection.

    If you mistyped the name of the time source server, simply
    unload SYNC and re-load it with the correct target name.

Prerequisites:
    SYNC.NLM runs on NetWare v3.12, or v4.0x.

    On NetWare v3.11 you must update your CLIB.NLM first (at least
    v3.11d is required). A current CLIB can be found on CompuServe
    as LIBUP1.EXE in NovLib or in 311UPD.EXE in NovFiles.

    The time source server can be any NetWare version (v2.x-v4.x)

Optional parameters:

/TZ=hh:mm              (Time Zones)
    The target server may be located in a different time zone.
    Specify the '[/TZ=time diff]' parameter in the 'LOAD SYNC ...'
    command then; the time difference is specified in +/- hours and
    minutes.
	The acceptable range is -23:59 to +23:59
	Sample values include:  "/TZ=+1"  "/TZ=-5"  "/TZ=-1:30"
    If you for example load SYNC.NLM on a server in San Francisco
    and want to synchronize with a server in Provo/Utah type:
	LOAD SYNC FS_Provo +1
    Synchronization over WAN links should only be used on fast links.

/I=<min>                (Synchronization Interval)
    By default SYNC will synchronize every 5 minutes if neccessary.
    This interval may be modified according to customer needs (e.g.
    to reduce NetWork traffic over WAN links). The sync interval
    must be specified in minutes.
	Sample values include:  "/I=10"  "/I=1"  "/I=600"


Examples:
    'LOAD SYNC NYC_Server'
    'LOAD SYNC ChiServ /TZ=2'        (local server 2h ahead)
    'LOAD SYNC NYC_Server /TZ=-2:30' (local server 2:30h behind)
    'LOAD SYNC SF_Main /I=60'        (synchronize every 60 min)
    'LOAD SYNC SF_Main /TZ=3 /I=60'  (server 3h ahead, check every
hour)


Program history:
    v1.00   Nov 93  First release on CompuServe
    v1.01   Dec 93  Added feature of time zones (released on Internet)
    v1.02   Feb 94  Added features: adjustable sync intervals;
		    time zones with fractions of hours accepted

------------------------------

Date: Wed, 30 Oct 1996 15:53:06 +0200
From: Thomas Anderssen <thanders@JEV.MULTI.FI>
Subject: Re: netware 4.1 atomic clock update

>I've just downloaded the rdate.NLM from the murkworks site but to my
>dismay there was no readme file. Does anyone have details on the
>requirements, installation and use of this item.

Here is a copy of a recent posting of mine. Hopes it can help.

>>>
I can report success with following PD programs used on our NW 4.1 (patched)
50 user server:

For Accurate timekeeping on NW server from a UNIX server (which in turn is
syncronized to various time servers on Internet):

LOAD RDATE /p 60  xxx.xxx.xxx.xx

One cutback; if you try to use UTP as indicated in the help screen (you get
that when loading RDATE without any parameters), the /c switch does not
work. My server time WAS updated, although I just wanted to check the
difference!!! Luckily the diff was only 117 sec:s... Can be potentially
dangerous if the Unix machine:s clock is wrong!  TCP protocol works as
indicated. You get help on the issue by typing RDATE alon on the console.

Downloaded from netlab2.usu.edu/misc/rdate.zip
Thanks for help to following repliers (no answer needed):

erik.cummings@santafe.cc.fl.us
jukka.kaipainen@edita.fi
rodney@vasquez.csd.sc.edu (indirect, supplied address)
<<<

---------

Date: Wed, 30 Oct 1996 12:42:30 MST
From: Christopher Diebold <cdiebold@CI.ENGLEWOOD.CO.US>
Subject: Re: netware 4.1 atomic clock update

Here's the RDATE.NLM readme...

This package contains an RDATE NLM for Novell Netware 386 (tm)

+-------------------------------------------------------------------+
|Permission is hereby granted for this archive to be distributed via|
|BBS, Compuserve, Anonymous FTP and any other means so long as no   |
|fee is charged for distribution and all components of this archive |
|remain together.						    |
+-------------------------------------------------------------------+

The RDATE NLM is Copyright (c) 1992,93 MurkWorks, Inc. All Rights
Reserved.

RDATE.NLM  - 11/23/93

** This is free software **

MurkWorks, Inc has provided this NLM to the Novell user community at no
charge.

Purpose:

The RDATE NLM allows the supervisor to synchronize the time
of a Novell NW386 file server with the time of a nearby
Unix host (or any other host which supports the time protocol).

Usage:

    load rdate  [/c] [/p nn] [/u] [/v nn] [/q] servername ...

	Where		Means

	/c		Just check the time and report the difference
			Does not set the file server time.

	/p nn		Continually poll the server every nn minutes
			and update the server time accordingly.

			The nlm may be unloaded with the UNLOAD command.

	/u		Use UDP instead of TCP

	/v nn		Don't change the server time unless the
			time difference is more than nn seconds.

	/m nn		Don't change the server time if the time
			difference is greater than nn seconds.
			(default is 3660 seconds).

	/q		Don't report when the time has been changed
			on the server.

	servername	The IP name or IP address of the host(s)
			running the time server, you may specify
			multiple servers.

If the /p option is not used, the NLM unloads itself when it is done.

Example:

    load rdate  /p 60 /q /v 1 timeserver1.domain.com timeserver2.domain.com

The RDATE NLM will poll the timeserver once every hour and
update the time if the server is off by more than 1 second.
A message will not appear on the screen when the time has
changed. (this example only)  If timeserver1 is unavailable
the NLM will ask timeserver2


NOTE:

You MUST set the timezone on the server BEFORE CLIB.LIB is loaded:

	set timezone EST5EDT

See the System Administration Manual for more information. If you do not
set the timezone, the RDATE NLM will set your server time incorrectly.

When using the TCP method of obtaining the time (default), the TCP
connection takes a LONG time to timeout if the remote host is down
(more than 15 minutes and still counting)  This appears to be a problem
with the TCPIP.NLM, since TCP connections should timeout quicker than
that.  If you expect your host(s) to be down at intervals, use UDP mode
instead of TCP mode and specify multiple servers on the command line.
UDP times out in a few seconds and moves onto the next server in the list
to get the time.

*------------------------ end of manual --------------------------------*

MurkWorks, Inc. develops and markets TCP/IP related NLMs for Novell
Netware 386. You may contact us at

	info@MurkWorks.com

	MurkWorks, Inc.
	PO Box 631
	Potsdam, NY 13676-0631

	315-265-4717
	315-268-9812 Fax

Write or call for the latest product information.

Check out our FTP archive on

	ftp.msen.com:pub/vendor/murkworks

------------------------------

Date: Thu, 7 Nov 1996 15:01:04 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Synthetic Time on Single Ref

>>>Anyone shed any light on why my Single Ref time sourced 4.10 server would
>>>issue synthetic time when all it's dependent on is the H/W clock???
>>----------
>>	What would you deduce? The OTHER SERVERS disagree on time.
>>How would one find out? After the standard rtfm advice, try dsrepair,
>>carefully.
>>	Joe D.
>
>All servers _do_ agree on time, dsrepair lists them as in synch as does a
>TIME command at each server.  RTFM would be nice if it wasn't on CD.  You'll
>be happy to know I am reading the DS info printed out from whichever text
>file is recommended reading on patlst.htm ...
---------
	Good man. What I would do next is shut down the master server and
observe its hardware clock value. See if it is very close to network time.
Repeat round the net once in a while to maintain consistency. Also, just
in case, tell each server to be a secondary pointing specifically at that
single standard server, to avoid stray boxes telling temporal fibs. Finally,
I've found that even single standard boxes will proclaim synthetic time if
they cannot NDS-sync to other servers (broken wire, all that jazz).
	I also sync the single time server to the real world via RDATE.NLM.
Thanks to great foresight by Novell you will have to backdate TCP*.NLM to
about Jan 96 to enable RDATE to run again. I do just that. What is needed
from Novell for over 3 years now is an NTP.NLM (network time protocol, IP
based) to avoid dependence on the crummy PC clocks. In my case RDATE goes
to local machines which are the local time standard and which are sync'd via
Unix version xntpd to national time standards.
	Btw, one can pull the docs onto a disk drive, if space is available.
A bound version of the interesting parts of the manuals, plus commentary, is
the oft-mentioned book "Novell's Guide to NetWare 4.1", Novell Press.
	Joe D.

------------------------------

Date: Fri, 8 Nov 1996 17:10:59 -0600
From: "Lindsay R. Johnson" <lrj5@IAONLINE.COM>
Subject: Re: Synthetic Time on Single Ref

ATTN: 4 Responses have been consolidated into a single thread here!

Situation:

2 NDS Trees with a total of 3 - 4.10 servers.  Live tree (SFMC_TREE) has
4.10 server set as type SINGLE reference.  Other 2 servers are set as
SECONDARY reference with their time source set to the SINGLE reference
server.  One of the SECONDARY servers is in the live tree, the other in the
R&D tree.  CONFIGURED SOURCES is set to ON on all 3 servers.  Therefore, the
SINGLE reference server gets its time from its internal hardware clock.
Error message received follows:

11-07-96  10:27:27am  DS - 5.1 - 12
	Severity=1   Locus=17   Class=19
	Synthetic Time is being issued on partition "SFMC_TREE"

The above-mentioned partition's Master Replica resides on the SINGLE
reference server.  It's R/W Replica resides on the SECONDARY reference
server in this same tree.  This error has not recurred to date (16:27 11/08/96).

Edited list discourse to-date:

>>>How would one find out? After the standard rtfm advice, try dsrepair,
>>>carefully.
>>>        Joe D.
>>>
>>
>>All servers _do_ agree on time, dsrepair lists them as in synch as does a
>>TIME command at each server.  RTFM would be nice if it wasn't on CD.  You'll
>>be happy to know I am reading the DS info printed out from whichever text
>>file is recommended reading on patlst.htm ...
>>
>>Lindsay
>---------
>        Good man. What I would do next is shut down the master server and
>observe its hardware clock value. See if it is very close to network time.

Server shutdown in our 24-hour, direct-patient-care network is not taken at
all lightly...

>Repeat round the net once in a while to maintain consistency. Also, just
>in case, tell each server to be a secondary pointing specifically at that
>single standard server, to avoid stray boxes telling temporal fibs. Finally,

Defined as above since deployment months ago...

>I've found that even single standard boxes will proclaim synthetic time if
>they cannot NDS-sync to other servers (broken wire, all that jazz).

Frame Relay between the SINGLE and SECONDARY in the same tree did not have a
problem at that time (it did "go away" for 28 minutes overnight last night
and the message has not recurred since the original message).

>        I also sync the single time server to the real world via RDATE.NLM.
>Thanks to great foresight by Novell you will have to backdate TCP*.NLM to
>about Jan 96 to enable RDATE to run again. I do just that. What is needed
>from Novell for over 3 years now is an NTP.NLM (network time protocol, IP
>based) to avoid dependence on the crummy PC clocks. In my case RDATE goes
>to local machines which are the local time standard and which are sync'd via
>Unix version xntpd to national time standards.

We haven't gotten there yet but we understand we can get the time straight
from our voice-line trunks from the telco.  It will be interesting to see if
it's feasible.

>Hi,
>
>Did you down the server to DOS and start it again without rebooting?
>Did you change the time settings? Does "TIME" display the correct
>time?

Again, downtime's NOT feasible unless there is a true outage.  While this
could escalate to there I'm working on alternatives!

>Two case :
>A change in the Hour occured voluntary : in this case you had to go on
>the server wich hold the Master Replica for each replica that stored
>this Server. Use Dsrepair.NLM, advanced options, Replica & partion
>option, select the replica,  choose Repair Time Stamps and declare a
>new epoch
>Second case : the hour change unvunlontary : so the first procedure
>will solve the problem but you have to find the cause and perhaps set
>up an external clock

I'll tuck this one away - it is the procedure I figured I should try should
I need to start in NDS.  With no additional Synthetic Time messages I'll let
sleeping dogs lie for now.  And, yes, we will be implementing a dependable
external time source - just a matter of when!

>Synthetic time actually has nothing to do with time synchronization.  When a
>server gives a synthetic time message, it means that an object in the NDS
>has a creation/modification date/time that is in the future.  This could
>happen if someone logged in with the date set in the future and then changed
>something in the NDS.  The error will go away when the present date is equal
>to or greater than the date that was used to modify the NDS.  There's a
>pretty good article explaining how to fix it on http://support.novell.com,
>use the Search option and search for Synthetic Time.  I think you can use
>one of the Advanced Options in DSRepair to fix it.  The article has step by
>step instructions.
>
>Jason Lester
>Washington County Schools

Jason - I think you've hit on my most likely scenario.  I understood it had
to do with stamping in the NDS but it didn't make sense until you mentioned
someone changing something in the NDS.  If I'm not mistaken, Last Login date
and time hit the NDS at login for each station.  If a station is not
configured to get it's time from the server this seems inevitable!  This
sounds like a liability to NDS at first blush!  I assume this information
comes from the server itself, though.  Counting on station info for this
seems like an auditing/accounting/security risk.  Most likely is one of my
(very few) administrators' clock is slipping, or is not configured to get
it's time from the server.  This would be easy enough to replicate I would
think.  I'll give this a shot on our R&D tree.

Thanks all for your input!  Any more discussion is quite welcome!  I'll post
progress as I am able.

Regards,

Lindsay

------------------------------

Date: Thu, 14 Nov 1996 09:39:58 -0500
From: Craig Lyndes <CRAIG@CVUMAIL.CVU.CSSD.K12.VT.US>
Subject: SOLVED!  New Epoch creates 100% utilization -Reply

I thought I would share this solution, and warning, with the list.

Repair time stamps and declare a new epoch (DSREPAIR) apparently is
very processor and resource intensive.  The Novell Tech that finally
talked me through the repair said it can create problems in partitions
that otherwise appear to be fine.

When doing directory and partition operations Transaction Tracking
System (TTS) must be active or everything comes to a halt.

What had happened to me is while doing the new epoch, TTS had run out
of resources (64 Megs RAM in an 8 GIG 250 User 4.1 - Joe, could this be
where Novell comes up with their rather excessive memory requirements?)
and shut down.  No matter how long I waited nothing was going to
happen.  When I powered off I corrupted the DS databases on that server
so bad that whenever they were loaded the server would go into an infinite
loop.

The repair then became, deleting that replica and the DS databases on
that server and recreating them without losing any objects' attributes, a
$200.00 Novell call with the tech using lots of undocumented switches and
commands.

The solution for next time, whenever TTS shuts down or you get -621
errors in dstrace, restart TTS.  It will finish what it was working on and
go after the problem again.  This may have to be repeated.  I also upped
the server RAM to 128 Megs.

------------------------------

Date: Thu, 14 Nov 1996 17:25:05 -0600
From: "Lindsay R. Johnson" <lrj5@IAONLINE.COM>
Subject: Re: Password Problems

>I took a look and this and it said ALL PROCESSED =YES but it only shows
>my 4.1 servers. Does this mean it is not seeing the 3.x servers.
>
>>At 02:49 PM 11/13/96 -0800, you wrote:
>>>I have several servers in my system and I am having problem when it
>>>comes time for users to change their passwords. I am currently in the
>>>process of taking all of the servers to 4.1 but I still have several on
>>>3.11 and 3.12. We are logging in as bindery objects. What happens is
>>>that it may or may not recognize the changes. I had one person I had to
>>>run syscon to change their password. It seems I cannot go a day without
>>>users who have problems that the system is not seeing the change they
>>>made the day before to thier password. I have users with this problem
>>>running win 3.1 and Win 95. Any help would be great.
>
>>>Sounds like your timesync for NDS is off.  Remember NDS is still >>operating
>>>even though you're running bindery emulation.  SET DSTRACE=ON so you >>can
>>>have a screen to view and do a SET DSTRACE=*H to verify it all returns >>an
>>>ALL PROCESSED=YES.  You can also do DSREPAIR and select Time
>>Synchronization
>>>to see if all are synched.  I'm sure other 4.x people with more NDS >>time
>>>than I might have other, better suggestions...
>
>>Lindsay

Your 3.x servers use neither timesync nor NDS.  Updates with SYSCON on those
servers should be working for those servers.  It's the 4.x servers that
should be presenting the problem.

Updates to NDS include timestamping.  If the servers disagree on time an
update can be lost.  It was happening to me just as you mentioned in your
original post.  Changed passwords wouldn't take.  A remote server's time
reference was not properly defined.  Be sure you have your time references
setup so all can agree on the time.  We have a SINGLE reference server (FS4)
and all the other 4.10 servers are SECONDARY reference servers who have
their TIME SOURCE defined as the SINGLE reference server.  Ours is only one
example of how timesync can be defined in a 4.10 net.  You can check this on
your servers by using the SET command:

SET TIMESYNC TIME SOURCE

will tell you who the server is referencing for it's time

SET TIMESYNC TYPE

will tell you which type of time reference is defined for the current server

You can just type in SET and select Time (option 9) and read all the current
settings on your 4.x server.

If this seems new/alien I'd suggest you break open your manuals immediately
and learn about timesync as it's essential to NDS operation.  As all the
changes that take place in your network get recorded the information must go
to all replicas of your partitions.  Each change has a timestamp.  If a
receiving server is not in sync time-wise your results are unpredictable.

Again, I'll ask for other, more lucid explanations from those here who know
the subject well.  Also, this is only my impression of what your problem
likely is.

Again, hope this helps!  Unfortunately, bindery emulation doesn't mean we
can ignore NDS issues.

------------------------------

Date: Sun, 17 Nov 1996 01:53:46 GMT
From: Paul Lees <P.R.Lees@SUNS.SALFORD.AC.UK>
Subject: Re: "Synthetic time"

Information from Novell TID2909011.

Synthetic time is issued when you have objects in your tree that
have been time stamped with a future date and time.  This most
often occurs when the time on your NetWare 4.x tree has been set
to the future and then back again to the correct time.  Any
change to the NDS database while time is set to the future will
cause a future time stamp to be added to the object changed.
Changes include user login, password change, object creation,
etc.  Once the time and date are corrected on the server, NDS
detects that there are values in the NDS database that have been
stamped with future times.  This is when synthetic time is
issued.

To fix it;

1. Make sure time is correct and in sync.
2. Make sure the replica in question is synchronising.
   ("All processed = Yes" from DSTrace on all servers in the ring)
3. Load DSRepair from any server in the replica ring.
4. Choose "Advanced options menu".
5. Choose "Replica and partition operations".
6. Highlight the Partition indicating a synthetic time
   error and press Enter.
7. Choose "Repair time stamps and declare a new epoch".
8. Login as Admin or Equivalent.

------------------------------

Date: Wed, 4 Dec 1996 12:52:27 +0100
From: "Niels Chr Nielsen, 5551" <niels.c.nielsen@RISOE.DK>
Subject: Re: FTPD and RDATE. Works...

>For Accurate timekeeping on NW server from a UNIX server (which in
>turn is syncronized to various time servers on Internet):
>
>	LOAD RDATE /p 60  xxx.xxx.xxx.xx
>
> One cutback; if you try to use UTP as indicated in the help screen
>(you get that when loading RDATE without any parameters), the /c
>switch does not work. My server time WAS updated, although I just
>wanted to check the difference!!! Luckily the diff was only 117
>sec:s... Can be potentially dangerous if the Unix machine:s clock
>is wrong!  TCP protocol works as indicated.
>
> Downloaded from netlab2.usu.edu/misc/rdate.zip

RDATE (v1,20) is very particular with the order of switches, so while

	RDATE /u /c xxx.xxx.xxx.xxx

only checks and reports time on the remote server,

	RDATE /c /u xxx.xxx.xxx.xxx

disregards the "/c" and sets the time on the local server.  Btw, by
default RDATE will not change the local server time if the difference
between local and remote time is greater than 3660 sec (ie. 1 hour 1 minute).

------------------------------

Date: Tue, 17 Dec 1996 12:10:59 EST
From: Philip Chase <pbc@VPHA.HEALTH.UFL.EDU>
Subject: Re: Synthetic Time is being issued on partition "XXX"

>Currently, I just installed a new NW server 4.11, there are two hardisks
>with two volumes. Immediately I reboot the PC and up the server, the
>server console keep on coming out the error message : <Synthetic Time is
>being issued on partition "XXX">. What's worng with this ? How do i solve
>this problem ??

You have an error in your time configuration--most likely you have specified
your server to be the wrong type of time server for the tree it is in.  Not
knowing what your tree is like, I have to say, read this section in the
Netware 4.1x documentation.

Many people have found this document useful when planning time
configurations, though it may be more than you need:

	http://www.circa.ufl.edu/netware/timesync.html

------------------------------

Date: Mon, 13 Jan 1997 17:39:35 +1300
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: Incorrect Time Restrictions on NW Admin Running on NT 4.0

>I have noticed in both Windows NT 3.51 and 4.0 workstation that NW Admin
>does not show correctly the login time restrictions.  Under Windows 95 I
>show the login time restriction as being from 12am to 4am Sun to Sat
>which is correct.  If I pull the same account on NW Admin running on NT
>workstation then the time is 5 hrs off (5am to 9am).  I have tried other
>NT machines and noticed the same effect.  The clock on all PCs are
>correct.  Any ideas as to why this occurs?

Login time restrictions are stored in NDS in UTC or GMT and are adjusted
to local time by nwadmin when displayed. Local time is determined from
a TZ variable if set (or maybe from the operating system for NT - I'm not
sure here), otherwise the server's UTC offset is used. The header above
indicates your message was sent from a machine with a GMT offset of
+0000 when it probably should be -0500 (Syracuse being up the coast from
Atlanta if my geography is correct). Assuming this is the same NT machine
on which you are running NWADMIN, it won't be coincidence that your time
restrictions show as 5 hrs out when your GMT offset is 5 hrs out!

------------------------------

Date: Wed, 22 Jan 1997 23:38:53 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@bgu.edu
Subject: Re: CHRON.NLM?

>I have to run an ARCServe database repair which will take a long
>time (at least eight hours), and want to kick it off over the
>weekend.  Does anyone know of an .NLM job / command scheduler
>(preferrably free or shareware)?

I know of five products and of them there are three I could recommend
without hating myself in the morning.

Podell Systems makes Console Manager for NetWare that is a console
enhancemer that includes task scheduling.  It is about $500.00,
but as far as I know they are not on the net.  They are on
Compu$erve, and evanuation copies may be available there.  Try "GO
PODELL".   Podell's system looks so much like a Windows interface,
you'll be reaching for your mouse.  Quite stable.

Avanti Systems makes TaskMaster, an NLM that enhances the console and
comes with a DOS and Windows client.  It offers task scheduling and
extends the console by adding a number of commands.  Avanti's system
is more of a command line junkies wet-dream.  Also quite stable.
They have an excellent web site at http://www.avanti-tech.com/ that
is worth a visit - lots of good tech tips there.  It's also abotu
$500.

Snap-In Tools offers AutoAttendent for about $100.  It's an NLM and a
NWAdmin extension that offers scheduling and a bit more.  While it is
very stable, the user interface is tortorous.  Still, once a
recurring job is set up, it shouldn't be a problem.  They are on the
net at http://www.snap-in.com/, and eval copies are available.  While
cheaper than the previous two products and no less stable, I prefer
both of them.  Trying to extend NWAdmin has painted them into a
corner, and the result is not entirely pleasant.

As to the other two.....

One is a free scheduler that a French Novell employee let out.
Sadly, it abends servers.  It may still be floating around, but I've
put its name out of my memory.  I had hopes for it once.  <g>

Also, there is the Citadel Phantom of the Console.  It earned the
nickname "Phantom Abender" in a Compu$erve forum, and was less than
delightful in my own testing.

------------------------------

Date: Wed, 5 Feb 1997 14:29:42 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Problem with SYSTIME utility

>I administer a Netware 4.10 network.  I have noticed recently that
>the SYSTIME utility reports the correct date but the incorrect day.
>(e.g. invoking SYSTIME on Feb 5 returns the following:
>
>"Current system time:  Tuesday 2/05/97 1:57:33 pm")
>
>It is 2/05/97 but it's Wednesday!  This also affects our mail
>program (Pegasus), with messages reporting the wrong day.
>
>If you type TIME at the server console, the day and date are correct.

>I have applied all of the patches recommended by Novell for NW 4.1.
----------
	Check the Timezone settings on the server. Remember to Set Time
Zone = foo7bar before loading anything in autoexec.ncf.
	Joe D.

------------------------------

Date: Thu, 6 Feb 1997 09:38:06 -0600
From: Paul Rhoads <prhoads@MAIL.STATE.MO.US>
Subject: Re: Time Servers

>We currently have 2 servers on our wan designated as primary time
>references.  We're going to be evaluating software (Cadence v2.51) to
>automatically adjust the server times, and they require the server it's
>installed on to be a reference time server.  What, if any implication or
>impact will it have changing one server from primary to reference?  We
>made 2 primary servers so our wan would poll/average to resolve the
>network time.

The only difference is that instead of averaging their time, the Primary
server(s) will adjust their time to the Reference server if they can find
it, which is what you  bought Cadence for, I guess.

By the way, are you using configured time source lists, or SAPing it? I
would use a configured time source list over the WAN, and turn off SAP.

------------------------------

Date: Thu, 20 Feb 1997 17:56:33 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Time sync on netware 4.1

>>	In any case, relying on PC clocks is a bad joke. Preferrable and
>>free is RDATE.NLM which can talk to a reliable "real machine" on site to
>>obtain true time.
>>	Joe D.
>
>Anybody seen any sign of a updated RDATE.NLM  which works with TCPIP.NLM
>newer than 5.0? (Going to update to NW 4.11 next week... Needs time sync.)

Specify the command-line option to use UDP rather than TCP.
that works. In a NW4 environment I'd only load RDATE on the reference time
servers; timesync is important enough that you don't want them disagreeing
too much, and if everything is synced then you don't need it on all
servers.

------------------------------

Date: Sat, 22 Feb 1997 01:03:57 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: RDATE2 options on Netware 3.11 and 4.11

>I recently updated our rdate.nlm setup with rdate2.nlm and I'm
>getting the following message on the console.
>
> :RDATE2.NLM spurious time response
>
>Which I understand to mean that it didn't take.

Basically it means that rdate2 got a response from your time server more
than 5 seconds after the request was sent, and hence the packet may have
been in the network some timeand it won't rely upon it for the time

The NLM is still loaded, and if it gets speedy responses will use them.

>RDATE.NLM version 1.00 Copyright (c) 1993 University of Salford

Don't the years go quick! I can't belive I wrote it that long ago.

I've not updated the source for a long time, mainly because we now use
Brad Clements / Murkworks on our servers. rdate2 was originally written as
a programming exercise by me, and to give UDp support which was missing
from RDATE at the time I think. RDATE would unload off our 3.x servers
without warning and time would start to drift.

With NW4.x, as long as the time sync is working we only need to check the
master/ reference servers.

------------------------------

Date: Thu, 6 Mar 1997 08:49:01 +0800
From: Brett Looney <BLooney@COMTECH.COM.AU>
Subject: Re: DOS clock stopped ?

>I boot to  DOS and set  time with 'time'  command to, say,  10:40.
>Then  I start  the server  with 'server.exe'.  TIME command  in NW
>shows the proper time. When the server runs for some time (say one
>hour) I check time  again and it shows 11:40 - OK.  The I down the
>server,  type EXIT  to go  back to  DOS and  enter the  'time' DOS
>command -  it shows 10:41 !  After reset the computer  is rebooted
>and the  DOS time is  correct again (i.e.  about 11:42) !  (So the
>BIOS seems to keep the correct time).
>
>Is  this behaviour  normal ?  Is  it  a hardware  problem ?  Is is
>a problem of patched server.exe ? Is it a problem at all ?

This behaviour is normal. This is what is happening:

One of the things DOS does is update its internal clock. It does this by
hooking into the timer interrupt (which happens 18.2 times a second) and
from that it increments internal counters. Every time you start DOS it
reads its time from the CMOS clock which keeps time all by itself (hence is
more accurate).

When you start NetWare, it basically throws DOS away, so that no interrupts
that DOS was listening to get serviced by DOS because it isn't running at
all! So, the clock stops, and when you DOWN and EXIT from NetWare the clock
starts up where it left off.

Now, if you restart a Single Reference 4.x server WITHOUT rebooting or
resetting the time/date in DOS, then it will start with the wrong time and
bad things will happen. In fact, Novell say this is their course material,
and I think (not sure - dim memory of this) somewhere in the red books.

------------------------------

Date: Wed, 5 Mar 1997 18:34:56 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: NTP (Network Time Protocol) client available for NetWare servers

	Thanks to the sharp eyes of Michael Setzer we have available
an NTP client for NW servers. I'll explain in a moment. Here's Michael's
message to me. Good on you Michael.

>>>>>
I just downloaded this program from Compuserve, but it available
at this site. It is suppose to be a SNTP Client for Novell 4.

	http://www.neatech.ch/sntpclnt/

Michael D. Setzer II -  Computer Science Instructor
<<<<<
	So what's NTP? It's Network Time Protocol using TCP/IP to query
NTP time serving machines across the Internet (or even just on site). It is
widely used in the Unix and VMS communities to keep clocks aligned to small
fractions of a second, and reliably too by sampling more than one time
source. The font of all NTP wisdom is David Mills at the Univ of Delaware,
see louie.udel.edu, dig into xntpd. Xntpd deals with mere clients as well
as the whole range of external GPS and radio clocks (in sophisticated ways)
but that program is not for NetWare.
	I loaded up the above sntpclnt on an INW 4.11 machine this afternoon
and it has run fine for these several hours. I unloaded RDATE first.
	This item is free folks, and supposedly runs on NW 3 and NW 4.
Side effects, if any, are not known here. Please report problems to the
author, and let the list readership know too.
	I pointed sntpclnt.nlm at our three site master time servers
(stratum 2 in NTP-speak) and they in turn point at several national time
servers (stratum 1, can't be more authorative than that). The INW 4.11
server is setup as a SINGLE time object, and other NW 4 servers point to
it as SECONDARY time objects. Sntpclnt queries the local standards once
every 10 minutes in my setup, and each probe is just a few packets.
	Joe D.

------------------------------

Date: Thu, 6 Mar 1997 12:21:47 -0500
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: DOS clock stopped ?

>The BIOS clock is derived
>from programmable counter interrupt occuring approx. 18 times a second=20
>(does anybody know why such terrible frequency was choosen?

... because the IBM PC had an Intel 8088 processor, running at 4.77MHz.  18.2
hardware timer interrupts per second was as much as it would reasonably
process.  It makes a nice round number of 0x1800B0 ticks in an day.

>and why it was not divided by more suitable divisor to get ms or 10 ms
>resolution?) and is kept in BIOS data area (4 bytes (and 1 bit) 40:xxH).

Suitable for whom?  This number is perfectly suitable for an operating system.
If I were an OS, I'd worry about keeping track of time for my own sake, not a
programmer who can't make a machine divide by 0x1800B0, or call BIOS function
1A instead of using the equivalent of a "peek."

... and given the capabilities of the original hardware, 10ms resolution
wasn't really viable.

------------------------------

Date: Thu, 6 Mar 1997 20:26:24 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DOS clock stopped ?

>>... because the IBM PC had an Intel 8088 processor, running at 4.77MHz.
>>18.2 hardware timer interrupts per second was as much as it would
>>reasonably process.  It makes a nice round number of 0x1800B0 ticks in
>>an day.
>
>Actually, approx. 18.2 is the number you get when you divide 65536 by 3600
>65536 being the wrap around point for 16 bit numbers (nice size for
>an 808[68] register) and 3600 being the number of seconds in an hour.
>So, when our handy 16 bit counting register overflows, we know that
>it's the next hour. The counting code also compenstates for the fact
>that 18.2 times a second is hard to get exactly right.
>
>But, you still get drift because it isn't quite 18.2 times a second...
-----------
	EE fans may wish to delve back into their PC hardware books to
discover the el cheapo 14.318 MHz crytstal which is the source of such
timing information. It is that frequency to divide down to TV video
values, not to make a pretty time of day counter. A 1.193182MHz pulse
rate divided by 2^16 isn't a nice clock rate. See your 8254 spec sheets.
	Many EE fans will note cheap crystals are cheap for a reason:
accuracy of about 1 part in 10^5, high drift rate, and very temperature
dependent. Worse even that wrist watch crystals.
	Sharp system managers will recall my message this week about the
sntpclnt.nlm NTP program for NW servers to sample stable clocks via TCP/IP.
	Those with time on their hands may wish to visit alt.comp.folklore
or comp.protocols.ntp NEWS groups, or any other place but here.
	Joe D.

------------------------------

Date: Fri, 7 Mar 1997 11:31:31 +0800
From: Brett Looney <BLooney@COMTECH.COM.AU>
Subject: Re: DOS clock stopped ?

>>Now, if you restart a Single Reference 4.x server WITHOUT rebooting or
>>resetting the time/date in DOS, then it will start with the wrong time
>>and bad things will happen. In fact, Novell say this is their course
>>material, and I think (not sure - dim memory of this) somewhere in the
>>red books.
>
>I always thought that it was standard procedure to, instead of setting
>TIME at the DOS prompt, to use the SET TIME command (or some form of that
>command) on a Single Reference server in 4.x, so long as that server was
>the only server in the network.
>
>If memory serves me correct, if this time server was a reference server
>for others, you would end up with synthetic time on the rest of the
>servers in that network until all the servers in the network were synced
>in time with the Single Reference Server..

Mostly right but of course there are things that the course material
doesn't mention that you learn by accident (hopefully not bad ones...)
later on.

Firstly, yes you can set the time on a Single Reference server by doing
"SET TIME" and yes, this is the preferred method. But when you start the
server it reads the time from the DOS clock. So, if the DOS clock is right
no problems. If the DOS clock is wrong then we have a problem, and one
reason it could be wrong is the situation under discussion.

Secondly, this will still work even if that server is not the only server
on the network - but only if all the oether servers in the network are
Secondary - meaning they listen to the Single Reference server as the
authoritative source of time. (To all you other people out there, yes I
know this is a simplification - there are lots of other ways to do this...
:-)  )

The reason you get synthetic time is this: DS has a time stamp for
everything. If it finds a time stamp that is _later_ than the current time,
it has a problem. Older version of NetWare (4.0x) wouldn't let you update
DS when this happened, because something was obviously wrong with the
timestamping mechanism. 4.1x issues synthetic time which is where it will
let you update things, but it fudges the time stamps. Synthetic time will
last until we fix the problem in DSREPAIR or we catch up to the time stamp
that is wrong. This could obviously take a long time if you've set the date
forward to, say, 2010, and then set it back to 1997.

If I set the time on my server back I will get synthetic time until either
I catch up to "now", or I set the time back to "now".

------------------------------

Date: Fri, 7 Mar 1997 15:01:10 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NTP (Network Time Protocol) client available for NW servers

>>Joe,
>>
>>So what does it offer above RDATE?
>>
><cut Joe D.'s post about the NTP client>
>
>I asked that same question at the download site and here is the
>response I got:
>
>>Basically the SNTP uses a much more sophisticated system to provide
>>network time, than RDATE can. But this brings only advantages when
>>you run a SNTP server as well, since they have a synchronisation
>>sheme, who has about the same features as the NW 4.x timeservers have
>>between each others.
------------
	No, not really. NTP is a fancy network time protocol, for sure,
and one of the RFCs is in the package. But you do NOT have to run an NTP
server. In fact, have only three local standards machines, each slaved to
different national standards, and read time from the locals. If you lack
the locals then go to the nationals or whatever directly.
	The whole idea is to use the Internet as a source of time servers,
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and to do so accurately. The Internet in this case can be local machines,
if you wish, or far away, or both. Be considerate of bandwidth and machine
loading.
	Before hanging on to someone else's machine please get their
permission. I strongly recommend reading NEWS group comp.protocols.ntp
to get an idea what is going on and where standards sites are located.
NTP is the de facto precision time keeping mechanism for "real machines",
including the better Unix boxes. PC motherboard clocks have always been a
joke as time keepers.
	RDATE is used to get the clock to roughly the right time (say within
seconds); use it as a one-shot at server startup and ensure it is unloaded
before starting SNTPCLNT. Recall that NetWare 4 no longer bothers keeping
DOS time current (sigh, I do wish they would stop that).
	Some of us have been pressuring Novell to have NTP built into NW 4,
for all the obvious reasons (see "joke" above). Amongst other tiny worries,
NDS comes alive and talking before the TCP/IP stack loads, which can disrupt
a network with false time. Rumors say they might look into it.
	Joe D.

	Folks, I do recommend doing the background reading on the subject
because it is useful professionally. The main docs are RFCs, such as 2030
and 1769, available from many places including netlab1.usu.edu and
netlab2.usu.edu.

------------------------------

Date: Thu, 20 Mar 1997 18:14:56 +0100
From: "David W. Hanson" <hansond@AFRC.GARMISCH.ARMY.MIL>
Subject: Re: NTP settings poll interval

>I am setting a Netware 4.11 reference server to an atomic clock
>on the Internet.  What would be the best poll interval for this
>application? I was thinking something like a poll every hour,
>but I am interested in your comments.

It depends on how fast your server clock drifts and how accurate
your server time -needs- to be.  With RDATE.NLM, you have two
settings, frequency of polling and time offset before fixing the
time.

You only need to poll about twice in the time it takes for your
clock to drift by the offset amount.  More than that is excessive,
and wastes the resources of the system you are synching to.

The important thing for NDS is that the servers are synched to each
other, which NetWare's time synchronization takes care of, so
polling frequency depends on how accurate you need your server time
to be.

Note that the workstation time only gets set from the server when the
workstation connects, so unless individuals are connecting and
disconnecting very frequently, workstation clock drift will introduce
further error at the workstation.  Twice a day should serve the
purpose at most sites (YMMV).

------------------------------

Date: Mon, 24 Mar 1997 11:53:03 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: RDATE

>>Any suggestions?
>
>Yes to go http://www.neatech.ch/sntpclnt/ and get teh SNTPCLNT
>NLM for your version of Netware. It is an rdate and rdate2
>replacement.  Works like charm here (on v3.11, 4.10 and 4.11)
-----------
	No, don't go there.
	As we have stated many times now, use RDATE /U blah to employ
UDP rather than TCP.

	SNTPCLNT is a disaster at this moment on NW 4. It will clobber
your time synchronization. I discarded it after about a zillion console
beeps about loss of sync. This is too bad and I hope the authors, who
have a broken email contact, will learn how to tame it.
	Joe D.

------------------------------

Date: Mon, 24 Mar 1997 20:58:44 -0500
From: Kipp Stephenson <kstephenson@UTSE.SMATNET.NET>
Subject: Re: NOVELL Digest - 24 Mar 1997 - Special issue

>>Yes to go http://www.neatech.ch/sntpclnt/ and get teh SNTPCLNT
>>NLM for your version of Netware. It is an rdate and rdate2
>>replacement.  Works like charm here (on v3.11, 4.10 and 4.11)
>-----------
>	No, don't go there.
>	As we have stated many times now, use RDATE /U blah to employ
>UDP rather than TCP.
>
>	SNTPCLNT is a disaster at this moment on NW 4. It will clobber
>your time synchronization. I discarded it after about a zillion console
>beeps about loss of sync. This is too bad and I hope the authors, who
>have a broken email contact, will learn how to tame it.
>	Joe D.

For Joe D. and the rest of the list I post the following message from the
developer of sntpclnt in case you did not receive it:

>After receiving considerable feedback I have take some time to look
>at most problems.
>
>Look at the new 0.17 version of sntpclnt located at
>
>http://www.neatech.ch/sntpclnt
>
>On compuserve you can find it in the NOVUSER forum.
>
>Here the highlights of this version:
>
> - A statistic screen who tells you what is going on <vbg>
> - You can use a logfile
> - Better integration with NW 4.x
>
>Andre.

---------

Date: Mon, 24 Mar 1997 19:40:28 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NOVELL Digest - 24 Mar 1997 - Special issue

[replying to the above email...]
---------
	Let's be clear about this.
	First, I have in fact referred to just that 0.17 version as being
unsafe.
	Second, I would love to have a working NTP time keeper.
	Third, the author's email address bounced my traffic, so they have
trouble with that too.
	Fourth, it is apparent that sntpclnt does not correct the hardware
clock because it continues to show a nearly constant "offset". And the
unfortunate .htm files which masquerade as documentation do not come to grips
with explaining just what this program does accomplish.
	Fifth, it does not run on NW 3.12. Undefined symbols is the problem.
	Sixth, it does run on NW 4.11, but it causes major time disruption
and the tree loses time synchronization. This indicates to me the authors
have not properly dealt with matching NTP measurements to NDS timekeeping
and that is the very core of the task.
	Seventh, not to look gift horses in the mouth, but the program
needs much discipline about talking to the screen/log file at length.

	Taken together I commend the authors for tackling a difficult job,
but simultaneously I must say the program needs much work before it can
be safely employed in a production environment. Further, we need to know what
the program is trying to accomplish.
	Joe D.

------------------------------

Date: Sun, 6 Apr 1997 14:14:33 -0600
From: John Bezy <JBezy@HCI-OMAHA.COM>
Subject: A CLM (Career Limiting Move)....

We got a call from one of our clients Friday morning about 9am.
They (and they wouldn't define who the 'they' was...) had set
the time on their NetFrame (running NetWare v4.02) forward to
the year 2000, and (big surprise) no one could log in....
Besides the fact they had expired all the users accounts, they
caused havoc with their NDS.  They even had no idea how to fix it.
The solution was to use the DS option 'reset time stamps to current
date and declare a new epoch', but was difficult to find.  That
option is now part of the DSREPAIR utility, under the Advanced
Options.  For the older version of NetWare, it was part of the
Partition Manager tool in NWadmin...  But running that option
fixed their problems.  Short story- don't test the Year 2000
issue on your production server just as the work day starts!!

------------------------------

Date: Tue, 22 Apr 1997 17:20:17 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: Time + Time Zone's on a 4.1 Server

>I've just spent the last few hours sorting out a "  Synthetic Time is
>being issued on partition blah" problem. A big thank you to the FAQ and
>it's contributors for the solution. Now when I type time at the console
>prompt, I get the following response from my 4.1 server.
>
>EMIS:time
>  Time zone string: "GMT+0100"
>  DST status:  OFF
>  DST start:   not set
>  DST end:     not set
>  Time synchronization is active.
>  Time is synchronized to the network.
>Sunday, April 27, 1997   1:11:50 am UTC
>Tuesday, April 22, 1997   9:11:50 pm GMT
>
>The correct date and time are on the bottom. This is the only 4.1 server
>on the network. If I set the time-zone to UTC, then both lines read
>the same, that of the correct time and date! The time and date in the bios
>are the same as the bottom line, ie, Tuesday, . . . . . .
>
>My question is where does the line "Sunday, April 27, 1997   1:11:50 am
>UTC" come from ??????.

It's your local time plus 100 hours, just like you set it.  You meant to do
that, right?

>Is GMT not a valid time zone for Novell. My reading tells me UTC and GMT
>are one and the same. Has the acryomn GMT been replaced by UTC ??

They're functionally the same.  GMT is a time zone, UTC is a time value.  The
time in the GMT zone equals the value of UTC.

You might consider setting your time zone to "GMT+1".

------------------------------

Date: Thu, 24 Apr 1997 09:31:00 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Netware Time Sync.

>Recently I have been reading through my backlog of messages from this
>group.  While reading the messages, a number of members have been
>discussing the concepts of updating the Netware Server's time from the
>Internet (via SNTPCLNT.NLM or RDATE.NLM).

	Just a word at this point. Use RDATE rather than SNTPCLNT because
the latter is very much in need of redesign to work properly. I've
corresponded with the authors.

>This is ok is your network is connected directly to the internet but
>my network is not!
>
>Does anyone know of an NLM that will emulate a NTP server so that this
>can produce a time source locally on the network?
>
>I know that Netware 4 looks after this but I have 15 Netware 3.12
>servers all over the UK and the company isn't prepared to upgrade at
>this stage.

	NW 3.12 doesn't need to be timesync'd closely. Just use an accurate
watch to get them started. To obtain national standards time you can look
into a Unix machine and a GBH or similar pulse per second radio clock. The
software on the Unix machine is xntpd, from louie.udel.edu.
	Joe D.

------------------------------

Date: Sat, 26 Apr 1997 08:13:06 -0400
From: Lance Candia <indylmc@IN.NET>
Subject: Re: 4.11 Time Sync Plan

>>We are in the process of planning to change our existing WAN (36 -
>>3.12 Novell Servers) over to Netware 4.11, we gave a server at every
>>campus in the school district.  My questions is that we would like to
>>have an outside time source for our time sync plan.  does anyone know
>>what? where? how? I can find out the specifics of implementing this.
>>Is it a good idea?  What do you need?  Any information that you  have
>>would be greatly appreciated.
>
>I recommend that you obtain a copy of the Novell Press publication "The
>Four Principals of NDS Design."  It goes into time synchronization on a
>NW4.x network in detail as well as desiging your NDS tree.
>
>It would be a good idea to follow the book's recommendation and set up a
>time provider group and set up your remote servers to obtain their time
>from one of the provider group servers. This is all explained in the book.
>
>As far as a time source for your network is concerned check out Polygon
>Inc.'s Cadence NLM. It works very well and can be configured to operate
>with several types of reference sources. These can be dial-in to a time
>source like the Naval Observatory or any number of external clocks with
>a serial port and receive time via LF (60KHz) HF (3MHz-30MHz) WWV
>broadcasts or satellite sources, whatever. Very flexible.

You also might consider the following:

http://www.novell.com:80/nwc/oct.96/timeo6/index.html

------------------------------

Date: Mon, 28 Apr 1997 10:46:43 PST
From: Kevin Miller <kevinm@UHS.BERKELEY.EDU>
Subject: Re: Time Changes on a 4.11 Server

>We have 6 local Novell 4.1 servers (3 IntranetWare) and 3 Remote Servers
>(4.1, WAN is frame relay).  One of the local servers is setup as the
>Single Reference time source, the rest get their times from it.  It is
>about 10 minutes fast. What is the best way to adjust the time back?

Aside from the time problem, this is seems like a bad way to set up
your time sync.  You would probably be better off (as far as WAN
bandwidth) with a configuration like this:


    Primary Time Server    ------ WAN ------   Primary Time Server
	 /   \                                       /   \
       /       \                                   /       \
Secondary   Secondary                      Secondary   Secondary

With this configuration, you would have only the Primary time servers
communicating across the WAN.  With your configuration, you have all
three remote servers going across the WAN.

------------------------------

Date: Mon, 28 Apr 1997 19:30:40 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Time Changes on a 4.11 Server

>We have 6 local Novell 4.1 servers (3 IntranetWare) and 3 Remote Servers
>(4.1 , Wan is frame relay).  One of the local servers is setup as the Single
>Reference time source, the rest get their times from it.  It is about 10
>minutes fast.  What is the best way to adjust the time back?
---------
	Reset the time a little, use DSREPAIR to declare a new epoch.
Wait for NDS to fully settle down, wait some more. Repeat until on time.
Then go to netlab2.usu.edu, cd misc, and get rdate.zip. That will talk
over the Internet to stable time servers and control your Single time
server. Basically NW should never have relied upon the crummy clock
found on PC motherboards, but the customer is always right.
	Joe D.

---------

Date: Tue, 29 Apr 1997 13:43:32 -0700
From: Richard Bahcic <Richard.Bahcic@T-ONLINE.DE>
Subject: Re: Time Changes on a 4.11 Server

>>We have 6 local Novell 4.1 servers (3 IntranetWare) and 3 Remote Servers
>>(4.1 , Wan is frame relay).  One of the local servers is setup as the Single
>>Reference time source, the rest get their times from it.  It is about 10
>>minutes fast.  What is the best way to adjust the time back?
>	Reset the time a little, use DSREPAIR to declare a new epoch.
>Wait for NDS to fully settle down, wait some more. Repeat until on time.
<snip>
>	Joe D.

Joe,

I have learned that the *right* way should be the following set-command
at the fileserver-console of a Single- or a Reference- (or aPrimary-)
TimeServer:
   "set timesync time adjustment = -00:10:00 [[at] [date'n time]]"
or "set timesync time adjustment = -00.10.00" (languagespecific?)
or use the SERVMAN Server-utility.

Then the Time-Providers would all at once adjust their time at the same
point in time (basic default is 1h after issuing the 'time adjustment')

------------------------------

Date: Fri, 23 May 1997 11:57:50 +0800
From: Brett Looney <BLooney@COMTECH.COM.AU>
Subject: Re: (Q) Stop server setting workstation time?

>How do i stop my NetWare 3.12 server setting the workstations
>date & time ?  I know it can be done by adding something to the
>net.cfg, but i want to be able to do this globally.

The problem is that the workstation actually does this twice - once when
loading NETX/VLMs, the other during the login script.

Now, you can put this line in the login script to stop the second bit from
happening:

     SET_TIME OFF

This may require an updated LOGIN.EXE to work. So even though you can do
this bit globally, you still have to edit every NET.CFG.

Just for people who don't know, the NET.CFG setting is:

     SET STATION TIME=OFF

This should go in the "NETWARE DOS REQUESTER" section.

------------------------------

Date: Wed, 28 May 1997 18:25:36 -0400
From: Bob Becker <becker@CLARK.NET>
Subject: Re: How to set time on NW 4.10?

>Of some reason my 4.10 erver's date and time is set at Feb. 2001 - 02.05
>o'clock at night...<snip>

Wow! Setting the clock back that much could conceivably cause major
problems in Directory Services.

If this is a production server and you have multiple servers, I'd recommend
removing any replicas, removing Directory Services, downing, resetting the
clock and then reinstalling DS and adding replicas.

Otherwise, you could try the SET TIMESYNC TIME ADJUSTMENT command (the
recommended way to change time on a NW4 server -- check the documentation)
although it's going to take a while to get this back in sync with "real" time.

------------------------------

Date: Sat, 31 May 1997 09:55:38 +0100
From: Andre Schild <ASchild@neatech.ch>
To: floyd@direct.ca
Subject: Addition for novell.faq

For timesynchronisation of netware servers you can use a utility called
sntpclnt. It runs on the server as NLM and uses the NTP protocoll to get
the current time.

It is fully NDS compliant, but a Netware 3.x version is available too.
The 3.x version allows you to simulate a daylight saving on Netware 3.x
servers.

Basically it does the same as RDATE, but it uses the new NTP protcoll,
runs on 3.x and 4.x servers. (Intranetware too) It is shareware. (15US$
for 2 servers, 60US$ for unlimitted number of servers)

More infos are found under http://www.neatech.ch/sntpclnt

------------------------------

Date: Tue, 10 Jun 1997 11:56:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: new epoch

>Can someone define EPOCH for me?
-----
	I could suggest a dictionary. You know, that thick book which
is more than a spelling checker. It's related to the word era, based
on time. As an example, this the era when folks don't configure their
mailers properly and thus send unwanted gibberish attachments to email
messages (hint).
	Epoch is the time base of the system. NDS keeps messages in order
by timestamp, and needs to so that an old message is recognized as having
likely inaccurate information compared to recent messages and hence should
be discarded.
	Using DSREPAIR to "declare a new epoch" means in practice to stop,
wait for the declarer to say The time a the tone will be ..., and then
let servers progress from that point forward. Those servers ahead of the
time hack are obliged to forget and then relearn information based on the
announced time. One does not want to "declare" frequently because it is a
serious disruption to NDS synchronization activities, but when we need it
we really need it.
	The common mistake on epoch things is let a server get days or
years ahead of the tree. Oh boy, that's serious stuff. Ditto in the
other direction. So we always check the time when rebooting a server
and only after that check do we let the machine start server.exe. The
smarter the system manager the more often time/dates are set wildly wrong,
an observed situation based on not wanting to follow directions.
	Joe D.

---------

Date: Wed, 11 Jun 1997 00:19:33 +0200
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: new epoch

>Can someone define EPOCH for me?

You mean to say that the help screen doesn't tell you enough?
When the cursor is at 'repair time stamps and declare a new epoch',
press F1. Check out page 2 out of a total of 5.

------------------------------

