| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| HOW to Set MQMD Attributes |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Sun Jan 21, 2007 9:44 am Post subject: |
 |
|
Guest
|
Stop trying to build an MQ Dead Letter Header for your applications to use. Stop trying to use the system dead letter queue as a place your applications can put messages needing application 'special handling'.
As designed, the Dead Letter Header has a rather limited number of reason codes that deal with delivery, conversion and triggering. The IBM-supplied Dead Letter Handler works well for real MQ dead letters. This mechanism is not intended for application use; and IBM will likely not support your misuse of it. Be warned! Do NOT use the system dead letter queue.
Two alternatives have proven successful:
Alternative 1: The MQMD (Message Descriptor) has some fields that your applications could use to transport information when you can't (or won't) add it to the application data portion of the message.
Find a field in the MD that your application is NOT using, and never will use. FEEDBACK and FORMAT might be good choices since they are application oriented; MSGID, CORRELID are others. Pick carefully. Read the manuals documented in this post BEFORE selecting the MD field.
Have the application that identifies the message as needing special handling insert an application-oriented special-handling code into the chosen MD field, then MQPUT it to an application 'special handling' queue. Notice that I did not say Reason Code. Notice that I did not say Dead Letter Queue. This is not an MQ issue; it's an application issue. Do NOT use the system dead letter queue.
Alternative 2: Have the application architects invent a 'special-handling header' of their own, and include it with the application data, and put it to an application 'special handling' queue. Notice that I did not say Reason Code. Again, this is not an MQ issue; it's an application issue. Do not expect MQ internals to resolve your business rules issues. Do NOT use the system dead letter queue.
In either case (1 or 2), the application programmers will then need to write an application to get messages from the 'special handling' queue, interrogate the application-specific 'special handling code', then do whatever your business rules dictate. Do NOT use the system dead letter queue.
You are not the first to encounter bad business data; nor will you be the last. I suspect that your application architects didn't plan for bad data in messages. Bad data is strictly an application issue. There is no quick fix to poorly designed applications. System admins can not resolve bad application design.
One more time: Do NOT use the system dead letter queue. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jan 22, 2007 12:18 am Post subject: Re: Setting MQDLH by application |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Abhinav_jain wrote: |
Actually, here the idea is that whenever the Application is too loaded to process the messages, they can be put on a custom dead queue and then a DLQ handler will be run periodically to pick the messages and put them back onto the intended queues. This way the main queue will be free to accept messages continuously.
....
Folks, really need your expert help for some resolution to this...
|
In my expert opinion you have 3 choices:
1) Put the application development team against a wall and shoot them for producing such a stupid idea - an "overflow" queue indeed! The whole point of MQ is to hold messages until processed. What value are you getting from hiding them in queue B instead of queue A? What happpens if a time critical message is sent & hidden under the matteress of queue B? Etc? Etc?
2) Tell the development team they need to build an application that scales properly & has more power than the clockwork mouse they seem to have built.
3) Look into the various methods built into MQ to scale message throughput - multiple reading threads, clustering, etc, etc. If you're on z/OS (you've posted in a CICS section) you also have queue sharing groups available to you.
If I was in your postion I'd use option 1, which will properly motivate the surviving team members when I propose option 2. Holding option 3 in reserve in case they can't get it to scale & I've run out of ammunition.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 22, 2007 7:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| There is no quick fix to poorly designed applications. System admins can not resolve bad application design. |
But it's amazing how often they're called upon to try. I once worked with a DBA who threatened to deck the next developer who blamed the database for poor performance when the application was doing tablescans or Cartesian joins.
I personally quite liked the project manager who suggested buying a "bigger" mainframe would be easier, cheaper & quicker than reworking his development. Never did see the business case for that, but we didn't upgrade the mainframe in the end... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 22, 2007 7:32 am Post subject: |
|
|
Guest
|
The resolution to an underpowered hardware platform is new hardware. If it's the MQGETting application unable to keep up with message MQPUT to the queue, perhaps another concurrent instance of the MQGETting application would help.
(Vitor: shooting all the programmers is counter-productive. Shooting every other programmer would motivate the survivors.) |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 22, 2007 7:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| The resolution to an underpowered hardware platform is new hardware. If it's the MQGETting application unable to keep up with message MQPUT to the queue, perhaps another concurrent instance of the MQGETting application would help. |
It's a philosophical point - when is an underpowered hardware platform not an underpowered hardware platform? When the application is not making the best use of the available resource? Going from a 4-way to an 8-way will not have a significant impact on a single threaded environment.
But hiding the "extra" in another queue is not the answer.
| bruce2359 wrote: |
(Vitor: shooting all the programmers is counter-productive. Shooting every other programmer would motivate the survivors.) |
Point taken; I personally find it more enjoyable explaining to the new team why there's a new team, but that's a preference thing certainly. I've certainly never found any difficulty recruiting more programmers (certainly at this level of percieved skill).
Comparisions with a certain insect are neither confirmed or denied. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 22, 2007 7:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
y'all don't vet your programmers by putting them at the receiving end of a computer-controlled machine gun, and telling them it will start firing in ten minutes, and here's the manual for the software?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 22, 2007 7:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
| y'all don't vet your programmers by putting them at the receiving end of a computer-controlled machine gun, and telling them it will start firing in ten minutes, and here's the manual for the software? |
I now know what the ultimate hardware upgrade is. I must own this device, possess it and make it mine. I shall love it and pet it and clean it and call it George. I must have one, and sometimes use it for interviewing programmers.
After I've resolved some outstanding issues with the test & design teams.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 22, 2007 8:14 am Post subject: |
|
|
Guest
|
Abhinav_jain:
Technical folks (me included) often approach a problem with a single resolution steadfastly in mind. Perhaps the one you originally posted was thrust upon you. Since you asked for help we have offered some alternatives to the deliberate misuse of an MQ mechanism.
Yes, you could create an application that builds a DLH, you could put it to the DLQ, and you could create/modify the supplied Dead Letter Handler to do whatever you want. Consider that when you next apply MQ service, IBM just might corrupt your implementation - requiring you (your programmers) to re-write their applications after each service.
It seems that our ideas conflict with your original post. Appologies. But those of us that have worked with MQ and other vendor products learned pretty quickly to leave the vendor-supplied internals as the vendor intended.
I worked under a manager that used to ask "name five ways to..." accomplish some technical thing. If asked to come up with a (single) way, we naturally become emotionally invested in the one we pick.
If you are in a political environment where you don't get to decide things like this, print the responses to your post and get your manager and programmers to read them.
Expecting to modify IBM-supplied internals to satisfy your unique application design is irrational, and likely won't work in the long run.
Again, appologies if we can't provide you a quick fix to this. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 22, 2007 8:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
All comments to the contrary (and I so want that computer controlled gun!!) the option 3 I outlined above is a much better & more IBM-supported way of dealing with a loaded application than farming messages into other queues.
That's just going to cause so many problems.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| tleichen |
| Posted: Wed Feb 07, 2007 10:19 am Post subject: Re: Setting MQDLH by application |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| Abhinav_jain wrote: |
Hi,
I agree with the statements, that application can clog the DLQ with the messages. Actually, here the idea is that whenever the Application is too loaded to process the messages, they can be put on a custom dead queue and then a DLQ handler will be run periodically to pick the messages and put them back onto the intended queues. This way the main queue will be free to accept messages continuously.
The problem we are facing is that the application is putting the messages on the Dead Queue and the MQDLH header is not coming. We need some way to prefix the message with the header. The application here is Siebel. We can do some scripting to do this. But we want to find out if setting up of MQMD parameters like format (or something else) can achieve this? or is there any way that we can make the Qmanager to prefix this header to the message. |
What you are describing sounds more like some sort of overflow queue. It appears like you should not be pointing them to the DLQ at all. I don't know who wrote the application in question, but if they had intended those messages to go to a DLQ, then they would have put them out with a valid DLH and you would not have to worry about it. Since they did not, you need some other type of application to pull them off of the overflow queue that you would choose in this case. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 07, 2007 3:55 pm Post subject: |
|
|
Guest
|
Against all advice to the contrary, it appears that you are going to continue to allow your programmers to put messages directly into the system dead letter queue; and then expect that the dead-letter-handler utility will then do something with these not-really dead letters.
Refer to the Application Programming Guide Chapter 8. MQDLH – Dead-letter header. It describes what a program can do to put messages directly into the dead-letter queue; and what it must do to make the message look to the dead-letter-handler like a real dead letter. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
