Fixing Your System Clock with COBOL
Back when I was doing Y2K application software, one of the most common things that came up was the fact that people didnt 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 didnt 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 its 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. Its 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 dont 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 Ive 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 arent 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. Ill 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:
Shawn Gordon, whose S.M. Gordon & Associates firm supplies HP 3000 utilities, has worked with 3000s since 1983.
Copyright The 3000 NewsWire. All rights reserved.