On Tue, 13 Mar 2012 11:46:39 +0000, Jousma, David wrote:
>I just read about that. Not sure it is too helpful, unless I am
>mis-understanding it? Time changes at 02:00 local time, based on what I
>read, the CICS clock would be off for the next 22 hours until the next local
>midnight?:
>
>AUTORESETTIME
>The AUTORESETTIME parameter specifies the action CICS should take if, at the
>next local midnight, the CICS time-of-day differs from the system time-of-day
>by more than 30 minutes; for example, setting clocks forward or back to adjust
>for summer and winter time.
>
>AUTORESETTIME={NO|YES}
>Valid values are as follows:
>NO
>CICS issues message DFHAP1500 to indicate that a CEMT PERFORM RESET command is
>required to synchronize the CICS time-of-day with the system time-of-day.
>YES
>CICS issues a PERFORM RESET command to synchronize the CICS time-of-day with
>the system time-of-day
>Note: Setting clocks back might cause end-of-day statistics to be written
>twice.
>
Sigh. Sounds like a powerful argument for performing the RESET
instantaneously instead of at midnight. Or the customer's using
auto ops to issue the RESET command every day at 01:01 and 02:01.
Why does CICS even have its own time-of-day when there's a perfectly
good system time-of-day it could use? Simpler is better. And why a
30 minute fuzz? One second should be enough to trigger a RESET.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
