IBM Support

PM70748: WEBSPHERE MQ V701, IMS APPLICATION GETS DIFFERENT RETURNCODES ATMQCONN USING DEFAULT-QMGR VERSUS EXPLICIT QMGR

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Error DescriptionÏ
    detect different ReturnCodes at MQConn using Default-QMGR
    versus explicit QMGR, if mixed MQ-Stubs(CSQBSTUB+CSQBRRSI) are
    used in one application programm:
    
    Environment:
    ============
    - MQ Version 7.0.1
    - IMS-Batch Version 11.1
    - using XRST and CHKPT-Call
    - all Tests run with 1 QMGR
    
    Testcase 1:
    ===========
    1. MQ-Connect -> CSQBSTUB
    2. MQ-Open for Input
    3. MQ-Open for Output
    4. MQ-Get
    5. MQ-Connect -> CSQBRRSI
               using Default-QMGR  => RC=2012=MQRC_ENVIRONMENT_ERROR
               using explicit QMGR => RC=2002=MQRC_ALREADY_CONNECTED
    
    Testcase 2:
    ===========
    1. MQ-Connect -> CSQBRRSI
    2. MQ-Open for Input
    3. MQ-Open for Output
    4. MQ-Get
    5. MQ-Connect -> CSQBSTUB
               using Default-QMGR  => RC=2012=MQRC_ENVIRONMENT_ERROR
               using explicit QMGR => RC=2002=MQRC_ALREADY_CONNECTED
    
    RC=2012=MQRC_ENVIRONMENT_ERROR should be returned in each case,
    regardless of using Default or explizit-QMGR
    
    For testcase 1, CSQBRRSI does not check the type of connection
    after locating the BLOA from the SSAT;
    For testcase 2, CSQBCON does not check the type of connection
    after locating the BLOA from the name/token
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
    *                 Release 0 Modification 1 and Release 1       *
    *                 Modification 0.                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: An application program link-edited with *
    *                      an RRS batch stub issues MQCONN with no *
    *                      MQDISC before ending, and then another  *
    *                      program link-edited with a non-RRS      *
    *                      batch stub is subsequently invoked and  *
    *                      issues an MQCONN to the same queue      *
    *                      manager. The MQCONN returns             *
    *                      MQRC_ALREADY_CONNECTED instead of       *
    *                      failing with MQRC_ENVIRONMENT_ERROR as  *
    *                      expected.                               *
    *                      The same problem occurs if the first    *
    *                      program is link-edited with a non-RRS   *
    *                      batch stub and the second program with  *
    *                      an RRS batch stub.                      *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    Two similar problems are reported here.
    In the first case a program linkedited with CSQBSTUB connects to
    a qmgr then another program linkedited with an RRS
    batch stub (e.g. CSQBRSTB) is invoked.
    When this latter issues an MQCONN the CSQBRSTB stub fails to
    check the bloa.caller for compatibility and as result it returns
    a MQCC_WARNING and an MQRC_ALREADY_CONNECTED. It should have
    issued MQCC_FAILED and MQRC_ENVIRONMENT_ERROR.
    In the second case a program linkedited with an RRS stub such as
    CSQBRSTB issues an MQCONN and then a program linkedited with
    CSQBSTUB in invoked. In this case CSQBCON fails to check the
    bloa.caller for compatibility and again MQRC_ALREADY_CONNECTED
    is returned instead of MQRC_ENVIRONMENT_ERROR.
    

Problem conclusion

  • CSQBCON has been changed to check the caller type and if
    incompatible will issue MQRC_ENVIRONMENT_ERROR. Similarly the
    RRS batch stubs will check the caller type, and if not an RSS
    type will issue MQRC_ENVIRONMENT_ERROR.
    010Y
    100Y
    CSQBCON
    CSQBRRSI
    CSQBRSTB
    IMQS23DR
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM70748

  • Reported component name

    WMQ Z/OS V7

  • Reported component ID

    5655R3600

  • Reported release

    010

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2012-08-13

  • Closed date

    2012-12-13

  • Last modified date

    2016-02-15

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

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

    UK90287 UK90288

Modules/Macros

  • CSQBCON  CSQBRRSI CSQBRSTB IMQS23DR
    

Fix information

  • Fixed component name

    WMQ Z/OS V7

  • Fixed component ID

    5655R3600

Applicable component levels

  • R010 PSY UK90287

       UP13/01/16 P F301

  • R100 PSY UK90288

       UP13/01/16 P F301

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.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
15 February 2016