MQSERIES call to MQGET using dynamic variable as message buffer

, ,
1

We have variable length messages coming in on an MQ and the idea was to code the Natural message receiver program with an initial “most likely” buffer/msg length and then trap for the MQRC-TRUNCATED-MSG-FAILED condition when the actual message exceeds the buffer length - EXPAND can then be used to increase the buffer length to match the current msg len. MQ is not liking using a dynamic variable in it’s MQGET parameter list (RC 2004, reason 2). Does anyone have some feedback? We can certainly code a humongous variable as the message buffer, but wanted to exploit the advantage of using a dynamic variable. This is running in a mainframe CICS environment.

Thanks.

2

EXPAND and RESIZE reserve memory. To actually allocate memory and make it available to an external application you must explicitly populate the dynamic variable, something like -

1 MQ_BUFFER_LENGTH(I4)
1 MQ_BUFFER(A) DYNAMIC
…
MQ_BUFFER_LENGTH := 10000
MOVE ALL ’ ’ TO MQ_BUFFER UNTIL MQ_BUFFER_LENGTH
…
CALL ‘MQGET’ etc

This will solve your RC 2004. You could still get a RC 2080 if MQGMO_ACCEPT_TRUNCATED_MSG is false and the buffer is too small but as you rightly say, trap the error, expand the buffer and call MQGET again.

Remember that if your queue is being serviced by multiple listeners you could get a 2033 on the second MQGET.

3

Brilliant Nigel! Understood, tested and confirmed. Thank you for the assistance. We are retrofitting our legacy applications to move from older messaging tech to an MQ-based pub-sub process so getting this to work as intended was key to establishing the new development standard.

Cheers.

4

Happy to help, Pierre.

To add to the discussion in case other folk read this thread…

The other method we considered was to issue a first MQGET with browse (non-destructive), a zero-length buffer and option ACCCEPT_TRUNCATED_MSG set to false - so RC 2080 would ALWAYS be returned. Then allocate the buffer according the actual message length and do a second (destructive) MQGET, accepting the minor overhead of 2 calls. I recall that this design was suggested by one of the tutors during MQ training.

Anyway we decided against this. We oblige our developers to figure out their maximum message length up-front. Any truncated messages are trapped and re-directed to an error queue :slight_smile: