Queue Manager Clusters
- About this book
- Who should read this book
- What we need to know to understand this book
- How to use this book
- Appearance of text in this book
- Terms used in this book
- Summary of changes
- Changes for this edition (plug-in version 6.0.2.11)
- Changes for the previous edition (SC34-6589-01)
- Getting started with queue manager clusters
- Concepts and terminology
- Concepts
- Comparison with distributed queuing
- Overview of cluster components
- Terminology
- Benefits
- Things to consider
- Summary of concepts
- Using clusters to ease system administration
- How can I use clusters?
- Can I use clusters and queue-sharing groups?
- How does the system administrator benefit?
- Definitions to set up a network using distributed queuing
- Definitions to set up a network using clusters
- What about my applications?
- How do I set up a cluster?
- Establishing communication in a cluster
- Channel initiator
- Channel listener
- First tasks
- Task 1: Setting up a new cluster
- Procedure
- 1. Decide on the organization of the cluster and its name
- 2. Determine which queue managers should hold full repositories
- 3. Alter the queue-manager definitions to add repository definitions
- 4. Define the CLUSRCVR channels
- 5. Define the CLUSSDR channels
- 6. Define the cluster queue INVENTQ
- 7. Verify and test the cluster
- Using the sample program
- Using your own programs
- Task 2a: Adding a new queue manager to a cluster
- Procedure
- 1. Determine which full repository PARIS should refer to first
- 2. Define a CLUSRCVR channel on queue manager PARIS
- 3. Define a CLUSSDR channel on queue manager PARIS
- 4. Issue the REFRESH CLUSTER command
- Task 2b: Adding a new queue manager to a cluster — using DHCP
- Procedure
- 1. Determine which full repository PARIS should refer to first
- 2. Define a CLUSRCVR channel on queue manager PARIS
- 3. Define a CLUSSDR channel on queue manager PARIS
- 4. Issue the REFRESH CLUSTER command
- Using queue manager clusters
- How queue manager clusters work
- Components of a cluster
- Queue managers and repositories
- Queues
- Cluster transmission queue
- Cluster channels
- Auto-definition of remote queues
- Auto-definition of channels
- What makes clustering work?
- Using aliases and remote-queue definitions with clusters
- Queue-manager aliases
- Reply-to queue aliases
- Queue aliases
- Examples of using aliases within clusters
- Putting from a queue manager outside a cluster
- Replying to a queue manager outside the cluster
- Putting from a queue manager outside the cluster - alternative techniques
- Using a queue manager alias
- Using a clustered queue as a queue manager alias
- Putting to a queue manager outside the cluster
- Replying from a queue manager outside the cluster
- Putting across clusters
- Using clusters for workload management
- More than one instance of a queue
- Workload balancing
- The cluster workload management algorithm
- Cluster workload user exit
- Writing and compiling cluster workload exit programs
- WebSphere MQ for z/OS
- Platforms other than z/OS
- Sample cluster workload exit
- Programming considerations
- Reviewing applications for message affinities
- Handling message affinities
- MQI and clusters
- MQOPEN
- Resolved queue manager name
- MQPUT and MQPUT1
- MQINQ
- MQSET
- Return codes
- Using WebSphere MQ commands with clusters
- MQSC command attributes
- Queue-manager definition commands
- Channel definition commands
- Queue definition commands
- WebSphere MQ commands for work with clusters
- DISPLAY CLUSQMGR
- SUSPEND QMGR and RESUME QMGR
- REFRESH CLUSTER
- RESET CLUSTER
- CLUSTER commands on z/OS
- Managing WebSphere MQ clusters
- Designing clusters
- Selecting queue managers to hold full repositories
- Organizing a cluster
- Naming Convention
- Overlapping clusters
- Defining classes of service
- Objects
- Cluster-administration considerations
- Maintaining a queue manager
- Refreshing a queue manager
- Recovering a queue manager
- Maintaining the cluster transmission queue
- What happens when a queue manager fails?
- What happens when a repository fails?
- What happens if I put-disable a cluster queue?
- How long do the queue manager repositories retain information?
- Cluster channels
- Online monitoring
- Keeping clusters secure
- Stopping unauthorized queue managers sending messages to your queue manager
- Stopping unauthorized queue managers putting messages on your queues
- Stopping your queue manager putting messages to remote queues
- Preventing queue managers joining a cluster
- Using security exits on cluster channels
- Forcing unwanted queue managers to leave a cluster
- Using SSL
- Upgrading clustered queue managers and channels to use SSL
- Disabling SSL on clustered queue managers and channels
- Advanced tasks
- Task 3: Adding a new queue manager that hosts a queue
- Procedure
- 1. Determine which full repository TORONTO should refer to first
- 2. Define the CLUSRCVR channel
- 3. Define a CLUSSDR channel on queue manager TORONTO
- 4. Issue the REFRESH CLUSTER command
- 5. Review the inventory application for message affinities
- 6. Install the inventory application on the system in Toronto
- 7. Define the cluster queue INVENTQ
- Task 4: Removing a cluster queue from a queue manager
- Procedure
- 1. Indicate that the queue is no longer available
- 2. Check that the queue is no longer available
- 3. Disable the queue
- 4. Monitor the queue until it is empty
- 5. Monitor the channel to ensure there are no in-doubt messages
- 6. Delete the local queue
- Task 5: Moving a full repository to another queue manager
- Procedure
- 1. Alter PARIS to make it a full repository queue manager
- 2. Add a CLUSSDR channel on PARIS
- 3. Define a CLUSSDR channel on NEWYORK that points to PARIS
- 4. Check that queue manager PARIS now has a full repository
- 5. Alter the queue-manager definition on LONDON
- 6. Remove or change any outstanding definitions
- Task 6: Converting an existing network into a cluster
- Procedure
- 1. Review the inventory application for message affinities
- 2. Alter the two central queue managers to make them full repository queue managers
- 3. Define a CLUSRCVR channel on each queue manager
- 4. Define a CLUSSDR channel on each queue manager
- 5. Install the inventory application on CHICAGO2
- 6. Define the INVENTQ queue on the central queue managers
- 7. Check that the cluster changes have been propagated
- 8. Delete all remote-queue definitions for the INVENTQ
- 9. Implement the cluster workload exit (optional step)
- Task 7: Adding a new, interconnected cluster
- Procedure
- 1. Create a namelist of the cluster names
- 2. Alter the two queue-manager definitions
- 3. Alter the CLUSRCVR channels on CHICAGO and CHICAGO2
- 4. Alter the CLUSSDR channels on CHICAGO and CHICAGO2
- 5. Create a namelist on SEATTLE and ATLANTA
- 6. Alter the CLUSRCVR channels on SEATTLE and ATLANTA
- 7. Alter the CLUSSDR channels on SEATTLE and ATLANTA
- 8. Define CLUSRCVR and CLUSSDR channels on HARTFORD and OMAHA
- 9. Define the MORDERQ queue on OMAHA
- 10. Check that the cluster changes have been propagated
- Task 8: Removing a cluster network
- Procedure
- 1. Remove cluster queues from the cluster
- 2. Stop all applications that have access to cluster queues
- 3. Remove the repository attribute from the full repository queue managers
- 4. Remove cluster channels
- 5. Stop cluster channels
- 6. Issue the REFRESH CLUSTER command
- 7. Repeat Steps 4 and 5 for each queue manager in the cluster
- 8. Replace the remote-queue definitions for the INVENTQ
- 9. Tidy up the cluster
- Task 9: Adding new queue managers that host a shared queue
- Procedure
- 1. Determine which full repository the queue managers will refer to first
- 2. Define the CLUSRCVR channels
- 3. Define a CLUSSDR channel for the queue-sharing group
- 4. Define the shared queue
- Task 10: Removing a queue manager from a cluster
- Procedure
- 1. Modify the full repository queue manager REPOS and REPOSNL attributes
- 2. Check that the REPOS and REPOSNL changes have been propagated
- 3. Suspend queue manager TORONTO
- 4. Check that queue manager TORONTO has been suspended
- 5. Remove the CLUSRCVR channel definition
- 6. Stop the CLUSRCVR channel at TORONTO
- 7. Delete the CLUSSDR channel definition
- 8. Issue the REFRESH CLUSTER command
- Advanced workload balancing tasks
- Task 11: Adding a queue manager that hosts a queue locally
- Procedure
- 1. Alter the PARIS queue manager
- 2. Review the inventory application for message affinities
- 3. Install the inventory application on the system in Paris
- 4. Define the cluster queue INVENTQ
- Task 12: Using two networks in a cluster
- Procedure
- 1. Determine which full repository EDINBURGH should refer to first
- 2. Define the CLUSRCVR channels
- 3. Define a CLUSSDR channel on queue manager EDINBURGH
- Task 13: Using a primary and a secondary network in a cluster
- Procedure
- 1. Alter the existing CLUSRCVR channels on EDINBURGH
- Task 14: Adding a queue to act as a backup
- Procedure
- 1. Determine which full repository CHICAGO should refer to first
- 2. Define the CLUSRCVR channel
- 3. Define a CLUSSDR channel on queue manager CHICAGO
- 4. Alter the existing cluster queue INVENTQ
- 5. Review the inventory application for message affinities
- 6. Install the inventory application on the system in CHICAGO
- 7. Define the backup cluster queue INVENTQ
- Task 15: Restricting the number of channels used
- Procedure
- 1. Choose 2 full repositories
- 2. Define a CLUSRCVR channel on each queue manager
- 3. Define a CLUSSDR channel on each queue manager
- 4. Install the price check application
- 5. Define the PRICEQ queue on all the server queue managers
- 6. Restrict the number of channels used by queries
- Task 16: Adding a more powerful queue manager that hosts a queue
- Procedure
- 1. Determine which full repository LOSANGELES should refer to first
- 2. Define the CLUSRCVR channel
- 3. Define a CLUSSDR channel on queue manager LOSANGELES
- 4. Alter the CLUSRCVR channel on queue manager NEWYORK
- 5. Review the inventory application for message affinities
- 6. Install the inventory application on the system in Los Angeles
- 7. Define the cluster queue INVENTQ
- Reference information
- Cluster workload exit call and data structures
- MQ_CLUSTER_WORKLOAD_EXIT - Cluster workload exit
- Syntax
- Parameters
- Usage notes
- C invocation
- System/390 assembler invocation
- MQWXP - Cluster workload exit parameter structure
- Fields
- C declaration
- System/390 assembler declaration
- MQWDR - Cluster workload destination-record structure
- Fields
- C declaration
- System/390 assembler declaration
- MQWQR - Cluster workload queue-record structure
- Fields
- C declaration
- System/390 assembler declaration
- MQWCR - Cluster workload cluster-record structure
- Fields
- C declaration
- System/390 assembler declaration
- MQXCLWLN - Navigate cluster workload records
- MQXCLWLN - Navigate Cluster workload records
- Syntax
- Parameters
- Usage notes
- C invocation
- System/390 assembler declaration
- Workload balancing attributes
- Queue attributes for workload balancing
- CLWLPRTY queue attribute
- CLWLRANK queue attribute
- CLWLUSEQ queue attribute
- Queue manager attributes for workload balancing
- CLWLUSEQ queue manager attribute
- CLWLMRUC queue manager attribute
- Channel attributes for workload balancing
- CLWLPRTY channel attribute
- CLWLRANK channel attribute
- CLWLWGHT channel attribute
- NETPRTY channel attribute
- Troubleshooting
- Troubleshooting
- Symptom — A cluster sender channel is in retry state.
- Cause
- Symptom — DISPLAY CLUSQMGR shows CLUSQMGR names starting SYSTEM.TEMP.
- Cause
- Symptom — Applications get rc=2085 MQRC_UNKNOWN_OBJECT_NAME when trying to open a queue in the cluster.
- Cause
- Symptom — Applications get rc= 2189 MQRC_CLUSTER_RESOLUTION_ERROR when trying to open a queue in the cluster.
- Cause
- Symptom — Messages are not appearing on the destination queues.
- Cause
- Symptom — Applications put messages to a QALIAS but they go the SYSTEM.DEAD.LETTER.QUEUE rather then the TARGQ of the alias.
- Cause
- Symptom — A queue manager does not appear to have up to date information about queues and channels in the cluster.
- Cause
- Symptom — No changes in the cluster are being reflected in the local queue manager.
- Cause
- Symptom — DISPLAY CLUSQMGR, shows a queue manager twice.
- Cause
- Symptom — RESET CLUSTER and REFRESH CLUSTER commands were issued, but the queue manager would not rejoin the cluster.
- Cause
- Resolving Problems
- Problem 1 — Out of date information in a restored cluster.
- Problem 2 — cluster DEMO force removed by mistake.
- Problem 3 — Possible repository messages deleted.
- Problem 4 — 2 full repositories moved at the same time.
- Problem 5 — Unknown state of a cluster.
- Programming interface information
- Trademarks