Back when I was doing Y2K application software, one of the most common things that came up was the fact that people didn’t have their system clocks set up right. There are a number of parameters involved, such as having the time zone correct, and the TZ variable correct. An example of where this can cause serious trouble is with the PowerHouse software family. They use the hardware clock and software clock for the date and time (I forget which is used for which). In any case, you could easily get the wrong date for the time if you didn’t have the TZ variable set up, and the time zone on your system was messed up.

Well, you can do a lot of this stuff manually, but I wrote a COBOL program to basically walk a user through the steps of getting the time right. It uses some neat things like the rather difficult-to-find BITMAPCNV intrinsic. This is documented in the VPlus manual, so it’s hard to find.

Basically BITMAPCNV will take a bitmask and convert it to a byte array. Since I needed to know if the user had SM or OP to issue the SETCLOCK commands, I needed to call the WHO intrinsic and figure out if they had either of those capabilities. By converting to a byte string, the process becomes very simple and saves a lot of effort. It’s possible that there are other ways to do this now — but you know how it is when you have figured something out and just keep using it.

The program also makes use of the MOVE FUNCTION CURRENT DATE to get a date format that takes into account the TZ variable. We compared this to what is returned to the old time intrinsics for returning date and time values to see if there is a discrepancy in what is currently on the system.

Figure 1 below shows the dialog that goes on if the hardware and software clocks don’t match. The TIMEZONE portion is usually the difficult part to get right, and this value can take a very, very long time to adjust if you let it go GRADUAL. There is actually no way to make the TIMEZONE adjustment be NOW, like setting the clock. However there is an interesting side affect of issuing a CANCEL against a TIMEZONE adjustment. It causes the TIMEZONE adjustment to be immediately executed. So that is what I’ve done in this example.

The Kompany: run clockfix.pub.timewarp

Current offset from GMT: -04:00

No TZ variable is set, I will show you the correct value,
after you answer some questions.

WARNING: Hardware clock doesn't match the software clock
Hardware clock = 11:08
Software clock = 08:08

Is it currently Daylight Savings Time? Y
Please select one of the following as your TimeZone

1.  Eastern European Time (EET-2DST)
2.  Middle European Time  (MET-1DST)
3.  Western European Time (GMT0BST)
4.  Atlantic Time (AST4ADT)
5.  Eastern Time  (EST5EDT)
6.  Central Time  (CST6CDT)
7.  Mountain Time (MST7MDT)
8.  Pacific Time  (PST8PDT)
9.  Yukon Time    (YST9YDT)

     Enter Option: 8

I am now ready to fix your hardware clock.
Choose one of the following options
1. Gradually change the time over an hour
2. Change the time immediatly

    Enter Option: 2
SETCLOCK TIMEZONE=W7:00


SYSTEM TIME: TUE, JUL 18, 2000,  8:09:19 AM
CURRENT TIME CORRECTION:            0 SECONDS
TIME ZONE:    7 HOURS  0 MINUTES WESTERN HEMISPHERE

SETCLOCK;CANCEL

CORRECTION OF            0 SECONDS HAS BEEN CANCELLED.

SETCLOCK DATE=07/18/2000;TIME=08:09 ;NOW


You will want to set up the following command as a system logon UDC;
SETVAR TZ,"PST8PDT "

Normal termination at 08:09:00

END OF PROGRAM
The Kompany: SHOWCLOCK

SYSTEM TIME: TUE, JUL 18, 2000,  8:09:10 AM
CURRENT TIME CORRECTION:            0 SECONDS
TIME ZONE:    7 HOURS  0 MINUTES WESTERN HEMISPHERE

The Kompany: SHOWTIME
TUE, JUL 18, 2000,  8:09 AM
The Kompany:

Our main source code example is online this month. There aren’t any huge tricks in it, other than knowing the different intrinsic calls to get the information you need. In the example, you will notice the HPCIGETVAR intrinsic is used to retrieve the value of the TZ variable, if it exists and has a value in it. Also, the example makes good use of the STRING verb to get our SETCLOCK command formatted “all nice and purty.”

This is a pretty useful tool. I’ll give you one other gem that has nothing to do with COBOL, but it does have to do with keeping your timezone in sync, an issue in the countries that practice Daylight Savings Time (which ends on Oct. 29 this year). I put this in my batch scheduler, to run every Sunday, to tell my HP 3000 when to change the time:

IF HPMONTH = 10 AND HPDATE > 24 THEN
ECHO We are going back to Standard Time
SETCLOCK TIMEZONE = W8:00
ENDIF
IF HPMONTH = 4 AND HPDATE < 8 THEN
ECHO Setting clock for Daylight Savings Time SETCLOCK TIMEZONE = W7:00
ENDIF

I’m on the West coast, so adjust the TIMEZONE value to your own time zone.

Shawn Gordon, whose S.M. Gordon & Associates firm supplies HP 3000 utilities, has worked with 3000s since 1983.