gtpm6m0nMain Supervisor Reference

Managing and Synchronizing Clocks

The control program clock software uses three hardware clock components:

Timekeeping in this system is performed using the TOD clock to drive a set of software clocks. Whenever the system is above 1052 state, TOD clock comparator interrupts increment a control program seconds clock, a systems clock, and a set of subsystem clocks. Software clocks are not incremented when the system is not above 1052 state. The CPU timer is used to verify that ECB-controlled programs release control of the CPU, in a half-second.

Note:
Base systems (those that do not include HPO/MDBF) are treated as MDBF systems with a basic subsystem only. For systems that include MDBF, all subsystem clock values, including the basic subsystem, are derived from the system clock.

The system clocks maintained in this system are:

The subsystem clocks are:

Commands

A number of commands exist to either display or alter clock and date information. These include: ZDDAT, ZDTIM, and ZATIM. Consult the TPF Operations for detailed information on these messages.

Displaying the Time and Date

Clock display facilities can display:

Date displays are identical to those designed for clocks. Thus, display capabilities include:

Altering Clock Values

Periodically, the need arises to alter various system and/or subsystem clock values. In TPF, the capability exists to alter either: a subsystem time clock, or the TOD clock. Altering the TOD clock will initiate an automatic change to the system clock as well.

Considerations for TOD Clock Alteration

Considerations for Subsystem Clock Alteration

  1. A subsystem may be in any system state (NORM,1052,etc.) when a subsystem clock is altered.
  2. Altering a subsystem clock has no effect on the TOD clock, the system clock, or any other subsystem clock.
  3. Issuing the ZATIM SET option to alter a subsystem clock in 1052 state, does not change the subsystem date from the date when the subsystem was last above 1052 state.
  4. Issuing the ZATIM ADD option to alter the subsystem clock in 1052 state, the system calculates what the time would be if the subsystem was above 1052 state (including any date change) and then updates the subsystem clock as requested.

Restart Facilities

During system restart, the clock program verifies that the TOD clock is operating. If it is not operating, the operator is prompted for a ZATIM command to set the TOD clock. When the TOD clock is operating or after it is started, the system generates the following message to inform the operator:

CLKS0001I   HH.MM.SS  SYSTEM CLOCK IS NOW SET

Cycle Facilities

Entering the ZCYCL command to cycle a subsystem above 1052 state results in a clock program test of the midnight boundary. If the subsystem crosses a midnight boundary since the last time it was above 1052 state:

  1. A message is sent to inform the operator
  2. The operator is prompted with a second command, ZATME, before cycling the system. The operator can choose one of 3 options:
    1. Cycle-up the subsystem with the new date - ZATME GOOD
    2. Alter the subsystem time to maintain the old date and then cycle-up the subsystem - ZATIM SET followed by ZATME GOOD
    3. Cancel the cycle request - ZATME CNCL

The subsystem calendar is initialized each time a subsystem is cycled above 1052 state. The subsystem perpetual minutes clock is used to determine the correct date.

Time-Initiated Functions

Using the CRETC macro, real-time programs activate other programs at a later interval of time. The system calculates the clock value when the program is to be activated, and transfers control to the program at that time. (Refer to the section entitled Initializing ECBs for Entries from Create Macros.)

CRETC Considerations

  1. For subsystems in 1052 state, CRETC requests are ignored if the subsystem clocks are not operating, unless the STATE=1052 option is specified.
  2. CRETC macro requests with the seconds option are activated when the system seconds clock reaches the calculated time. Thus, an alter time request has no effect on the activation of the program.
  3. CRETC macro requests with the minutes option are activated when the subsystem minutes clock reaches the calculated time. Thus, if the subsystem clocks are altered, such a request may be activated at a time interval other than had been specified in the request.
  4. When a subsystem is cycled-down, all pending CRETC macro requests for the subsystem are purged unless the STATE=1052 option was specified.
  5. ECBs created by the CRETC macro are dispatched on the I-stream on which the CRETC was issued.
  6. ECBs created by the CRETC macro with the STATE=1052 option specified are honored at the time requested regardless of the system state.

Timekeeping Considerations for Loosely Coupled Processing

Synchronization Check Error

A synchronization check error (referred to as synch check in Messages (System Error and Offline) and Messages (Online)) is a condition detected by the hardware that indicates 2 clocks are not in synchronization when they are supposed to be. Clocks are either reference points sending timing signals (master clocks) or are remote points receiving timing signals (remote or slave clocks). If an STR is the synchronization source, then all the clocks in the complex are considered remote. Otherwise, a CPC is the synchronization source. Each remote clock is either in synchronization with the master synchronization source or it is in error. This error is known as a synch check. There is no functional connection between remote clocks. However, there is a functional connection between the master synchronization source and the remote clocks.

Hardware features determine the relationships between clocks. Control register 0 contains a bit that determines whether the clock on that processor will be sensitive to the timing pulses sent to it. If this bit is not set, any stepping pulses sent to it will be ignored. If the bit is set, a stepping pulse every microsecond is expected. If the TOD RPQ is used, the master clock ignores timing pulses, while remote clocks expect the timing pulses. If an STR is used, all clocks are remote and expect timing pulses. Control register 0 also contains a bit that determines whether synch checks will be recognized. If this bit is set, synch checks will be recognized, otherwise not. Recognizing a synch check means that at the moment the remote clock reaches the one second mark it expects a synchronization pulse to be sent by the master clock and, if this pulse doesn't occur at that moment, an external interrupt will take place on the remote processor. A synch check is a catastrophic condition under most configurations.

This logical picture of clocks in synchronization is the same whether the system consists of standard 370 hardware, STR hardware, or a TOD clock RPQ enhancement. The standard hardware maintains the synchronization in a CPC. The STR hardware or the TOD RPQ hardware maintains the synchronization between CPCs. The standard hardware, the STR hardware, and the TOD RPQ can be involved in loosely coupled complexes of tightly coupled CPCs.

When a sync check occurs, the external interrupt handler is invoked to determine which error has occurred. When the sync check is isolated, TOD clock synchronization routines are called to attempt to resolve the error. If the processor in error is a remote processor in a loosely coupled complex with the TOD RPQ or an STR, hardware revalidation is attempted. If the hardware is operational, the processor is not taken down. All other scenarios are catastrophic. After a catastrophic synch check the system reloads and the time must be confirmed with an external source. If a synch check is not catastrophic, the CPC will be locally synchronous, in the loosely coupled complex. To restore the CPC to the synchronization of the complex, the time should be reset on the master CPC, or the CPC must be reIPLed.