Page 1 of 1

MQ Connector- Selective reading- Aborted with error

Posted: Tue Mar 04, 2008 8:10 am
by basav_ds
Hi,
I am using MQ connector stage as source.I am reading the messages(Msg Read Mode=Delete, so that only the read msgs are deleted from the Q) selectively based on the Filter property 'Application ID Data'(i.e when Application ID Data=1).Wait Time is set to -1, so that MQ connectr keeps on reading msgs for infinite time. The selectively read msgs i.e msgs having Application ID Data=1, are inserted into DB2 table using DB2API stage(Transaction size=1).

Msgs put on Queue are in order as shown:
Msg1(Application ID Data=1), Msg2(Application ID Data=1), Msg3(Application ID Data=2),Msg4(Application ID Data=1)

So when i run the job, Msg1, Msg2, Msg4 are inserted into table and are deleted from the Queue.Now only Msg3 remains on the Queue.

But immedietly after this, the job is getting aborted by itself with the following error:

Src_MQC_selectivereading_Message,0: [IIS-CONN-WSMQ-000016] Get message failed with reason code: 2034(MQRC_NO_MSG_UNDER_CURSOR) (CC_WSMQSourceQueue::getNextMsgFromQueue(), file CC_WSMQSourceQueue.cpp, line 613) [pxbridge.c:2833]

Plz can you tell me what is this error about? And why is it coming?
Suggest your solution to the same.

Thank You.

Posted: Tue Mar 04, 2008 8:27 am
by chulett
Suggest you contact your support provider. Googling for your message seems to indicate this may be a bug. Hard to say, though. :?

Posted: Tue Mar 04, 2008 8:38 am
by ArndW
I don't see how you can change the filter in the stage interactively. Also, are you doing Wave processing?

Posted: Tue Mar 04, 2008 10:12 am
by yserrano
Check if there is another application getting messages from the queue.
Check IBM.com for patches for your Queue Manager installation.

You will probably need to "trace" the queue from the WMQ perspective to see how the messages are extracted from the queue.

I think MQ, after finishing one complete loop thru the queue, is trying to position the cursor back to Msg1(Application ID Data=1) and, since the message does not exist in the queue anymore, the message 2034 is returned.

Posted: Tue Mar 04, 2008 4:38 pm
by eostic
This is certainly an interesting one. Have you tried (at least for testing purposes) filtering in other ways (meaning -- use another column or MQ attribute for the filter --- there are lots of filtering options) to review the behavior under similar conditions? Some of the filtering options use formal MQ API capabilties, and others are historically "derived" within DataStage by browsing first and then looking for filter values. I wonder if this is one of those, and gets into conflict with the syncpoint controls that are in the new Connector.... just a thought.

Ernie

Posted: Tue Mar 04, 2008 11:15 pm
by basav_ds
Hi ArndW,
I am not changing filter condition in MQ Connector stage interactively. Application ID Data=1 is set before compiling.
I have set 'End Of Wave'=Before and 'End Of Data'=Yes

Posted: Wed Mar 05, 2008 3:16 am
by ArndW
In addition to Ernie's suggestions also turn off waves and see if the error behaviour changes.

Posted: Thu Mar 06, 2008 1:07 am
by basav_ds
Hi,
If i turn off the waves, records are not getting inserted into table.

As suggested by Ernie, i tried other filter property 'Priority'. In this case also i am getting the same error.

Another clarification: Error comes only when i put new msg (which satisfies Filter condition) on to Q when job is already running. If i put new msg (which doesn't satisfy the Filter condition) on to Q when job is already running, then no error appears as that msg is not read(hence not deleted from Q).

Another fact to be noted is, this situation works fine without error when i use MQ(normal stage) instead of MQ Connector stage in the job. Here i tested it for filter property 'Priority' (as 'Application ID Data' is not available in MQ normal stage).

So is this the problem(or bug) with the MQ Connector stage rather than problem(or bug) with Websphere MQ...?

Your suggestions plz...

Posted: Fri Mar 07, 2008 12:58 pm
by yserrano
Your problem might be with this:
Wait Time is set to -1, so that MQ connectr keeps on reading msgs for infinite time.
When using "Selective Reading" with MQ it is recommended to clear the MQMD fields used as filters after every successful loop thru the queue.
Of course this is only possible when you are building the application (connector). :(