Peter, I don't know about any tool to do this. Have you thought about getting the time before and after the get, do the math in the program and put a non-persistent message to a protocol queue? Performance impact of the second put (non-persistent, outside syncpoint) should be minimal. You could then trigger a little program off that queue that either writes the results to a file (probably including an application and queu name, if you want to use it in several applications) or a database asynchronously without any further impact. You then can use any standard software (e.g. EXCEL) to do charts etc. off of that. It's a bit of work I admit, but it's a possible option. Just a thought, Stefan
>From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: How long did my MQGEt wait? >Date: Thu, 29 Aug 2002 15:18:35 -0400 > >I did this originally. I added some displays before the Get and After the >GET and then checked SYSOUT. Grabbed a pencil and paper and checked about >30 >transactions and did the math. > >But I need something that will track all this automatically. Manually >looking at SYSOUT is not feasible. I toyed with the idea of directing this >data to a DB, and then writing code to sort and process it all, but now I >have DB writes in my app, which itself effects performance. > > > >Peter Potkay >IBM MQSeries Certified Specialist, Developer >[EMAIL PROTECTED] >X 77906 > > >-----Original Message----- >From: Bruce Giordano [mailto:[EMAIL PROTECTED]] >Sent: Thursday, August 29, 2002 3:02 PM >To: [EMAIL PROTECTED] >Subject: Re: How long did my MQGEt wait? > > >Assuming you can update the application and that all replies get back in 5 >seconds, just check the time when you issue the put and then check the >time again when you get a reply back from the get. The difference is how >long it took. You do realize don't you that increasing the wait to 5000 >milliseconds isn't going to slow down the response from the get. Your >application should get control back as soon as a message arrives on the >reply queue. > - Bruce >Giordano > > > > "Potkay, Peter M (PLC, IT)" > <[EMAIL PROTECTED]> To: >[EMAIL PROTECTED] > cc: > Sent by: MQSeries List Subject: How >long did my MQGEt wait? > <[EMAIL PROTECTED]> > > > > Thursday August 29, 2002 02:12 PM > Please respond to MQSeries List > > > > > > >My mainframe app sends a request and immediately goes to the reply queue to >wait for the reply. We have the wait set to 500 milliseconds, which is a >business requirement (hope) that this transaction comes back in that amount >of time. > >The request goes to MQSI to be converted from COBOL to XML, to a >distributed >platform to have the request processed, the XML reply then goes thru MQSI >to >be converted back to COBOL before the reply is placed to the reply queue >back on the mainframe. > >20% of the GETs are getting 2033, but we do see those replies back on the >reply queue. I assume that 500 milliseconds is to little. Is there anyway >to >know what wait interval will satisfy 99.9% of the transactions other than >bumping up the wait time a little every couple of days till it seems to >work? > >I would like to be able to jack the time up to say 5000 milliseconds and >then run with it a week, at the end of which I would like to say to the >customer "Hey, the average wait time was 453 milliseconds. 90% came back in >600 milliseconds. The shortest wait was...." > >Is there any way/tool to do this? > >As for those reply messages that seem to make it back to late, is there any >way/tool to tell how long they took to make the round trip? (System clocks >between all the machines are not synced.) > >Peter Potkay >IBM MQSeries Certified Specialist, Developer >[EMAIL PROTECTED] >X 77906 > > > >This communication, including attachments, is for the exclusive use of >addressee and may contain proprietary, confidential or privileged >information. If you are not the intended recipient, any use, copying, >disclosure, dissemination or distribution is strictly prohibited. If >you are not the intended recipient, please notify the sender >immediately by return email and delete this communication and destroy all >copies. > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
