Options that control the action of MQCONNX.
Binding options: The following options control the type of MQ binding that will be used; only one of these options can be specified:
This option causes the application and the local-queue manager agent (the component that manages queuing operations) to run in separate units of execution (generally, in separate processes). This arrangement maintains the integrity of the queue manager, that is, it protects the queue manager from errant programs.
CNSBND should be used in situations where the application may not have been fully tested, or may be unreliable or untrustworthy. CNSBND is the default.
CNSBND is defined to aid program documentation. It is not intended that this option be used with any other option controlling the type of binding used, but as its value is zero, such use cannot be detected.
This option is supported in all environments.
This option causes the application and the local-queue manager agent to be part of the same unit of execution. This is in contrast to the normal method of binding, where the application and the local-queue manager agent run in separate units of execution.
CNFBND is ignored if the queue manager does not support this type of binding; processing continues as though the option had not been specified.
CNFBND may be of advantage in situations where the use of multiple processes is a significant performance overhead compared to the overall resource used by the application. An application that uses the fastpath binding is known as a trusted application.
The following important points must be considered when deciding whether to use the fastpath binding:
The following points apply to the use of CNFBND in the environments indicated:
For more information about the implications of using trusted applications, see the WebSphere MQ Application Programming Guide.
This option causes the application and the local-queue-manager agent (the component that manages queuing operations) to run in separate units of execution (generally, in separate processes). This arrangement maintains the integrity of the queue manager, that is, it protects the queue manager from errant programs. However some resources are shared between the application and the local-queue-manager agent. 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.
This option causes the application and the local-queue-manager agent (the component that manages queuing operations) to run in separate units of execution (generally, in separate processes). This arrangement maintains the integrity of the queue manager, that is, it protects the queue manager from errant programs. 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.
Handle-sharing options: The following options control the sharing of handles between different threads (units of parallel processing) within the same process. Only one of these options can be specified.
This option indicates that connection and object handles can be used only by the thread that caused the handle to be allocated (that is, the thread that issued the MQCONN, MQCONNX, or MQOPEN call). The handles cannot be used by other threads belonging to the same process.
This option indicates that connection and object handles allocated by one thread of a process can be used by other threads belonging to the same process. However, only one thread at a time can use any particular handle, that is, only serial use of a handle is permitted. If a thread tries to use a handle that is already in use by another thread, the call blocks (waits) until the handle becomes available.
This is the same as CNHSB, except that if the handle is in use by another thread, the call completes immediately with CCFAIL and RC2219 instead of blocking until the handle becomes available.
A thread can have zero or one nonshared handle, plus zero or more shared handles:
Object handles inherit the same share properties as the connection handle specified on the MQOPEN call that created the object handle. Also, units of work inherit the same share properties as the connection handle used to start the unit of work; if the unit of work is started in one thread using a shared handle, the unit of work can be updated in another thread using the same handle.
If no handle-sharing option is specified, the default is determined by the environment:
Default option: If none of the options described above is required, the following option can be used:
CNNONE is defined to aid program documentation. It is not intended that this option be used with any other CN* option, but as its value is zero, such use cannot be detected.
This is always an input field. The initial value of this field is CNNONE.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
js50566 |