 Updated:  24-Jul-1993     %                                 RDATE   4                  Obtain Remote Date and Time for VMS     Description   C    Rdate performs a function similar to the Unix rdate program.  It E obtains the time of day from another network host that implements the B Time Protocol as described in RFC 868 (probably all Unix systems),B displays the time, and resets the system clock to the new time, if@ requested.  The user must have OPER and LOG_IO privileges to set the system time.C    Rdate was written in VAXC using UCX 2.0 for VMS 5.5.  Though, it B should be portable to other C compilers and TCP/IP implementations which provide sockets for VMS.     Building Rdate  @ 1. Edit the rdate.h file and change the values of the defines to;    describe your time zone and Daylight Savings Time rules.   E 2. Create a link options file (e.g. link.opts) containing the options   !       sys$library:ucx$ipc.olb/lib !       sys$share:vaxcrtl.exe/share    3. Compile rdate         cc rdate  
 4. Link rdate          link rdate, link.opts/opt   
 5. Test rdate   "       rdate == "$<directory>rdate"%       rdate <host name or IP address>   F    After invoking rdate with the name of a network host which provides1 time service, you should see something similar to          $ rdate foo.bar.com   +       Polling foo.bar.com (255.254.253.252)   ,       System time:   24-JUL-1993 17:03:25.00,       Network time:  24-JUL-1993 17:08:02.00  9    To have rdate set the system time to the network time,          $ rdate -s foo.bar.com  +       Polling foo.bar.com (255.254.253.252) *       Setting system time to network time.  ,       System time:   24-JUL-1993 17:03:25.00,       Network time:  24-JUL-1993 17:08:02.00         $ show time            24-JUL-1993 17:08:15.00   D    You may specify more than one host on the command line, and rdate; will try each host in turn until it obtains a network time.   4       $ rdate foo1.bar.com foo2.bar.com foo3.bar.com    
 Discussion  F    The resolution of the Time Protocol is only one second.  Therefore,H even though rdate tries to compensate for network and processing delays,A the accuracy cannot be better than one second.  (Actually, on the E average it is within 0.5 seconds.)  You can see this if you run rdate @ several times in a row and compare the system and network times.G    For example, suppose you happen to request the time half way through G a second.  Rdate sets the system time accurately to the current second, F but the system time will be half a second slower than the network host& because of when the time is retrieved.G    If you require greater accuracy, you should investigate NTP (Network C Time Protocol) which has the potential to synchronize time across a C network to the pico second, far beyond what a VAX requires.  I have . heard that Multinet provides NTP capabilities.F    If you have DTSS (Digital Time Service) from the DECnet extensions,H there is an NTP provider program for UCX on the net you can get ahold of< to access NTP time and pass that along to DTSS, if you wish.E    Some day if I have the time and motivation, I may hack the ntpdate G program for use with UCX which would allow better resolution.  However, 1 working with time on the VAX is quite cumbersome. F    Consideration should be given to the network host that will provideA the time.  Ideally, it will be a machine in your domain that does < synchronize with NTP, or at the least, which has the desired stability and accuracy. B    DEC hardware is known for the stability of its clocks, and theyH should not drift much during a 24-hour period.  Therefore, running rdateG more often than once every 24 hours will probably not provide any great F benefit.  You may want to run it once a week or once a month dependingC on your taste.  However, running it once a day, say in a batch file H queued for 2:01 a.m., will keep the clock on time and will automatically3 take care of Daylight Savings Time when it changes.     
 Bugs and Such   A    Questions, bugs, suggestions, patches, or reports of how it is A working may be sent to mose@ccsn.edu.  Due to other priorities, I > cannot promise to fix every bug immediately or implement every suggestion.    Russell Mosemann Computing Center Concordia College 
 Seward, NE
 mose@ccsn.edu 