Migrating your existing applications to use shared queues

Reason codes, triggering, and the MQINQ API call can work differently in a shared queue environment.

Migrating your existing queues to shared queues is described in the Administer IBM MQ for z/OS .

When we migrate your existing applications, consider the following things, which might work in a different way in the shared queue environment:

    Reason codes
    When we migrate your existing applications to use shared queues, check for the new reason codes that can be issued.

    Triggering
    If we are using a shared application queue, triggering works on committed messages only (on a non-shared application queue, triggering works on all messages).

    If we use triggering to start applications, you might want to use a shared initiation queue. Table 1 describes what we need to consider when deciding which type of initiation queue to use.

      Non-shared application queue Shared application queue
    Non-shared initiation queue As for previous releases. If we use a trigger type of FIRST or DEPTH, we can use a non-shared initiation queue with a shared application queue. Extra trigger messages might be generated, but this setup is good for triggering long-running applications (like the CICS bridge) and provides high availability.

    For trigger type FIRST or DEPTH, a trigger message triggers an instance of the application on every queue manager that is running a trigger monitor and that does not already have the application queue open for input. One trigger message is generated for every queue manager; if there is more than one trigger monitor running against the non-shared local initiation queue, on a particular queue manager, they will compete to process the message.

    Shared initiation queue Do not use a shared initiation queue with a non-shared application queue. If we have a shared application queue that has a trigger type of EVERY, use a shared initiation queue, or you might lose trigger messages in certain circumstances; for example, a queue manager failing.

    For trigger type FIRST or DEPTH, one trigger message is generated by each queue manager that has the named initiation queue open for input.

    Note: For trigger type FIRST or DEPTH, if one trigger monitor instance is busy, this leaves the potential for less busy trigger monitors to process more than one trigger message from the shared initiation queue. Hence, multiple instances of the server application may be started against a given queue manager. Note that these multiple instances are started as a result of processing multiple trigger messages. Ordinarily, for trigger type FIRST or DEPTH, if an application instance is already serving an application queue, another trigger message will not be generated by the queue manager that the application is connected to.

    MQINQ
    When we use the MQINQ call to display information about a shared queue, the values of the number of MQOPEN calls that have the queue open for input and output relate only to the queue manager that issued the call. No information is produced about other queue managers in the queue sharing group that have the queue open.

Parent topic: Application programming with shared queues