One possibility is that if you queue's delivery sequence is a priority (instead of FIFO) then it is possible to insert higher priority messages behind the browse cursor so that they will not be seen until a browse first is issued (resetting the browse cursor).
The same thing may be possible with equal priority message or in a FIFO
queue if messages 1 and 2 are put under syncpoint but messages 3 is put by
another UOW and committed while the first two are not yet committed. The
browse next would return message 3 under these circumstances and I believe
move the browse cursor past messages 1 and 2 (who's places on the queue
were set during the put, not the later commit). If this is true then again,
until you get to the browse first again, the messages are behind the
cursor.
I am a little puzzled why you would use such extremes for wait interval
starting with 0 then jumping to unlimited. Once you are at unlimited
anything that ends up behind the browse cursor is not a candidate for your
browse-next, until you run into a condition that causes you to
browse-first. Typically I've seen these application triggered on first,
using an appropriate wait interval to prevent unnecessary re-triggering and
shutting down during periods of longer inactivity ( up to your definition
of what is long). Then relying on MQ and the CKTI transaction to wake-up a
new instance of the servicing transaction.
I'm also curious why you chose to 1) browse the message, 2) process it, and
then 3) destructively get and commit the get if the processing worked.
Typically applications I've worked with 1) destructively get the message
under syncpoint (making it unavailable to anyone else and yet still there),
2) process it, and then 3) commit the get if processing worked (otherwise
roll it back).
Rick
|---------+--------------------------------------->
| | Sridhar Ramasubramonian |
| | <[EMAIL PROTECTED]>|
| | |
| | Sent by: MQSeries List |
| | <[EMAIL PROTECTED]> |
| | |
| | |
| | |
| | Tuesday September 17, 2002 10:56 AM |
| | Please respond to MQSeries List |
| | |
|---------+--------------------------------------->
>----------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Application using BROWSE missing messages
|
>----------------------------------------------------------------------------------------------------|
hi all...
I am looking for some help to solve a particular problem that we are
facing here.
The problem is explained below.....
We have a MQ based application written in C++ running in CICS and reading
messages
from MQ. The overall functioning logic of the application is as explained
below.
|----|------>( 1 ) Input queue opened for Browse with options and read in a
LOOP till messages are over.
| | MQGMO_WAIT + MQGMO_FAIL_IF_QUIESCING +
MQGMO_BROWSE_NEXT+MQOO_INPUT_SHARED
| | and wait interval as 0.
| |
| | ( 2 ) Use message (May have syncpoint calls in this process)
| |
| | ( 3 ) IF DB deadlock of -911 THEN
| | is got then ROLLBACK everything uncommitted, and
repeat step 1 onwards with
| | the following options
MQGMO_WAIT+MQGMO_FAIL_IF_QUIESCING+MQGMO_BROWSE_FIRST
| | Change here is that the queue is again reopened
fresh with a Browse_First option as shown above.
| | ELSE
| | Remove the message under syncpoint control with a
destructive Get with the
| | following options, MQGMO_WAIT +
MQGMO_FAIL_IF_QUIESCING + MQGMO_MSG_UNDER_CURSOR
| | + MQGMO_SYNCPOINT
| | ENDIF
| |
| |------- ( 4 ) Perform a SYNCPOINT in CICS
|
| ( 5 ) Out of above loop when no more entries left in queue on
error code 2033
|
| ( 6 ) Infinite wait on MQ Read by using the below options ,
| MQGMO_WAIT + MQGMO_FAIL_IF_QUIESCING + MQGMO_BROWSE_NEXT
and MQWI_UNLIMITED
| Transaction is waiting on MQ to alert and wake this guy up
when a message arrives.
|
|----------- ( 7 ) Message arrives in queue and from this point step 1
onwards is repeated
PROBLEM
In the above logic that we are using we are using we have noticed that
some-times a queue has 1 or 2 messages
and the transaction in CICS is in GETWAIT waiting for messages to arrive.
The 2 messages which get left out are
never picked up where as further messages which arrive in that input queue
are picked and processed.
Anybody facing a problem like this or know of something in this regard.
Also i see a PTF at the IBM site closed recently with details as below
APAR CLOSE
DATE
yy/mm/dd PTF(s) Fixing APAR
if PTF in error HIPER? Description/comments
PQ61246 02/08/15 UQ68768
MQGET WITH WAIT ISN'T POSTED ALTHOUGH THE QUEUE HAS A MESSAGE.
Any IDEA as to how to get the details for this.. or anybody out there who
might have actually have
raised this particular problem.
Any help would be highly appreciated.
Thanks and regards
Sridhar R
(See attached file: C.htm)
|
hi
all...
I am looking for some
help to solve a particular
problem that we are facing
here.
The problem is explained
below.....
We have a MQ based application
written in C++ running in CICS and reading messages
from MQ. The overall functioning
logic of the application is as explained below.
|----|------>( 1 ) Input queue
opened for Browse with options and read in a LOOP till messages are
over.
| | MQGMO_WAIT
+ MQGMO_FAIL_IF_QUIESCING + MQGMO_BROWSE_NEXT+MQOO_INPUT_SHARED
| | and
wait interval as 0.
| |
| | ( 2 ) Use
message (May have syncpoint calls in this process)
| |
| | ( 3 ) IF DB
deadlock of -911 THEN
| | is
got then ROLLBACK everything uncommitted, and repeat step 1 onwards with
| | the
following options
MQGMO_WAIT+MQGMO_FAIL_IF_QUIESCING+MQGMO_BROWSE_FIRST
| | Change
here is that the queue is again reopened fresh with a Browse_First option as
shown above.
| | ELSE
| | Remove
the message under syncpoint control with a destructive Get with the
| | following
options, MQGMO_WAIT + MQGMO_FAIL_IF_QUIESCING +
MQGMO_MSG_UNDER_CURSOR
| | +
MQGMO_SYNCPOINT
| |
ENDIF
| |
| |------- ( 4 ) Perform a SYNCPOINT
in CICS
|
|
( 5 ) Out of above loop when no more entries left in queue on error code
2033
|
| (
6 ) Infinite wait on MQ Read by using the below options ,
| MQGMO_WAIT
+ MQGMO_FAIL_IF_QUIESCING + MQGMO_BROWSE_NEXT and MQWI_UNLIMITED
| Transaction
is waiting on MQ to alert and wake this guy up when a message
arrives.
|
|----------- ( 7 ) Message arrives in
queue and from this point step 1 onwards is repeated
PROBLEM
In the above logic that we
are using we are using we have noticed that some-times a queue has 1 or 2
messages
and the transaction in CICS
is in GETWAIT waiting for messages to arrive. The 2 messages which get left out
are
never picked up where as
further messages which arrive in that input queue are picked and
processed.
Anybody facing a problem like this or know of something
in this regard.
Also i
see a PTF at the IBM site closed recently with details as
below
Any
IDEA as to how to get the details for this.. or anybody out there who might have
actually have
raised
this particular problem.
Any
help would be highly appreciated.
Thanks
and regards
Sridhar R
|
