ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ API SupportTransaction takes long time

Post new topicReply to topic
Transaction takes long time View previous topic :: View next topic
Author Message
rtgordon
PostPosted: Mon Jul 16, 2001 11:18 am Post subject: Reply with quote

Apprentice

Joined: 27 Jun 2001
Posts: 34
Location: Lewisville, TX

I did a test program using the sample java programs available. What I am actually doing is sending a message to the host system which fires off a CICS transaction to query a file, populate the message, and send it back to me. It is taking on the outside of ten seconds to perform this. This seems a little on the lengthy side. Should it take this long??

We are sending datagram, non-persistent messages. I can provide anything else you want to know that might help get this figured out.

Thanks,
Gordon
Back to top
View user's profile Send private message Send e-mail
bduncan
PostPosted: Mon Jul 16, 2001 12:25 pm Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

Information about the host in question would be helpful, i.e., it makes a difference if this is a 16-processor Enterprise Sun Server, or a 200mhz pentium running linux. The hardware, OS, and any other software (other than CICS and MQ obviously) that are running concurrently on the system like DB2 or Oracle...


_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
rtgordon
PostPosted: Mon Jul 16, 2001 1:08 pm Post subject: Reply with quote

Apprentice

Joined: 27 Jun 2001
Posts: 34
Location: Lewisville, TX

The NT box is a 4 processor (200mhz each) with two gigs of RAM. (an IBM Netfinity 7000). I don't have any specifics on the mainframe other than it is a MP 3000 H55 running VSE with MQSeries v1.2.0. The data being accessed is coming from standard indexed VSAM files. No Oracle or DB2 here.

gordon

[ This Message was edited by: rtgordon on 2001-07-16 14:13 ]
Back to top
View user's profile Send private message Send e-mail
kolban
PostPosted: Mon Jul 16, 2001 4:28 pm Post subject: Reply with quote

Grand Master

Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA

Gordon. Can we get an understanding of the topology in play here? It is my understanding that an MQ Client can not communicate directly with an MQ/390 server and thus must communicate with an intermediate queue manager. I think I get the impression that you have a Java program that connects to an NT MQSeries queue manager that has a channel definition to the mainframe.... is this correct?

What is the transport protocol between the NT box and S/390 - TCP/IP or SNA?

If you logged in to CICS on the 390 and used the CECI transaction to issue an EXEC CICS LINK to the target program, how long before response? I want to eliminate an overloaded CICS server from the equation.

If after sending the request to the mainframe and while you are waiting for the response, can you poll the response queue using MQExplorer's refresh function? I want to see if the response message becomes available but the program is slow in responding?

Can you post the channel definitions for your channel to S/390?
Back to top
View user's profile Send private message
rtgordon
PostPosted: Tue Jul 17, 2001 6:23 am Post subject: Reply with quote

Apprentice

Joined: 27 Jun 2001
Posts: 34
Location: Lewisville, TX

Thanks a bunch for the responses!

I think that we found part of the problem. In the COBOL program, which is triggered, we get the message, process the request, put the message, and then check for new messages. The wait interval was set to five seconds. We assumed that the program would execute the put, and the message would be on it's way before the program ended. When we took out the loop with wait interval, the program finished in 4-5 seconds. Obviously, we want to get this number as low as possible, so we will continue to look for areas of improvement.

Yes, you are correct about what the program is attempting to accomplish. We are using TCP/IP. As far as CICS being overloaded, that shouldn't be an issue. We are running in a test LPAR, and the COBOL program starts/completes in less than a second. We wrote timestamps out to the CICS log during execution, and they all came back during the same second. I tried polling the queue through mqseries explorer, and I did not see a message waiting during any time the java program was running, so, I am assuming that everything is okay there.

My channel definition to VSE:

dis chl(TXROST01.TXVSET01)
8 : dis chl(TXROST01.TXVSET01)
AMQ8414: Display Channel details.
CHANNEL(TXROST01.TXVSET01)
CHLTYPE(SDR)
TRPTYPE(TCP)
DESCR( )
XMITQ(TXVSET01)
MCANAME( )
MODENAME( )
TPNAME( )
BATCHSZ(10)
DISCINT(60)
SHORTRTY(10)
SHORTTMR(60)
LONGRTY(999999999)
LONGTMR(1200)
SCYEXIT( )
SEQWRAP(999999)
MAXMSGL(32000)
CONVERT(YES)
SCYDATA( )
USERID( )
PASSWORD( )
MCATYPE(PROCESS)
CONNAME(10.1.2.2 (1415))
HBINT(300)
BATCHINT(0)
NPMSPEED(FAST)
MCAUSER( )
ALTDATE(2001-07-16)
ALTTIME(15.01.42)
MSGEXIT( )
SENDEXIT( )
RCVEXIT( )
MSGDATA( )
SENDDATA( )
RCVDATA( )

Thanks again for the help!
gordon
Back to top
View user's profile Send private message Send e-mail
kolban
PostPosted: Tue Jul 17, 2001 7:38 am Post subject: Reply with quote

Grand Master

Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA

Gordon, you gave exactly the clues that are needed. When your CICS Program puts the reply message, it is being put under syncpoint. This means that the message does not make its way back to the requestor until the CICS transaction completes. You can either do an explicit EXEC CICS SYNCPOINT after the put of the message or else put the message with the PMO option of MQPMO_NO_SYNCPOINT. The default on OS/390 is MQPMO_SYNCPOINT.
Back to top
View user's profile Send private message
rtgordon
PostPosted: Tue Jul 17, 2001 11:19 am Post subject: Reply with quote

Apprentice

Joined: 27 Jun 2001
Posts: 34
Location: Lewisville, TX

Great, now our program is running in the sub five second range.Hopefully, through trial and error, we will get it to run even faster. Only problem is that it is not running where it should (see the post in the java/jms section

gordon
Back to top
View user's profile Send private message Send e-mail
bduncan
PostPosted: Tue Jul 17, 2001 2:23 pm Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

Neil,
Great job noticing that syncpoint problem in their code. I'm curious, you mention that syncpoint is default on OS390. Is this only on PUTs? Are GETs syncpointed by default as well? I ask this because I am currently dealing with increasing the performance of an OS390 application the does a browse on a message, processes some information, and when it's all done, it does an MQGET to remove the message from the queue. (Don't ask why we aren't doing a single GET with syncpoint and committing - it's too long of a story to explain!). Anyway, we are trying to make it run faster, and I had been assuming that the GET was being done without syncpoint, because we are issuing the GET without explicitly setting any syncpoint parameters, and I know that on unix systems it defaults to no syncpoint. Since we are only doing the second MQGET to remove the message from the queue when we are done processing its contents (that we got from the browse), then we don't need to do an MQGET with syncpoint right? Even if our application fails right after doing the GET, the message has been removed which is what we want. And if we fail during the GET, well, we would have failed in any case, even if we had been using syncpoint. Either way the message would stay on the queue, which is what we would expect in such an erroneous condition...


_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
kolban
PostPosted: Tue Jul 17, 2001 5:03 pm Post subject: Reply with quote

Grand Master

Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA

From the MQSeries Application Programming Reference - GMO - Options section:

--- cut ---
If neither this option nor MQGMO_NO_SYNCPOINT is specified, the
inclusion of the get request in unit-of-work protocols is determined by the
environment:

o On OS/390, Tandem NonStop Kernel, and VSE/ESA, the get request is
within a unit of work.

o In all other environments, the get request is not within a unit of work.

Because of these differences, an application which is intended to be
portable should not allow this option to default; either
MQGMO_SYNCPOINT or MQGMO_NO_SYNCPOINT should be specified
explicitly.

--- cut ---

Hope this helps....

[ This Message was edited by: kolban on 2001-07-17 18:04 ]

[ This Message was edited by: kolban on 2001-07-17 18:05 ]
Back to top
View user's profile Send private message
bduncan
PostPosted: Tue Jul 17, 2001 8:11 pm Post subject: Reply with quote

Padawan

Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley

Yeah, I ended up tracking that info down in the reference manual as well, and informed our application programmers that we can force NO_SYNCPOINT in order to get the approx. 10x performance gain on the MQGET. Multiply that by the 1000s of transactions per hour we do, and it should increase throughput by some measureable amount.. hopefully..
thanks for the info!


_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator
Back to top
View user's profile Send private message Visit poster's website AIM Address
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ API SupportTransaction takes long time
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.