HP OpenVMS Systems Documentation

Table 6-3 lists all predefined date format logical names, their formats, and examples of the output generated using those formats. The mnemonics used to specify the formats are listed in Table 6-2.

Table 6-4 lists all predefined time format logical names, their formats, and examples of the output generated using those formats.

A user can specify a choice of language by defining the SYS$LANGUAGE logical. For example:

$ DEFINE SYS$LANGUAGE FRENCH

A user can also specify a date and time format by defining the LIB$DT_FORMAT logical. For example:

$ DEFINE LIB$DT_FORMAT LIB$DATE_FORMAT_002, LIB$TIME_FORMAT_006

Once you have installed and customized your system, Compaq recommends that you back up your system disk. To do so, follow the instructions in Section 11.17.

On VAX systems, back up the console volume (if applicable). If your computer has a console storage device, make a backup copy of your console volume in case your original becomes corrupted. The operating system provides a command procedure called CONSCOPY.COM (in the SYS$UPDATE directory), which copies your console volume to a blank one.

The procedure for backing up the console volume varies for different computers. For specific instructions on backing up the console volumes, refer to the upgrade and installation supplement for your VAX computer.

6.9 Using SYSMAN to Manage System Time

You can manage system time for an OpenVMS Cluster system with SYSMAN CONFIGURATION commands. Table 6-5 summarizes these CONFIGURATION commands and their functions.

Use the CONFIGURATION SET TIME command to modify system time for nodes in an OpenVMS Cluster system, as well as for individual nodes. You can specify time values in the following format:

You can also enter delta time values. Refer to the OpenVMS User's Manual for more information about time formats.

In a cluster environment, SYSMAN sets the time on each node to the value you specify. However, if you do not specify a value, SYSMAN reads the clock on the node from which you are executing SYSMAN and assigns this value to all nodes in the cluster. In a remote cluster, SYSMAN reads the clock on the target node in the cluster and assigns that value to all nodes. Note that the time-of-year clock is optional for some processors; refer to your processor's hardware handbook for more information.

SYSMAN tries to ensure that all processors in the cluster are set to the same time. Because of communication and processing delays, it is not possible to synchronize clocks exactly. However, the variation is typically less than a few hundredths of a second. If SYSMAN cannot set the time to within one-half second of the specified time, you receive a warning message that names the node that failed to respond quickly enough.

As a result of slight inaccuracies in each processor clock, times on various members of a cluster tend to drift apart. The first two examples show how to synchronize system time in a cluster.

Examples

1. The following procedure sets the time on all cluster nodes to the value obtained from the local time-of-year clock, waits 6 hours, then resets the time for the cluster:

   $ SYNCH_CLOCKS: $ RUN SYS$SYSTEM:SYSMAN SET ENVIRONMENT/CLUSTER CONFIGURATION SET TIME EXIT $ WAIT 6:00:00 $ GOTO SYNCH_CLOCKS

2. The next example sets the environment to NODE21, NODE22, and NODE23, sets privilege, and modifies the system time on all three nodes:

   SYSMAN> SET ENVIRONMENT/NODE=(NODE21,NODE22,NODE23) SYSMAN> SET PROFILE/PRIVILEGE=LOG_IO SYSMAN> CONFIGURATION SET TIME 12:38:00

3. The following example sets the environment to cluster and displays the system time for all nodes:

   SYSMAN> SET ENVIRONMENT/CLUSTER/NODE=NODE23 SYSMAN> CONFIGURATION SHOW TIME System time on node NODE21: 19-APR-2001 13:32:19.45 System time on node NODE22: 19-APR-2001 13:32:27.79 System time on node NODE23: 19-APR-2001 13:32:58.66

The Time of Day Register (TODR), which the system uses to maintain system time, has a limit of approximately 15 months. Between January 1 and April 1, reset the system time; otherwise, the following problems might occur:

• The first time in a new year that you reboot an OpenVMS Cluster system or a node in the system, one or more nodes display any of the following system times:
  • A year in the past
  • A year in the future, which might cause passwords to expire and other difficulties
  • A correct time, but a SHOW SYSTEM command indicates that the system has been up since a time in the 1800s
• Even if you correct the system time during system boot, the following problems might remain:
  • A SHOW SYSTEM command displays an incorrect up time such as a date in the 1800s
  • The error log report (ERRLOG) shows errors for a year in the future
  • Batch jobs are waiting for a year in the future
  • Files have a creation or modification date in the future

Because the TODR has an approximate limit of 15 months, the system maintains time by combining the TODR value with a base time recorded in the base system image (SYS$LOADABLE_IMAGES:SYS.EXE). The definition of base time is:

01-JAN-CURRENT_YEAR 00:00:00.00

Because all TODRs ordinarily have the same base, multiple CPUs can boot off the same system disk, and you can use multiple system disks on one CPU; the system sets the time correctly.

When a SET TIME command is issued (with or without specifying a time), OpenVMS performs the following actions:

1. Writes the current time to the system image file
2. Resets the TODR as an offset within the current year

In an OpenVMS Cluster system (or for a node that is not part of the cluster), when you set the time, the TODR and the base time in the system image are reset with the values for the new year. However, multiple systems might share the system image. This does not normally cause a problem except after the first day of a new year.

By December, each node has a very large offset stored in the TODR (from the base time of 1-JAN of that year). When the time advances to a new year, the system image still has the old year and the TODR values are still large.

After January 1, if a SET TIME command is issued on any node (or any node is shut down using SHUTDOWN.COM), the following events occur:

1. The new year becomes the base year.
2. The system resets the TODR on that node.
3. The other nodes still have a large value in the TODR.

After these three events occur, if a node that has a large TODR crashes and rejoins the cluster, its system time is initially in the next year (applying the large TODR to the new year). This system time is recorded as the system's boot time. When the node joins the cluster, its time is set to the correct value but the boot time remains one year in the future. Certain forms of the SHOW SYSTEM command compare current time to boot time; in this instance, SHOW SYSTEM displays incorrect values.

If a system disk is used at different times by different, unclustered CPUs or if different system disks are used at different times on the same CPU, the system might incorrectly set the time to a year in the future or a year in the past, depending on how the CPU's TODR and the value recorded on the system disk become unsynchronized:

• Sharing a system disk across multiple CPUs pushes the time into the future
• Using multiple disks on one CPU pushes the time into the past

Example

The following example uses SYSMAN commands to reset the time on all nodes in an OpenVMS Cluster system:

$ RUN SYS$SYSTEM:SYSMAN
SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> SET PROFILE/PRIVILEGE=(LOG_IO,SYSLCK)
SYSMAN> CONFIGURATION SET TIME 05-JAN-2001:12:00:00
SYSMAN> EXIT