PK56509: ABENDS0C4 DFSRLM20 REQUEUE_MSG RLM_PARMS POINTER TO FLAGS ZERO, AFTER PK37614 ON REQUEUE OF SQ BACKEND MSG 07/11/13 PTF PECHANGE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• With PK37614 installed, synchronous APPC transaction is entered
  on FE IMS and processed on a BE IMS. The application initiates
  a protected APPC outbound conversation, but then issues IMS
  ROLB call. PK37614 logic will caused the BE IMS to notify
  the FE IMS to requeue the message for retry. This logic
  path through DFSRLM10 -> DFSRLM20 makes use of a parameter
  area, RLM_Parm. In this particular path this area is not
  initialized, and the pointer within it to 'FLAGS' is zero.
  DFSRLM10 Requeue_MSG routine stores into FLAGS so
  this causes a S0C4. The contents of the RLM_Parm area
  depend upon residual contents of the LUMP Pool storage used
  as PL/X dynamic work area so the abend is not solid ( and
  random overlays may result ).
  Additional Symptom:
  This apar will also address a serialization
  problem between DFSAOSW0, DFSLUM00, and DFSRLM20
  on a Front End IMS. The scenario being addressed
  is when a transaction suffers the PK37614 ROLB
  scenario on a BE IMS, is requeued vis DFSAPPCQ
  to FE, FE requeues original input, and this
  input runs on a different BE and fails the
  DFSAPPCQ requeue resulting in a DFS2224
  message arriving at the FE IMS before DFSRLM20
  finishes requeue of the input.
  This causes DFSAOSW0 to put an AWE address
  into TIB_SYNC_PTR which DFSRLM20 then attempts
  to IPOST at exit, resulting in an S0C1.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All IMS V10 APPC/OTMA users in a shared      *
  *                 queues environment with AOS=Y.               *
  ****************************************************************
  * PROBLEM DESCRIPTION: 1.                                      *
  *                      ABEND0C4 in DFSRLM20 due to an invalid  *
  *                      flag pointer in RLM_PARMS.              *
  *                      2.                                      *
  *                      ABEND0C1 in DFSRLM20 due to invalid     *
  *                      posting of an AWE in TIB_SYNC_PTR.      *
  *                      3.                                      *
  *                      ABENDU0711-34 occurs and a DFS2224      *
  *                      message is wrongly sent to the IMS      *
  *                      Front End ( and DFS555 in log ).        *
  *                      4.                                      *
  *                      ABENDU0711-34 after a RC=8/RSNX'18'     *
  *                      when performing a security check while  *
  *                      executing an ATRQUERY call issued from  *
  *                      module DFSRRSI0.                        *
  *                                                              *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  1.
  
  ABEND0C4 in DFSRLM20.
  
  DFSRLM20 is called by DFSRLM10 to perform several functions.
  The parameter list, RLM_PARMS, is a block of LUM pool storage
  acquired and setup by DFSRLM10. However, DFSRLM10 fails to
  initialize the storage on each invocation. Therefore, if the
  same LUM block is reused there could be residual data in the
  block.
  
  In the parameter list there's a pointer to some flag fields,
  RLM_PARMS.Flagsaddr. The address of this field was not
  set (i.e. it was zero) when DFSRLM10 called DFSRLM20 for the
  RequeueMsg function, which resulted in ABEND0C4 when DFSRLM20
  attempted to update the flags.
  
  2.
  
  ABEND0C1 in DFSRLM20
  
  DFSRLM20 Requeue_Msg subroutine attempts to synchronize the use
  of the TIB using TIB_SYNC_PTR, which contains either the TCB of
  the waiter or an AWE, if TIB_SYNC_AWE is set. However, the code
  failed to check for TIB_SYNC_AWE and therefore assumed that
  TIB_SYNC_PTR was an ECB and IPOST'd it, when it was actually an
  AWE, resulting in ABEND0C1.
  
  3.
  
  ABENDU0711-34 occurs and a DFS2224 message is wrongly sent to
  the IMS Front End ( and DFS555 in log ). A non conversational
  transaction can get scheduled using the same PST from the
  previous schedule of a conversational transaction. The PSTSPA
  field contained a residual address during processing of the
  non-conversational transaction, causing the DFS2224 message and
  ultimately an ABENDU0711-34 to be incorrectly issued.
  
  This is a based code problem that was surfaced by the code
  added by PK37614 / UK29626 .
  
  4.
  
  AENDU0711-34 in DFSRRSI0.
  
  DFSRRSI0 executes the ATRQUERY under the dependent region TCB
  (call added by APAR PK37614).  If using some form of a security
  control for resource protection, a security check may be issued
  during the execution of the ATRQUERY call that references the
  userid of the IMS dependent region.
  
  This security check could fail, causing the ATRQUERY call to
  also fail, as it did in this reported case.  The failing
  ATRQUERY call resulted in a non-zero return code being passed
  back to module DFSRRSI0, causing the ABENDU0711-34 to be
  incorrectly issued.
  
  Additionally, to state the need for the ATRQUERY call requiring
  resource security access, a HOLD card should have been included
  in the PK37614 / UK29626 service.
  

Problem conclusion

• AIDS: RIDS/DCS RIDS/CNTRL DCS CNTRL
    GEN:
  SYSPLEXSQ
  
  *** END IMS KEYWORDS ***
  1.
  
  DFSRLM10 was modified to initialize RLM_PARMS to zero and set
  the address of the flag field with each invocation.
  
  2.
  
  DFSRLM20 was modified to check TIB_SYNC_AWE and if set, queue
  the AWE to DFSAOSW0 for processing.
  
  3.
  
  DFSSABN0 in the PST clean-up routine will clear the SPA address
  from the PST and free the storage used for the SPA and its
  header.
  
  4.
  
  DFSRRSI0 added code to switch to the Control Task TCB when the
  ATRQUERY is executed.  This will avoid the security problem and
  the ABEND711-34.  The security check will be done using the
  userid for the IMS CTL region which is not so variable as a
  dependent region userid.  The code will switch back to the
  dependent region TCB upon return from the ATRQUERY call.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

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

  UK32743

Modules/Macros

• DFSRLM10 DFSRLM20 DFSRRSI0 DFSSABN0
  

Fix information

• Fixed component name

  IMS V10

• Fixed component ID

  5635A0100

Applicable component levels

• R010 PSY UK32743

     UP08/01/11 P F801 «

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.