PM03338: DFHTS0001 AN ABEND (CODE 0C4/AKEA) AT OFFSET X'92E' IN DFHTSPT DURING SOS

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The CICS region took abend0C4 's in DFHTSPT offset x'92E' during
  a SOS for below the line UDSA storage. The abend0C4s are
  occurring for tasks that are trying to RETRIEVE data from
  DFxxxxxx queues. DFHTSPT is processing a GET_RELEASE_SET
  request, and fails on a MVC instruction (D207 F000 AC7E) with
  Reg15 containing zeroes. This instruction is trying to copy the
  >TSIOA eyecatcher into SET storage. The SET storage should have
  been acquired from an unconditional GETMAIN in DFHTSPT.
  .
  It appears that the GETMAIN for SET storage failed, probably due
  to the task being timed-out while waiting for storage. But
  DFHTSPT issues a Lock Manager call to regain the TS lock before
  checking the response from DFHSMGF for the GETMAIN. The Lock
  Manager call uses the same parameter list as the GETMAIN so
  would overwrite the GETMAIN response.
  .
  Additional Symptom(s) Search Keyword(s):
  KIXREVWJB 0C4 S0C4 abendS0C4 TSIOA_EYECATCHER ITEMP
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All                                          *
  ****************************************************************
  * PROBLEM DESCRIPTION: DFHTS0001 0C4 exception in DFHTSPT.     *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  CICS was short on storage. A started task issued an EXEC
  CICS RETRIEVE command to retrieve the FROM data passed to
  it by the START command. Interval control called
  temporary storage to return the data. DFHTSPT issued
  a conditional getmain to acquire set storage to move the
  temporary storage data into. This failed with a reason of
  insufficient storage. DFHTSPT then called lock manager to
  release the domain lock, before calling storage manager
  to perform an unconditional getmain. This could time out or
  be purged. However, DFHTSPT then called the lock manager to
  reacquire the domain lock before analysing the response
  to the storage manager call. Since DFHTSPT is defined to
  use the same area of automatic storage for lmlm_parms
  and smgf_parms, the response and reason codes from
  the getmain were by now overwritten by those from the
  lock manager call. DFHTSPT interpreted the response as
  being one of smgf_ok, so attempted to move data into what it
  thought was the storage area from the getmain. Since no
  address was returned, this tried to move data into low-core,
  and a protection exception / abend akea took place.
  Keywords: abends0c4 abend s0c4 SOS
            smmc_insufficient_storage smgf_insufficient_storage
            msgdfhts0001 ts0001 ts 0001 abendakea
  

Problem conclusion

• DFHTSPT has been changed to define the storage for lmlm_parms as
  separate to the union of plists used by its other domain calls.
  

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:

  PM05454 UK54206 UK54207

Modules/Macros

•    DESTSQR  DFHTSPT
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R400 PSY UK54206

     UP10/02/11 P F002

• R500 PSY UK54207

     UP10/02/11 P F002

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.