PH30791: DFHSM0133 CICS SOS SHORT ON STORAGE DUE TO LARGE GETMAIN FOR SUBPOOL RZGENRAL OUT OF DFHRZRJ

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• CICS region goes short on storage DFHSM0133 due to huge getmain
  for subpool RZGENRAL out of DFHRZRJ.
  
  Trace leading up to the failing GETMAIN:
  SM 0301 SMGF  ENTRY - FUNCTION(GETMAIN) SUBPOOL_TOKEN(659CA818 ,
  0000004D) GET_LENGTH(22100008) SUSPEND(YES) REMARK(RZTCSEND)
  TASK-85300 KE_NUM-006E TCB-C/QR   /008FC0F0
  RET-A203CF84 TIME-14:20:50.4154365830 INTERVAL-00.0000003159
  
  SM 1206 SMPQ  *EXC* - Insufficient_storage_to_satisfy_request -
  FUNCTION(ALLOCATE_PAGEPOOL_STORAGE) SUBPOOL_TOKEN(659CA818)
  GET_LENGTH(22100010) SUSPEND(YES)
  TASK-85300 KE_NUM-006E TCB-C/QR   /008FC0F0
  RET-2163E1A1 TIME-14:20:50.4154478935 INTERVAL-00.0000113105
  2-0000  D9E9C7C5 D5D9C1D3 *RZGENRAL                        *
  3-0000  C5C3C4E2 C1404040 *ECDSA                           *
  
  You will see that the failing task is suspended for ECDSA
  storage:
  ==SM: Suspend queue summary
  
     KE Task  Tran #  Susptok  Subpool  DSA       Request
  
     22DC1000 0085300 058E495F RZGENRAL ECDSA     571473936
  .
  Task 85300 was timed out from its suspend.  DFHRZRJ did set an
  exception response, but instead of performing any further error
  handling the normal processing continues.  We can see the RZRS
  RECEIVE_REPLY call failing, but the subsequent getmain is still
  done.  This uses a residual value from the parameter list as the
  length.  This first getmain manages to work.  There are then
  further failures because there isn't actually a reply message to
  process.  Then another getmain is issued for the same residual
  length value and that causes the SOS condition.
  
  This was created for Salesforce case TS004356317.
  Additonal Keywords and Symptoms:
  KIXREVSCB
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users                               *
  ****************************************************************
  * PROBLEM DESCRIPTION: SOS in RZGENRAL after a WS-AT task      *
  *                      times out waiting for a reply.          *
  ****************************************************************
  CICS is acting as a web service provider.  The PIPELINE is
  configured to use WS-AT (Web Service Atomic Transactions).  When
  a request is received the use of WS-AT causes a context switch
  to occur and a new task to be attached to run the user
  application.  This transaction is defined to be remote in an
  AOR.  The request is routed to the AOR using request streams.
  After the request has been processed the application task
  remains in the AOR to wait for the next request or WS-AT
  protocol message.
  
  A second web service request is sent in.  This needs to join the
  existing application task running in the AOR.  The request is
  sent to the AOR using request streams and DFHRZJNP (remote join
  program) passes the request to the application task and then
  waits for the reply.
  
  The application task gets delayed for an extended period.  This
  causes the suspend issued by DFHRZJNP to be timed out due to
  hitting its DTIMOUT limit.  Instead of stopping at this point,
  processing continues using residual values.  This leads to
  very large getmains for storage in the RZGENRAL subpool, which
  can lead to SOS.  The trace will also show several exceptions
  from RZ domain routines due to trying to process invalid data.
  

Problem conclusion

• DFHRZJNP has been updated to issue an ARZR abend if any of the
  calls it makes fail.
  
  The CICS TS 5.5 and 5.6 Knowledge Centers will be updated to
  document the new ARZR abend code as follows;
  
  ARZR
  
  Explanation
  A request stream task encountered a failure while trying to join
  with an existing target request stream task.  This may be caused
  by the existing target task taking too long to respond and the
  new task reaching its DTIMOUT limit.
  
  System action
  The transaction is abnormally terminated with abend code ARZR.
  CICS takes a transaction dump, unless module DFHDUIO is not
  loaded.
  
  User response
  Use the transaction dump to determine the cause of the failure.
  For further assistance, or if module DFHDUIO is not loaded and
  no transaction dump is available, contact your system
  programmer.
  
  Module
  DFHRZJN
  

Temporary fix

Comments

APAR Information

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

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

  UI73219 UI73220

Modules/Macros

• DFHPIPM  DFHRZJN  DFHRZRJ
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R200 PSY UI73220

     UP20/12/19 P F012

• R300 PSY UI73219

     UP20/12/22 P F012

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.