PM82504: S0C1 ABEND AT OFFSET X'0840' IN MODULE DFHDSDS4

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• In the trace there is a task that is attempting to
  purge another task. However, in the time that the task
  is being cancelled, it issued a Change_Mode:
  .
  Prior to this Cancel_Task completing task, the purged
  task is running ABTERM_ALLOWED. It then does a change_mode to
  the QR:
  .
  QR    DS 0002 DSAT  ENTRY CANCEL_TASK
  L818Z DS 0002 DSAT  ENTRY CHANGE_MODE
  L818Z DS 0016 DSDS3 ENTRY PARTITION_EXIT
  .
  We have code in DFHDSAT for this Cancel_Task processing when the
  task is determined to be running_abterm_allowed. If the task
  that is being cancelled is running_abterm_allowed then its
  status is changed to cs_abterm_pending. When the purging task
  tried to purge a task (Cancel_task) it sees that the task is
  currently  running_abterm_allowed so it changed the tasks state
  to cs_abterm_pending. However, the issue comes in when this task
  does a change_mode to the QR tcb making itself dispatchable.
  .
  The DTA+X'44' is the Task_State. Currently the state is
  03AB0000. The 03 means that it is dispatchable and the AB means
  it is running abterm. When the Cancel_Task put the task in
  cs_abterm_pending, it made the Task_State = 04AB0000 (04
  indicates that the task is running_abterm_ allowed). So here is
  where we see the problem.
  .
  When CICS issues the Compare and Swap (CS) in DFHDSDS4 we get
  the 0C1 abend because we are expecting the state to still be
  04AB0000. When the CS is issued we are expecting both of the
  operands in the instruction to be the same value. But in this
  case, it is not, because of the change_mode that was issued in
  between the Cancel_Task being issued and the CS instruction in
  DFHDSDS4 running.
  .
  In the section of code where these instructions are issued, if
  both the operands in the CS were equal (which we are expecting
  them to be) then we do some other processing and branch to
  another section of code. However if the operands are not equal,
  it does not branch to this section of code, it falls through to
  the x'0000' and it causes an 0C1 abend.
  .
  The CS instruction is BAB2 9044
  .
  This is a timing problem. There just happened to be a change
  mode when the task was purged. Usually when a task is purged it
  doesn't change state in the small window between the Cancel_Task
  starting and finishing. This time it happened to occur, so the
  0C1 happens. So CICS will have to be able to look out for these
  kinds of situation and adjust accordingly. It will need to react
  to this in a manner other than causing an 0C1 abend.
  Additional Symptom(s) Search Keyword(s):  KIXREVCTC
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All.                                         *
  ****************************************************************
  * PROBLEM DESCRIPTION: Abend 0C1 in DFHDSDS4.                  *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  This problem is happening when a pipeline application is being
  purged.
  The pipeline task will drive DFHPITP and this then calls
  DFHPITL. If the purge occurs and then is deferred because the
  task is not in a purgeable state, the tasks stack has its R14
  changed. When DFHPITL returns to DFHPITP it switches to abterm
  allowed, but because R14 has been changed in the tasks stack
  the task now branches into CICS code running abterm allowed,
  which should never happen and then if the task is purged
  for a second time the abend0C1 occurs.
  

Problem conclusion

• Changes made to DFHPITP and DFHPITL so that DFHPITL will only
  return to DFHPITP running abterm allowed, if on entry to DFHPITL
  it was running abterm allowed.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

• ž**** PE13/04/15 FIX IN ERROR. SEE APAR PM86985  FOR DESCRIPTION
  

APAR Information

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

  PM78746

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

  UK92314

Modules/Macros

• DFHPITL  DFHPITP
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R800 PSY UK92314

     UP13/03/15 P F303

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.