Here's the response as it appeared on vse-l this past January: 1)Setting the clock forward There are no known CICS problems when the clock is set forward by one hour. There is no need to shut CICS down and restart it. Once the time has been reset on VSE, the CEMT PERFORM RESET command should be issued to synchronise the CICS date and time of day with that of the system. This command also adjusts the expiry time in any pending Interval Control requests for transaction start or task delay requests.
If this CICS command is not issued, then it means that CICS will be out of synch with the time that VSE has -- it should not cause any data integrity problems from a CICS standpoint, but could affect time dependent application programs. If the command is not issued, then the time held by CICS will be one hour behind the system until either midnight or when CICS is next restarted -- this is because CICS automatically synchronises its time and date with that of the system at startup, and once per day at midnight. 2)Setting the clock back However, there is the risk of a problem when clocks are set back by one hour if CICS is not shutdown and restarted. The risk is that if the CICS time is reset online via the PERFORM RESET command and a CICS failure occurs before a wrap-around of the system log has occurred, then an emergency restart of CICS would not necessarily recover all in-flight transactions and there would be a data integrity exposure. The reason for this is that during its recovery processing CICS reads backwards from the most recent record in the system log and would find a log record time stamped more recent than the one it had just read. At this point it would stop reading the system log, thereby not doing any backout for in-flight transactions prior to that point. In addition to the risk of an "unsafe" CICS restart, the log(s) containing the disjoint time stamped records could cause problems with forward recovery utilities that use the log(s) -- such as the CICS VSAM Recovery (CICSVR) product and the DL/I forward recovery utilities. There would not be any problem with CICS emergency restart if at the time of CICS failure a wrap-around of the log had occurred, as the out of sequence log records would have been overwritten. However, the risk would still exist in doing any forward recovery based on any archived logs containing records with inconsistent time-stamps. The risk with CICS emergency restart could be avoided by doing a normal shutdown of CICS, changing the VSE time, and restarting CICS. But again, the risk would still exist in doing any forward recovery based on any archived logs. So, the only absolutely safe action when setting the clock back one hour is to: 1) Perform a normal shutdown of CICS 2) Change the VSE system time 3) Wait one hour so that when CICS next starts the time is at least that when it shutdown 4) Restart CICS On Tuesday 29 October 2002 02:27 pm, Mark Perry wrote: > Hi Rich, > not being either a VSE or a CICS type of person, I was surprised about your > comment "CICS journalling and warm start data tends to get a little ornery > about the clock going backward" - is there no way to make CICS use GMT/UTC > rather than local time for such important things as journaling? > > Ciao > Mark -- Rich Smrcina Sytek Services, Inc. Milwaukee, WI [EMAIL PROTECTED] [EMAIL PROTECTED] Catch the WAVV! Stay for Requirements and the Free for All! Update your S/390 skills in 4 days for a very reasonable price. WAVV 2003 in Winston-Salem, NC. April 25-29, 2003 For details see http://www.wavv.org
