OSF DCE Application Development Guide--Core Components

OSF DCE Application Development Guide—Core Components
5. Make the remote procedure call ServerRequestProviderTime to obtain the
timestamps from the external time-provider. If the procedure does not return
within the elapsed time specified by the control message (timeout), then
synchronize with peer servers. Schedule the next synchronization based upon the
applicable DTS management parameters, ignoring nextPoll.
6. If the procedure returns successfully, verify that the TP process status is
K_TPI_SUCCESS. Otherwise, synchronize with peer servers and schedule the
next synchronization.
7. Extract the timestamps from the data message and synchronize using the
timestamps.
8. Schedule the next synchronization time by adding the value of nextPoll seconds to
the current time. At the next synchronization, go to step 2.
Note: Application developers do not have to perform these steps; DTS performs
these steps internally during synchronization with an external time-
provider.
20.6 Running the Time-Provider Process
Both the TP process and the DTS daemon must run on the same system. The TP process
must be started up under the login context of the machine’s principal, which has root
privileges. The DTS daemon and the TP process are started independently. However,
before starting the TP process, ensure that dced is running on the system. If it is not
running, start it. The TP process can always exit without affecting the DTS daemon.
DTS dynamically reestablishes communications with the TP process when it creates
binding handles.
20.7 Sources of Additional Information
Refer to the following for additional information:
• See /examples/dts for examples of time-provider programs that you can use with
several different types of external time-provider devices.
• See the for commercial sources of external time-providers.
• See the OSF DCE Application Development Reference for reference pages
describing the RPC API and DTS API routines.
20 − 12 Tandem Computers Incorporated 124245