STP and CTN terminology is sometimes mixed; this is technically incorrect but the meanings are usually clear. The figure shows three zPDT instances (each in a separate PC) in a CTN. The figure includes the following high-level elements:

This chapter describes the practical configuration and operation of STP in a zPDT system. Much more general STP detail is available in Server Time Protocol Planning Guide, SG24-7280.

You cannot use a devmap (as the operand of an awsstart command) that has an [stp] stanza unless the CCT/STP function is running. You can check the status by using the stpserverquery command.

If you display Linux processes directly, with a ps aux | grep cct command for example, you see a line that ends with newcct information, as in the following example:

The CCT/STP function does not affect the Linux time-of-day clock. It affects only clocks that use the CCT interface library routines; in practice, this means zPDT (when a [stp] stanza is present in the devmap) and z/OS (when the CLOCKxx parameter is set).

The z/Architecture places tight tolerances on STP clock synchronization and uses the high speed coupling channels as part of the design to achieve the specified tolerances. zPDT, using IP communication, cannot duplicate this environment and the z/Architecture tolerances are relaxed for the zPDT STP function. You must evaluate the usefulness and correctness of the zPDT STP function for your environment.

Both the client and server create log files. Our sample configuration places these in /tmp. Existing log files are overwritten when a server or client is started. The server log files typically have little in them. A client log file might have entries such as these:

The fields in the client log are as follows:

The “ping-pong” messages mentioned are short message exchanges between a client and server.

The time-of-day provided to z/OS by the CCT/STP function ultimately depends on the time-of-day returned by the effective Linux clock.¹ A user might have a substantially inaccurate time-of-day in the PC BIOS clock that is used to set the Linux clocks when Linux is booted. Another user might have an NTP² connection for Linux, resulting in a Linux clock that is accurate to within a second or so. At the zPDT level, there is no control over the accuracy of the time data provided by Linux. The STP function keeps multiple zPDT TOD values synchronized, but does not control the accuracy of the time presented.

The log files are not intended for normal user inspection and may contain messages with whimsical phrasing, such as this example:

This indicates a client failure, but the client immediately restarts itself. We have seen these messages at random intervals on zPDT CCT networks very closely coupled (private 1 GB Ethernet) but have not seen them on other systems connected through the “real” Internet. In our test environment, these transient failures appear to have no effect on z/OS basic sysplex operation. Corresponding log messages on the CCT server include these:

When a remote client connects to the STP server, another server instance is automatically started. No action is needed to manage this, but you might see multiple STP servers when using the Linux ps command.

If you have an [stp] stanza in a devmap, you cannot start this devmap (using the awsstart command) unless you have an STP function active. If you do not have STP active, the zPDT startup will fail. The most common error message is INVALID REGISTER NUMBER.

The zPDT STP facility relies on a fast, low-jitter TCP/IP connection between host Linux systems in order to synchronize the zPDT TOD clock values. Insufficient TCP/IP connection quality results in STP reporting either unsynchronized or unusable TOD clock-source machine checks to the zPDT-hosted OS. You must provide a physical TCP/IP connection with sufficient quality to support machine-check-free STP operation. In a virtualized environment, the hypervisor increases the TCP/IP latency and jitter, as perceived by the STP facility, increasing the risk of disruptive zPDT STP machine checks. We have performed limited STP testing in a virtualized environment with mixed results and therefore recommend that STP not be used in a virtualized environment.

You may update the leap second information block by including an additional statement in the devmap, as in the following example:

The format for the LEAPSECONDS statement is as follows:

where:

Two new zPDT commands (issued in a Linux command window) are provided for leap second details:

We understand that the z/OS CLOCKxx parameter STPZONE must be set to YES for z/OS to process leap seconds when using an STP time source. The leap second information block is displayed, as in the following example: