PI57780: CSSY RESPONSE TIMES AND COUNTS

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Monitoring data shows a high number of CSSY tasks.
  Besides there being a high number of tasks,
  their average response time is almost half a second.
  For example, one customer encountered about
  one CSSY task per minute per CICS region.
  They had an average response time of 0.4 seconds per task.
  This put the CSSY tasks consistently as the longest
  running tasks in their system.
  .
    Transaction CSSY is an internal CICS task.
  It can be started for many different reasons.
  In this case, most of the tasks were attached
  by DFHAPATT to check for a clock mismatch
  because of SIT option AUTORESETTIME=IMMEDIATE.
  With this option set, each time a task is dispatched
  or DFHZDSP runs in a TOR (after APAR PI39631)
  CICS checks to see if its clock is different
  than the system clock.  If it is, it attaches
  a CSSY task to do more checking to see if CICS needs
  to automatically adjust its clock.
  The code only compares hours, minutes and seconds
  but no subseconds (HHMMSS).  The CSSY may be attached
  when the check happens at about the same time
  as the clock is changing from one second to the next.
  In that case the CICS clock and system clock
  may be on either side of the second boundry,
  for example
  CICS   clock = 10:11:11.9999
  System clock = 10:11:12.0001
  In this case, because the subsecond values are not used,
  the compare thinks the timestamps may be different.
  A CSSY task is attached to look at it further.
  The first thing the CSSY task does
  is delay itself for 0.2 seconds.
  This allows both clocks to get closer to the middle
  of a second time.  Then, the compare would match
  and the CSSY task would simply end
  without taking any action.
  .
    This APAR is being taken to investigate whether
  the code could be changed
  - to use math to look at  the difference between the clocks
  - instead of a simple compare.
  The math could detect that there is less than one second
  difference between the clocks
  and avoid attaching the CSSY tasks at all.
  That would save the time taken to attach, run and terminate
  all of the CSSY tasks.  It would also remove the large
  number of CSSY tasks from the monitor reports
  so that they don't impact customer research time
  to see what the tasks are for.
  KIXREVDWZ
  

Local fix

•   Ignore the monitor report.
  The response time delay is part of normal processing
  for CSSY tasks started for clock checking.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All.                                         *
  ****************************************************************
  * PROBLEM DESCRIPTION: Excessive attaches of system task CSSY. *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  This problem presents when the AUTORESETTIME=IMMEDIATE SIT
  parameter is in use.
                                                                 .
  When AUTORESETTIME=IMMEDIATE is coded, DFHAPIN will test the
  MVS and CSA clocks to a granularity of seconds.  If they are
  out by 1s or more then it attaches a CSSY system task to
  investigate the mismatch further and possibly do a DFHIC reset
  if the mismatch is a genuine one.  As would be the case when
  the MVS time is adjusted forwards or backwards, or when a
  leap second adjustment is made within MVS.
                                                                 .
  However, if the MVS and CSA times are at different seconds but
  the difference is less than a second, for example:
  MVS Time   = 11:33:15.00
  CSA Time   = 11:33:14.99
  Difference = 0.01 seconds.
  then currently DFHAPIN would still attach a CSSY task - even
  though the real difference is only 0.01 of a second.  This is
  unnecessary and could be avoided by DFHAPIN filtering out
  these perceived mismatches prior to attaching a new CSSY system
  task.
  Keywords: CVTLSO CVTLSOH CVTLSOL
  

Problem conclusion

• DFHAPIN has been modified and will now attach a CSSY task if
  the CICS and MVS times differ because of leap second
  adjustment, or for all cases unless the MVS time appears only
  one second ahead.
                                                                 .
  The following change will be made to the CICS Transaction
  Server for z/OS Version 4 Release 2 Data Areas Manual
  GC34-7163-01.
                                                                 .
  The CSA ( DFHCSAPS ) will be updated as follows:
                                                                 .
  A new bit CSALSADD will be added within byte CSAICIND thus:
                                                                 .
  Offset  Type      Len    Name(Dim)  Description
  (5B)    11.. ....        *          Reserved
  (5B)    ..1. ....        CSALSADD   Leap Second Adjustment
                                                                 .
  In addition, a previously unused 2 byte field ( following
  CSACPSMW ) will now be named field CSALSO thus:
                                                                 .
  Offset  Type      Len    Name(Dim)       Description
  72      Character 2      CSALSO          Leap seconds offset
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  PI58559 PI58560 UI38224

Modules/Macros

• DFHAPIN  DFHCSAD  DFHSIA1
  

Fix information

• Fixed component name

  CICS TS Z/OS V4

• Fixed component ID

  5655S9700

Applicable component levels

• R700 PSY UI38224

     UP16/06/03 P F606

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.