[z/OS]

RESLEVEL と CICS 接続

デフォルトでは、 CICS® 接続で API リソース・セキュリティー検査が行われると、2 つのユーザー ID が検査されます。 RESLEVEL プロファイルをセットアップすれば、検査対象のユーザー ID を変更できます。

最初に検査されるユーザー ID は、 CICS アドレス・スペースのユーザー ID です。 これは、 CICS ジョブのジョブ・カード上のユーザー ID、または z/OS® STARTED クラスまたは開始プロシージャー・テーブルによって CICS 開始タスクに割り当てられたユーザー ID です。 (これは CICS DFLTUSER ではありません。)

検査される 2 番目のユーザー ID は、 CICS トランザクションに関連付けられたユーザー ID です。

このいずれかのユーザー ID に、リソースに対するアクセス権がなければ、要求は完了コード MQRC_NOT_AUTHORIZED で失敗します。 CICS アドレス・スペースのユーザー ID と、 CICS トランザクションを実行するユーザーのユーザー ID の両方が、正しいレベルでリソースにアクセスできる必要があります。

実行される検査に対する RESLEVEL の影響

RESLEVEL プロファイルのセットアップ方法によって、リソースへのアクセスが要求されたときに検査するユーザー ID を変更できます。 詳しくは、 表 1 を参照してください。

検査されるユーザー ID は、接続時に使用されるユーザー ID、つまり CICS アドレス・スペース・ユーザー ID によって異なります。 この制御により、あるシステムからの IBM® MQ 要求 (例えば、テスト・システム、TESTCICS) に対しては API リソース・セキュリティー検査をバイパスできますが、別のシステム (例えば、実動システム、PRODCICS) に対しては API リソース・セキュリティー検査を実装できます。

注: STARTED クラスまたは RACF® 開始プロシージャー・テーブル ICHRIN03に trusted 属性を指定して CICS アドレス・スペース・ユーザー ID をセットアップした場合、これは、キュー・マネージャーの RESLEVEL プロファイルによって確立された CICS アドレス・スペースのユーザー ID 検査をオーバーライドします (つまり、キュー・マネージャーは CICS アドレス・スペースのセキュリティー検査を実行しません)。 詳細については、確保CICS。

以下の表に、 CICS 接続に対して行われる検査を示します。

表 1. CICS 接続のさまざまな RACF アクセス・レベルで行われる検査
RACF アクセス・レベル 検査のレベル
NONE IBM MQ は、 CICS アドレス・スペースのユーザー ID とトランザクションのユーザー ID を検査します。
READ IBM MQ は、 CICS アドレス・スペースのユーザー ID のみを検査します。
UPDATE トランザクションが RESSEC(YES) を指定して CICS に定義されている場合、IBM MQ は、CICS アドレス・スペースのユーザー ID とトランザクション・ユーザー ID を検査します。
UPDATE トランザクションが RESSEC(NO) を指定して CICS に対して定義されている場合、IBM MQ は、CICS アドレス・スペースのユーザー ID のみを検査します。
CONTROL または ALTER IBM MQ は、ユーザー ID を検査しません。