PK70338: SQLCODE904 RC00D31052 WHEN CALLING 3 PART NAME STORED PROCEDURE ON V9 INTERMEDIATE SERVER MULTIPLE TIMES.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• DB2DDF DDFL09 DB2SP defect pk70338 dpk70338
  SQLCODE904 RC00D31052 when executing 3 part name stored
  procedure with different location as a first qualifier multiple
  times.
  The problem is as follows.
  WAS application connects to DB2 Z V9 server. (call this as LOCA)
  Then it calls 3 part name stored procedure to 2nd location(LOCB)
  Once first transaction completes, WAS again calls 3 part name
  stored procedure on 3rd location (LOCC). However, DB2 Z V9 at
  LOCA mistakenly flows the CALL SP request to the LOCB instead of
  LOCC as defined in 3 part name. This will eventually cause
  -904 with RC00D31052 condition where multiple thread is having
  the same LUWID.
  Because of this error, WAS could receive SQLCODE4203 or -4203 .
  It also possible that it would receive RC00D3101A.
  .
  XAResource.commit() XA_RBROLLBACK
  ***************************************
  Additional keywords and symptoms:
   SQLCODE-904 SQLN904 SQLCODE904 -904 RC00D31052 00D31052
   SQLCALL SQLSCALL Hop Hopping Intermediate server
   Stored Procedure
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All Distributed Data Facility (DDF) users.   *
  *                 Specifically users that CONNECT to a remote  *
  *                 server and then CALL a stored procedure      *
  *                 using 3-part name syntax.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: A CALL statement using a 3-part name    *
  *                      for the stored procedure receives       *
  *                      SQLCODE -904 REASON 00D31052 indicating *
  *                      the application caused recursive access *
  *                      to a remote location, followed by       *
  *                      access to another remote location,      *
  *                      which is not permitted.                 *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  In this problem scenario, the client application connects to a
  remote server and then calls a stored procedure using 3-part
  name syntax.  This causes multiple sites to be involved in the
  processing of the stored procedure -- the stored procedure CALL
  is said to be a "hopping CALL statement" as it hops from the
  remote server to additional servers.
  
  In the following description Site2, Site3, and Site4 all refer
  to DB2 for z/OS V9.  The client application runs on Site1.
  
  A client application connects to an intermediate server at
  Site2.  The client issues a hopping CALL statement CALL
  Site3.schema.procname.  The stored procedure runs to completion
  at Site3.  The client application issues another hopping CALL
  for the same stored procedure but at a different location, CALL
  Site4.schema.procname.  The CALL Site4.schema.procname is
  misrouted to Site3.  However, Site3 forwards the CALL
  Site4.schema.procname to the correct location and the stored
  procedure runs to completion.  The client application continues
  alternating hopping CALL statements between Site3 and Site4.
  
  When the CALL Site4.schema.procname occurs the second time, the
  intermediate server at Site2 again misroutes the statement to
  Site3.  This time, Site3 detects a loopback condition and fails
  the CALL statement with SQLCODE -904 REASON 00D31052.
  

Problem conclusion

• At Site2 intermediate server, DB2 did not refresh the target
  location name for hopping CALL statements when the same CALL
  section is used repeatedly.  This led to misrouting the CALL
  statements to the wrong downstream location and eventual SQLCODE
  -904 REASON 00D31052.  This problem can only occur when the
  intermediate server is DB2 for z/OS V9.  Also the same section
  must be used for all hopping CALL statements, only the
  fully qualified procedure name differs between each CALL, such
  as when using CALL host-variable.
  
  DB2, acting as an intermediate server, has been corrected to
  always refresh the target location name for hopping CALL
  statements.
  

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:

  UK39673

Modules/Macros

• DSNLXXSS DSNXERT2
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• R910 PSY UK39673

     UP08/09/24 P F809

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.