ibm-messaging / mq-golang

Calling IBM MQ from Go applications
Apache License 2.0
168 stars 60 forks source link

APAR IT13736: Padding md.Format with null causes issues with MQHRF2 #106

Closed ravellan closed 5 years ago

ravellan commented 5 years ago

I am working on an RFH2 extension to the package and experienced weird behavior when putting messages with format MQHRF2. I then found APAR IT13736 As suggested in the problem summary one of the following is a valid workaround

Not sure if it is safe to alter behavior of setMQIString or just pad MQFMT variables in cmqc with spaces.

ibmmqmet commented 5 years ago

Best temporary fix is the first option. I'll make a version of that a permanent solution next time I update the package to ensure the Format field is always padded during PUT. I don't know for certain why the APAR fix just didn't change the qmgr to work with NULL terminators in the same way as MQ works for just about every other CHAR field; the usual reason is they get worried about breaking existing apps that relied on current behaviour.

I don't want to have the Go versions of the strings padded by default. Either in the cmqc definitions or elsewhere. From the APAR it looks like it's only RFH2 that has the parsing problem, not any of the other MQFMT definitions, and I want to be consistent on what the Format looks like both on input and output. So Go apps (and Node.js apps which follow a similar pattern) should always be able to rely on no padding.

Of course, there's often no reason to work with RFH2 these days; using message properties (MQSETMP etc) can be a lot simpler.

ravellan commented 5 years ago

Thanks for the reply. Your argument for not changing anything in general for cmqc makes sense so I'll use the workaround until the package is updated. I haven't used message properties yet so I'll explore that option also.

ibmmqmet commented 5 years ago

V4.0.6 includes a solution for this