OA45792: PIPESQL ENCOUNTERS SQLCODE -923 RUNNING SQL THAT PREVIOUSLY RAN GOOD.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Using PIPESQL to run three Selects. The SQL is the same, just
  running it on 2 different DB2 subsystems.
  The first Select is run against subsystem A and works.
  The second Select is run against subsystem B and fails with -923
  The third Select is run against subsystem A and also fails with
  -923 when it previously worked.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All Tivoli NetView for z/OS users of the SQL *
  *                 PIPE stage using the DB2 CAF interface.      *
  ****************************************************************
  * PROBLEM DESCRIPTION: When running with the CAF DB2 interface *
  *                      after connecting to and disconnecting   *
  *                      from a DB2 subsystem successfully, then *
  *                      trying to connect to a second DB2       *
  *                      subsystem but unsuccessfully, and then  *
  *                      trying to reconnect to the first DB2    *
  *                      subsystem (all while running on the     *
  *                      same NetView task), the following       *
  *                      messages may be issued:                 *
  *                      DSNT408I SQLCODE = -9xx, ERROR:         *
  *                       AUTHORIZATION FAILURE: PLAN ACCESS     *
  *                       ERROR. REASON 00F30034                 *
  *                      DSNT418I SQLSTATE   = xxxxx SQLSTATE    *
  *                       RETURN CODE                            *
  *                      DSNT415I SQLERRP    = DSNAET03 SQL      *
  *                       PROCEDURE DETECTING ERROR              *
  *                      where 'x's represent the DB2 code.      *
  *                      DWO362E PIPELINE TERMINATED.  ERROR IN  *
  *                       STAGE n IN PIPELINE 'name': SQL ...    *
  *                      where the ellipsis represents an echo   *
  *                      of the rest of the failing SQL pipe     *
  *                      stage.                                  *
  *                      Additional search arguments:            *
  *                      msgDSNT408I msgDSNT415I msgDSNT418I     *
  *                      msgDWO362E                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  During the processing of the PIPE SQL stage NetView issues a DB2
  OPEN PLAN request (which has an implied DB2 CONNECT request).
  When the implied CONNECT succeeds but the OPEN fails, the
  DSNTxxxI and DWO362E messages are issued. NetView then needs to
  do a DB2 DISCONNECT but can't because DB2 doesn't allow an
  explicit DISCONNECT where an implied CONNECT was performed. Nor
  can NetView do a DB2 CLOSE because DB2 only allows that if a DB2
  PLAN was actually OPENed. In this case the OPEN failed so a
  CLOSE will also fail and still leave the NetView operator
  connected to the DB2 subsystem where the first failure occurred.
  While this connection exists NetView cannot establish
  connections to any other DB2 subsystems from the NetView
  operator encountering this failure. Attempting to do so only
  results in the same DSNTxxxI and DWO362E messages.
  NOTE: This problem only occurs when using the CAF DB2 interface
  but not when using the RRS DB2 interface.
  

Problem conclusion

• Processing for the NetView SQL PIPE stage when using the DB2 CAF
  interface is being changed to do an explicit DB2 CONNECT if the
  target DB2 subsystem is different from the NetView default DB2
  subsystem or no default DB2 subsystem has been identified by
  NetView. The default DB2 subsystem is defined in NetView by
  coding the "SUBSYSTEM=nnnn" statement (where the "nnnn"
  identifies the default DB2 subsystem name) in DSIPARM member
  DSIDB2DF (by default). This will allow NetView to recover from
  the reported error scenario by NetView issuing an explicit DB2
  DISCONNECT from the DB2 subsystem where the error was
  encountered.
  This change to perform an explicit DB2 CONNECT on any operator
  task does work, contrary to what the DB2 documentation states.
  In the DB2 Vx.y for z/OS Application Programming and SQL Guide
  in Chapter 2. Connecting to DB2 from your application program,
  under topic 'Invoking the call attachment facility', under
  subtopic 'CAF connection functions', in the section titled
  'CONNECT function for CAF', following the 'DSNALI CONNECT
  function' syntax diagram, under the description for the
  'startecb' parameter first paragragh, third sentence it states
  the following:
  'DB2 posts at most one startup ECB per address space.'
  This is incorrect, it should read more like the following for
  multi-task (TCB) address spaces:
  'DB2 posts at most one startup ECB per address space per task.'
  

Temporary fix

Comments

APAR Information

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

  OA45273

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

  UA75938 UA75939

Modules/Macros

• DSISQLRQ
  

Fix information

• Fixed component name

  AUTO CNTL NETV

• Fixed component ID

  5698LSA01

Applicable component levels

• R11B PSY UA75938

     UP15/01/22 P F501

• R12B PSY UA75939

     UP15/01/22 P F501

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.