64-bit queue manager migration information

 

This section provides you with information regarding the changes that might be necessary for applications to continue working now that WebSphere MQ V6.0 has introduced the 64-bit queue manager.

 

Introduction

Attention: On platforms where there is a 32-bit WebSphere MQ V6.0 product, for example, Linux (x86 platform), there is no migration path from 32-bit WebSphere MQ Version 6.0 queue managers to 64-bit WebSphere MQ V6.0 queue managers. If you wish to use a 64-bit WebSphere MQ V6.0 product on a machine where there was previously a 32-bit WebSphere MQ V6.0 installation, you will be prevented from starting any of the existing queue managers. Note however that migration from 32-bit queue managers in previous versions of WebSphere MQ , for example V5.3, is supported.

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.

 

Affected environments

The 64-bit queue manager is now supported on the following WebSphere MQ V6.0 platforms:

 

API implications

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 V6.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, we need to be aware that in WebSphere MQ V5.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 V6.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 platform sizes for 32-bit and 64-bit applications (Bracketed figures are for 64-bit size)
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)

1. A 32-bit long double on Sun Solaris for x86-64 is 12 bytes.

 

WebSphere MQ V6.0 bindings

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 V5.3.

 

EXTSHM on WebSphere MQ for AIX

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 V6.0.

32-bit customer WebSphere MQ applications will revert to the pre-WebSphere MQ V5.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.

 

Parent topic:

Migration Information


mi10140_