Operating System - OpenVMS
1745829 Members
4128 Online
108722 Solutions
New Discussion юеВ

application programming and NTP

 
Donald Hill
Advisor

application programming and NTP

We have designed an application where as part of the application and at the appropriate time of year we change the system time to daylight savings and back.. We are now wanting to use NTP to synchronize all the time critical elements in the system, both the VMS computers and other elements. Because of NTP's requirements to remain within 1000 seconds of current time or it will shut down, we need to stop and restart NTP upon these time shifts. We cannot find any system service calls or other means within the TCPIP manuals that allows us program control from our application on the operation of the NTP service. Any ideas on how this may be done?

Thanks
Don
7 REPLIES 7
Robert_Boyd
Respected Contributor

Re: application programming and NTP

Don,

The simplest would be to call out to DCL with LIB$DO_COMMAND to submit a batch job to run the SYS$STARTUP:TCPIP$NTP_SHUTDOWN.COM and the SYS$STARTUP:TCPIP$NTP_STARTUP.COM procedures.

Of course if you want to get fancier, you could call the $SNDJBC service directly as well.

Robert

Master you were right about 1 thing -- the negotiations were SHORT!
Donald Hill
Advisor

Re: application programming and NTP

Robert

We were looking more for a direct control of NTP as through a system service call to avoid the overhead and more importantly, the time delay of spawning a process as through LIB$SPAWN and the DCL commands.

As we need to continue the application, the call LIB$DO_COMMAND would not be appropriate as it does not return control to the calling program upon completion of the command. Instead, we would use LIB$SPAWN.
Thanks
Don
Robert_Boyd
Respected Contributor

Re: application programming and NTP

Don,

LIB$SPAWN would work just fine of course -- you might want to try reading through what the TCPIP$NTP_SHUTDOWN and TCPIP$NTP_STARTUP command procedures actually do to see if it is even feasible to find some sort of API call to trigger the same behaviors.

Robert
Master you were right about 1 thing -- the negotiations were SHORT!
Antoniov.
Honored Contributor

Re: application programming and NTP

Hi Don,
if I remember, LIB$SPAWN is able to execute dcl command file.

Antonio Vigliotti
Antonio Maria Vigliotti
Donald Hill
Advisor

Re: application programming and NTP

Antonio
Yes, it can. As mentioned above, we were trying not to use it to avoid the time required to spawn another process and run the DCL procedure.

Don
Robert Gezelter
Honored Contributor

Re: application programming and NTP

Don,

I have been busy dealing with a client problem, so my response is not research as thoroughly as I would like, but I wanted to put a few thoughts in.

First, I would like to point everybody at the RFC for NTP, which is available at the IETF www site at http://www.ietf.org/rfc/rfc1305.txt?number=1305

Doing a quick read of this raises the question of "What time zone is NTP operating in?" Scanning it quickly, the references to multi-time zone sources such as WWV imply (I did not find an explicit reference, but it was a quick scan) the use of UTC (aka GMT, Zulu) as the standard for overall transmissions.

WADR (with all due respect), I suggest that the best procedure is probably to keep the NTP feed on UTC at all times, and change the timezone offset used when the time is converted for printing. IMHO, consistency strongly suggests ignoring local time offsets in logs and using UTC for logs (which is why Air Traffic Control and other applications eschew local time in favor of UTC/GMT/Z). From a systems standpoint, this totally elimates the skew problem.

In the case of changing the formatting, all you need to at the appointed time, if it is not done automatically for you by the system, is do a call to the logical name services to redefine the logical name indicating standard or daylight time.

I hope that this is helpful.

- Bob Gezelter, http://www.rlgsc.com
Donald Hill
Advisor

Re: application programming and NTP

Sorry for the delay in response. I had thought I had responded earlier but I guess something went wrong.

Unfortunately our application was designed over a decade ago when we used GOES satelite clock receivers with a customized interface. Our software used standard system service calls to handle the receiver. We now are switching out to NTP and do not want to (cannot) redesign the architecture so we are stuck switching back and forth twice a year to keep the readable TOD clock on local time.

Don