The Four Hundred

Setting time on an iSeries box is easy, but there are a few pitfalls to OS/400 time synchronization in three specific situations: when your box is communicating with other servers, when it's running the Management Central server, and when it's running native Java programs. In these scenarios, you need to know the drill for setting up time synchronization. I'll walk you through an example of OS/400 time synchronization breaking down, and will then explain how to set things properly.

The problem starts with a shop that is using a third-party AS/400-based report server to e-mail a spool file to a remote user. The report server uses SMTP to forward the e-mail to a Domino Version 6 server, an e-mail relay server, which then sends the e-mail to the remote user. Domino correctly delivers the e-mail to the user, but with one small hitch: the Domino server time-stamps the iSeries-generated e-mail as six hours earlier than it was actually sent. The iSeries and Domino servers are both in Chicago, which is in the Central Standard time zone.

Here's how you would fix the time-stamp problem by setting certain OS/400 system values correctly. Fortunately, the correction is an easy one. Note, however, that these settings don't just affect time-stamps for third-party products. Time synchronization relates to other OS/400-based issues as well, including time-stamps in several Operations Navigator functions, especially Management Central, as well as in Java applications that run natively on an iSeries box.

First, make sure that your hardware clock is set correctly for your local time in the HH:MM:SS format, where "HH" stands for hours, "MM" is for minutes, and "SS" is for seconds. You can change the hardware clock by changing the QTIME system value to the current time. This time should already be set correctly, as it's used for most OS/400 native functions, including time reporting in most native OS/400 commands, as well as in many native programming languages. When you need to change the QTIME setting, you can use either the Work with System Value (WRKSYSVAL) command or the Change System Value (CHGSYSVAL) command. You can also adjust the hardware clock inside of iSeries Operations Navigator (which was renamed iSeries Navigator, with OS/400 V5R2).

If you live in a daylight-saving-time zone, you have to change the QTIME system value twice a year, since IBM doesn't offer settings that automatically make these changes.

After setting the local hardware clock, you also have to change OS/400's Universal Time Coordinated Offset (QUTCOFFSET) system value to match the correct Universal Time Coordinated (UTC) offset for your geographic location. The UTC offset specifies the difference (plus or minus hours and minutes) between the current system time, as specified in QTIME, and universal time (also known as Greenwich Mean Time). Universal time is used in computer systems throughout the world for a host of issues, including time synchronization with remote servers.

The QUTCOFFSET system value is defined in a five-character format, where the first character is a plus (+) or a minus (-) sign, followed by a two-character numeric hour offset (00 through 24) and a second two-character numeric minute offset (00 through 59). The hour and the minute offsets can be separated by a colon (:) in the system value.

By default, OS/400 sets QUTCOFFSET to +00:00, which tells programs that access this value that your system's hardware clock has zero deviation (offset) from universal time. If you enter a positive offset (such as +01:00), OS/400 will use this value when communicating with remote systems, effectively telling the remote system that your actual UTC-based time can be calculated by using the current UTC time plus the UTC offset. If you enter a negative offset (such as -02:00), OS/400 will tell remote systems that your actual UTC time is the GMT time, less the offset.

To change your QUTCOFFSET value, you first need to find the proper UTC offset for your location. This can be found in many places, but the Worldtimezone.com is a good place to find it because you can look up a UTC offset by time zone. For Chicago, which is in the Central time zone, the offset is -06:00 for mid-fall and winter and changes to +05:00 in mid-spring and summer.

Once you know your offset, it's easy to change the QUTCOFFSET system value. From the green screen, you can do this by using either the WRKSYSVAL or the CHGSYSVAL command. In OpsNav, follow the system name, the configuration and service, and then the system values nodes. Also, remember that since QUTCOFFSET affects timing issues, you must also change it upward or downward twice a year if you're in a daylight-saving time zone, just as you do for your QTIME value.

As you might have guessed, the original default setting QUTCOFFSET was at the root of the e-mail problem. In the example, the iSeries box was in Chicago, where the actual UTC offset should be -06:00. When OS/400 used SMTP to send a relay message to the Domino e-mail server, it used the default UTC offset of +00:00 to tell Domino how to time-stamp the message. As a result, Domino sent out an e-mail that was time-stamped six hours earlier, to compensate for the difference between the actual UTC offset (-06:00) and the iSeries box's UTC offset (+00:00). And that's how the message wound up with the wrong time stamp. Remote computers refer to each other's UTC offsets to coordinate on time-stamping issues.

QUTCOFFSET changes take effect immediately. So, after the QUTCOFFSET was changed to -06:00 in our example, the next time the third-party server used OS/400 SMTP to relay an e-mail to its external Domino server, Domino used the correct time stamp for the e-mail, because the UTC offsets on all involved machines were set to their proper values.

But, as I mentioned, QUTCOFFSET needs to be set correctly for more than just third-party software. If you're using Management Central to control other endpoint systems, QUTCOFFSET must also be set correctly on each endpoint system you're controlling, as well as on the controlling system. Also note that, starting with OS/400 V5R2, Management Central's system values support now includes updating the QTIME and QUTCOFFSET system values on endpoint systems, based on a model system. IBM provides this support in OpsNav under system name, configuration and service, then system values.

And, starting with OS/400 V5R1, Management Central time-dependent scheduling functions and other functions that display the correct time of day require you to set an additional, specific Java time-zone value correctly. Other Java applications that use time stamps will also require your Java time-zone value to be correct. These settings are included in a slightly more involved process that IBM spells out in a Redbook Hints & Tips white paper called Setting the correct time for OS/400 Management Central and Java programs.