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:
If you use triggering to start applications, you might want to use a shared initiation queue. Table 12 describes what you 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 you use a trigger type of FIRST or DEPTH, you 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(R) 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. |
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csqzal10110 |