02-07-2007 08:44 AM
You might have got these kind of query. This is bit diffrent. we have old tru64 box running "Digital UNIX V4.0F (Rev. 1229); Wed Jul 9 19:15:20 PDT 2003" with DUV40FB18AS0007-20020102 kit installed that is been up from 703 day. Now the one on the hp website they have link for "HP Tru64 UNIX V4.0F PK8 ". our I think pk1..question the same I can apply here without going for PK8? if not is there any easy solution for me?
The prerequisite says required is PK8.
Thanks in Advance.
02-07-2007 12:16 PM
If there is no problem after installing pk7(especially with NHD3 patches), then you can go ahead download pk8 and install.
02-07-2007 11:47 PM
Your choices are to:
1. Go to PK8 (a good idea in any case) and then install the available DST patch.
2. Make the necessary changes manually, i.e., edit the timezone source files and recompile the timezone definitions with "zic". I believe there are other threads here with details on this.
02-08-2007 07:18 AM
THANKS for the time. I am not in support of doing pk8 because We can'nt afford to fail on this one. Also I am not good at compilation stuff. is it possible that I can change the date & time manually on the system. since this box is going retire in another 6 months? is that good choice?
many many thanks
03-08-2007 07:35 AM
This makes time calculations much simpler: because the GMT/UTC time does not use DST, the timescale is continuous and each moment in time can be uniquely identified, even when the local time "falls back" in DST->Standard transition and one hour is "doubled" according to local time. When a file is created during that doubled hour, the system can still tell you whether the file was created during the DST or the Standard "version" of the hour.
All the timestamps in the filesystem are internally stored in Unix time_t format, for example.
If you change the system's idea of local time according to the new rules without changing the timezone information, you'll skew the system's idea of GMT/UTC time by one hour. When the old rules say it's time to transition to DST, you need to change the system time again.
After this, the system's idea of UTC time will again agree with the true UTC. You'll also have introduced *two* breaks to the system's UTC timescale, which normally has *never* any breaks at all. One of the breaks will be "spring forward" and the other "fall back" type. So there will be non-unique timestamps and files created up to one hour "in the future".
So, if you cannot get official patches for your OS version, I'd recommend you edit the timezone definition and use the "zic" command to make the changes available to the system.
This is why the "zic" command is included into the OS: so you won't be dependent on the vendor patches if the DST rules change.
In some countries, the government used to decide the times of DST transitions independently for each year. Unix admins in these countries have dealt with that, by editing the timezone definitions whenever necessary.