This section provides you with information regarding the changes that might 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 be transparent to most
applications.
However
, 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 could have an impact on
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 SupportPac™
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 on at least some platforms
.
You also need
to be aware that pointers for 64-bit applications and 64-bit MQ exits will
be 64-bit. If your user-exits
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
user-exit
to store a pointer to a block of pointers in the ExitUserArea.
If your
exits
have not been written in this way, you will
need to rewrite them 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 might occur.
Data type | Sun Solaris | HP-UX | AIX | Linux (POWER platform) | Linux (x86-64 platform) | Linux (zSeries 64-bit platform) |
---|---|---|---|---|---|---|
char | 1 byte (1 byte) | 1 byte (1 byte) | 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) | 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) | 4 bytes (4 bytes) | 4 bytes (4 bytes) |
long | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 4 bytes (8 bytes) |
float | 4 bytes (4 bytes) | 4 bytes (4 bytes) | 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) | 8 bytes (8 bytes) | 8 bytes (8 bytes) |
long double | 16 bytes (16 bytes)1 | 16 bytes (16 bytes) | 8 bytes (8 bytes) | 8 bytes (8 bytes) | 12 bytes (16 bytes) | 8 bytes (8 bytes) |
pointer | 4 bytes (8 bytes) | 4 bytes (8 bytes) | 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) | 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) | 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) | 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) | 4 bytes (8 bytes) | 4 bytes (8 bytes) |
wchar_t | 4 bytes (4 bytes) | 4 bytes (4 bytes) | 2 bytes (4 bytes) | 4 bytes (4 bytes) | 4 bytes (4 bytes) | 4 bytes (4 bytes) |
Note: 1. A 32-bit long
double on Sun Solaris for x86-64 is 12 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 available. If a 32-bit application tries to connect to the
queue manager via a fastpath binding it will be silently downgraded
to
Standard bindings. This will cause a noticeable loss of performance (it has
virtually identical performance as when connecting directly with a Standard
binding) to anyone currently using fastpath and
who
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
intend
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 ten
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.
Any setting of EXTSHM has no effect in WebSphere MQ Version 6.0
.
32-bit customer WebSphere MQ applications will revert to the
pre-WebSphere MQ Version 5.3 limit of ten
shared
storage segments. If your applications are using standard bindings, you might
run into resource problems due to this limitation. This limitation can be
avoided by using isolated bindings.
Do this by replacing MQCONN
calls with MQCONNX, and specifying MQCNO_ISOLATED_BINDING in the MQCNO parameter
of the MQCONNX calls.
There is virtually no limit to the number of shared storage segments created using 64-bit applications.