IBMMQ to_string() does not strip NULL as it claims

[andrewkirillov-ibm]

The problem was spotted when doing PCF inquiries of Queue Status.

First, lets see the dump from PCF Queue inquiry:

14:11:16,862 DUMP     : PCF Response:
-------------------------------------
[{2016: b'Q1                                              ', 20: 1, 134: -3, 2027: b'2025-11-02  ', 2028: b'12.11.04', 2019: b'                                                ', 22: 0, 276: -1, 2030: b'                                                ', 2029: b'                                                ', 2124: b'                                                ', 96: 0, 95: 0, 98: -3, 2004: b'2025-07-30  ', 2005: b'06.11.07', 

From the above, we can see that queue attributes like ibmmq.CMQC.MQCA_ALTERATION_DATE (2027) and ibmmq.CMQC.MQCA_CREATION_DATE (2004) are space padded.

However, lets see dump from Queue Status inquiry:

14:16:00,224 DUMP     : PCF Response:
-------------------------------------
[{2016: b'VASQUEUE1                                       ', 1103: 1105, 3: 6, 1437: 1, 1438: 2088960, 17: 0, 3130: b'2025-11-04\x00\x00', 3131: b'04.37.14', 3128: b'2025-11-04\x00\x00', 3129: b'04.39.05', 3073: b'', 123: 65, 1227: 92326, 18: 0, 1226: [195395574, 195395574], 1027: 0}]

Here we see that attributes like ibmmq.CMQCFC.MQCACF_LAST_GET_DATE (3130) and ibmmq.CMQCFC.MQCACF_LAST_PUT_DATE (3128) are NULL padded.

Doing ibmmq.to_string() on those NULL terminated byte arrays produces strings like this:

 'LGETDATE': '2025-11-04\x00\x00', 'LPUTDATE': '2025-11-04\x00\x00'

The implementation of to_string() does this: v.decode(encoding).strip(). As decode() converts 0 bytes to \x00 strings, the strip() has nothing really to strip.

[ibmmqmet]

Thanks for the strip() change, which I'll pull in, but I suspect there's something else going on - the LPUTDATE string returned should probably not have included the NULs at all. The unpacking might be including the padding bytes needed to round the structure to 4. I'll need to check that further.

[ibmmqmet]

Although I don't like it, the padding bytes were in the original package and are explicitly expected in the unittests. While it would be trivial to fix, it could potentially break existing apps. So I've just added some comments to explain better what's going on. And the NUL-stripper can still do its job. Also updated the dis_queues example to test it working.

[andrewkirillov-ibm]

Also updated the dis_queues example to test it working.

Just to clarify. The reported problem was discovered while inquiring queue status (MQCMD_INQUIRE_Q_STATUS), not queue.

[ibmmqmet]

Yes - dis_queues uses both commands

[andrewkirillov-ibm]

It may not matter anymore, but just in case it might be useful. I found that NULL padding is not the problem of Queue Status only.

When doing inquiry on Channel Status for SVRCONN channel, I found that MCAUSER and RAPPLTAG suffer the same problem:

MQ attribute 3527 (MQCACH_MCA_USER_ID) : b'mcpuser\x00'
MQ attribute 3548 (MQCACH_REMOTE_APPL_TAG) : b'python3.12\x00\x00'