Troubleshooting
Problem
Following the MVS or z/OS time change for daylight 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.
Cause
The problem you are experiencing is caused by a mismatch between the CICS LOCAL TIME and 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.
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.
CICS will not automatically issue the PERFORM RESET if you do not have the system initialization table (SIT) parameter AUTORESETTIME set to YES.
Resolving The Problem
If you change the MVS system time-of-day at any other time than midnight and you have a CICS region running, then you should immediately enter a CEMT PERFORM RESET (or EXEC CICS RESETTIME) command to synchronize the CICS time-of-day with the system time-of-day. You should not wait until midnight to synchronize the CICS and system time-of-day. If CICS is down when you change the system time-of-day then the CICS time-of-day will be reset automatically when you bring CICS back up.
If you set the CICS SIT parameter AUTORESETTIME to YES, CICS automatically issues a PERFORM RESET command to synchronize the CICS time-of-day with the system time-of-day at the next local midnight. That is, if the CICS time-of-day differs from the system time-of-day by more than 30 minutes. So, if you reset the MVS system time just before midnight then you will not have to enter CEMT PERFORM RESET in your CICS regions.
If you set the CICS SIT parameter AUTORESETTIME to NO or let it default to NO, CICS does not automatically update the CICS time-of-day. 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.
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. 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 system time-of-day and CICS time-of-day need to be synchronized on your CICSPlex SM (CPSM) CMAS and WUI server address spaces as well. Failure to do so could result in symptoms such as abend AICG or BATCHREP commands receiving timeout.
To verify if CICS is using the correct time, you can look at the SYSLOG. If the time stamps of the MVS messages do not coincide with the time stamps of the CICS messages, then they are out of sync. Another option could be to check the DFHIC0801 message created at midnight. You will see a DFHIC0801 message anytime the CICS local date and time is altered, such as:
- at midnight when the MVS system time-of-day is reset to zero
- at PERFORM RESET or recycle time when CICS local time-of-day and MVS system time-of-day are synchronized
Related Information
Product Synonym
CICS/TS CICS TS CICS Transaction Server
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21109779