Changing the Date and Time on your HPe3000

Beginning with MPE/iX 5.0, changing the time on your HP3000 became a fairly trivial task, no longer requiring a reboot. Unfortunately, it has also generated a lot of confusion. I believe most of the confusion stems from the need to retrofit into MPE the idea of time zones and Unix-style date management. In addition, the commands to change the time can be used incorrectly if documentation is not read, possibly compounding other time-keeping issues.

One common problem I hear is log files from Posix programs (such as Apache) have the wrong date/time. I’ll explain why that happens later in this document. First, let’s handle the simple task of changing to and from Daylight Savings Time.

If your date, time and time zone are all set correctly (as described later), making the semiannual time change is trivial. The command SETCLOCK with the TIMEZONE option is the preferred method. MPE chose to make the term TIMEZONE a little confusing. Rather than being EST, CST or such, it is W5:00, W6:00 and so on. This represents both a direction and time offset from Greenwich Mean Time (also called Universal Standard Time). The first letter is either E or W, indicating East or West of Greenwich England (all of the US is W). The time component is hours and minutes different from GMT.

Changing to or from Daylight Savings Time

For the US, Eastern Standard Time is W5:00, Central is W6:00, Mountain is W7:00 and Pacific is W8:00. Daylight Savings Time moves the clocks ahead one hour, so each of the above moves one hour closer to GMT (i.e. Eastern Daylight is W4:00).

To set your HP3000 to Eastern Daylight Time in April, issue the following command:


To set your HP3000 to Eastern Standard Time in November, issue the following command:


That is it! Pretty simple, isn’t it. But maybe you noticed a problem. When you issued the second command to return to standard time (fall back an hour), the time did not change!

This is intentional and important. Many logfiles do not like to go back in time! To avoid this, MPE will not make the jump back an hour in the fall. Instead, it will introduce a “Correction” amount (in seconds). Time will continue to move forward, but at a much slower pace, until the dropped hour ‘catches up’. At this point, the correction will drop to zero. This usually takes about two hours. I generally make a job to do this and stream it to run early Sunday morning. Thus, very few users ever notice the change.

Getting the Time Right

Before worrying about semi-annual time changes, you first need to ensure that the time and time zone are correct on your system. Issue the following command:


This will display something like the following:

SYSTEM TIME: TUE, FEB 25, 2003, 10:05:16 AM

If your System Time and Time Zone are correct and the Current Time Correction is zero, you are in good shape. If not, read on.

Often, if your time is correct, but the time zone is not, someone has at some time used the incorrect options of the SETCLOCK command to change the time. These options are DATE, TIME and CORRECTION. We will, however, now use these options to fix your time.

If the time zone is correct, the time correction is zero, but the actual time is wrong, the CORRECTION option is generally the one to use. This situation is normal because all computer clocks’ times drift a bit. Often you may notice your system time off by five or ten minutes. To fix this, issue a SETLOCK with the CORRECTION option:


The value is in seconds – positive means move ahead, negative means move back. Unless the “NOW” option is also used, the backward correction is actually a slowed down forward movement (like the time change above) until the correction is complete.

When the time zone is wrong, we need two steps to make it correct. First we need to change the time zone, then we need to change the time, since changing the time zone will move the time.

Let’s assume you are in US Central Time. It’s winter, so your time zone should be W6:00. But your SHOWCLOCK shows it to be W7:45 (wow!). The time shows 8:25 a.m. and that is correct. Here’s how to get everything correct.

First, since we will be overriding MPE’s ‘always keep the clock going forward’ policy, try to do this when there is minimal activity on the system. Now issue the following command to get the time zone correct:


A SHOWCLOCK will now show a correct time zone, but the local time will be 9:40 a.m. because we changed the time zone by 1:15 to the east (just like going on DST). To fix this first issue this command to cancel any correction in progress:


Now issue the following command to get the time back to 8:15:

SETCLOCK DATE=mm/dd/yyyy;TIME=08:15;NOW

This will immediately change the time to 8:15 while leaving the time zone alone. A SHOWCLOCK will now give the correct time, time zone and a correction of zero.


But wait, there’s more! The above steps will insure that your time is reported correctly by all MPE intrinsics and commands. However, the Unix world has a different approach to time, and programs ported from Unix (running under Posix) often expect to use the Unix method.

Under Unix, a system variable called TZ holds a value that is a key into a table (TZTAB) of time zone information. Certain C and C++ language functions make use of this information in determining the correct time to return to the calling program. If the TZ variable is not set, or set incorrectly, you may see wrong times in Apache, Samba and other Posix based log files.

Issue the following command:


You will see output similar to this:

 DEBUG/iX C.25.06
 HPDEBUG Intrinsic at: 339.00007258 PROGRAM+$198
 PRIV=$3 := $0
 ***                                                       ***
 *** Greenwich Mean Time : FRI, AUG 27, 2010, 3:28 PM      ***
 *** GMT/MPE offset : -4:00:00                             ***
 *** MPE System Time : FRI, FEB 27, 2010, 10:28 AM         ***
 ***                                                       ***
 **** C Library Information ****

 Current value of Time Zone(TZ) variable : NOT ASSIGNED
 CTIME function return : Fri Aug 27 10:28:35 2010

As you can see near the bottom of the report, the Current Value of TZ is NOT ASSIGNED. However, the CTIME function return still gives a time and it is correct! How can this be?

It works because I am lucky! HP arbitrarily decided that the TZ would default to Eastern time if it was not set. Since I am in Eastern time, my CTIME is correct. Often I get calls from other time zones asking why the Apache log files are off by one hour or more. The reason is they did not set TZ, so the log files are in Eastern time.

I recommend globally setting the TZ variable as part of your Logon UDC. Simply issue the following command (if you are in Eastern time):


(For Central Time: CST6CDT, Mountain Time: MST7MDT, Pacific Time: PST8PDT)

Issue another SHOWCLKS and the last two lines now read:

Current value of Time Zone(TZ) variable : EST5EDT
CTIME function return : Tue Feb 25 11:00:14 2003

As mentioned, the TZ value is just a key into the TZTAB file. This table (under MPE) is located in TZTAB.LIB.SYS. This is a text file, so you can PRINT it to see what is in it. Its format is beyond the scope of this article, but can be found by issuing a ‘man tztab’ on any HP-UX or Linux system.