2012 (07DC) (RC2012): MQRC_ENVIRONMENT_ERROR

Explanation

The call is not valid for the current environment.
  • [z/OS]On z/OS®, when one of the following applies:
    • An MQCONN or MQCONNX call was issued, but the application has been linked with an adapter that is not supported in the environment in which the application is running. For example, this can arise when the application is linked with the MQ RRS adapter, but the application is running in a Db2® Stored Procedure address space. RRS is not supported in this environment. Stored Procedures wishing to use the MQ RRS adapter must run in a Db2 WLM-managed Stored Procedure address space.
    • An MQCMIT or MQBACK call was issued, but the application has been linked with the RRS batch adapter CSQBRSTB. This adapter does not support the MQCMIT and MQBACK calls.
    • An MQCMIT or MQBACK call was issued in the CICS® or IMS environment.
    • The RRS subsystem is not operational on the z/OS system that ran the application.
    • An MQCTL call with MQOP_START or an MQCB call registering an Event Listener, was issued but the application is not allowed to create a POSIX thread.
    • An IBM® MQ classes for Java application has instantiated an MQQueueManager object using the CLIENT transport. The z/OS environment only supports the use of the BINDINGS transport.
  • On IBM i, HP Integrity NonStop Server, UNIX systems, and Windows, when one of the following applies:
    • The application is linked to unsupported libraries.
    • The application is linked to the wrong libraries (threaded or nonthreaded).
    • An MQBEGIN, MQCMIT, or MQBACK call was issued, but an external unit-of-work manager is in use. For example, this reason code occurs on Windows when an MTS object is running as a DTC transaction. This reason code also occurs if the queue manager does not support units of work.
    • The MQBEGIN call was issued in an MQ MQI client environment.
    • An MQXCLWLN call was issued, but the call did not originate from a cluster workload exit.
    • An MQCONNX call was issued specifying the option MQCNO_HANDLE_SHARE_NONE from within an MQ channel exit, an API Exit, or a Callback function. The reason code occurs only if a shared hConn is bound to the application thread.
    • An IBM MQ Object is unable to connect fastpath.
    • An IBM MQ classes for Java application has created an MQQueueManager object that uses the CLIENT transport, and then called MQQueueManager.begin(). This method can only be called on MQQueueManager objects that use the BINDINGS transport.
  • On Windows, when using the managed .NET client, an attempt was made to use one of the unsupported features:
    • Unmanaged channel exits
    • Secure Sockets Layer (SSL)
    • XA Transactions
    • Communications other than TCP/IP
    • Channel compression

Completion Code

MQCC_FAILED

Programmer response

Do one of the following (as appropriate):
  • On z/OS:
    • Link the application with the correct adapter.
    • Modify the application to use the SRRCMIT and SRRBACK calls in place of the MQCMIT and MQBACK calls. Alternatively, link the application with the RRS batch adapter CSQBRRSI. This adapter supports MQCMIT and MQBACK in addition to SRRCMIT and SRRBACK.
    • For a CICS or IMS application, issue the appropriate CICS or IMS call to commit or backout the unit of work.
    • Start the RRS subsystem on the z/OS system that is running the application.
    • If your application uses Language Environment (LE) ensure that it uses the DLL interface and it runs with POSIX(ON).
    • Ensure that your application is allowed to use Unix System Services (USS).
    • Ensure that your Connection Factory definitions for local z/OS applications and WebSphere® Application Server applications use Transport Type with bindings mode connections.
  • In the other environments:
    • Link the application with the correct libraries (threaded or nonthreaded).
    • Remove from the application the call or feature that is not supported.
    • Change your application to run setuid, if you want to run fastpath.