One of the common mistakes that people make when they first start programming with the MQI can be seen in this pseudo-code example:<\/p>\n\n\n\n
MQMD md = {MQMD_DEFAULT}\nMQGMO gmo = {MQGMO_DEFAULT}\nint bufsize = 128\nPMQCHAR buf = malloc(bufsize)\ndo {\n MQGET(&md,&gmo,buf,bufsize))\n} while (rc != MQRC_NO_MSG_AVAILABLE)<\/pre>\n\n\n\nThey complain that despite pre-loading the queue, only a single message is returned. Anyone reading this is likely to recognise immediately the problem: the MsgId <\/em>of the first message is returned in the md<\/code> variable. The next iteration of the loop tries to match that MsgID <\/em>and doesn’t find any more messages. <\/p>\n\n\n\nThere are aspects of the MQI that try to minimise your chances of getting this wrong, like the MatchOptions<\/code> flag in the MQGMO structure. But that in turn requires you know a) to set it and b) override the default version of the structure.<\/p>\n\n\n\nHaving worked with MQ for so many years, I am hopefully not going to make that kind of mistake. But I still got caught out recently by a very similar problem.<\/p>\n\n\n\n\n\n\n\n
Variation<\/h3>\n\n\n\n
The pseudo-code for my program looks like this:<\/p>\n\n\n\n
MQMD md = {MQMD_DEFAULT}\nMQGMO gmo = {MQGMO_DEFAULT}\nint bufsize = 128\nPMQCHAR buf\ngmo.Options = MQGMO_CONVERT\ndo {\n bufsize = bufsize*2\n buf = malloc(bufsize) \/\/ Increase the buffer on each loop\n MQGET(&md,&gmo, buf, bufsize)\n} while (rc == MQRC_TRUNCATED_MSG_FAILED)<\/pre>\n\n\n\nThis again is not the real compilable code but it should explain the principle. So you can ignore the apparent memory leak. The idea is that since we don’t know how big the message is, we keep enlarging the data buffer until we can get the full message. And my system behaved as expected when I tested it.<\/p>\n\n\n\n
But I got reports of corrupt message data when the program ran as a client to a z\/OS system. It was very easy to debug once I reproduced the environment. It – annoyingly and perhaps embarrassingly – turned out to be a lot like the MsgId <\/em>problem. The returned md<\/code> variable is modified not only with the MsgId <\/em>but also with the CodedCharSetId <\/em>(codepage) and Encoding <\/em>(endianness) of the message even when the MQGET fails. Since I wasn’t resetting the md<\/code> contents inside the loop, the second attempt asks for the data to be converted into its own codepage and endianness. So the message data is not in fact converted, and hence it looks corrupt.<\/p>\n\n\n\nCoda<\/h3>\n\n\n\n
This was very easy to fix once I’d diagnosed the problem. But I’ve not seen this specific issue before, so perhaps this can be a warning to others.<\/p>\n
This post was last updated on September 20th, 2021 at 08:17 am<\/p>","protected":false},"excerpt":{"rendered":"