Yea, no problem. There are many places in CP where the timestamp doesn't get reevaluated by the current timezone. This looks like one of them. Perhaps the timestamp is a literal imbedded in the code.
I don't know if it is still the case, but the timestamp on spool files were not dynamically being reconverted to the current timezone. You would notice this behavior, if you had, for example, a spool file always arrive about 3 PM. After the timezone change, old files may now show 2 PM or 4 PM, depending on which way the timezone went, and newer files would still show 3 PM. I'm not sure if it is worth the overhead of passing "every" timestamp thru the timezone routines or not. Many cases, yes. Just some, I'm not sure of. Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 11/04/05 4:25 PM >>> We would be interested in hearing comments on this. Before we IPLed on 10/30 for the timezone change (I usually do the SET TIMEZONE command but there was also a VM/Secure upgrade happening), we regenerated CP at 14:20 EDT. At 14:46 EDT we IPLed our (z/VM 3.1) system. The timezone definitions in SYSTEM CONFIG took place and we were back one hour, but it looks like we generated CP *after* we ipled and shows it generated EST rather than EDT (see below). Is this to be expected? Any comments? q cplevel z/VM Version 3 Release 1.0, service level 0401 (32-bit) Generated at 10/30/05 14:20:29 EST IPL at 10/30/05 13:46:04 EST Ready; T=0.01/0.01 17:12:59 q timezone Zone Direction Offset Status UTC ---- 00.00.00 Inactive GMT ---- 00.00.00 Inactive EDT West 04.00.00 Inactive EST West 05.00.00 Active Ready; T=0.01/0.01 17:13:04 - Don
