Closed ravellan closed 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.
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.
V4.0.6 includes a solution for this
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
md.Format = MQFMT_RF_HEADER_2 + " "
Not sure if it is safe to alter behavior of
setMQIString
or just pad MQFMT variables in cmqc with spaces.