shared handles, handle sharing" />
CNOPT (10-digit signed integer)
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:
- CNSBND
- Standard binding.
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.
- CNFBND
- Fastpath binding.
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:
- Use of the CNFBND option compromises the integrity of the queue manager, because it permits a rogue application to alter or corrupt messages and other data areas belonging to the queue manager. It should therefore be considered for use only in situations where these issues have been fully evaluated.
- The application must not use asynchronous signals or timer interrupts (such as
sigkill) with CNFBND. There are also restrictions on the use of shared memory segments. Refer to the WebSphere MQ Application Programming Guide for more information.
- The application must not have more than one thread connected to the queue manager at any one time.
- The application must use the MQDISC call to disconnect from the queue manager.
- The application must finish before ending the queue manager with the
endmqm command.
The following points apply to the use of CNFBND in the environments indicated:
- On i5/OS, the job must run under user profile QMQM that belongs to the
QMQMADM group. Also, the program must not terminate abnormally, otherwise unpredictable results may occur.
For more information about the implications of using trusted applications, see the WebSphere MQ Application Programming Guide.
- MQCNO_SHARED_BINDING
- Shared Bindings.
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.
- MQCNO_ISOLATED_BINDING
- Isolated Bindings.
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.
- CNHSN
- No handle sharing between threads.
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.
- CNHSB
- Serial handle sharing between threads, with call blocking.
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.
- CNHSNB
- Serial handle sharing between threads, without call blocking.
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:
- Each MQCONN or MQCONNX call that specifies CNHSN returns a new nonshared handle on the first call, and the same nonshared handle on the second and later calls (assuming no intervening MQDISC call). The reason code is RC2002 for the second and later calls.
- Each MQCONNX call that specifies CNHSB or CNHSNB returns a new shared handle on each call.
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:
- In the Microsoft Transaction Server (MTS) environment, the default is the same as CNHSB.
- In other environments, the default is the same as CNHSN.
Default option: If none of the options described above is required, the following option can be used:
- CNNONE
- No options specified.
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.