IBM Support

PI28869: AN MQRC_HOBJ_ERROR (2019) WAS CAUSED BY AN ERROR IN DISCONNECT IN THE MQ JAVA CLASSES FOR A CICS TRANSACTION

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as duplicate of another APAR.

Error description

  • An MQRC_HOBJ_ERROR (2019) was caused by an error
    in disconnect in the MQ Java classes for
    a CICS transaction.
    .
    The problem occurred after migrating to JVM Server
    in CICS TS 510 from CICS v420, which ran JVM
    Pooling for the Java application.
    .
    If multiple MQQueueManager objects are created
    within a single CICS transaction, then calling
    MQQueueManager.disconnect() on one of them will
    incorrectly close all queue handles for the
    CICS transaction.
    The handles which were created by another
    MQQueueManager object will no-longer be valid,
    and 2019 will be returned if they are used for
    MQ API calls.
    .
    In the java core dump, there was the following:
    Current thread
     ----------------------
    "Finalizer thread"
    J9VMThread:0x00000048869AC200,
    j9thread_t:0x0000004885FE7820,
    java/lang/Thread:0x000000488EBCC6B0,
    state:R, prio=5
    java/lang/Thread getId:0x169, isDaemon:true)
    Heap bytes allocated since last GC
    cycle=2450088 (0x2562A8)
    Java callstack:
    at com/ibm/mq/jmqi/local/internal/base/Native.MQCLOSE
      (Native Method)
    at com/ibm/mq/jmqi/local/LocalMQ.MQCLOSE
      (LocalMQ.java:1978)
    at com/ibm/mq/MQSESSION.MQCLOSE(MQSESSION.java:801)
    at com/ibm/mq/MQManagedObject.close
      (MQManagedObject.java:407)
       (entered lock: com/ibm/mq/MQQueue@0x0000004891DF1B78,
       entry count: 2)
    at com/ibm/mq/MQQueue.close(MQQueue.java:960)
       (entered lock: com/ibm/mq/MQQueue@0x0000004891DF1B78,
       entry count: 1)
    at com/ibm/mq/MQManagedObject.finalize
      (MQManagedObject.java:444)
    at java/lang/J9VMInternals.runFinalize
       (J9VMInternals.java:489
       (Compiled Code))
    No native callstack available on this platform
    .
    In the SVXCDUMP:
    ip verbx ledata 'nthreads(*)'
    IP VERBX LEDATA 'CAA(00000048FDEFEC60)
    DSA(0000004903CF4180) ALL'
    .
    CELQHROD    +00000266    CELQLIB   CELQHROD
    CSQC3CLS    +00000150    CSQCLB16
     Java_com_ibm_mq_jmqi_local_internal_base_Native_MQCLOSE
                +000000F2    *PATHNAM
     RUNCALLINMETHOD
                +00000000    *PATHNAM
     callStaticVoidMethodV
                +00000040    *PATHNAM
     JNIEnv_::CallStaticVoidMethod(_jclass*,_jmethodID*,...)
    .
    And in the LE Stack:
    .
    14       __zerro     +00001072
    15       __zerros    +00000350
    16       CEEHDSP     +00004450
    17       CEEOSIGJ    +000009B2
    18       CELQHROD    +00000266
    19       CEEOSIGG    +00000000
    20       CELQHROD    +00000266
    21       CSQC3CLS    +00000150  <<< Exception
    22       Java_com_ibm_mq_jmqi_local_internal_base
             _Native_MQCLOSE
                         +000000F2
    23       RUNCALLINMETHOD
                         +00000000
    24       callStaticVoidMethodV
                         +00000040
    .
    
    
    Additional Symptom(s) Search Keyword(s):
    

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

  • Problem summary:
    When an MQ Java application running as part of a CICS task
    creates an MQQueueManager object, the MQ classes for Java
    connect to MQ using an MQCONNX call, even if the application has
    not set any options which would require MQCONNX to be used.
    If the application later disconnects from MQ, the MQ CICS
    adapter will attempt to release the conntag from the MQCONNX
    request. This results in any open queue handles for the CICS
    task being closed.
    If another part of the application had previously opened a
    queue, then a subsequent call to MQPUT or MQGET will fail with
    reason code 2019 (MQRC_HOBJ_ERROR).
    
    Problem resolution:
    The MQ classes for Java have been changed so that when running
    in CICS an MQCONNX is only used if the application has set
    fields which would require an MQCONNX call. If no fields have
    been set, then an MQCONN call will be used.
    If MQCONN is used, then a subsequent MQDISC call will not close
    any queue handles that the task has open, and they will remain
    available for use by other parts of the application.
    
    This fix changes the Java component of MQ, and will be
    included in a FixPack APAR.
    
    The fix is targeted for delivery in the following PTFs:
    Version Maintenance Level
    v7.1.0 - 7.1.0.7 (PI34462 on z/OS)
    v7.5.0 - 7.5.0.6 (Distributed platforms only)
    v8.0.0 - 8.0.0.3 (PM34470 on z/OS)
    
    The latest available maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
    
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
    
    COMMENTS.41
    

APAR Information

  • APAR number

    PI28869

  • Reported component name

    WMQ Z/OS V7

  • Reported component ID

    5655R3600

  • Reported release

    108

  • Status

    CLOSED DUB

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2014-11-03

  • Closed date

    2015-02-20

  • Last modified date

    2015-11-19

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

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

Fix information

Applicable component levels

[{"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.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
19 November 2015