| Author |
Message
|
| jgonz |
 Posted: Mon Jan 18, 2016 9:52 pm Post subject: BIP7122E with reason code 2093 |
 |
|
Novice
Joined: 20 Nov 2015
Posts: 16
|
I am getting an error stating, BIP7122E: Failure occurred putting a message to the queue manager on topic 'TOPIC_NAME'. The WebSphere MQ reason code is '2093'.
I was unable to find any information about this error other than the description of 2093 which reads:
MQRC_NOT_OPEN_FOR_PASS_ALL;2093;082D;RC2093;An MQPUT call was issued with the MQPMO_PASS_ALL_CONTEXT option specified in the PutMsgOpts parameter, but the queue had not been opened with the MQOO_PASS_ALL_CONTEXT option.;MQCC_FAILED;Specify MQOO_PASS_ALL_CONTEXT (or another option that implies it) when the queue is opened.;
I have a Broker sub-flow that is publishing a message onto a topic. It sets the topic in ESQL based on a UDP value. This code is tested and works fine in various environments and even in other flows in the same environment where the error is occurring. Using the subflow in this particular application however, I am unable to publish the message to the topic as I get the above error.
To reiterate, subflow 1 is used in flow A and flow B. Both flow A and B work fine in environment 1. But only Flow A works in environment 2 while flow B receives the above error. The same topic is used for both flow A and B as it is defined within subflow 1. As far as I can tell, there is no difference between the setup in either environment and Flow B is deployed almost exactly the same (only difference is datasource) in environment 1 and environment 2.
Any help would be much appreciated, very confused on what is going on here! |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Jan 19, 2016 5:12 am Post subject: Re: BIP7122E with reason code 2093 |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jgonz wrote: |
MQRC_NOT_OPEN_FOR_PASS_ALL;2093;082D;RC2093;An MQPUT call was issued with the MQPMO_PASS_ALL_CONTEXT option specified in the PutMsgOpts parameter, but the queue had not been opened with the MQOO_PASS_ALL_CONTEXT option.;MQCC_FAILED;Specify MQOO_PASS_ALL_CONTEXT (or another option that implies it) when the queue is opened.;
I have a Broker sub-flow that is publishing a message onto a topic. It sets the topic in ESQL based on a UDP value. This code is tested and works fine in various environments and even in other flows in the same environment where the error is occurring. Using the subflow in this particular application however, I am unable to publish the message to the topic as I get the above error.
To reiterate, subflow 1 is used in flow A and flow B. Both flow A and B work fine in environment 1. But only Flow A works in environment 2 while flow B receives the above error. The same topic is used for both flow A and B as it is defined within subflow 1. As far as I can tell, there is no difference between the setup in either environment and Flow B is deployed almost exactly the same (only difference is datasource) in environment 1 and environment 2.
Any help would be much appreciated, very confused on what is going on here! |
Please check as well that the permissions are set correctly on the queue/topic. And remember that until the flow is done, the error could come from an MQ Output node downstream of your subflow. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jgonz |
| Posted: Tue Jan 19, 2016 8:24 am Post subject: Re: BIP7122E with reason code 2093 |
|
|
Novice
Joined: 20 Nov 2015
Posts: 16
|
| fjb_saper wrote: |
Please check as well that the permissions are set correctly on the queue/topic. |
Can you elaborate on what permissions can be set? Publish/subscribe is allowed on the topic and put/get is also allowed on the queue. As I mentioned, another flow using the exact same topic string, subscription, and queue is working fine. Are there flow specific permissions that can be set when simply publishing to a topic? I'm aware that you can change the 'PASS ALL' etc. in an output node, but haven't seen any similar properties for a publish node. And besides, this is working in all my other flows that use the same subflow to publish to the topic.
| fjb_saper wrote: |
| And remember that until the flow is done, the error could come from an MQ Output node downstream of your subflow. |
When in debug mode, I can see the error occurring just after the publish node. Regardless, I tried removing the logic after the publish node (which was just another subflow that I never reached in debug mode) to eliminate this as a possibility, but still the error occurs. |
|
| Back to top |
|
|
| jgonz |
| Posted: Wed Jan 27, 2016 8:23 am Post subject: |
|
|
Novice
Joined: 20 Nov 2015
Posts: 16
|
Really could use some help here.
Not sure how helpful this is, but here's more info on the process:
We have a subflow that is used to publish exceptions (using an xml message containing exception details) to a topic, we'll call TOPIC_ERR. This subflow is used across all our flows.
We have an application that does nothing but pull messages off a TIBCO EMS queue and publishes the message to a topic (using a value in the header of the message as the topic string). We have a few subscriptions on that topic which we'll call TOPIC_1. Then, we have two applications which pick up the messages from the different subscription queues and just put to a database.
I've added a throw node in each of these applications to generate an exception. What I've noticed is that these two applications are causing our problem, but any other flow works just fine using the TOPIC_ERR. Again, these two applications WORK FINE in our DEV environment and only fail on the publish to TOPIC_ERR in test. I've checked the outgoing messages using debugger and I've seen that there is no difference in any headers/properties of the messages. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 27, 2016 8:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The other place to look is at the properties of the MQInput node.
And look at the code upstream of the subflow. it's possible that it's setting mqmd properties that would require pass all.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| jgonz |
| Posted: Wed Jan 27, 2016 8:50 am Post subject: |
|
|
Novice
Joined: 20 Nov 2015
Posts: 16
|
I created a new topic, subscription, and flow. Then published a test message to the topic and the new receiving application simply has an MQ Input node and throws an exception which is then caught and passed to our subflow. The same error occurs in this case.
I really feel that there must be some configuration specific to the environment that is causing this issue, I don't see why there would be a problem with the code when it works fine in one environment but not the other. |
|
| Back to top |
|
|
| jgonz |
| Posted: Wed Jan 27, 2016 9:19 am Post subject: |
|
|
Novice
Joined: 20 Nov 2015
Posts: 16
|
| mqjeff wrote: |
| The other place to look is at the properties of the MQInput node. |
What properties might have an impact due to environment configurations? The only one I can think of would be the Security properties, but I believe the user would always be mqm in our case. I currently have this set to 'Transport Default'. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 27, 2016 10:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It vaguely sounds like an MQ security issue, of some sort.
But see what a user trace shows.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| jgonz |
| Posted: Wed Jan 27, 2016 11:44 am Post subject: |
|
|
Novice
Joined: 20 Nov 2015
Posts: 16
|
| mqjeff wrote: |
It vaguely sounds like an MQ security issue, of some sort.
But see what a user trace shows. |
Thanks for the direction. I tried this, but I'm unfortunately not able to access the user trace, will have to get access and get back. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jan 28, 2016 5:12 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What version of IIB are you using?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jgonz |
| Posted: Fri Jan 29, 2016 9:10 am Post subject: |
|
|
Novice
Joined: 20 Nov 2015
Posts: 16
|
| fjb_saper wrote: |
| What version of IIB are you using? |
WMB v8.0.0.5
MQ v7.5.0.4 |
|
| Back to top |
|
|
| jgonz |
| Posted: Fri Jan 29, 2016 10:35 am Post subject: |
|
|
Novice
Joined: 20 Nov 2015
Posts: 16
|
| mqjeff wrote: |
It vaguely sounds like an MQ security issue, of some sort.
But see what a user trace shows. |
I was able to have someone send me the user trace logs. I got user trace logs for an application that uses MQInput and another application that uses SOAPInput while both use the same error handling flow to publish messages to a topic. Here they are:
Working:
| Code: |
#ImbPubSubEngineNode::setPscProperty
ImbPubSubEngineNode::publish
1No SubscriptionPoint (or possibly topic!) present
ImbPubSubEngineNode::publish
MQSI_PUBSUB_USE_BROKER_USERID is
ImbPubSubEngineNode::publish
&Using default broker userid to publish
ImbPubSubEngineNode::publish
MQOPEN()
ImbPubSubEngineNode::publish
Context was not from MQ
ImbPubSubEngineNode::publish
lpiSPIPut()
ImbPubSubEngineNode::publish
N/build/slot1/S800_P/src/DataFlowEngine/JavaNodeLibrary/ImbPubSubEngineNode.cpp
Published to MQ
ImbPubSubEngineNode::publish
MQCLOSE() 2
ImbPubSubEngineNode::publish
MQDLTMH()
#ImbMessage::ReadCursor::~ReadCursor |
...~100 lines later...
| Code: |
ImbPubSubEngineNode::publish
PDTMO
ImbPubSubEngineNode::evaluate
7ImbPubSubMessageProperties::~ImbPubSubMessageProperties |
...~100 lines later...
| Code: |
5ImbPubSubHeaderProperties::~ImbPubSubHeaderProperties
ImbDataFlowTerminal::evaluate
'ImbUserExitManager::nodeCompletionEvent
'ImbUserExitManager::nodeCompletionEvent
ImbDataFlowTerminal::propagate |
Not Working:
| Code: |
#ImbPubSubEngineNode::setPscProperty
ImbPubSubEngineNode::publish
1No SubscriptionPoint (or possibly topic!) present
ImbPubSubEngineNode::publish
MQSI_PUBSUB_USE_BROKER_USERID is
ImbPubSubEngineNode::publish
&Using default broker userid to publish
ImbPubSubEngineNode::publish
MQOPEN()
ImbPubSubEngineNode::publish
lpiSPIPut()
ImbPubSubEngineNode::publish
MQCLOSE()
ImbPubSubEngineNode::publish
MQDLTMH()
ImbPubSubEngineNode::publish
#ImbMessage::ReadCursor::~ReadCursor |
...~100 lines later...
| Code: |
ImbPubSubEngineNode::evaluate
Caught PubSub Exception
ImbPubSubEngineNode::evaluate
N/build/slot1/S800_P/src/DataFlowEngine/JavaNodeLibrary/ImbPubSubEngineNode.cpp
PubSub Exception
!ImbDataFlowNode::logExceptionList
"ImbMessage::ReadCursor::ReadCursor |
What I've gathered from this is that with the MQInput node, the context may be explicitly set while the SOAPInputNode is using PASS_ALL by default? Please let me know if you have any further insight. My next step is to get trace logs of the same 'not-working' flow that is working in our DEV environment and compare the two.[/code] |
|
| Back to top |
|
|
| jgonz |
| Posted: Mon Feb 01, 2016 12:36 pm Post subject: |
|
|
Novice
Joined: 20 Nov 2015
Posts: 16
|
| Update: We have found that this error is completely local to a single environment and opened a PMR. Not sure what will turn up, but will keep posted. |
|
| Back to top |
|
|
| jgonz |
| Posted: Thu Feb 18, 2016 9:18 am Post subject: Root Cause |
|
|
Novice
Joined: 20 Nov 2015
Posts: 16
|
Turns out that someone requested an environment variable be set on the mqsi profile for this server... 
export MQSI_PUBSUB_USE_MQCONTEXT=passAll
Disabling this fixed the issue. |
|
| Back to top |
|
|
|
|
