The MQCONNX call is similar to the MQCONN call, but includes options to control the way that the call works.
As input to MQCONNX, you can supply a queue manager name, or a queue-sharing group name on z/OS shared queue systems. The output from MQCONNX is:
You use the connection handle on subsequent MQI calls.
A description of all the parameters of MQCONNX is given in the WebSphere MQ Application Programming Reference. The Options field allows you to set STANDARD_BINDING, FASTPATH_BINDING, SHARED_BINDING, or ISOLATED_BINDING for any version of MQCNO. You can also make shared (thread independent) connections using a MQCONNX call. See Shared (thread independent) connections with MQCONNX for more information about these.
By default, MQCONNX (like MQCONN) implies two logical threads where the WebSphere MQ application and the local queue manager agent run in separate processes. The WebSphere MQ application requests the WebSphere MQ operation and the local queue manager agent services the request. This is defined by the MQCNO_STANDARD_BINDING option on the MQCONNX call.
Trusted applications imply that the WebSphere MQ application and the local queue manager agent become the same process. Because the agent process no longer needs to use an interface to access the queue manager, these applications become an extension of the queue manager. This is defined by the MQCNO_FASTPATH_BINDING option on the MQCONNX call.
You need to link trusted applications to the threaded WebSphere MQ libraries. For instructions on how to set up a WebSphere(R) MQ application to run as trusted, see the WebSphere MQ Application Programming Reference.
Specify this option to make the application and the local queue manager agent run in separate processes. This maintains the integrity of the queue manager, that is, it protects the queue manager from errant programs. However, the application and the local-queue-manager agent share some resources.
MQCNO_SHARED_BINDING is ignored if the queue manager does not support this type of binding. Processing continues as though the option had not been specified.
Specify this option to make the application and the local queue manager agent run in separate processes, as for MQCNO_SHARED_BINDING. In this case, however, the application process and the local-queue-manager agent are isolated from each other in that they do not share resources.
MQCNO_ISOLATED_BINDING is ignored if the queue manager does not support this type of binding. Processing continues as though the option had not been specified.
On z/OS(TM) these options are tolerated, but only a standard bound connection is performed. MQCNO Version 3, for z/OS, allows four alternative options:
This allows an application to request that only one instance of an application runs at any one time in a queue-sharing group. This is achieved by registering the use of a connection tag, whose value is specified or derived by the application. The tag is a 128 byte character string specified in the Version 3 MQCNO.
This is used where an application consists of more than one process (or a TCB), each of which can connect to a queue manager. Connection is permitted only if there is no current use of the tag, or the requesting application is within the same processing scope. This is MVS(TM) address space within the same queue-sharing group as the tag owner.
This is similar to MQCNO_SERIALIZE_CONN_TAG_QSG, but only the local queue manager is interrogated to see if the requested tag is already in use.
This is similar to MQCNO_RESTRICT_CONN_TAG_QSG, but only the local queue manager is interrogated to see if the requested tag is already in use.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
fastx |