tags:

views:

30

answers:

2

Hi, all

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 didnot record the put action because of the encoding?

Any advices would be appreciated! Thank you!

A: 

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.

paxdiablo
Thank you! Pax, I know why there is a "%" before my actual message data now. But why the put action wasnot recored in the log? My API EXIT was desiged to record actions like put, get. Any advice?Thank you, again!
allan
Not sure on that but I'll give one _possibility._ If your exit is in C (or another language that uses null-terminated strings) and the output is ".%Hello" (where "." is the nul byte), you may get an empty string just because that's how it's seen. The ".%" would be the 2-byte length section. That's a guess on my part so it may be totally wrong. I would probably do something else in the exit as well (like create/update a file) as the _first_ thing you do, so you can see if it's being called at all.
paxdiablo
I think you may be right... My EXIT is in C.Why writeUTF exist? The method adds extra info before the actual message. If client program used writeUTF instead of writeString, what am I supposed to do?By the way, I saw only "%Hello" in message explorer, is it because "." is not visiable?Great Thanks!
allan
`WriteUTF` exists because it's a good way to get UTF data easily from one end to the other (using `ReadUTF` which understands the format). You should probably do a dump of the data in your exit based on the length as given by MQ itself, rather than assuming it's a C-type string. That way, binary information will not pose a problem.
paxdiablo
Thank you, Pax, Thank you!
allan
A: 

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.

T.Rob
Thank you, Rob.I didn't recycle the QMgr between these two programs.The log file was created right after the first execution, and I checked it, I got start and end, but no content (info about the put action).My MQ version is 7.0.1.1, and I just tested the 32bit API EXIT function now.Containing the length bytes (content not changed) will stop API EXIT from recording?Appreciate Your Help, Thank you!Sorry for the delay...
allan
Now we are getting down to the gnarly bits...the length is in two bytes and the string is so short that one of those bytes must be 0x00. Since strings are null-terminated, is it possible that the log file is simply not being displayed correctly? Did you hex-dump the log? The possibilities I'm considering here are that the data was written but not displayed correctly or that the exit is behaving differently for the Java programs than the sample programs. The first you can verify, the second points to a 32-bit/64-bit issue, depending on your JVM.
T.Rob
You guys are amazing! I hex-dump the log, it's the nul byte that stopped my api exit from recording. Great thanks!!!
allan