STP and CTN terminology is sometimes used interchangeably, which is technically incorrect but the meanings are usually clear. Figure 18-1 on page 347 shows three zPDT instances (each in a separate PC) in a CTN. Figure 18-1 on page 347 includes the following high-level elements:

This chapter describes the practical configuration and operation of STP in a zPDT system. For more information about in general, see 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, for example, a ps aux | grep cct command, you see a line that ends with newcct information, as in the following example:

The CCT/STP function does not affect the Linux TOD clock. It affects only clocks that use the CCT interface library routines; in practice, the 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 high-speed coupling channels as part of the design to achieve the specified tolerances. zPDT, by using IP communication, cannot duplicate this environment, so 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 them 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 the following ones:

The fields in the client log are as follows:

The TOD that is provided to z/OS by the CCT/STP function ultimately depends on the TOD that is returned by the effective Linux clock.¹ A user might have a substantially inaccurate TOD in the PC BIOS clock that is used to set the Linux clocks when Linux starts. 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 that is provided by Linux. The STP function keeps multiple zPDT TOD values synchronized, but does not control the accuracy of the time that is presented.

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

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

When a remote client connects to the STP server, another server instance is automatically started. No action is needed to manage this task, 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 (by using the awsstart command) unless you have an STP function active. If you do not have STP active, the zPDT startup fails. 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 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, which increases the risk of disruptive zPDT STP machine checks. We have performed limited STP testing in a virtualized environment with mixed results, so as a best practice, do not use STP in a virtualized environment.

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

The format for the LEAPSECONDS statement is as follows:

Two new zPDT commands (issued in a Linux command-line interface (CLI)) 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: