If you really want the details ... The "string" gets passed from Python to C where it's converted using `PyArg_ParseTuple` and the documentation for the particular converter says it returns both a C string or bytes buffer and a length - but in Python 3.9, the length is being returned as 0. Those are then used in the C extension layer to build the MQCHARV contents. Might be able to simply use strlen, but that then depends on Python guarantees about returning NULL-terminated strings. So quite a few things to check.
Got it sorted now: essentially seems to be differences between long/int processing at the C layer with different environments. Looks like only SETMP and INQMP were affected. I'll push a fix to the git repo. Won't do a new PyPI release yet to see if anything else pops up over the next few days.
Original Message:
Sent: Wed October 01, 2025 04:14 AM
From: Morag Hughson
Subject: Using ibmmq via PiPY (python
Hi Mark,
We had only just got to the point of realising that it might be a defect. I was about to raise an issue on github on Ken's behalf. I won't bother now that you have noticed in here.
I'm curious to hear that some version of Python could generate a MQCHARV? How does that happen? Or do you think that the order of string and length parts of a Python String match an MQCHARV and it was just getting away with it before?
Anyway, hopefully you'll be able to convert the name string into the expected MQCHARV so it can work going forward.
Thanks!
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Wed October 01, 2025 04:01 AM
From: Mark Taylor
Subject: Using ibmmq via PiPY (python
a) This would have been better handled by opening an issue on the github repo where I might have seen it earlier.
b) It appears to be a change (bug fix?) between versions of Python passing strings to C. On Python 3.13, it works fine, but the sample program fails in the same way in a python 3.9 environment. So I'll have to see how pervasive it is - does it affect other parameters to other verbs - and then work out the best way of handling it.
------------------------------
Mark Taylor
Winchester
Original Message:
Sent: Tue September 30, 2025 10:46 PM
From: Kenneth Nichols
Subject: Using ibmmq via PiPY (python
Hi Morag
In case my response didn't show up earlier: Just tried message_properties.py and get the same error on the set method, so it's starting to look like the problem is that the MQCHARV struct is not getting constructed (or not getting constructed properly). I'm doing this from my work account, so not sure I have access to post an issue in the GitHub repo.
Ken
------------------------------
Kenneth Nichols
Original Message:
Sent: Tue September 30, 2025 04:27 PM
From: Morag Hughson
Subject: Using ibmmq via PiPY (python
Hi Kenneth,
Looking at the code that implements set on a message handle, I can see that the "name" parameter is passed straight into the C-language MQSETMP call. The MQSETMP call expects the name to be an MQCHARV. So that might be why it's not working.
Oddly though, the sample that illustrates message properties appears to just use a string name and not an MQCHARV as well. Have you run that sample? Does the sample show the same error for you? If it does it is probably time to raise an issue on the GitHub repo?
I haven't had a chance to try this new python interface yet. I've only used the PyMQI flavour.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Tue September 30, 2025 03:08 PM
From: Kenneth Nichols
Subject: Using ibmmq via PiPY (python
Hi Morag
Here is a snippet from the original test program:
import ibmmq
my_qm = ibmmq.connect('QL0006','QL0006.RME.SVRCONN','internal-url.dev.mycompany.net(1414)')
my_msg_handle = ibmmq.MessageHandle(my_qm)
propertyname1 = 'QTU.SampleProperty'
try:
propvalue1 = 'This is meta-data, not part of the message payload'
my_msg_handle.properties.set(propertyname1, propvalue1)
except ibmmq.MQMIError as ex:
print (f'Trapped a read exception: {ex}')
print (f'{type(ex)}')
The trapped exception looked like this:
Trapped a read exception: MQI Error. Comp 2, Reason 2513: FAILED: MQRC_PROPERTY_NAME_LENGTH_ERR
<class 'mqerrors.MQMIError'>
I then tried a null-terminated string:
propertyname1 = 'QTU.SampleProperty' + '\x00'. # null-terminated string
Converting the string to bytes:
propertyname1 = b'QTU.SampleProperty'. # bytes array
Adding a null to the end of the bytes array:
propertyname1 = b'QTU.SampleProperty' + b'\x00'. # bytes array with null at end
Same exception in all cases
I also tried putting the property name string into a list array and then specifying the list element on the set call (as appeared in one of the example programs). No joy...
Ken
------------------------------
Kenneth Nichols
Original Message:
Sent: Mon September 29, 2025 06:36 PM
From: Morag Hughson
Subject: Using ibmmq via PiPY (python
Hi Kenneth,
Can you provide an example of your code setting the property that raises the error?
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Mon September 29, 2025 03:34 PM
From: Kenneth Nichols
Subject: Using ibmmq via PiPY (python
Has anyone here tried setting message properties via the ibmmq python library? I keep encountering the exception 2513 (MQRC_PROPERTY_NAME_LENGTH_ERROR), which would seem to indicate something is wrong with the MQCHARV setup for the 'name' argument prior to making the real call to MQSETMP. I've tried explicitly 'casting' the property name string into a bytes object ( "propertyname = bytes (property_name_string, "utf-8") " ) and a few other variants, but it always returns the same error. Took a look at mqmsghdl.py in gitlab but didn't immediately see where the MQCHARV struct was being set up, so thought I'd ask in this forum while still trying to puzzle it out via the repository.
------------------------------
Kenneth Nichols
------------------------------