IBM Support

PI28011: WEBSPHERE MQ, CHANNEL STARTED TWICE WHEN CHIN IS STARTING AND LEADS TO CSQX514E

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • When CHIN is starting, some channels started twice though there
    is no start channel command put explicitly, and it leads to
    CSQX514E:  csect-name Channel channel-name is active on
    qmgr-name.
    
    The channel was in retry state when the CHIN was started. This
    was therefore detected by riiCheckChannels, which set the
    status to STARTED and then scheduled a dispatch process to run
    the channel. The channel then started initialization
    processing. However, before the channel reached RUNNING state,
    there was an MQPUT in the queue-manager which resulted in a
    message going to the cluster xmitq for TO.MQ2A. CSQMPCHS
    checked if the channel was in RUNNING, RETRY or DISABLED state,
    and as it was none of these a trigger message was sent to the
    CHIN to start the channel. This then lead to the CSQX514E
    message being issued.
    
    
    Additional Symptom(s) Search Keyword(s): CHIN, channel, start,
    twice, CSQX514E
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 *
    *                 Release 0 Modification 0                     *
    ****************************************************************
    * PROBLEM DESCRIPTION: Message CSQX514E issued by CHINIT       *
    *                      soon after initialisation.              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    After CHINIT has initialised the supervisor task calls
    rivCheckChannels which in turn calls riiCheckChannels in order
    to start any channels which are in RETRY status.
    riiCheckChannels will update the channel status table with
    a status of STARTED, before calling CSQXRCHL to schedule a
    DPRO to perform the start.
    However if an application tries to send a message down a CLUSSDR
    that is in this state it will cause a trigger message to be
    generated by CSQMPCHS which will in turn cause another DPRO to
    try and start the channel. Once the channel starts the second
    DPRO will issue CSQX514E to say that the channel is active.
    

Problem conclusion

  • CSQMPCHS has been changed so that it doesn't generate a trigger
    to start a channel that is already being started.
    

Temporary fix

Comments

APAR Information

  • APAR number

    PI28011

  • Reported component name

    WMQ Z/OS 8

  • Reported component ID

    5655W9700

  • Reported release

    000

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2014-10-20

  • Closed date

    2014-11-06

  • Last modified date

    2015-02-03

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

    PI23860

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

    UI22829

Modules/Macros

  • CSQMPCHS
    

Fix information

  • Fixed component name

    WMQ Z/OS 8

  • Fixed component ID

    5655W9700

Applicable component levels

  • R000 PSY UI22829

       UP15/01/29 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.

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

Document Information

Modified date:
30 April 2020