2017-10-29 25 views
1

最近、Websphereアプリケーションサーバーv8.0.0.3が8.5.5.8に移行されました。 1つのアプリケーションが実行されていました。これはIBM MQ Java APIを使用して、サードパーティのマシンをMQサーバー接続チャネル経由で接続しています。Websphere Application Server 8.5.5.8 - MQRC 2035

同じアプリケーションがv8.0.0.3で正常に機能していますが、同じアプリケーションがv8.5.5.8でMQと接続していません。私たちは「MQRC 2035」(認可されていない)を取得しています。

正確なエラー:

Could be configuarion, network or service availability issue. Root Cause: MQJE001: Completion Code '2', Reason '2035' 

"SYSTEM" ユーザー(Windowsサービス)として実行しているアプリケーションサーバーの両方古いと新しいバージョン。

サードパーティ側でsetmqauthを追加することで解決できます。同じアプリケーションがv8.5.5.8で動作しない理由を明確にする必要があります。

答えて

1

WAS v8.0.0.3には、IBM MQ RA v7.0.1.7が付属しています。 WAS v8.5.5.8 には、IBM MQ RA v7.1.0.6が付属しています。

空のMCAUSERが流れないように、IBM MQ MQの動作がv7.1で変更されました。これは、IBM Technote "Changes in the default user identifier between WebSphere MQ V7.0.1 classes for JMS and WebSphere MQ V7.1 classes for JMS"に記載されています。

Answer

WebSphere MQ access control is based on user identifiers. There is a deliberate change in the default behaviour between the WebSphere MQ V7.0.1 classes for JMS and the WebSphere MQ V7.1 (and later) classes for JMS regarding the default user identifier flowed to the queue manager. From the WebSphere MQ V7.1 classes for JMS onwards, a non-blank user identifier is always flowed to the queue manager when creating a connection to WebSphere MQ.

第三者側はWAS v8.0.0.3ブランクMCAUSERを許可されている場合は、サードパーティの側は、あなたが渡すとさらに悪い可能性が高いあなたはMQと接続せているものを検証されていないことを示すことになります管理者は、キュー・マネージャー上のSYSTEMキューを含むすべてのキューにアクセスできます。

0

MQEnvironmentに明示的にユーザーIDを追加した後、問題が解決されました。

ハッシュテーブルmqht =新しいハッシュテーブル(); mqht.put(CMQC.USER_ID_PROPERTY、userID);

http://www-01.ibm.com/support/docview.wss?uid=swg21138961

+0

これはまだ、それはちょうどあなたがMQ管理者ユーザーになる空白を含め、それを送って任意の値を受け入れているという点で、キューマネージャのセキュリティホールを開けたまま。 – JoshMc

関連する問題