Hello Ken, I seriously doubt you are 'losing messages'. What is mostly likely happening is that during the first step of processing by BizTalk, it is finding some thing that it does not know or like and error-ing out / abending without writing anything to your DB or log files.
> Is there any way to turn on any MQ logging so we can see that the message > is actually being picked off the queue? There are commercial 'Message Tracking' products that can help or you can try the unsupported 'mirrorq'. See here for 'Message Tracking' products: http://www.capitalware.biz/mq_tools_comm.html#mqtrk Or here for 'mirrorq' http://www.capitalware.biz/mq_code_c.html#exitcode > The queues are setup as persistent. Is there anyway to interpret what is > in the log/active folder to see what is going on? Log replay see here for commercial products: http://www.capitalware.biz/mq_tools_comm.html#mqlog > Can the MQ trace facility be used to help us? Not really. > In parallel, the developers are looking at the code to see if there is a > flaw. I'm positive that is where the bugs are but developers get very protective of their code, so you may here something like: 'we had to update our code to handle MQ losing messages'. Translation: They found the bug and fixed it but they don't want to admit it. :) Regards, Roger Lacroix Capitalware Inc. http://www.capitalware.biz On Thu, 7 Jun 2007 11:34:20 -0400, [EMAIL PROTECTED] wrote: > Let me describe our dilema and if anyone has any suggestions on how we can > troubleshoot this, it would be greatly appreciated. > > We have a mainframe application that receives messages from a server based > application on a queue. The mainframe processes the message and puts a > response on a queue (it gets this from the reply to queue/manager from the > initial message). The application that reads the response is a biztalk > application and does a mqget every second to see if messages are waiting > (I > know thats alot of overhead, but until we can re-architect it I am stuck > with it). > > The problem is that we are intermittently losing messages. The mainframe > confirms that they are putting the response on the queue, and the biztalk > application does not appear to be seeing it. We put a network sniffer and > we actually do see the mq message coming over the network. We compared > that message to one that was properly received and nothing jumps out at > us. > In a normal situation, as soon as a message is picked off the queue it > writes to a SQL database with tracking info. The "lost" transactions are > not appearing on the database. > > > Now the questions: > > Is there any way to turn on any MQ logging so we can see that the message > is actually being picked off the queue? > The queues are setup as persistent. Is there anyway to interpret what is > in the log/active folder to see what is going on? > Can the MQ trace facility be used to help us? > Any other ideas would be greatly appreciated. > > In parallel, the developers are looking at the code to see if there is a > flaw. (maybe 2 messages arriving at the same time - it processes 1 and > drops the next?). > > To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
