On Thu, 19 Jan 2012 10:21:01 -0600, Chase, John <[email protected]> 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. Simple solution to this problem is to have the draining transaction do its first MQGET with a wait of say 250 to 1000 ms. Cheers, Jantje. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
