Are they getting with wait for  specific message or hoping the first
message returned is the one they are waiting on.

I hope they are waiting on a specific message retrieving my correlid or
something.
They better find a way to get rid of expired messages from the applications
that returned a message after the wait ended.
I forgot the rules for using expiry and do not have time to look it up.  I
think any browse will delete the expired messages not sure if a get by
correlid  will do this but it sure seems if they are getting the wrong
messages they are not getting by correlid and are hoping for all theings to
fall into the proper sequence.


I know this is all pretty basic and not what you are asking but maybe it
will trigger some other ideas.



                      Jim Ford
                      <[EMAIL PROTECTED]        To:       [EMAIL PROTECTED]
                      M>                       cc:
                      Sent by: MQSeries        Subject:  Debugging Help on OS/390 
Needed
                      List
                      <[EMAIL PROTECTED]
                      N.AC.AT>


                      07/14/2004 04:15
                      PM
                      Please respond to
                      MQSeries List






One of our less savvy application teams has put together a big, clumsy app
that is having problems. It's big and clumsy enough that they are having
problems describing it to me. As near as I can tell, they have an
MQ-enabled CICS transaction. This transaction does an EXEC CICS LINK to a
few subprograms. Those programs in turn LINK to more programs. Or some of
them may do one or more synchronous MQ round trips to get information. They
say it is about 5 "layers" deep.

Problems have surfaced lately where their app is slowing down and/or
failing. In some cases info is returned from a different loan than the end
user is working on. To try to fix it, they changed a bunch of their
get-with-waits to wait longer. Things still fail, but now take longer to
fail. So there's obviously some problem in their code, probably where they
are losing replies somehow. They, of course, feel they've proven it's an MQ
problem, and have dumped it on me.

These are all synchronous processes, with non-persistent messages and many
dynamic reply queues. It's really difficult to capture any relevant
information. Even our CICS monitor isn't much help, because some of these
CICS transactions stay up all day and process hundreds of messages.

Any tips on how to get my hands on something I can use to debug this?

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

Reply via email to