Originally posted by: SystemAdmin

I put an MQ driven system up from 7.5 to 8.1 (my first), and Management console keeps generating error after error of system not available. Turning the trace on, I see 2033, message not available. If I throw one on the queue, I'll get a success, then the 12's will pile back on.

It's like it's not listening, it just keeps attempting to read, rather then wait for a message.

Any help is appreciated.

17538-001>: FULL TRACE ON
<17538-001>: Adapter command: -QMN UGA009HDS -QN N174.EASYLINK.EDI.INBOUND -T
<17538-001>: intm4mqsCheckAdapterCommand
<17538-001>: intm4mqsCheckAdapterCommand (rc = 0) OK
<17538-006>: m4mqsConnect
<17538-006>: | MQCONN, hQueueManager = 1100005624
<17538-006>: | Connected successfully to the queue manager UGA009HDS
<17538-006>: m4mqsConnect (rc = 0) OK
<17538-006>: m4mqsOnNotify
<17538-006>: | OnNotify->ListenStart
<17538-006>: | intm4mqsOpenQueue
<17538-006>: | | Obtaining handle for the queue N174.EASYLINK.EDI.INBOUND
<17538-006>: | | Queue N174.EASYLINK.EDI.INBOUND is the first queue on the connection
<17538-006>: | | Opening queue N174.EASYLINK.EDI.INBOUND
<17538-006>: | | Queue N174.EASYLINK.EDI.INBOUND was opened successfully
<17538-006>: | intm4mqsOpenQueue (rc = 0) OK
<17538-006>: m4mqsOnNotify (rc = 0) OK
<17538-006>: m4mqsListen
<17538-006>: | intm4mqsObtainQueueNode
<17538-006>: | | Queue node found: N174.EASYLINK.EDI.INBOUND
<17538-006>: | intm4mqsObtainQueueNode (rc = 0) OK
<17538-006>: | MQGMO_NO_WAIT specified
<17538-006>: | No message found
<17538-006>: | MQSeries error (ReasonCode = 2033)
#DataExchange
#IBM-Websphere-Transformation-Extender
#IBMSterlingTransformationExtender

Originally posted by: SystemAdmin

When you say "MQ driven system", you mean the SourceEvent is set to ON for the MQ Input in your system definition, right?

In the trace log, the line "MQGMO_NO_WAIT specified" indicates that WTX is trying to read the message and should fail if there is none (and that's the behavior you're seeing).

Without further information, I would question if some other event is the trigger for your system, then the system also tries to read MQ?
#IBMSterlingTransformationExtender
#IBM-Websphere-Transformation-Extender
#DataExchange

Originally posted by: SystemAdmin

Yeah, I just noticed the "no wait", but I had tried it with LSN=S, which is infinite, and the default, and I got the same results.

A co-worker did just offer something else I can check, so I'll do that and post if I get a good result.

Thanks!
#IBM-Websphere-Transformation-Extender
#DataExchange
#IBMSterlingTransformationExtender

Originally posted by: SystemAdmin

I'm an idiot. Well, no, but I feel like one, though I still don't know why that trace log said that.

I posted a while back about a SUBSTITUTE function that worked in 7.5, that killed the map with two tags of the audit log created. I hit another testing a map in this system, changed it to LEAVEAPLPHANUM() and it worked. I tested another map in this system, failed again, and I changed the SUBSTITUTE, that builds the output filename, to LEAVEALPHANUM(), but what I didn't realize, is the MID that was in there. So I named the output file the entire lenght of the input data, of which looks like it was enough to kick off the map, but not get read.

That map just happens to have the same name as the one I thought was failing and created the log, both of which are in the same msl.

I guess if I thought about it, you could use the map mmc more then once in the same msl, if the msl is going to overwrite the input and output when it runs it, based on which one got kicked off......I just never would do it that way.
#IBMSterlingTransformationExtender
#DataExchange
#IBM-Websphere-Transformation-Extender

Originally posted by: TarunB

I had a similar situation the other day where a map was set up to trigger from a queue and kept on producing 2033 errors in the m4mq trace file.

Errors weren't being displayed in the Mgmt Console, neither were there any map errors. This is because no maps were being executed, because nothing had arrived on the queue. So what appeared to be happening was that the event trigger continually polled the queue and kept throwing up 2033 errors because there wasn't a message. When a message did arrive, the return code was OK and the message was processed successfully.

These 2033 errors piled up causing a huge trace file to be produced. I have yet to investigate why this occurs, but for now I have simply turned off all input MQ traces (output traces do not have the same problem).
#IBMSterlingTransformationExtender
#IBM-Websphere-Transformation-Extender
#DataExchange

Originally posted by: SystemAdmin

We've had several problems with various 8.1.0.1 adapters, so I wanted to see if the same behavior is found across different versions. I tried a map that is triggered by MQ in 7.5.1, 8.1.0.1, and 8.1.0.3 launchers and all filled the mqstrace.log with 2033 errors.

As an MQ support person at my organization, this seems like something that should be changed at the adapter. In my limited understanding of how the adapter works, it connects to MQ and Browses the queue until a message is found. Only when a message is available is the destructive Get done.

If the adapter is Browsing to see if a message is available, no messages on the queue is a normal occurrence and should be ignored. However, if the Browse operation indicates a message is available then the Get call receives a 2033 from MQ, that may be an error. (It depends on whether or not another application is allowed to read the same queue at the same time, say in a multi-threading case.)
#IBMSterlingTransformationExtender
#DataExchange
#IBM-Websphere-Transformation-Extender