Closed DanRoseus closed 9 months ago
The loop is not intended to refetch if the message is too large. It is because there might be multiple responses that need to be handled. For example, if the parameter to the program uses a wildcard for the object name, or if running against a z/OS qmgr. The GET should definitely NOT use ACCEPT_TRUNCATED_MESSAGE because that would potentially result in trying to parse a mal-formed message. Responses for a single object will never be split across multiple messages.
If you want to see an example of looping to handle large responses, look at the getWithoutTruncation
function in the ../mqmetric/discover.go
file.
Thanks @ibmmqmet , that makes sense now, I just saw that loop do exactly as you said when using Inquire Queues with a wildcard. I retract this defect report!
The sample code for PCF commands includes an example of processing PCF responses. It creates a buffer of 10KB :
It has a loop that will keep fetching buffers if the response is >10KB, but this doesn't work (I tested by doing Inquire Queue Names against a QM with 5000 queues). I see a couple of things wrong with the code: 1) It currently sets to
gmo.Options = ibmmq.MQGMO_NO_SYNCPOINT
, which results in getting MQRC_TRUNCATED_MSG_FAILED back if the response is big rather than truncating. I think it should also set MQGMO_ACCEPT_TRUNCATED_MSG?2) When processing the potentially truncated buffer it makes no attempt to handle if the PCF Parameter crosses between 2 buffers.
Ideally the sample would be fixed to properly handle truncated buffers. If not then maybe remove that looping and make it clearer that this sample requires the buffer to be big enough for the full response.