Home

 

Usage notes

  1. The queue manager to which connection is made using the MQCONN call is called the local queue manager.

  2. Queues that are owned by the local queue manager appear to the application as local queues. It is possible to put messages on and get messages from these queues.

    Shared queues that are owned by the queue-sharing group to which the local queue manager belongs appear to the application as local queues. It is possible to put messages on and get messages from these queues.

    Queues that are owned by remote queue managers appear as remote queues. It is possible to put messages on these queues, but not to get messages from these queues.

  3. If the queue manager fails while an application is running, the application must issue the MQCONN call again to obtain a new connection handle to use on subsequent MQ calls. The application can issue the MQCONN call periodically until the call succeeds.

    If an application is not sure whether it is connected to the queue manager, the application can safely issue an MQCONN call to obtain a connection handle. If the application is already connected, the handle returned is the same as that returned by the previous MQCONN call, but with completion code MQCC_WARNING and reason code MQRC_ALREADY_CONNECTED.

  4. When the application has finished using MQ calls, the application must use the MQDISC call to disconnect from the queue manager.

  5. On z/OS:

    • Batch, TSO, and IMS applications must issue the MQCONN call to use the other MQ calls. These applications can connect to more than one queue manager concurrently.

      If the queue manager fails, the application must issue the call again after the queue manager has restarted to obtain a new connection handle.

      Although IMS applications can issue the MQCONN call repeatedly, even when already connected, this is not recommended for online message processing programs (MPPs).

    • CICS applications do not have to issue the MQCONN call to use the other MQ calls, but can do so if they want; both the MQCONN call and the MQDISC call are accepted. However, it is not possible to connect to more than one queue manager concurrently.

      If the queue manager fails, these applications are automatically reconnected when the queue manager restarts, and so do not need to issue the MQCONN call.

  6. On z/OS, to define the available queue managers:

    • For batch applications, system programmers can use the CSQBDEF macro to create a module (CSQBDEFV) that defines the default queue-manager name, or queue-sharing group name.

    • For IMS applications, system programmers can use the CSQQDEFX macro to create a module (CSQQDEFV) that defines the names of the available queue managers and specifies the default queue manager.

      In addition, each queue manager must be defined to the IMS control region and to each dependent region accessing that queue manager. To do this, create a subsystem member in the IMS.PROCLIB library and identify the subsystem member to the applicable IMS regions. If an application attempts to connect to a queue manager that is not defined in the subsystem member for its IMS region, the application abends.

    For more information on using these macros, see the WebSphere MQ for z/OS System Setup Guide.

  7. On i5/OS, applications written for previous releases of the queue manager can run without recompiling. This is called compatibility mode. This mode of operation provides a compatible run-time environment for applications. It comprises the following:

    • The service program AMQZSTUB residing in the library QMQM.

      AMQZSTUB provides the same public interface as previous releases, and has the same signature. Use this service program to access the MQI through bound procedure calls.

    • The program QMQM residing in the library QMQM.

      QMQM provides a means of accessing the MQI through dynamic program calls.

    • Programs MQCLOSE, MQCONN, MQDISC, MQGET, MQINQ, MQOPEN, MQPUT, MQPUT1, and MQSET residing in the library QMQM.

      These programs also provide a means of accessing the MQI through dynamic program calls, but with a parameter list that corresponds to the standard descriptions of the MQ calls.

    These three interfaces do not include capabilities that were introduced in MQSeries V5.1. For example, the MQBACK, MQCMIT, and MQCONNX calls are not supported. The support provided by these interfaces is for single-threaded applications only.

    Support for the new MQ calls in single-threaded applications, and for all MQ calls in multi-threaded applications, is provided through the service programs LIBMQM and LIBMQM_R.

  8. On i5/OS, programs that end abnormally are not automatically disconnected from the queue manager. Write applications to allow for the possibility of the MQCONN or MQCONNX call returning completion code MQCC_WARNING and reason code MQRC_ALREADY_CONNECTED. Use the connection handle returned in this situation as normal.




 

Home