I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin

When I build a C program, on z/OS, in 64-bit, that prints out the size of the MQOD structure, it says it is 424 bytes.

Perhaps you can share your code and your build options so we can understand how you got 422 which is not even divisible by 4!

You ask for a special compile option to force pointers to be 31-bit. I'm not sure exactly what you mean there. You already said you built it 31-bit and and got the expected length of 400 in that situation. What more do you want the special option to do beyond that? Perhaps expand on your requirement so we can help further.

I agree that it would be nice if the z/OS version of the CMQC header file had the same pairs of #defined constants too, after all they have other #if defined(_LP64) statements in the header file. Would be nice just for consistency, but I have to say that I have rarely used those constants, and just use sizeof() when I need the length. If you use them, perhaps it would be worth raising an IDEA?

I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin

When I build a C program, on z/OS, in 64-bit, that prints out the size of the MQOD structure, it says it is 424 bytes.

Perhaps you can share your code and your build options so we can understand how you got 422 which is not even divisible by 4!

You ask for a special compile option to force pointers to be 31-bit. I'm not sure exactly what you mean there. You already said you built it 31-bit and and got the expected length of 400 in that situation. What more do you want the special option to do beyond that? Perhaps expand on your requirement so we can help further.

I agree that it would be nice if the z/OS version of the CMQC header file had the same pairs of #defined constants too, after all they have other #if defined(_LP64) statements in the header file. Would be nice just for consistency, but I have to say that I have rarely used those constants, and just use sizeof() when I need the length. If you use them, perhaps it would be worth raising an IDEA?

I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin

I guess no-one has built this code on z/OS before. Perhaps you could show us a snippet of the code so we understand what you're grappling with. Is the parameter in question coming from an external source? i.e. how come the application can't trust that the  MQOD passed to it is the full current length, is it because the source of the parameter can be built with a different version of the header files and thus be a different length?

Certainly it sounds like putting in the #ifdef's yourself will solve the problem if you need those lengths.

In my earlier response I linked to Mark Taylor's blog post that describes the change from the old RFE process to the new IDEA process. However, I have been told that his blog is black-listed by some companies, so for completion, here is the link to the IDEA process directly. I will update my prior response to include both. I'll also see if Mark is willing to write his blog post on the IBM Community so everyone can see it.

EDIT: Looks like he already did, so I have edited my previous response to include the link to the IBM Community version of the post.

Cheers,
Morag

​

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Fri December 31, 2021 03:11 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

When I build a C program, on z/OS, in 64-bit, that prints out the size of the MQOD structure, it says it is 424 bytes.

Perhaps you can share your code and your build options so we can understand how you got 422 which is not even divisible by 4!

You ask for a special compile option to force pointers to be 31-bit. I'm not sure exactly what you mean there. You already said you built it 31-bit and and got the expected length of 400 in that situation. What more do you want the special option to do beyond that? Perhaps expand on your requirement so we can help further.

I agree that it would be nice if the z/OS version of the CMQC header file had the same pairs of #defined constants too, after all they have other #if defined(_LP64) statements in the header file. Would be nice just for consistency, but I have to say that I have rarely used those constants, and just use sizeof() when I need the length. If you use them, perhaps it would be worth raising an IDEA?

I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin

I guess no-one has built this code on z/OS before. Perhaps you could show us a snippet of the code so we understand what you're grappling with. Is the parameter in question coming from an external source? i.e. how come the application can't trust that the  MQOD passed to it is the full current length, is it because the source of the parameter can be built with a different version of the header files and thus be a different length?

Certainly it sounds like putting in the #ifdef's yourself will solve the problem if you need those lengths.

In my earlier response I linked to Mark Taylor's blog post that describes the change from the old RFE process to the new IDEA process. However, I have been told that his blog is black-listed by some companies, so for completion, here is the link to the IDEA process directly. I will update my prior response to include both. I'll also see if Mark is willing to write his blog post on the IBM Community so everyone can see it.

EDIT: Looks like he already did, so I have edited my previous response to include the link to the IBM Community version of the post.

Cheers,
Morag

​

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Fri December 31, 2021 03:11 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

When I build a C program, on z/OS, in 64-bit, that prints out the size of the MQOD structure, it says it is 424 bytes.

Perhaps you can share your code and your build options so we can understand how you got 422 which is not even divisible by 4!

You ask for a special compile option to force pointers to be 31-bit. I'm not sure exactly what you mean there. You already said you built it 31-bit and and got the expected length of 400 in that situation. What more do you want the special option to do beyond that? Perhaps expand on your requirement so we can help further.

I agree that it would be nice if the z/OS version of the CMQC header file had the same pairs of #defined constants too, after all they have other #if defined(_LP64) statements in the header file. Would be nice just for consistency, but I have to say that I have rarely used those constants, and just use sizeof() when I need the length. If you use them, perhaps it would be worth raising an IDEA?

I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin

and the MQMD's are different sizes...
on midrange the MQMD is a V2, on z/OS is is a V1!

I'll raise another IDEA  to make these compatible.

------------------------------
Colin Paice

Original Message:
Sent: Sat January 01, 2022 10:46 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

Hi Morag,
I'll raise an IDEA for this.

The code is pymqi (Python MQI code).  It looks good resilient code, making sure the length of the control block is as expected.
It has code to generate the MQOD, then says .. if MQ release > 7 then add  to the MQOD,  the ObjectString, SelectionString etc.
The length check is good to make sure it is consistent, and not missing a field.

Here are some code excerpts.


#define PYMQI_MQOD_SIZEOF MQOD_CURRENT_LENGTH
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
//  qDescBufferLength is the length of the(MQOD) object passed in
if (checkArgSize(qDescBufferLength, PYMQI_MQOD_SIZEOF, "MQOD")) {
return NULL;
}


static int checkArgSize(Py_ssize_t given, Py_ssize_t expected, const char *name) {
if (given != expected) {
PyErr_Format(ErrorObj, "%s wrong size. Given: %lu, expected %lu", name, (unsigned long)given, (unsigned long)expected);
return 1;
}
return 0;
}

regards

Colin

------------------------------
Colin Paice

Original Message:
Sent: Fri December 31, 2021 10:38 PM
From: Morag Hughson
Subject: How long's the MQOD on z/OS - it depends

I guess no-one has built this code on z/OS before. Perhaps you could show us a snippet of the code so we understand what you're grappling with. Is the parameter in question coming from an external source? i.e. how come the application can't trust that the  MQOD passed to it is the full current length, is it because the source of the parameter can be built with a different version of the header files and thus be a different length?

Certainly it sounds like putting in the #ifdef's yourself will solve the problem if you need those lengths.

In my earlier response I linked to Mark Taylor's blog post that describes the change from the old RFE process to the new IDEA process. However, I have been told that his blog is black-listed by some companies, so for completion, here is the link to the IDEA process directly. I will update my prior response to include both. I'll also see if Mark is willing to write his blog post on the IBM Community so everyone can see it.

EDIT: Looks like he already did, so I have edited my previous response to include the link to the IBM Community version of the post.

Cheers,
Morag

​

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Fri December 31, 2021 03:11 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

When I build a C program, on z/OS, in 64-bit, that prints out the size of the MQOD structure, it says it is 424 bytes.

Perhaps you can share your code and your build options so we can understand how you got 422 which is not even divisible by 4!

You ask for a special compile option to force pointers to be 31-bit. I'm not sure exactly what you mean there. You already said you built it 31-bit and and got the expected length of 400 in that situation. What more do you want the special option to do beyond that? Perhaps expand on your requirement so we can help further.

I agree that it would be nice if the z/OS version of the CMQC header file had the same pairs of #defined constants too, after all they have other #if defined(_LP64) statements in the header file. Would be nice just for consistency, but I have to say that I have rarely used those constants, and just use sizeof() when I need the length. If you use them, perhaps it would be worth raising an IDEA?

I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin

and the MQMD's are different sizes...
on midrange the MQMD is a V2, on z/OS is is a V1!

I'll raise another IDEA  to make these compatible.

------------------------------
Colin Paice

Original Message:
Sent: Sat January 01, 2022 10:46 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

Hi Morag,
I'll raise an IDEA for this.

The code is pymqi (Python MQI code).  It looks good resilient code, making sure the length of the control block is as expected.
It has code to generate the MQOD, then says .. if MQ release > 7 then add  to the MQOD,  the ObjectString, SelectionString etc.
The length check is good to make sure it is consistent, and not missing a field.

Here are some code excerpts.


#define PYMQI_MQOD_SIZEOF MQOD_CURRENT_LENGTH
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
//  qDescBufferLength is the length of the(MQOD) object passed in
if (checkArgSize(qDescBufferLength, PYMQI_MQOD_SIZEOF, "MQOD")) {
return NULL;
}


static int checkArgSize(Py_ssize_t given, Py_ssize_t expected, const char *name) {
if (given != expected) {
PyErr_Format(ErrorObj, "%s wrong size. Given: %lu, expected %lu", name, (unsigned long)given, (unsigned long)expected);
return 1;
}
return 0;
}

regards

Colin

------------------------------
Colin Paice

Original Message:
Sent: Fri December 31, 2021 10:38 PM
From: Morag Hughson
Subject: How long's the MQOD on z/OS - it depends

I guess no-one has built this code on z/OS before. Perhaps you could show us a snippet of the code so we understand what you're grappling with. Is the parameter in question coming from an external source? i.e. how come the application can't trust that the  MQOD passed to it is the full current length, is it because the source of the parameter can be built with a different version of the header files and thus be a different length?

Certainly it sounds like putting in the #ifdef's yourself will solve the problem if you need those lengths.

In my earlier response I linked to Mark Taylor's blog post that describes the change from the old RFE process to the new IDEA process. However, I have been told that his blog is black-listed by some companies, so for completion, here is the link to the IDEA process directly. I will update my prior response to include both. I'll also see if Mark is willing to write his blog post on the IBM Community so everyone can see it.

EDIT: Looks like he already did, so I have edited my previous response to include the link to the IBM Community version of the post.

Cheers,
Morag

​

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Fri December 31, 2021 03:11 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

When I build a C program, on z/OS, in 64-bit, that prints out the size of the MQOD structure, it says it is 424 bytes.

Perhaps you can share your code and your build options so we can understand how you got 422 which is not even divisible by 4!

You ask for a special compile option to force pointers to be 31-bit. I'm not sure exactly what you mean there. You already said you built it 31-bit and and got the expected length of 400 in that situation. What more do you want the special option to do beyond that? Perhaps expand on your requirement so we can help further.

I agree that it would be nice if the z/OS version of the CMQC header file had the same pairs of #defined constants too, after all they have other #if defined(_LP64) statements in the header file. Would be nice just for consistency, but I have to say that I have rarely used those constants, and just use sizeof() when I need the length. If you use them, perhaps it would be worth raising an IDEA?

I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin

and the MQMD's are different sizes...
on midrange the MQMD is a V2, on z/OS is is a V1!

I'll raise another IDEA  to make these compatible.

------------------------------
Colin Paice

Original Message:
Sent: Sat January 01, 2022 10:46 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

Hi Morag,
I'll raise an IDEA for this.

The code is pymqi (Python MQI code).  It looks good resilient code, making sure the length of the control block is as expected.
It has code to generate the MQOD, then says .. if MQ release > 7 then add  to the MQOD,  the ObjectString, SelectionString etc.
The length check is good to make sure it is consistent, and not missing a field.

Here are some code excerpts.


#define PYMQI_MQOD_SIZEOF MQOD_CURRENT_LENGTH
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
//  qDescBufferLength is the length of the(MQOD) object passed in
if (checkArgSize(qDescBufferLength, PYMQI_MQOD_SIZEOF, "MQOD")) {
return NULL;
}


static int checkArgSize(Py_ssize_t given, Py_ssize_t expected, const char *name) {
if (given != expected) {
PyErr_Format(ErrorObj, "%s wrong size. Given: %lu, expected %lu", name, (unsigned long)given, (unsigned long)expected);
return 1;
}
return 0;
}

regards

Colin

------------------------------
Colin Paice

Original Message:
Sent: Fri December 31, 2021 10:38 PM
From: Morag Hughson
Subject: How long's the MQOD on z/OS - it depends

I guess no-one has built this code on z/OS before. Perhaps you could show us a snippet of the code so we understand what you're grappling with. Is the parameter in question coming from an external source? i.e. how come the application can't trust that the  MQOD passed to it is the full current length, is it because the source of the parameter can be built with a different version of the header files and thus be a different length?

Certainly it sounds like putting in the #ifdef's yourself will solve the problem if you need those lengths.

In my earlier response I linked to Mark Taylor's blog post that describes the change from the old RFE process to the new IDEA process. However, I have been told that his blog is black-listed by some companies, so for completion, here is the link to the IDEA process directly. I will update my prior response to include both. I'll also see if Mark is willing to write his blog post on the IBM Community so everyone can see it.

EDIT: Looks like he already did, so I have edited my previous response to include the link to the IBM Community version of the post.

Cheers,
Morag

​

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Fri December 31, 2021 03:11 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

When I build a C program, on z/OS, in 64-bit, that prints out the size of the MQOD structure, it says it is 424 bytes.

Perhaps you can share your code and your build options so we can understand how you got 422 which is not even divisible by 4!

You ask for a special compile option to force pointers to be 31-bit. I'm not sure exactly what you mean there. You already said you built it 31-bit and and got the expected length of 400 in that situation. What more do you want the special option to do beyond that? Perhaps expand on your requirement so we can help further.

I agree that it would be nice if the z/OS version of the CMQC header file had the same pairs of #defined constants too, after all they have other #if defined(_LP64) statements in the header file. Would be nice just for consistency, but I have to say that I have rarely used those constants, and just use sizeof() when I need the length. If you use them, perhaps it would be worth raising an IDEA?

I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin

and the MQMD's are different sizes...
on midrange the MQMD is a V2, on z/OS is is a V1!

I'll raise another IDEA  to make these compatible.

------------------------------
Colin Paice

Original Message:
Sent: Sat January 01, 2022 10:46 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

Hi Morag,
I'll raise an IDEA for this.

The code is pymqi (Python MQI code).  It looks good resilient code, making sure the length of the control block is as expected.
It has code to generate the MQOD, then says .. if MQ release > 7 then add  to the MQOD,  the ObjectString, SelectionString etc.
The length check is good to make sure it is consistent, and not missing a field.

Here are some code excerpts.


#define PYMQI_MQOD_SIZEOF MQOD_CURRENT_LENGTH
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
//  qDescBufferLength is the length of the(MQOD) object passed in
if (checkArgSize(qDescBufferLength, PYMQI_MQOD_SIZEOF, "MQOD")) {
return NULL;
}


static int checkArgSize(Py_ssize_t given, Py_ssize_t expected, const char *name) {
if (given != expected) {
PyErr_Format(ErrorObj, "%s wrong size. Given: %lu, expected %lu", name, (unsigned long)given, (unsigned long)expected);
return 1;
}
return 0;
}

regards

Colin

------------------------------
Colin Paice

Original Message:
Sent: Fri December 31, 2021 10:38 PM
From: Morag Hughson
Subject: How long's the MQOD on z/OS - it depends

I guess no-one has built this code on z/OS before. Perhaps you could show us a snippet of the code so we understand what you're grappling with. Is the parameter in question coming from an external source? i.e. how come the application can't trust that the  MQOD passed to it is the full current length, is it because the source of the parameter can be built with a different version of the header files and thus be a different length?

Certainly it sounds like putting in the #ifdef's yourself will solve the problem if you need those lengths.

In my earlier response I linked to Mark Taylor's blog post that describes the change from the old RFE process to the new IDEA process. However, I have been told that his blog is black-listed by some companies, so for completion, here is the link to the IDEA process directly. I will update my prior response to include both. I'll also see if Mark is willing to write his blog post on the IBM Community so everyone can see it.

EDIT: Looks like he already did, so I have edited my previous response to include the link to the IBM Community version of the post.

Cheers,
Morag

​

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Fri December 31, 2021 03:11 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

When I build a C program, on z/OS, in 64-bit, that prints out the size of the MQOD structure, it says it is 424 bytes.

Perhaps you can share your code and your build options so we can understand how you got 422 which is not even divisible by 4!

You ask for a special compile option to force pointers to be 31-bit. I'm not sure exactly what you mean there. You already said you built it 31-bit and and got the expected length of 400 in that situation. What more do you want the special option to do beyond that? Perhaps expand on your requirement so we can help further.

I agree that it would be nice if the z/OS version of the CMQC header file had the same pairs of #defined constants too, after all they have other #if defined(_LP64) statements in the header file. Would be nice just for consistency, but I have to say that I have rarely used those constants, and just use sizeof() when I need the length. If you use them, perhaps it would be worth raising an IDEA?

I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin

I had to change the common code, and change it from MQMD to MQMDv2.  On midrange it is the same structure, and on z/OS it will pick up the V2.

#ifdef __MVS__
#define PYMQI_MQMD_SIZEOF sizeof(MQMD2)
#else
#define PYMQI_MQMD_SIZEOF sizeof(MQMD)
#endif

then it works.

and the MQMD's are different sizes...
on midrange the MQMD is a V2, on z/OS is is a V1!

I'll raise another IDEA  to make these compatible.

------------------------------
Colin Paice

Original Message:
Sent: Sat January 01, 2022 10:46 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

Hi Morag,
I'll raise an IDEA for this.

The code is pymqi (Python MQI code).  It looks good resilient code, making sure the length of the control block is as expected.
It has code to generate the MQOD, then says .. if MQ release > 7 then add  to the MQOD,  the ObjectString, SelectionString etc.
The length check is good to make sure it is consistent, and not missing a field.

Here are some code excerpts.


#define PYMQI_MQOD_SIZEOF MQOD_CURRENT_LENGTH
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
//  qDescBufferLength is the length of the(MQOD) object passed in
if (checkArgSize(qDescBufferLength, PYMQI_MQOD_SIZEOF, "MQOD")) {
return NULL;
}


static int checkArgSize(Py_ssize_t given, Py_ssize_t expected, const char *name) {
if (given != expected) {
PyErr_Format(ErrorObj, "%s wrong size. Given: %lu, expected %lu", name, (unsigned long)given, (unsigned long)expected);
return 1;
}
return 0;
}

regards

Colin

------------------------------
Colin Paice

Original Message:
Sent: Fri December 31, 2021 10:38 PM
From: Morag Hughson
Subject: How long's the MQOD on z/OS - it depends

I guess no-one has built this code on z/OS before. Perhaps you could show us a snippet of the code so we understand what you're grappling with. Is the parameter in question coming from an external source? i.e. how come the application can't trust that the  MQOD passed to it is the full current length, is it because the source of the parameter can be built with a different version of the header files and thus be a different length?

Certainly it sounds like putting in the #ifdef's yourself will solve the problem if you need those lengths.

In my earlier response I linked to Mark Taylor's blog post that describes the change from the old RFE process to the new IDEA process. However, I have been told that his blog is black-listed by some companies, so for completion, here is the link to the IDEA process directly. I will update my prior response to include both. I'll also see if Mark is willing to write his blog post on the IBM Community so everyone can see it.

EDIT: Looks like he already did, so I have edited my previous response to include the link to the IBM Community version of the post.

Cheers,
Morag

​

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Fri December 31, 2021 03:11 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

When I build a C program, on z/OS, in 64-bit, that prints out the size of the MQOD structure, it says it is 424 bytes.

Perhaps you can share your code and your build options so we can understand how you got 422 which is not even divisible by 4!

You ask for a special compile option to force pointers to be 31-bit. I'm not sure exactly what you mean there. You already said you built it 31-bit and and got the expected length of 400 in that situation. What more do you want the special option to do beyond that? Perhaps expand on your requirement so we can help further.

I agree that it would be nice if the z/OS version of the CMQC header file had the same pairs of #defined constants too, after all they have other #if defined(_LP64) statements in the header file. Would be nice just for consistency, but I have to say that I have rarely used those constants, and just use sizeof() when I need the length. If you use them, perhaps it would be worth raising an IDEA?

I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin

The MQMD2 structure is defined on distributed as well as z/OS. It is defined so that you don't need to do what you have done, you can have exactly the same code on both platform sets.

So remove the #ifdefs and just use:-

#define PYMQI_MQMD_SIZEOF sizeof(MQMD2)

Cheers,
Morag

I had to change the common code, and change it from MQMD to MQMDv2.  On midrange it is the same structure, and on z/OS it will pick up the V2.

#ifdef __MVS__
#define PYMQI_MQMD_SIZEOF sizeof(MQMD2)
#else
#define PYMQI_MQMD_SIZEOF sizeof(MQMD)
#endif

then it works.

and the MQMD's are different sizes...
on midrange the MQMD is a V2, on z/OS is is a V1!

I'll raise another IDEA  to make these compatible.

------------------------------
Colin Paice

Original Message:
Sent: Sat January 01, 2022 10:46 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

Hi Morag,
I'll raise an IDEA for this.

The code is pymqi (Python MQI code).  It looks good resilient code, making sure the length of the control block is as expected.
It has code to generate the MQOD, then says .. if MQ release > 7 then add  to the MQOD,  the ObjectString, SelectionString etc.
The length check is good to make sure it is consistent, and not missing a field.

Here are some code excerpts.


#define PYMQI_MQOD_SIZEOF MQOD_CURRENT_LENGTH
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
//  qDescBufferLength is the length of the(MQOD) object passed in
if (checkArgSize(qDescBufferLength, PYMQI_MQOD_SIZEOF, "MQOD")) {
return NULL;
}


static int checkArgSize(Py_ssize_t given, Py_ssize_t expected, const char *name) {
if (given != expected) {
PyErr_Format(ErrorObj, "%s wrong size. Given: %lu, expected %lu", name, (unsigned long)given, (unsigned long)expected);
return 1;
}
return 0;
}

regards

Colin

------------------------------
Colin Paice

Original Message:
Sent: Fri December 31, 2021 10:38 PM
From: Morag Hughson
Subject: How long's the MQOD on z/OS - it depends

I guess no-one has built this code on z/OS before. Perhaps you could show us a snippet of the code so we understand what you're grappling with. Is the parameter in question coming from an external source? i.e. how come the application can't trust that the  MQOD passed to it is the full current length, is it because the source of the parameter can be built with a different version of the header files and thus be a different length?

Certainly it sounds like putting in the #ifdef's yourself will solve the problem if you need those lengths.

In my earlier response I linked to Mark Taylor's blog post that describes the change from the old RFE process to the new IDEA process. However, I have been told that his blog is black-listed by some companies, so for completion, here is the link to the IDEA process directly. I will update my prior response to include both. I'll also see if Mark is willing to write his blog post on the IBM Community so everyone can see it.

EDIT: Looks like he already did, so I have edited my previous response to include the link to the IBM Community version of the post.

Cheers,
Morag

​

------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com

Original Message:
Sent: Fri December 31, 2021 03:11 AM
From: Colin Paice
Subject: How long's the MQOD on z/OS - it depends

When I build a C program, on z/OS, in 64-bit, that prints out the size of the MQOD structure, it says it is 424 bytes.

Perhaps you can share your code and your build options so we can understand how you got 422 which is not even divisible by 4!

You ask for a special compile option to force pointers to be 31-bit. I'm not sure exactly what you mean there. You already said you built it 31-bit and and got the expected length of 400 in that situation. What more do you want the special option to do beyond that? Perhaps expand on your requirement so we can help further.

I agree that it would be nice if the z/OS version of the CMQC header file had the same pairs of #defined constants too, after all they have other #if defined(_LP64) statements in the header file. Would be nice just for consistency, but I have to say that I have rarely used those constants, and just use sizeof() when I need the length. If you use them, perhaps it would be worth raising an IDEA?

I've been compiling a program on z/OS and found the length of the MQOD (and others)  are not what I expect.
If I compile with 31 bit I get an MQOD with length 400 which matches the MQOD_CURRENT_LENGTH  in the CMQC.H (There is only one MQOD_CURRENT_LENGTH in the file).

If I compile with 64 bit, I get an MQOD with length 422.

If I look at the QMQC.h on midrange it has

#if defined(MQ_64_BIT)
#define MQOD_CURRENT_LENGTH 424
#else
#define MQOD_CURRENT_LENGTH 400
#endif

Which is what I expect...

do I need a special compile option for z/OS to force pointers to be 31 bit ?

Colin