Why My WebSphere MQ (on Windows) API Exit didn't record anything when I put messages through a client program based on Java?

Question

I wrote a API EXIT for WebSphere MQ 7 on Windows, when I put to or get from queue a simple message from command line like: "amqsput" or "amqsget", I would get some log files containing information like time, message data, queue name, etc.

That's what I expect for my test program writen in Java, but when I used code below:

MQMessage msg = new MQMessage();
msg.writeUTF("Hello, World!");
MQPutMessageOptions pmo = new MQPutMessageOptions();
queue.put(msg, pmo);

I got blank log file. Then I used code below:

MQMessage msg = new MQMessage();
msg.writeString("Hello, World!");
MQPutMessageOptions pmo = new MQPutMessageOptions();
queue.put(msg, pmo);

Then I saw familar data in log file.

I opened MQ explorer, I saw two messages in "Message Browser":
Hello, World!
%Hello, World!

I'm totally lost here, where is this "%" from? My api exit didn't record the put action because of the encoding?

Any advices would be appreciated! Thank you!

Answer 1

I'm pretty certain I remember reading somewhere that writeUTF() outputs length information as well as the string.

---

Ah, yes, here it is:

From IBM's own doco on WriteUTF():

This method takes an ActiveX string and writes it into the message data buffer at the current position in UTF format. The data written consists of a 2-byte length followed by the character data. DataOffset is incremented by the length of the string if the method succeeds.

(my italics). As you've already discovered, WriteString() is the way to do it without a length.

Answer 2

When you install an API exit, the queue manager must be stopped and restarted in order to load the exit. Did you by any chance recycle the QMgr between executing the first and second programs?

Also, unless the exit explicitly flushes the output buffer you may not see the output immediately. This is another possible explanation for the behavior you are seeing.

Finally, what version of WMQ are you on? (Do a dspmq to find out.) Here's an APAR IC60172: 64-BIT WINDOWS APPLICATION DOES NOT FIND API EXIT IN EXITS64 which was fixed in 7.0.1.0 and would account for a difference between 32-bit programs and 64-bit programs behaving differently with regard to exits.

As for the difference in output, pax has provided a link. The output would contain the length bytes in Java as well as ActiveX so the doco applies equally well in your case.