In general, you can connect either to a specific queue manager, or to the default queue manager:
Alternatively, in the z/OS MVS batch, TSO, and RRS environments you may connect to any one queue manager within a queue-sharing group. The MQCONN or MQCONNX request will select any one of the active members of the group.
The queue manager you connect to must be local to the task. This means that it must belong to the same system as the WebSphere MQ application.
In the IMS environment, the queue manager must be connected to the IMS control region and to the dependent region that the program uses. The default queue manager is specified in the CSQQDEFV module when WebSphere MQ for z/OS is installed.
With the CICS on Open Systems environment, and TXSeries for Windows NT and AIX, the queue manager must be defined as an XA resource to CICS.
To connect to the default queue manager, call MQCONN, specifying a name consisting entirely of blanks or starting with a null (X'00') character.
Within WebSphere MQ on UNIX systems, an application must be authorized for it to successfully connect to a queue manager. For more information, see WebSphere MQ System Administration Guide for WebSphere MQ for AIX, HP-UX, and Solaris; for other platforms, see the appropriate System Management Guide.
The output from MQCONN is:
You will need to use the connection handle on subsequent MQI calls.
If the reason code indicates that the application is already connected to that queue manager, the connection handle that is returned is the same as the one that was returned when the application first connected. So the application probably should not issue the MQDISC call in this situation because the calling application will expect to remain connected.
The scope of the connection handle is the same as that of the object handle (see Opening objects using the MQOPEN call).
Descriptions of the parameters are given in the description of the MQCONN call in WebSphere MQ Application Programming Reference.
The MQCONN call fails if the queue manager is in a quiescing state when you
issue the call, or if the queue manager is shutting down.
Scope of MQCONN or MQCONNX
Within WebSphere MQ for iSeries, MQSeries for Compaq OpenVMS Alpha, MQSeries for OS/2 Warp, WebSphere MQ on UNIX systems and WebSphere MQ for Windows, the scope of an MQCONN or MQCONNX call is usually the thread that issued it. That is, the connection handle returned from the call is valid only within the thread that issued the call. Only one call may be made at any one time using the handle. If it is used from a different thread, it will be rejected as invalid. If you have multiple threads in your application and each wishes to use WebSphere MQ calls, each one must individually issue MQCONN or MQCONNX. Alternatively, consider Shared (thread independent) connections with MQCONNX.
Each thread can connect to a different queue manager using MQCONN or MQCONNX on OS/2 and Windows systems, but not on OS/400 or UNIX.
If your application is running as a client, it may connect to more than one queue manager within a thread.
OS/2 has a limit of 4095 active threads in a system. However, the default is 64. This value may be controlled by the THREADS=xxxx parameter in CONFIG.SYS. Limitations on the number of concurrent MQCONN calls that can be made within a system are dependent on this value, although other factors to consider are disk space availability for the swapper.dat file and shared memory availability.
On MQSeries for VSE/ESA, there is a maximum of 1000 concurrently-connected tasks. The connection handle is unique to the ID of the transaction that is executing and only valid for the duration of that transaction.