I was trying to specify message selection strings in MQOPEN and I was getting no messages when I did my MQGET. I thought I would pass on the micro gems of what I learned.
I was running on z.Lunix and my C program had parameters -SSKEYWORD=kw and -SSVALUE=value. My program then built the SelectionString from kw '=' value.
When I specified myprog -SSKEYWORD=COLOUR -SSVALUE='BLUE' no messages were retrieved. I was expecting the SelectionString to be COLOUR='BLUE'
- I found I had to specify mqgmo.Version = MQGMO_VERSION_4 instead of using the MQGMO_DEFAULT
- Using /opt/mqm/samp/bin/amqsbcgc CP0000 colin 3 gave me return code 2058 - because I was trying to use the client program without setting up the connection information. It worked when I used amqsbcg and local bindings.
- I used /opt/mqm/samp/bin/amqsbcg CP0000 colin 3 to display the message data in the RFH2 header - the message was correct
- I used/opt/mqm/samp/bin/amqsbcg CP0000 colin 1 to display the message property COLOUR BLUE - the message was correct
- It turned out I had to escape the quotes as the bash shell was treating 'BLUE' as BLUE and so my selection string was COLOUR = BLUE (without the quotes), which means check to see if property named COLOUR has the same value as the property named BLUE. Messages property BLUE did not exist, the comparison was not true - and so the get failed. When I specified myprog -SSKEYWORD=COLOUR -SSVALUE=\'BLUE'\' using the bacxkslash \ it worked.
- I had printed out the SelectionString being passed to MQ - and this was "COLOUR = BLUE" and I could see this was 'obviously' correct. If I had looked more closely I would have spotted the missing quotes and saved myself a couple of hours debugging.
- When I specified message property COLOUR=BLUE, and then added a second colour COLUR=RED to the message, there was only one message property COLOUR=RED. as the second instance replaced the first one.