I posted a note about Powerhouse 7.29C8 and the hardware clock previously
but it seems to have got lost and it doesn't appear in the
list archives. I mentioned it in a subsequent post and Gilles Schipper
asked for more info. I had my e-mail to him returned for some reason so I
am reposting it here. I beg your indulgence for the bandwidth use.
Hi Gilles,
I cannot find my original note and the archives don't seem to have a copy
(maybe it didn't get to the list after all....) so I have recreated it
(roughly).
While testing Powerhouse 7.29C8 for year 2000 compliance, I had some
significant problems. It turns out that 7.29C8 is the first version of
Powerhouse to use the Hardware clock instead of the software clock. What
this means is that reports will show a different time (and possibly date)
unless your hardware clock is in synch with the software clock. The
following is an extract from the Cognos Powerfacts :
***************************************************************************
********************************
PowerHouse 729C8 returns the wrong date for SYSDATE if clocks are not
synchronized
Solution Description
This document is available as part number 20625 and should be ordered when
requesting PH729C8 or higher.
Set hardware to be the right date and time.
PowerHouse 729C8 uses the hardware clock
The fixes for the century 2000 data conversion problems were achieved by
reading the hardware clock instead of using the iX intrinsic CALENDAR.
Clients using
this fix must ensure that the hardware clock is set correctly. The
underlying SYSDATE software is sensitive to the value in the environment
variable, TZ.
EST5EDT is the default. On the other hand, SYSTIME is based on the software
clock which is not sensitive to the value in the environment variable, TZ.
Therefore, it is imperative that that the software clock and the hardware
clock
be synchronized to the second and if you are not in the Eastern Time Zone
that the right TZ variable be used.
Appendix A of the HP/XL C Library Reference Manual contains a list of
commonly used time zones and the TZ environment variable strings that
correspond to
these time zones. They are also listed at the back of this document.
The TZ strings can used by the time and date library functions for
adjustment to specific time zones. Refer to the description of the ctime
function in chapter 3 of
HP/XL C Library Reference Manual for details.
The first line of each entry contains the time zone name followed by the
Daylight Savings Time zone name, if appropriate. The next few lines contain
the geographic
locations associated with this time zone. The last line contains the TZ
environment variable string that corresponds to this time zone. These can
also be found in the
file TZTAB.LIB.SYS.
e.g.
Hawaiian Standard Time, Hawaiian Daylight Time
United States: Hawaii
HST10
Setting the TZ variable:
Signon to MANAGER.COGNOS,CURRENT
Make sure the ANY has read and execute permission to CURRENT.
Create a file called TZSET.CURRENT.COGNOS
Comment if you are living in Hawaii
Echo SETVAR TZ ?HST10? > TZSET.CURRENT.COGNOS
Add the following line in the SETPOWERHOUSE udc:
TZSET.CURRENT.COGNOS
ISL Boot Utilities
The system uses bootable ISL utilities to either load the system from tape
or to start the system from disk. The current boot utilities are START,
UPDATE,
INSTALL, and DUMP. There are additional utilities for system management:
SADPATCH, DISCUTIL, CLKUTIL, SAT, CAEXR, and IOMAP.
Reading and setting the hardware clock
The ISL utility CLKUTIL reads and sets the battery backed-up hardware
clock. This clock maintains Greenwich Mean Time (GMT) independently of the
software clock that is displayed when you enter the ISL START utility or
any of the other ISL utilities that support the software clock. The CLKUTIL
utility,
therefore, reads the date and time that were previously set with CLKUTIL,
but does not itself reflect the changes that you may make while in any
other ISL utility.
The hardware clock should be set to GMT if the clock displays are to be
correct on the booted system. The hardware clock provides the basis for
time displays
that are part of some ISL utilities.
When the local time is entered during particular ISL utilities, the system
computes an offset and stores it in stable storage. During a boot, the GMT
and this offset
are combined to produce the local time, displayed on the console.
To read or set the hardware clock, enter:
ISL> CLKUTIL
The system responds with the following banner:
SYSTEM FOR ISL STAND ALONE UTILITIES. [IHO, SPU LAB]
Version 1.0
****** clock utility ************ ver 1.0 ***** 11/6/86
enter command : (r) read clock, (s) set clock >
To read the GMT time from the hardware clock, enter r at the CLKUTIL
prompt:
enter command : (r) read clock, (s) set clock > r
The system responds with a message similar to the following:
THU, JAN 1, 1988, 9:00:16 AM
If the GMT time is wrong, use the s option to set it.
To set the clock, enter s at the CLKUTIL prompt:
enter command : (r) read clock, (s) set clock > s
The system responds with a message similar to the following:
enter date mm/dd/yyyy
When the enter date prompt appears, enter the date in the correct format:
mm is a two-digit number, 1-12, representing the month;
dd is a two-digit number, 1-31, representing the day of the month;
yyyy is a four-digit number representing the year.
(You can also enter just the last two digits for the year.)
The system continues by issuing the following prompt:
enter time hh:mm:ss
Enter the time using Greenwich Mean Time in 24-hour format.
The system requests verification of the adjusted date and time by issuing a
message similar to the following:
THU, JAN 7, 1988, 11:17:00 PM
ok (y/n)?
Entering Y returns a message of:
clock set!
Entering N returns you to the enter date prompt.
Pressing Return at the enter command prompt returns you to the ISL prompt.
What if the GMT entered is right but the offset is wrong? Answer: Do a soft
boot of the system and enter the correct local time. This will cause
MPE/iX to
recalculate the offset.
If the SYSDATE is still wrong in PowerHouse check with HP for further
assistance.
HP has a unsupported utility called SHOWCLKS.PUBXL.TELESUP.
We are in the Eastern time zone and we use daylight savings time. So that
puts us 4 hours behind Greenwich. During the winter we are 5 hours behind
Greenwich.
Our MPE Systime Time is equal to CTIME function time.
Except for Newfoundland and Central Australia the offset from GMT
should be a even number of hours. Those other two places should have
offsets on the half hour.
Here is the output when the clocks are set correctly:
SHOWCLKS/XL A.10.00
DEBUG/iX B.30.45
HPDEBUG Intrinsic at: 46c.00007258 PROGRAM+$198
PRIV=$3 := $0
*************************************************************
*** ***
*** Greenwich Mean Time : THU, AUG 28, 1997, 2:11 PM ***
*** GMT/MPE offset : -4:00:00 ***
*** MPE System Time : THU, AUG 28, 1997, 10:11 AM ***
*** ***
*************************************************************
**** C Library Information ****
Current value of Time Zone(TZ) variable : NOT ASSIGNED
CTIME function return : Thu Aug 28 10:11:31 1997
Here is one from a machine that does not have GMT set
correctly:
SHOWCLKS/XL A.10.00
DEBUG/iX C.05.08
HPDEBUG Intrinsic at: 504.00007258 PROGRAM+$198
PRIV=$3 := $0
*************************************************************
*** ***
*** Greenwich Mean Time : THU, AUG 28, 1997, 3:25 PM ***
*** GMT/MPE offset : -5:00:00 ***
*** MPE System Time : THU, AUG 28, 1997, 10:25 AM ***
*** ***
*************************************************************
**** C Library Information ****
Current value of Time Zone(TZ) variable : NOT ASSIGNED
CTIME function return : Thu Aug 28 11:25:49 1997
The person who booted this system forgot about daylight savings
time. And thus calculated GMT incorrectly. It maybe useful
to have a wall clock in the machine room which displays
GMT so that mistakes like this do not occur. We can see that CTIME is a
hour ahead of the MPE System Time.
This means at 11:00PM the date will roll over into the new day
but the time will not until an hour later. So if in PowerHouse 729C8
we were recording current date time data with the following formula:
DEFINE dt DATETIME = sysdate + systime/100000000
At 11:00 PM
dt = 1997/08/28 22:59:58
dt = 1997/08/28 22:59:59
dt = 1997/08/29 23:00:00
dt = 1997/08/29 23:00:01
dt = 1997/08/29 23:00:02
At midnight
dt = 1997/08/29 23:59:58
dt = 1997/08/29 23:59:59
dt = 1997/08/29 00:00:00
dt = 1997/08/29 00:00:01
dt = 1997/08/29 00:00:02
The dt values calculated between 11:00PM and midnight are almost 24 hours
out of sync.
Some commonly used TZ values
>From Appendix A of the HP/XL C Library Reference Manual.
Hawaiian Standard Time, Hawaiian Daylight Time
United States: Hawaii
HST10
Aleutian Standard Time, Aleutian Daylight Time
United States: Alaska (parts)
AST10ADT
Yukon Standard Time, Yukon Daylight Time
United States: Alaska (parts)
YST9YD
Pacific Standard Time, Pacific Daylight Time
Canada: British Columbia.
PST8PDT - Canada
Pacific Standard Time, Pacific Daylight Time
United States: California, Idaho (parts), Nevada, Oregon (parts),
Washington.
PST8PDT
Mountain Standard Time, Mountain Daylight Time
Canada: Alberta, Saskatchewan (parts).
MST7MDT - Canada
Mountain Standard Time, Mountain Daylight Time
United States: Colorado, Idaho (parts), Kansas (parts), Montana,
Nebraska (parts), New Mexico, North Dakota (parts), Oregon (parts),
South Dakota (parts), Texas (parts), Utah, Wyoming.
MST7MDT
Mountain Standard Time
United States: Arizona
MST7
Central Standard Time, Central Daylight Time
Canada: Manitoba, Ontario (parts), Saskatchewan (parts).
CST6CDT - Canada
Central Standard Time, Central Daylight Time
United States: Alabama, Arkansas, Florida (parts), Illinois, Iowa,
Kansas, Kentucky (parts), Louisiana, Michigan (parts), Minnesota,
Mississippi, Missouri, Nebraska, North Dakota, Oklahoma, South Dakota,
Tennessee (parts), Texas, Wisconsin.
CST6CDT
Eastern Standard Time, Central Daylight Time
United States: Indiana (most)
EST6CDT
Eastern Standard Time, Eastern Daylight Time
Canada: Ontario (parts), Quebec (parts).
EST5EDT - Canada
Eastern Standard Time, Eastern Daylight Time
United States: Connecticut, Delaware, District of Columbia, Florida,
Georgia, Kentucky, Maine, Maryland, Massachusetts, Michigan, New
Hampshire, New Jersey, New York, North Carolina, Ohio, Pennsylvania,
Rhode Island, South Carolina, Tennessee (parts), Vermont, Virginia,
West Virginia.
EST5EDT
Atlantic Standard Time, Atlantic Daylight Time
Canada: Newfoundland (parts), Nova Scotia, Prince Edward Island,
Quebec(parts).
AST4ADT
Newfoundland Standard Time, Newfoundland Daylight Time
Canada: Newfoundland (parts).
NST3:30NDT
Western European Time, Western European Time Daylight Savings Time
Great Britain, Ireland
WET0WETDST
Portuguese Winter Time, Portuguese Summer Time
PWT0PST
Mitteleuropaeische Zeit, Mitteleuropaeische Sommerzeit
MEZ-1MESZ
Middle European Time, Middle European Time Daylight Savings Time
Belgium, Luxembourg, Netherlands, Denmark, Norway, Austria, Poland,
Czechoslovakia, Sweden, Switzerland, DDR, DBR, France, Spain, Hungary,
Italy, Yugoslavia
MET-1METDST
South Africa Standard Time, South Africa Daylight Time
SAST-2SADT
Japan Standard Time
Japan
JST-9
Australian Western Standard Time
Australia: Western Australia
WST-8:00
Australian Central Standard Time
Australia: Northern Territory
CST-9:30
Australian Central Standard Time, Australian Central Daylight Time
Australia: South Australia
CST-9:30CDT
Australian Eastern Standard Time
Australia: Queensland
EST-10
Australian Eastern Standard Time, Australian Eastern Daylight Time
Australia: New South Wales, Victoria
EST-10EDT
Australian Eastern Standard Time, Australian Eastern Daylight Time
Australia: Tasmania
EST-10EDT - Tasmania
New Zealand Standard Time, New Zealand Daylight Time
NZST-12NZDT
PART # 20625
***************************************************************************
************
Gilles,
One thing I didn't realise was that each time I used the SETCLOCK
command to change the date for some further testing, the Hardware
clock was reset too based on the Timezone. Also, the TZ variable
would be cleared. If the TZ variable is NOT ASSIGNED, the "CTIME"
value becomes invalid. I gained some more valuable clock setting
information from two previous posts, one from Holger Wiemann
([log in to unmask]) on 9 Jan 1997 and another
from Damian Coffey ([log in to unmask]) on 27th Aug 1996.
Based on their information, I used the SHOWCLKS program to show
the appropriate values and ensured that I set the TZ variable each time
the date was changed. This enabled me to complete the testing
for year 2000 compliance successfully. I do have an issue with the
method Cognos used to get round the date problem as sites situated
in timezones well away from GMT will have a large discrepancy with
their software clock and their Powerhouse date reporting but that's
another issue.
Cheers,
John Dunlop
Work : [log in to unmask]
Home : [log in to unmask]
Web Site : http://www.tcp.co.uk/~jdunlop/index.html
|
