> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Jan MOEYERSONS
> 
> On Thu, 19 Jan 2012 10:21:01 -0600, Chase, John wrote:
> 
> >Occasionally, that MQ-draining transaction will be spawned nearly
1,000
> >times per second, and apparently "do nothing":  No "I'm starting"
> >message, no "I'm finished" message, no ABEND, no nothing.  SMF
records
> >for these "phantom" transactions, formatted by CA-Sysview, show that
> >each instance starts the program, which then issues two MQOPENs (not
> >back-to-back), two MQCLOSEs (again, not back-to-back), one MQINQ, one
> >MQGET and one SQL SELECT, and then it ends "without comment".
Average
> >task lifetime for these "phantoms" is around 8 milliseconds.
> 
> I think this may be related to the fact that an MQ triggering message
is made available to the
> initiation queue at the very moment the sending application puts an MQ
message on the queue, before
> this application message is committed. Depending on how long it takes
the batch program to commit its
> unit of work, this may well result in the draining transaction firing
up, finding its input queue
> empty and ending again. Because there are still messages on the queue
(not yet available for draining,
> but they are there...) MQ then immediately re-triggers the same. Over
and over and over... until a
> message is actually committed and thus becoming available to the
drainer.

Hmmm....  That seems consistent with what we see in the SMF records, and
seems to explain why the problem eventually "corrects itself".  

Here's an excerpt from the SMF record of a "normal" transaction:

                                                     --Message Length--

APIcall    Object                               Reqs   Avg   Max  Total
>RC00
MQGET      APPLICATION.QUEUE                       2   705   705   1410
1

Here's the same excerpt from a "phantom" transaction:

                                                     --Message Length--

APIcall    Object                               Reqs   Avg   Max  Total
>RC00
MQGET      APPLICATION.QUEUE                       1
1

Note the absence of data under the --Message Length-- header in the
"phantom" transaction.

> Simple solution to this problem is to have the draining transaction do
its first MQGET with a wait of
> say 250 to 1000 ms.

I've forwarded this to our Application Support team.

Thanks,

    -jc-

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to