Author |
Message
|
AKM |
Posted: Tue Dec 03, 2013 11:19 pm Post subject: Skipping/Deleting 0 Byte file when receiving Over MQ |
|
|
Newbie
Joined: 03 Dec 2013 Posts: 3
|
Hi,
We have been using basic MQ for transmitting and receiving messages in our application and using triggers to process the received messages.
Recently we observed that when we are receiving a 0 byte file over MQ, the trigger stops and always need to be manually started.
We are seeking guidance to identify 0 byte file and delete from the Queue probably thru Channel Exit / Msg Exit script in C program.
any guidance and help on this would be highly appreciated.
Regds
AKM |
|
Back to top |
|
 |
zpat |
Posted: Wed Dec 04, 2013 12:30 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
MQ does not send files, it sends messages.
If you are generating empty messages, then fix it at source. To use an exit would be ridiculous. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
AKM |
Posted: Wed Dec 04, 2013 1:11 am Post subject: |
|
|
Newbie
Joined: 03 Dec 2013 Posts: 3
|
Hello Mr Jedi,
Thanks a lot for your quick response. Much appreciated.
Unfortunately we have no control over the source application and hence we are required to provide the solution in our application.
You are correct about the message over the MQ and not the file. |
|
Back to top |
|
 |
zpat |
Posted: Wed Dec 04, 2013 3:01 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
You should to refuse to implement a faulty application.
You should not adopt a "we will work around it no matter how stupid it is" approach.
This is a cultural issue, that I often see and it is not the right approach.
The source app is badly broken and needs to be corrected by whoever owns that application.
To code an exit (a very low-level and difficult thing to get perfect) would be really the wrong thing to do. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
Vitor |
Posted: Wed Dec 04, 2013 5:48 am Post subject: Re: Skipping/Deleting 0 Byte file when receiving Over MQ |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
AKM wrote: |
Recently we observed that when we are receiving a 0 byte file over MQ, the trigger stops and always need to be manually started. |
Why? There's nothing inherently wrong about a zero byte message that should cause a trigger not to fire.
If you mean the triggered application can't tollerate a zero byte message and abends, you should fix that. Even that wouldn't (or shouldn't) stop the WMQ triggering process working.
AKM wrote: |
We are seeking guidance to identify 0 byte file and delete from the Queue probably thru Channel Exit / Msg Exit script in C program.
any guidance and help on this would be highly appreciated. |
Yes - don't do it. As my worthy associate points out, exits are a highly advanced topic and should be considered the last resort solution to any problem. Remember that an exit runs as part of the WMQ internal process it was called from, so an inexpertly written exit will have consequences for resource use and performance.
A badly written exit will bring your queue manager crashing down.
That's a big risk to take just to handle a zero byte message correctly. I'd fix whatever you've done wrong with the triggering first. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
AKM |
Posted: Wed Dec 04, 2013 7:23 pm Post subject: |
|
|
Newbie
Joined: 03 Dec 2013 Posts: 3
|
Thanks Vitor and Jedi for your comments. The root cause of this message is not yet identified and hence the source system application is not taking any responsibility for the empty message. The overall understanding is that the QManager is somehow creating this empty message and not the application.
Our application is using a C program to read the messages and convert them to file and this process is failing. Due to this being a legacy system and huge dependency of other modules on this C program, it is not easy to change the same. Hence my request was to write a new C program and use it in Channel exit on the receiver side. This program will identify the message with 0 bytes and delete it from the queue.
Your suggestions are most welcome. |
|
Back to top |
|
 |
zpat |
Posted: Wed Dec 04, 2013 11:08 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Fix the putting application. There is no other rational approach.
Queue managers do not randomly put zero length messages on a queue.
You can isolate MQ applications very easily. First put the messages to the queue (but do NOT consume them yet). Inspect this queue with MO71 or MQ explorer and ensure all messages are valid (correct MQMD format, ccsid, length, persistence etc).
If any are not valid, FIX the application that puts them on the queue. Don't try to tell me you can't be sure if there are zero length messages - look at the queue - are they there or not?
When you have only valid messages on the queue, then any problems are due to the consuming application. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Dec 05, 2013 8:29 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Application data payload of an MQ message can be from zero bytes to 100 megabytes per physical message. Apparently, the application that is creating the zero-byte messages is doing just that - specifying application data length of zero bytes just before the MQPUT command. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
zpat |
Posted: Thu Dec 05, 2013 8:41 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Strictly speaking any message on a queue is "valid" in pure MQ terms - MQ is not that fussy (unless you try to convert the message).
However you need to change either the putting application to avoid poisoning the getting application, or change the getting application to tolerate any unpleasant messages it might get (and discard unwanted ones).
Using an exit (which is a low-level extension to the IBM product code) is not necessary other than in extreme circumstances. It would also be an on-going maintenance and upgrade concern. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Last edited by zpat on Thu Dec 05, 2013 8:44 am; edited 1 time in total |
|
Back to top |
|
 |
bruce2359 |
Posted: Thu Dec 05, 2013 8:43 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
with zpat. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
Vitor |
Posted: Fri Dec 06, 2013 5:28 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
AKM wrote: |
it is not easy to change the same. |
It's going to be easier than writing a channel exit and will have much less potentially fallout.
AKM wrote: |
Your suggestions are most welcome. |
My suggestion remains the same - don't do it.
You started out asking for guidance and help; you now have it. You must now decide if you want to go ahead with this exit, armed with the guidance you got from us about how much trouble you're making for yourself, or if you want to fix the consuming application, or if you want to push back on the sender. In the end, it's your decision because it's your site and you have to live with this.
My final comment - queue managers do not randomly put zero byte messages on queues, or any message randomly. They do it in response to application or configuration action. The source application people refusing responsibility on that basis are being ludicrous. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|