This section provides you with information regarding the changes that may be necessary for applications to continue working now that WebSphere® MQ Version 6.0 has introduced the 64-bit queue manager.
With the queue manager becoming 64-bit for some distributed platforms, it removes many of the 32-bit addressing limitations. It gives a large increase to the amount of memory available for applications and WebSphere MQ, and the number and size of shared storage segments is also increased.
This move to 64-bit queue managers will not be transparent to all applications. A small number of 32-bit applications will no longer work as they will need some of the files they interact with to be built as 64-bit versions. This migration documentation provides information to help you identify those applications and those files that will be needed as 64-bit.
Where other changes have been made, and where these may have an impact to your current installation without your applications requiring a change (for example, performance), these have also been identified. As a general rule, 32-bit applications will not need to be modified, but 32-bit switches and exits will need to be rebuilt.
There are no changes to the API for existing applications to continue to work using 32-bit addressing (as will 64-bit addressing if the 64-bit client support pack has been installed) as 32-bit libraries are supplied for binary compatibility in WebSphere MQ Version 6.0.
Existing 64-bit client applications will continue to be able to take advantage of using their 64-bit client processes, without changes to the application API being required.
Although the API has not changed, you need to be aware that in WebSphere MQ Version 5.3 and earlier versions, an MQLONG, an int, a long, and a size_t were all 32-bit so effectively interchangeable in their use. In WebSphere MQ Version 6.0 this is no longer true as a long, and a size_t are now 64-bit.
You also need to be aware that pointers for 64-bit applications and 64-bit MQ exits will be 64-bit. If your applications were storing pointers in a WebSphere MQ exit ExitUserArea, which is an MQBYTE16, you will now only be able to store two pointers. This will not cause you a problem if you have written your application to store a pointer to a block of pointers in the ExitUserArea. If your applications have not been written in this way, you may need to rewrite your applications to use this approach if there is now no longer enough room in ExitUserArea to store the pointers that your application needs.
The following table gives you the sizes of the basic 'C' types to aid you to see where similar problems may occur.
Data type | Sun Solaris | HP-UX | AIX | Linux PPC |
---|---|---|---|---|
char | 1 byte (1 byte) | 1 byte (1 byte) | 1 byte (1 byte) | 1 byte (1 byte) |
short | 2 bytes (2 bytes) | 2 bytes (2 bytes) | 2 bytes (2 bytes) | 2 bytes (2 bytes) |
int | 4 bytes (4 bytes) | 4 bytes (4 bytes) | 4 bytes (4 bytes) | 4 bytes (4 bytes) |
long | 4 bytes (8 bytes) | 4 bytes (4 bytes) | 4 bytes (4 bytes) | 4 bytes (4 bytes) |
float | 4 bytes (4 bytes) | 4 bytes (4 bytes) | 4 bytes (4 bytes) | 4 bytes (4 bytes) |
double | 8 bytes (8 bytes) | 8 bytes (8 bytes) | 8 bytes (8 bytes) | 8 bytes (8 bytes) |
long double | 16 bytes (16 bytes) | 16 bytes (16 bytes) | 8 bytes (8 bytes) | 8 bytes (8 bytes) |
pointer | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) |
ptrdiff_t | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) |
size_t | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) |
time_t | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) |
clock_t | 4 bytes (8 bytes) | 4 bytes (4 bytes) | 4 bytes (4 bytes) | 4 bytes (8 bytes) |
wchar_t | 4 bytes (4 bytes) | 4 bytes (4 bytes) | 4 bytes (2 bytes) | 4 bytes (4 bytes) |
Three sets of bindings will be provided for 64-bit applications: isolated; Standard and fastpath bindings. For 32-bit applications only isolated and Standard bindings will be the available. If a 32-bit application tries to connect to the queue manager via a fastpath binding it will be silently down graded to Standard bindings. This will cause a noticeable loss of performance (it has virtually identical performance as to when connecting directly with a Standard binding) to anyone currently using fastpath and is unwilling or unable to port the application to 64-bit. If you require to connect your 32-bit applications using fastpath bindings because performance is an issue, and you are looking to keep your applications as 32-bit applications, then you will have to remain with WebSphere MQ Version 5.3.
Setting EXTSHM for WebSphere MQ for AIX will no longer allow more than eleven MQ shared storage segments to be attached to a 32-bit application process. This is because the WebSphere MQ shared storage segments will have been created by a 64-bit process and these have no concept of EXTSHM.
32-bit customer WebSphere MQ applications will revert to the pre-WebSphere MQ Version 5.3 limit of eleven shared storage segments. If your applications are using Standard bindings, you may run into resource problems due to this limitation. This limitation can be avoided by using isolated bindings.
There is virtually no limit to the number of shared storage segments created using 64-bit applications.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
wmqm1400 |