Migrating your existing applications to use shared queues

Migrating your existing applications to use shared queues

Migrating your existing queues to shared queues is described in the WebSphere MQ for z/OS System Administration Guide.

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

Reason Codes

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

Triggering

If you are using a shared application queue, triggering works on committed messages only (on a non-shared application queue, triggering works on all messages).
If you use triggering to start applications, you might want to use a shared initiation queue. Table 1 describes what you need to consider when deciding which type of initiation queue to use.

When to use a shared-initiation queue
Non-shared application queue Shared application queue
Non-shared initiation queue As for previous releases. If you 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 given 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 you have a shared application queue that has a trigger type of EVERY, use a shared initiation queue or you will lose trigger messages.
For trigger type FIRST or DEPTH, one trigger message is generated by each queue manager that has the named initiation queue open for input.

MQINQ

When you 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

fg15400_

	Non-shared application queue	Shared application queue
Non-shared initiation queue	As for previous releases.	If you 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 given 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 you have a shared application queue that has a trigger type of EVERY, use a shared initiation queue or you will lose trigger messages. For trigger type FIRST or DEPTH, one trigger message is generated by each queue manager that has the named initiation queue open for input.