Environment becomes unresponsive during the Spring DST Day

Products

• CA Automic Workload Automation - Automation Engine
• CA Automic One Automation

Issue/Introduction

At some point during the Sunday of the Spring DST change, the system becomes unresponsive.  When turning on a db=3, tcp/ip=2 trace on the WPs, the following loops over and over:

 

0250309/230105.218 -   STRT UCUREP         OPC: 0215  client=1 typ='LOG' ah-idnr=242499950 oh-idnr=0 msgnr=11329 msg-insert='C_PERIOD_TASK_NAME|00.00.0000|00:00|' vers=2
20250309/230105.218 -   EXIT UCUREP         RET: 0000000000 TIME: 0000,00001 RETTEXT=''  blkcnt=0
20250309/230105.218 -   STRT UCUREP         OPC: 0215  client=1 typ='CLNT' ah-idnr=242499950 oh-idnr=0 msgnr=11329 msg-insert='C_PERIOD_TASK_NAME|00.00.0000|00:00|' vers=2
20250309/230105.218 - U00009909 TRACE: (BINDPAR:  AH_Idnr           )                                          00007FFD35A493F8 000004
                                00000000  3295770E                             >2•w.<
20250309/230105.218 -                                        >242718002<
20250309/230105.218 - SELECT COUNT(AH_Idnr) DIVDB_Int4 FROM AH WHERE AH_TimeStamp4 is NULL AND AH_Idnr = ?
20250309/230105.218 - UCUDB32 SLCO RET 0000 HSTMT: 000001E93DBEC170 VALUE: 000001E93DBEC170 ALL:  0.00027 DB:  0.00024 ODBC:  0.00001 UDB:  0.00003
20250309/230105.218 - UCUDB Memory Information (Opc=0223): Mem Usage =         8192 (   123400192,   123408384 ), VM Size =         8192 (   114401280,    114409472 )
20250309/230105.218 - U00009909 TRACE: (DB-DATEN: DIVDB_Int4        )                                          00007FFD35A4727C 000004
                                00000000  01000000                             >....<
20250309/230105.218 -                                        >1<
20250309/230105.218 - UCUDB32 READ RET 0000 HSTMT: 000001E93DBEC170 VALUE: 0000000000000001 ALL:  0.00002 DB:  0.00000 ODBC:  0.00000 UDB:  0.00002
20250309/230105.218 - UCUDB32 CLST RET 0000 HSTMT: 000001E93DBEC170 VALUE: 0000000000000000 ALL:  0.00001 DB:  0.00000 ODBC:  0.00000 UDB:  0.00000
20250309/230105.218 -   EXIT UCUREP         RET: 0000000000 TIME: 0000,00035 RETTEXT=''  blkcnt=0
20250309/230105.218 - JPEXEC_R: set-epd-compare-ts  comp-ts=2025-03-09 16:00:00
20250309/230105.218 - JPEXEC_R: set-epd-timespan - fmode=0 ,tsp=0000000360
20250309/230105.218 - JPEXEC_R: is-timeframe-set - Yes
20250309/230105.218 - JPEXEC_R: get-next-timeframe-begin  wk-epd-compare-ts=2025-03-09 16:00:00
20250309/230105.218 - PERIODCALC: TimeFrame from in localTz=2025-03-09 12:00:00
20250309/230105.218 - PERIODCALC: TimeFrame end in localTz=2025-03-09 23:59:00
20250309/230105.218 - PERIODCALC: TimeFrame from in UTC=2025-03-09 16:00:00
20250309/230105.218 - PERIODCALC: TimeFrame end in UTC=2025-03-10 03:59:00
20250309/230105.218 - JPEXEC_R: get-next-timeframe-check  from-ts=2025-03-09 16:00:00
20250309/230105.218 - JPEXEC_R: get-next-timeframe-check  to-ts=2025-03-10 03:59:00
20250309/230105.218 - is-date-in-timeframe: wk-epd-in-timeframe-in
20250309/230105.218 - JPEXEC_R: get-next-timeframe-end  from-ts=2025-03-09 16:00:00
20250309/230105.218 - JPEXEC_R: get-next-timeframe-end  to-ts=2025-03-10 03:59:00
20250309/230105.218 - JPEXEC_R: adjust-to-timeframe  comp-ts=2025-03-09 16:00:00
20250309/230105.218 - JPEXEC_R: calc-ncck-every-add-loop  comp-ts=2025-03-09 16:00:00
20250309/230105.218 - JPEXEC_R: calc-ncck-every-add-loop  wk-ts=2025-03-10 03:01:05
20250309/230105.218 - JPEXEC_R: get-next-timeframe-begin  wk-epd-compare-ts=2025-03-09 16:00:00
20250309/230105.218 - PERIODCALC: TimeFrame from in localTz=2025-03-09 12:00:00
20250309/230105.218 - PERIODCALC: TimeFrame end in localTz=2025-03-09 23:59:00
20250309/230105.218 - PERIODCALC: TimeFrame from in UTC=2025-03-09 16:00:00
20250309/230105.218 - PERIODCALC: TimeFrame end in UTC=2025-03-10 03:59:00
20250309/230105.218 - JPEXEC_R: get-next-timeframe-check  from-ts=2025-03-09 16:00:00
20250309/230105.218 - JPEXEC_R: get-next-timeframe-check  to-ts=2025-03-10 03:59:00
20250309/230105.218 - is-date-in-timeframe: wk-epd-in-timeframe-in
20250309/230105.218 - JPEXEC_R: get-next-timeframe-end  from-ts=2025-03-09 16:00:00
20250309/230105.218 - JPEXEC_R: get-next-timeframe-end  to-ts=2025-03-10 03:59:00
20250309/230105.218 - is-date-in-timeframe: wk-epd-in-timeframe-in
20250309/230105.218 - JPEXEC_R: add-span-to-comp-ts  comp-ts=2025-03-09 16:00:00 span=00-00:60
20250309/230105.218 - JPEXEC_R: add-span-to-comp-ts-end  comp-ts=2025-03-09 22:00:00
20250309/230105.218 - JPEXEC_R: calc-ncck-every-add-loop  comp-ts=2025-03-09 22:00:00
20250309/230105.218 - JPEXEC_R: calc-ncck-every-add-loop  wk-ts=2025-03-10 03:01:05
20250309/230105.218 - JPEXEC_R: get-next-timeframe-begin  wk-epd-compare-ts=2025-03-09 22:00:00
20250309/230105.218 - PERIODCALC: TimeFrame from in localTz=2025-03-09 12:00:00
20250309/230105.218 - PERIODCALC: TimeFrame end in localTz=2025-03-09 23:59:00
20250309/230105.218 - PERIODCALC: TimeFrame from in UTC=2025-03-09 16:00:00
20250309/230105.218 - PERIODCALC: TimeFrame end in UTC=2025-03-10 03:59:00
20250309/230105.218 - JPEXEC_R: get-next-timeframe-check  from-ts=2025-03-09 16:00:00
20250309/230105.218 - JPEXEC_R: get-next-timeframe-check  to-ts=2025-03-10 03:59:00
20250309/230105.218 - is-date-in-timeframe: wk-epd-in-timeframe-in
20250309/230105.218 - JPEXEC_R: get-next-timeframe-end  from-ts=2025-03-09 16:00:00
20250309/230105.218 - JPEXEC_R: get-next-timeframe-end  to-ts=2025-03-10 03:59:00
20250309/230105.218 - is-date-in-timeframe: wk-epd-in-timeframe-in

Environment

Automation Engine version: 21.0.9 through 21.0.13; 24.4.0 and below

Resolution

This is fixed with version 21.0.15 and 24.4.1 - please note as this is a fix to the core components, all must be on the same major and minor version as well as service pack.

This is a defect caused by C_PERIOD objects and the 23 hour day.  It only happens during the Spring daylight saving time change and only appears to happen to time zones that are "less than" UTC (mostly north american time zones).  The best way to avoid this issue is to suspend C_PERIOD objects during the Sunday of the Spring DST change.  

The main goal is that C_PERIODs are suspended during the day of the daylight saving time change so that they don't have a next run that goes over the midnight threshold of that Sunday night/Monday morning.  

• You could have a queue that all C_PERIODs run in that can have max runs set to 0 on that Sunday.
• You could put a calendar and use PERIOD objects - this way the calendar is in a central place and the objects could run every day of the year except the second Sunday of March (for North America).
• You could also move tasks to schedule objects instead of C_PERIOD objects and this can help too.
• Another option is to have a schedule that is just for the Sunday of DST and suspend all C_PERIODS for the day