Effect of day-light savings time changes on CICS - Following the MVS™ or z/OS® time change for day-light saving time, there is a time difference between the z/OS and CICS® messages. You expected CICS® to pick up the MVS time change at the next midnight boundary. But it did not, the CICS time was still off by an hour. You would like to know why CICS did not to pick up the time correctly.
CICS does not automatically update for daylight saving time. A manual reset is required.
Either restart your CICS region or enter a CEMT PERFORM RESET command to allow the CICS and MVS clocks to synchronize.
To verify if CICS is using the correct time, you can take a look at the SYSLOG. If the timestamps of the MVS messages do not coincide with the timestamps of the CICS messages, then they are out of sync. Another option could be to check the DFHIC0801 message created at midnight.
A DFHIC0801 message is created anytime the CICS local date and time is altered, such as:
* at midnight when the MVS system time is reset to zero
* at PERFORM RESET or recycle time when CICS local time and MVS system time are synchronized
The problem you are experiencing is caused by a mismatch between the CICS LOCAL TIME and the MVS SYSTEM TIME. When you enter the CEMT PERFORM RESET, CICS issues an MVS store clock (STCK) macro to obtain the MVS time and then modifies this by the local time difference, if any, thus synchronizing the CICS LOCAL TIME with the MVS SYSTEM TIME. The 'local time' CICS generally obtains and stores at specific times of day (such as midnight) is a time internal to CICS and does not result in the MVS STCK being issued, so the CICS and MVS times are not synchronized at this point. Whenever you alter the MVS time, entering the CEMT PERFORM RESET will ensure that all your applications will receive the correct time by telling CICS to obtain the new MVS system time and update its local (internal) time.
The only time everything within CICS (especially the TIMER domain) gets synchronized with the MVS time is at startup or when you enter a PERFORM RESET. It is true that CICS obtains the local time and stores it at various times, but the TIMER domain is not one of the places that updates the local time. So, a component, such as MSGUSR, that uses the TIMER domain will be using a different time, (the CICS local time) from the MVS time until you reset the time or recycle the CICS region.
The crucial point here is that only a DFHIC RESET issued outside of midnight processing causes DFHICP after ICRESETN, to drop into the code after ICKEREST. Here (and ONLY here), CICS issues the KETIM macro to RESET_LOCAL_TIME. This function obtains the current stck value, and the newly-adjusted local time from MVS, and calculates the new delta, and whether it should be added to or subtracted from GMT. It then informs the Timer Domain, and any other requesting domain. Therefore, these actions ONLY take place at CICS startup or when you enter a CEMT P RESET (or the SPI equivalent command).
For example, if CICS learns that local time is exactly 4:00:00 hours behind GMT time, then CICS will set up to do midnight processing at exactly 4:00:00 GMT which CICS knows is the same as midnight. If the local time offset is changed (that is, the MVS System time has changed), CICS is unaware of this until the RESET is done or CICS is restarted.
Therefore, CICS is still thinking the local time is still 4:00:00 hours behind GMT time and is still going to do its midnight processing at 4:00:00 GMT, although the offset may have changed. Therefore, when the DFHIC0801 message is issued for midnight processing, you will be able to tell easily if the times are not in sync.
this a great article and it would be great to have a similar article in the Wiki ;-)