Working together: client, server, local queue manager

On the z/TPF system, the combination of support for the IBM® MQ client, server, and local queue manager provides you with powerful messaging capabilities. As a result, you have two methods for using the MQI:
  • The client can communicate with a IBM MQ server and use the MQI capabilities of that server.
  • The local queue manager can make and accept MQI calls.
Each of these methods has its own advantages and disadvantages. The client can be placed on many systems, and by connecting to a IBM MQ server, the applications using each client gain access to the MQI support on the server. This allows you to effectively employ the MQI without the costs of implementing local queue managers on more than one system.

However, there is overhead associated with using the client-server approach that does not exist when using the local queue manager implementation because of the increased communication flow required. A local queue manager on the z/TPF system has the ability to achieve higher messaging capabilities than the client-server combination. In addition, applications that connect to local queue managers are simplified because they do not risk a communication failure, such as that which can occur when the client is communicating with the server. The application can be certain that the message reached a queue when it is being managed locally. Finally, applications using the local queue manager on the z/TPF system have more transactional capabilities. An application can use commit scopes to include IBM MQ queue, fixed file, and pool updates in a single transaction. IBM MQ client APIs are not included in transactions because the update occurs on the server system. (However, when the z/TPF system is your IBM MQ server, there are some parameters and functions available to help with transaction management. See z/TPF Application Programming for more information about transaction management and z/TPF IBM MQ support.)

A z/TPF system has the ability to use both the z/TPF IBM MQ client and the z/TPF IBM MQ local queue manager. The way in which an application initially connects to a queue manager using the MQCONN C language function impacts how subsequent API calls are processed:
  • If the application codes MQCONN using the name of the local queue manager (a queue manager is given a name when it is defined), a connection is made to that local queue manager, and all subsequent IBM MQ API calls using the connection handle returned by MQCONN will use the local queue manager.
  • If the application codes MQCONN using the name of the queue manager other than the local queue manager, the z/TPF system will send the MQCONN C language function to the z/TPF IBM MQ client library. The client uses a CLNTCONN channel definition that connects to a remote IBM MQ server with the correct queue manager name. All subsequent API calls that use that handle are routed to the remote IBM MQ server.

For more information about z/TPF IBM MQ support, see z/TPF Application Programming.