IBM Support

IT33906: All channel processing hangs some weeks after user deletes cluster transmission queue

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • Due to a missing cluster transmission queue, the MQ cluster
    repository process (amqrrfma) hangs while holding a lock on the
    channel status table.
    
    When the MQ cluster is in this hung state, the DISPLAY CHSTATUS
    command hangs.
    
    FDCs are created:
    
    For example:
    
      Probe Id          :- RM419010
      Component         :- rrmRemoveNonReallocMsgs
      Program Name      :- amqrrmfa
      Major Errorcode   :- MQRC_UNKNOWN_OBJECT_NAME
      MQM Function Stack
      amqrrfma_main
      rrmMain
      rrmRepository
      rrmGetMsg
      rrmRunTimers
      rrmMaintenance
      rfxEnumCLQMGR
      rrmMaintainClqMgr
      rrmRemoveNonReallocMsgs
      xcsFFST
    
    Also:
      Probe Id          :- RM193001
      Component         :- rrmMaintenance
      Program Name      :- amqrrmfa
      Major Errorcode   :- rrcE_MQOPEN_FAILED
      Comment2          :- SYSTEM.CLUSTER.TRANSMIT.QUEUE
      MQM Function Stack
      amqrrfma_main
      rrmMain
      rrmRepository
      rrmGetMsg
      rrmRunTimers
      rrmMaintenance
      xcsFFST
    
    Also:
      Probe Id          :- XC307100
      Component         :- xlsRequestMutex
      Program Name      :- amqpcsea
      Major Errorcode   :- xecL_W_LONG_LOCK_WAIT
      MQM Function Stack
      pcmCommandServer
      pcmProcessMessage
      pcmEscape
      uscRunCommand
      uscRunIT
      pcmInquireChannelStatus
      rrxGetNextStatusEntry
      xlsRequestMutex
      xcsFFST
    

Local fix

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    Users who have configured a cluster sender channel to use a
    specific transmission queue, but this channel becomes disused,
    and the user deletes the transmission queue before MQ has
    automatically removed its own internal channel definition from
    its local cluster cache.
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    The user deleted a locally defined queue that was previously
    associated as the transmission queue for a local cluster sender
    channel.
    
    When that channel was not used for a long time (over 90 days)
    then, via internal automated processing in the queue manager's
    cluster repository manager, the local auto-defined channel
    definitions for it were expired from the local cluster cache.
    
    At this time the queue manager was calling MQOPEN on the cluster
    transmission queue that was configured for that channel.
    
    If the user had deleted the queue, then this failed, and in the
    error-handling logic that follows, the queue manager deadlocked
    waiting for a mutex that would not be released.
    

Problem conclusion

  • The MQ product code has been altered so that the missing
    transmission queue is not treated as an error condition at this
    point in the processing.  The cluster repository manager
    completes its removal of the old records from its cache without
    any errors.
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
     Version    Maintenance Level
     v8.1       8.1.0.6
    ---------------------------------------------------------------
    

Temporary fix

Comments

APAR Information

  • APAR number

    IT33906

  • Reported component name

    MQ FOR HPE NS O

  • Reported component ID

    5724A3904

  • Reported release

    810

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2020-08-14

  • Closed date

    2020-08-26

  • Last modified date

    2020-08-26

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

    IT21234

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

Fix information

  • Fixed component name

    MQ FOR HPE NS O

  • Fixed component ID

    5724A3904

Applicable component levels

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"810","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
27 August 2020