| Author |
Message
|
| flowersa |
 Posted: Wed Aug 07, 2002 10:06 am Post subject: Losing Messages Sending From 0S/390 to HP-UX |
 |
|
Newbie
Joined: 03 Jul 2002
Posts: 5
|
Hi all,
We are experiencing something strange. When a job is kicked off on the mainframe (OS/390) that sends messages to HP-UX for the first time for the day, we lose the very first message. We keep logs of all mqseries activities and it indicates that the message was created and sent. We then look at the target queue and find that it is not there. It appears that the lost message is placed on the sending QMGR's DEADQ for some reason. After the first run of the day there are no problems. All messages are sent successfully to the target. Not sure what to do here.
Note...The QMGRS are in a cluster the channels are created dynamically.
Any help would be much appreciated.
Thanks in advance.
Alan |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Wed Aug 07, 2002 10:13 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well the message in the dead queue will have a DLQ reason code that may help you find the issue
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| poki |
| Posted: Wed Aug 07, 2002 12:08 pm Post subject: |
|
|
Newbie
Joined: 05 Aug 2002
Posts: 9
Location: US
|
Hi
If your channel count increases then definitly your message would have reached your. May be its in DLQ or being picked up by appl. |
|
| Back to top |
|
|
| flowersa |
| Posted: Thu Aug 08, 2002 8:45 am Post subject: |
|
|
Newbie
Joined: 03 Jul 2002
Posts: 5
|
Thanks for the reply. We just tested this again today and found the messages are not being tossed to the DLQ. The only thing we can think of is that we do not have a stable channel by the time the first message is sent. Since we send it as non-persistent we lose it. Not sure if this makes any sense but we are going to test sending persistent messages to see if we lose it on the first run.
If anyone has any ideas please toss them my way.
Thanks.
Alan. |
|
| Back to top |
|
|
| GMcCarthy |
| Posted: Thu Aug 08, 2002 10:57 am Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
I don't believe the persistence would make the difference. Did you check your XMITQs? Maybe it's on the default XMITQ.
_________________
Regards,
Gina
IBM Certified MQSeries Specialist |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Aug 08, 2002 5:01 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
What is the Expiry value of the first message of the day?
What is the disconnect interval of the channels?
Here is a guess...
If you have a very small expiry, the first message of the day may expire on the XMIt queue before the channel can start. For the rest of the day, if the channel doesn't pause you are OK, but overnight there is a long enough period of inactivity that the channel goes inactive, causing a problem for the first message to start that channel up.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Aug 08, 2002 8:34 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Yes, persistance can make a difference.
If the MCA is having channel problems, it has the right to discard ANY non-persistance messages on restart!!
Although, are you sure that the receiving application is not getting and then throwing the message out (discarding it) without writing out any error messages?
later
Roger... |
|
| Back to top |
|
|
| GMcCarthy |
| Posted: Mon Aug 12, 2002 7:22 am Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
Roger,
Are you talking about restart of the channel or the qmgr?
If you are talking about channel issues, the MCA will not discard a message waiting to be transmitted - persistent or non-persistent (excluding expiry).
I don't believe he was talking about losing messages because of a qmgr restart. In which case, persistence is extremely vital.
_________________
Regards,
Gina
IBM Certified MQSeries Specialist |
|
| Back to top |
|
|
| flowersa |
| Posted: Mon Aug 12, 2002 8:36 am Post subject: |
|
|
Newbie
Joined: 03 Jul 2002
Posts: 5
|
| We changed our messages to be persistant and we have not lost any in the last two days. I check the expiry on the messages and we were using the defaults (MQEI_UNLIMITED) so that wasn't an issue. It appears that the persistence trick fixed our problem. We still don't know why we have to send a message over with persistence from OS/390 to make sure it is not lost when starting the channel but if it works we are happy with that. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Mon Aug 12, 2002 8:40 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well I would keep an eye on your system performance, persistent messages can severly impact performance.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| flowersa |
| Posted: Mon Aug 12, 2002 8:47 am Post subject: |
|
|
Newbie
Joined: 03 Jul 2002
Posts: 5
|
Thanks Jeff, this is one thing we are concerned with. For majoriy of the messages sent during the day we are not too worried but for our batch processing at night we are concerned. This is something we will definetly have to monitor.
Thanks to everyone for the help. This forum is AWESOME! |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Aug 12, 2002 8:37 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
GMcCarthy,
Go look-up the NPMSPEED(Fast) channel attribute in the MQSeries Intercommunication (or MQ System Admin) manual. You will understand what I am referring to.
Note: Fast is the default value for NPMSPEED. Therefore, since most people do not change this setting, non-persistent messages can be lost on channel restart.
later
Roger...
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| flowersa |
| Posted: Tue Aug 13, 2002 5:00 am Post subject: |
|
|
Newbie
Joined: 03 Jul 2002
Posts: 5
|
Roger, I checked and we are using the default (FAST). We would like to send these messages over as non-persistent. It appears if we change this attribute to NORMAL we will not lose any messages. Question, how is performance affected?
Thanks. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Aug 13, 2002 8:18 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hi,
Because of IBM's stupid little quirk, ALL transmit queues should always be defined with persistent set to YES.
Now in the real world, what the transmit queue persistent is set to and what persistence you use in your MQ application should not be related.
Obviously, messages with persistent set to YES will be slower than non-persistent messages. But that is ok (the trade-off is slower delivery but guaranteed delivery!!!).
What you have to decide is if the message if important (must not be lost). E.g. bank transaction, sales order, etc… These types of messages MUST be persistent messages.
The type of messages that should be set to non-persistent are query or informational messages. E.g. transaction history, client/server account lookup, web query for current status, etc… The MQ Application(s) that handle these types of messages (non-persistent) should be coded to handle missing or lost messages. E.g. Time-out after 15 seconds and try again (of course, with the user's permission!!!)
later
Roger Lacroix
Enterprise Architect
Capitalware Inc.
----------------------------------------
IBM Certified Specialist - MQSeries
IBM Certified Developer - MQSeries
IBM Certified Solutions Expert - MQSeries
----------------------------------------
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 14, 2002 5:23 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7716
|
Roger, If/when the MCA tosses a message because of a problem, is there any record of it after the fact?
I am trying to solve an app's problem where every once in a while they requesting application says they never got the reply. The replying app swears they put out the reply since their log file shows a good put.
The request queue statistics show the request came in and was pulled out.
The reply queue statistics show that the reply was never put to it.
So if the replier is putting the message, and its not on any DLQ, or XMIT queue, or the reply queue, and the apps log shows that the put was good to the correct reply queue with a big expiry, I wonder if the MCA is tossing the message.
But I would like proof first. I don't wanna just turn persistence on and hope. Besides these are inquiry message, high volume. Persistent is not appropriate for them.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
