wjm 05-sep-1995 (VMS/UCX port done for version 3.4v) using DECC V4 wjm 07-nov-1997 small fixes for DECC V5 (actually tested V5.6) and VMS versions up to V7.1 wjm 13-feb-1998 add warnings about DECnet/OSI -------------------------------------------------------------------------------- *** IMPORTANT NOTE: `xntpd' time service is *not* supposed to co-exist *** *** with DEC's DTSS (part of DECnet/OSI or DECnet-Plus). *** *** See below for XNTPD_TIC which does, but has limited utility. *** For OpenVMS machines running DEC's TCP/IP Services (UCX), a version of `xntpd' without support for [hardware] reference clocks, plus the `ntpq' and `xntpdc' programs can be made from this kit (an older VMS port of NTPDATE is available separate from `xntp'). The DECC compiler is required to compile (don't even try VAXC); at run time, only the DECC runtime kit is needed (always present on AXP, and on VAX starting with VMS V6); on VAX VMS V5, this apparently amounts to just DECCRTL.EXE and CMA$TIS_SHR.EXE, but of course one of the 'official' AACRT* kits from DEC (which can be freely copied) is to be preferred where applicable. I have run `xntpd' on VAX for VMS versions V5.4-3 thru V7.1, and on AXP for VMS versions V6.1 thru V7.1, with UCX versions V2.0D and higher (DECnet Phase IV !!!). In order to create the VMS executables, only the following directories are required: . (this top level directory) ./include ./lib ./ntpq ./xntpd ./xntpdc Just invoke $ @VMSMAKE.COM in the top directory. The relevant XNTP documentation is provided in the ./doc directory; additionally, for easy reading on VMS, I have provided the cleaned-up output of the UNIX `man' command for the "*.8" files as "*.MAN8". Restrictions/bugs/problems: - The ported `xntpd' cannot resolve host names, i.e. the config file must contain numeric addresses. (`xntpd' wants asynchronous name resolution. In principle, this is easy with VMS, but it's too much work for me integrate.) - Day times displayed by `ntpq' and `xntpdc' are UTC without regard to the local time zone. Think of this as a "feature" (as long as the DECC library's localtime() routine doesn't respect time zones). On VMS V7, you can avoid this "feature" by removing from [.*]VMSMAKE.COM the preprocessor definition __CRTL_VER=60100000 . I put this in, such that object files created on VMS V7 can be LINKed in traditional fashion against pre-V7 versions of the DECC shareable library; without, the DECC$CRTL.OLB approach (making for huge executables) is required. - DES encryption is not provided due to problems with US export regulations, so the relevant module (./lib/authdes.c) is _not_ required to build. (If you have the code, and really need it, try adding the routine to ./lib/VMSMAKE.COM, and also define the "DES" preprocessor constant there, just like "MD5" already is. I happen to know that both the US version, and a module derived from the Australian "international" DES code don't cause any problems with VMS.) Special VMS-only feature (optional): The XNTPD "make" file, [.XNTPD]VMSMAKE.COM, by default defines the constant VMS_LOCALUNIT as 3. If this constant is defined, it specifies a "local" reference clock _unit_ which gets special treatment (by default, this is 127.127.1.3; units 0..2 are not affected): This reference clock will operate only while a logical name (or a DCL symbol - not very useful) "XNTP_LCL_VALID" is visible to XNTPD{_TIC}.EXE. Whenever it is, XNTP will try to read the logical name's value as an integer; if this yields a value > 0, the "LCL" clock's dispersion will (dynamically) be set to that many milliseconds, otherwise the default dispersion of 10 ms will apply. With both XNTPD.EXE and XNTPD_TIC.EXE, this clock unit can be used to provide the local time via NTP in a controlled fashion. For this to work correctly, as of 3.4v, this local unit ... _must_ have the "prefer" flag set when used with XNTPD.EXE _must_ _not_ have the "prefer" flag set when used with XNTPD_TIC.EXE *** BE CAREFUL! *** N.B. All the "reference clock" support in `xntpd' looks rather unix-specific, so it doesn't lend itself to an easy port. With VMS, conceivably there might be standalone programs that synchronizes the system time to an external source. I do have one such thing running (for [German] DCF77 radio) - feel free to ask me about it if you're located close enough ... - w.j.m. Four executables are created by @VMSMAKE in the top directory: NTPQ.EXE should act like the unix version XNTPDC.EXE should act like the unix version XNTPD.EXE ditto, with the restrictions mentioned above (needs SYSPRV, CMKRNL, OPER, and LOG_IO privilege) XNTPD_TIC.EXE is an `xntpd' that neither changes the system clock, nor is sensitive to changes of same (i.e. it can co-exist with DEC's DTSS time service on the same machine). Requires SYSPRV only to run. It can in fact be queried by DTSS$PROVIDER_NTP.EXE ... On ALPHA, XNTPD_TIC is less accurate than XNTPD; on a VAX, both should work equally well. (This is a VMS-specific hack which uses the count of clock ticks since bootstrap - left alone by all known software - for its time base, instead of the system time [available via standard interfaces].) NTP works with UTC (Greenwich time) only, while the VMS system time traditionally is meant to reflect the local time, so all three programs have to know about the local timezone (XNTPD_TIC needs it only once at startup). They look for the logical names XNTP_TIMEZONE_DIFFERENTIAL and SYS$TIMEZONE_DIFFERENTIAL (in this order), which are supposed to contain the timezone offset as {seconds _east_ of Greenwich}. Starting with VMS V6, the latter logical name will be defined system-wide by VMS (see SYS$MANAGER:UTC$CONFIGURE_TDF.COM and the manuals for having it set _correctly_). While my adjtime() code might be able to serve as a means for "softly" adjusting the VMS system time at beginning and end of the daylight saving time period, I have no idea yet how to convince XNTPD to do so; until further notice, please shut down XNTPD.EXE prior to a DST adjustment, and restart it afterwards (don't forget to first re-define the relevant *TIMEZONE_DIFFERENTIAL logical). No reason to shut down XNTPD_TIC.EXE, but it'll also need the new logical the next time it starts up (DECdts _should_ take care of this). Note about VMS privileges: XNTPD.EXE requires CMKRNL exclusively to adjust the system time, and both OPER and LOG_IO only to update the battery-backed time-of-year ("TOY") clock. If one of the privileges is lacking, XNTPD will _not_ abort, but rather loudly complain on standard output, and maybe get a little confused. Both XNTPD.EXE and XNTPD_TIC.EXE require SYSPRV in order to use the privileged UDP port 123 that's reserved for the NTP protocol. Wolfgang J. Moeller, Tel. +49 551 2011516 or -510, moeller@gwdvms.dnet.gwdg.de GWDG, D-37077 Goettingen, F.R.Germany | Disclaimer: No claim intended! ----- ----- Here are my changes & additions, relative to version 3.4v (which already has most of my older VMS fixes for XNTPD & NTPQ) ... ./include/ NTP_TYPES.H - fix definition of u_char, u_short, etc. for VMS/UCX (partly this gets done by ) >>> DECC V5 needs no VMS-specific modifications <<< [new] NTP_SELECT.H - VMS-specific modification only required for old (V4?) versions of DECC compiler ./doc/ NTPQ.MAN8 XNTPD.MAN8 XNTPDC.MAN8 - `man' source files "*.8" converted to plain text. ./lib/ +++ Added +++ VMSMAKE.COM - stand-alone DCL `make' utility for the relevant files in this directory. Particularly neat when run with SET VERIFY on(!). VMS_GETPASS.C - drop-in for [unix] getpass() VMS_GETTICKFREQ.MAR - assembly routine to determine AXP hardware clock frequency (supposedly model dependent) VMS_GETTIMEOFDAY.C - implements gettimeofday() [w/o timezone support], for use by all executables. VMS_SETTICKLEN.MAR - kernel mode assembly routine to read & write the data cells used for system time adjustments VMS_UCX_IOCTL.C - wrapper around UCX$EXAMPLES:UCX$IOCTL_ROUTINE which implements ioctl() for UCX sockets. ./ntpq/ +++ Added +++ VMSMAKE.COM - cf. above ./xntpd/ NTP_LOOPFILTER.C - fix problems (probably not specific to VMS) with clock stability for XNTP clients. Also, support added for VMS_LOCALUNIT feature. NTP_PROTO.C, REFCLOCK_LOCAL.C - support added for VMS_LOCALUNIT feature. [new] NTP_IO.C - re-order VMS-specific conditionals so DECC V5 gets them right +++ Added +++ VMSMAKE.COM - cf. above VMS_ADJTIME.C - implements adjtime() & settimeofday(), using VMS_SETTICKLEN(), in a way sufficient for use by XNTPD (timezone ignored; save small residuals across subsequent calls because one cannot in general do an "exact" adjustment in a single call). VMS_LOCALCLOCK.C - used only when VMS_LOCALUNIT is defined, implements the VMS-specific logname-controlled clock. NOTE: this module must be revised whenever REFCLOCK_LOCAL.C changes! VMS_SYS_GETTIC.C, VMS_TICTIME.C - alternate implementation of gettimeofday(), settimeofday(), adjtime() which does its own "virtual" timekeeping, driven by the hardware clock tick count available in EXE$GL_ABSTIM_TICS (on ALPHA this provides only about the 10 ms resolution known from VAX). These routines replace VMS_GETTIMEOFDAY and VMS_ADJTIME for use by XNTPD_TIC only. ./xntpdc/ NTPDC.C - needs the ntp port number hard-coded, due to lack of a `services' database on VMS; small workaround against having the prompt (on `stderr') overprint the last line sent to `stdout' +++ Added +++ VMSMAKE.COM - cf. above ./ +++ Added +++ VMS.README - this file VMSMAKE.COM - this is a driver for the other VMSMAKE.COM files. XNTPD.COM, XNTPD_TIC.COM - example (batch) command files running the daemons, demonstrating my use of the "driftfile" etc. (Maybe the XNTP maintainer will move these two files somewhere else in the directory tree) Wolfgang J. Moeller, Tel. +49 551 2011516 or -510, moeller@gwdvms.dnet.gwdg.de GWDG, D-37077 Goettingen, F.R.Germany | Disclaimer: No claim intended! ----- -----