Lowering administration cost with Use Dead-Letter Queue (USEDLQ) channel attribute in WebSphere MQ V7.1
Marcela Adan 100000THF9 firstname.lastname@example.org | | Tags:  v7.1 mq websphere queue messaging usedlq
0 Comments | 4,236 Visits
By Cezar Aranha
Consultant - Messaging Integration Middleware
IBM Global Accounts (IGA) organization, IBM Brazil
I'm a consultant for messaging integration middleware in the IBM Global Accounts (IGA) organization, in IBM Brazil. WebSphere MQ is one of the main and most popular components in the infrastructure we deliver to our customers. Providing a highly reliable service at the lowest possible cost is a constant challenge. I'm always on the lookout for features and enhancements we can exploit to attain our goals. This blog post is inspired by a new feature provided with WebSphere MQ V7.1: the Use Dead-Letter Queue (USEDLQ) channel attribute.IBM WebSphere MQ Channel Access: Delete or Block? by Craig Both
InfoSphere Replication Server, usually called Q Replication or Q Rep, enables greater data availability for critical applications. It replicates data between source and target tables based on rules that the DBA and applications enable. Using a process called Q Capture on the source side, Q Replication reads the DB2 log for committed DB2 updates and uses WebSphere MQ to transmit them to the target. On the target side, the Q Apply process reads the queue and applies the same updates to the local replica. Q Rep is able to handle a high volume of transactions, as messages, between the source and target databases, or subsystems. There is some latency between the database replicas, but it is typically very small. To rebuild each transaction, it is critical that the messages that represent it are received and applied in the correct sequence (serialized application).
If a message cannot be delivered because, for example, the target queue is full, WebSphere MQ routes it to a dead-letter queue, if one is available. This can cause problems for the Q Apply program because messages can arrive on the target queue out of sequence. If this occurs the replication process is stopped until the problem can be addressed by an administrator.
To avoid this situation, the preferred WebSphere MQ environment for replication, and other applications that require messages to be processed in a strict sequence, has been not to define a dead-letter queue. This prevents messages being routed elsewhere, which preserves their sequence. An administrator only has to restart the channel once the problem has been resolved.
Our service organization supports several other applications that require a dead-letter queue. Before WebSphere MQ V7.1, the dead-letter queue was a global setting for all channels defined on a queue manager. Therefore, applications that require a dead-letter queue could not share a queue manager with applications such as Q Replication. Naturally, not being able to share a queue manager makes the support cost of these applications more expensive. With WebSphere MQ V7.1, each channel can be configured to use the dead-letter queue, or not, independently. We are planning to migrate our WebSphere MQ infrastructure to V7.1 to take advantage of this feature, and many other important enhancements, that will help us to meet several requirements from our customers and lower the service cost.
I recently participated in a project with a team of WebSphere MQ experts from IBM to write the IBM Redbooks publication IBM WebSphere MQ V7.1 and V7.5 Features and Enhancements. The book will help you understand the benefits of upgrading to WebSphere MQ V7.1 and V7.5 and how to implement the new functions.
Other blog posts from the team:How to write a WebSphere MQ book in 4 weeks (and survive to tell about it!) by Craig Both and Alex Ross
Introducing coexistence support for WebSphere MQ on Windows, UNIX, and Linux by Jamie Squibb
WebSphere MQ v7.1 SMDS: What goes up will come down by Carolyn Elkins
Improving z/OS WebSphere MQ availability: Structure failure or connectivity loss? by Barry Dearfield