注: 本資料をご使用になる前に、必ず特記事項に記載されている情報をお読みください。
|
本書は、IBM® Rational® Developer for System z® バージョン 9.1.1 (プログラム番号 5724-T07) および新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。
IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、 自ら適切と信ずる方法で、使用もしくは配布することができるものとします。
© Copyright IBM Corporation 2000, 2014
お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。
この資料では、IBM Rational Developer for System z 本体と、その他の z/OS® コンポーネントおよび製品 (WLM や CICS® など) の各種構成作業の背景情報について説明しています。
本書の情報は、すべての IBM Rational Developer for System z バージョン 9.1.1 パッケージに適用されます。
本書の最新バージョンについては、「IBM Rational Developer for System z ホスト構成リファレンス」(SA88-4226) (http://www-05.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=SA88-4226) を参照してください。
インストールの説明、ホワイト・ペーパー、ポッドキャスト、およびチュートリアルを含む、資料一式の最新バージョンについては、IBM Rational Developer for System z Web サイトのライブラリー・ページ (http://www-01.ibm.com/software/sw-library/en_US/products/Z964267S85716U24/) を参照してください。
本書は、IBM Rational Developer for System z バージョン 9.1.1 を構成およびチューニングするシステム・プログラマーを対象としています。
実際の構成は他の資料に記載されていますが、本書では、チューニング、セキュリティーのセットアップなど、各種の関連テーマについて詳しく挙げています。 本書を使用するには、z/OS UNIX システム・サービスおよび MVS™ ホスト・システムに精通している必要があります。
このセクションでは、「IBM Rational Developer for System z バージョン
9.1.1 ホスト構成リファレンス 」(SA88-4226-08) (2014 年 12 月 更新) の変更点を要約します。
本文または図表に対して技術的な変更または追加が行われている場合には、その個所の左側に縦線を引いて示してあります。
本書には、「IBM Rational Developer for System z バージョン 9.1.1 ホスト構成リファレンス 」(SA88-4226-07) に記載されていた情報が含まれています。
本書には、「IBM Rational Developer for System zバージョン 9.0.1 ホスト構成リファレンス」(SA88-4226-07) に記載されていた情報が含まれています。
本書には、「IBM Rational Developer for System zバージョン 9.0.1 ホスト構成リファレンス」(SA88-4226-04) に記載されていた情報が含まれています。
新しい情報:
本書には、「IBM Rational Developer for System zバージョン 8.5.1 ホスト構成リファレンス」(SA88-4226-03) に記載されていた情報が含まれています。
本書には、「IBM Rational Developer for System zバージョン 8.5 ホスト構成リファレンス」(SA88-4226-02) に記載されていた情報が含まれています。
本書には、「IBM Rational Developer for System z バージョン 8.0.3 ホスト構成リファレンス」(SA88-4226-01) に記載されていた情報が含まれています。
本書には、「IBM Rational Developer for System z バージョン 8.0.1 ホスト構成リファレンス」(SA88-4226-00) に記載されていた情報が含まれています。
ここでは、本書に記載されている情報を要約します。
Developer for System z ホストは、クライアントがホスト・サービスとデータにアクセスできるようにするために相互に作用する、複数のコンポーネントで構成されています。これらのコンポーネントの設計を理解しておくと、構成に関して適切な判断を行うことができます。
Developer for System z では、メインフレーム以外のワークステーション上にいるユーザーがメインフレームにアクセスできます。 このため、接続要求の妥当性検査、ホストとワークステーション間のセキュアな通信の提供、およびアクティビティーの許可と監査が、製品構成の重要な側面となります。
Developer for System z では、TCP/IP を使用して、非メインフレーム・ワークステーションのユーザーに、メインフレームからアクセスすることができます。 また、各種コンポーネントと他の製品との通信にも TCP/IP が使用されます。
従来の z/OS アプリケーションとは異なり、Developer for System z は、ワークロード・マネージャー (WLM) で容易に識別できる一体構造のアプリケーションではありません。Developer for System z は、クライアントがホスト・サービスとデータにアクセスできるようにするために相互に作用する、複数のコンポーネントで構成されています。これらのサービスの一部は異なるアドレス・スペースでアクティブとなるため、WLM 分類も異なることになります。
RSE (リモート・システム・エクスプローラー) は、Developer for System z の中核です。クライアントからの接続とワークロードを管理するために、RSE は、スレッド・プーリング・アドレス・スペースを制御するデーモン・アドレス・スペースから構成されています。デーモンは接続と管理のためのフォーカル・ポイントとして機能し、スレッド・プールはクライアント・ワークロードを処理します。
このため、RSE は Developer for System z セットアップをチューニングする場合の主要な対象となります。ただし、それぞれが 17 個以上のスレッドを使用する何百人ものユーザー、ある程度の大きさのストレージ、そして場合によっては 1 つ以上のアドレス・スペースを保守するには、Developer for System z と z/OS の両方を適切に構成する必要があります。
z/OS は高度にカスタマイズ可能なオペレーティング・システムであり、システムの (場合によっては小さな) 変更で全体のパフォーマンスに大きな影響を与えることができます。この章では、Developer for System z のパフォーマンスを向上させるために行うことができるいくつかの変更を中心に説明します。
この章には、CICS Transaction Server 管理者に有益な情報が記載されています。
この章は、出口ルーチンの作成による Developer for System z の機能強化についてユーザーを支援します。
この章は、Developer for System z で TSO 環境に DD ステートメントとデータ・セットを追加することにより、TSO ログオン・プロシージャーを模倣するのに役立ちます。
同じシステム上で Developer for System z の複数のインスタンスをアクティブにしたい場合があります。例えば、アップグレードをテストするときなどです。しかし、TCP/IP ポートなど、一部のリソースは共用できないため、デフォルトが常に適用可能であるとは限りません。この章の情報を使用して Developer for System z のさまざまなインスタンスの共存を計画してください。その後、この構成ガイドを使用して、それらのインスタンスをカスタマイズすることができます。
このセクションは、Secure Socket Layer (SSL) のセットアップ時、または既存のセットアップの検査時や変更時に発生する可能性があるいくつかの一般的な問題に関して、ユーザーを支援するためのものです。また、このセクションには、X.509 証明書を使用したユーザー自身の認証をサポートする、サンプルのセットアップも記載されています。
このセクションは、TCP/IP のセットアップ時、または既存のセットアップの検査時や変更時に発生する可能性があるいくつかの一般的な問題に関して、ユーザーを支援するためのものです。
Developer for System z ホストは、クライアントがホスト・サービスとデータにアクセスできるようにするために相互に作用する、複数のコンポーネントで構成されています。 これらのコンポーネントの設計を理解しておくと、構成に関して適切な判断を行うことができます。
前の段落とリストで説明したのは、RSE に割り当てられている中心的な役割です。わずかな例外を除き、クライアント通信はすべて RSE を経由します。これにより、クライアント/ホスト通信に使用されるポートの数が限定されるため、セキュリティーに関連したネットワーク・セットアップが容易になります。
クライアントからの接続とワークロードを管理するために、RSE は、スレッド・プーリング・アドレス・スペースを制御するデーモン・アドレス・スペースから構成されています。デーモンは接続と管理のためのフォーカル・ポイントとして機能し、スレッド・プールはクライアント・ワークロードを処理します。rsed.envvars 構成ファイルに定義されている値と実際のクライアント接続数に基づいて、デーモンは複数のスレッド・プール・アドレス・スペースを開始することができます。
図 2 は、RSE によるリソースの使用 (プロセスとストレージ) を基本的な図で示しています。
RSE は Java™ アプリケーションであるため、z/OS UNIX 環境でアクティブになります。このため、異なるホスト・プラットフォームへの移植が容易であり、同じく Java アプリケーションである (Eclipse フレームワーク・ベース) Developer for System z クライアントと簡単に通信することができます。したがって、z/OS UNIX および Java の仕組みに関する基本的な知識があると、Developer for System z を理解するうえで非常に役立ちます。
z/OS UNIX では、プログラムが PID (プロセス ID) で識別されるプロセス内で実行されます。各プログラムはそのプログラム専用のプロセス内でアクティブになるため、別のプログラムを呼び出すと新しいプロセスが作成されます。プロセスを開始したプロセスは、PPID (親 PID) で参照され、新しいプロセスは子プロセスと呼ばれます。子プロセスは同じアドレス・スペース内で実行することも、新しいアドレス・スペースで spawn (作成) することもできます。同じアドレス・スペースで新しいプロセスを実行することは、TSO でコマンドを実行することに相当し、新しいアドレス・スペースでプロセスを spawn することは、バッチ・ジョブを実行依頼することと似ています。
プロセスは、単一スレッドの場合とマルチスレッドの場合があるので注意してください。マルチスレッド・アプリケーション (RSE など) では、個別のアドレス・スペースのとき (より少ないオーバーヘッドによる) と同様に、個々のスレッドがシステム・リソースを得ようと競合します。
RSE は、31 ビットまたは 64 ビットのアドレッシング・モードで実行できるため、それぞれでストレージ限度も異なります。31 ビット・モードで使用可能なストレージの限度は 2 GB であり、64 ビット・モードでは、SYS1.PARMLIB で指定しない限り、限度はありません。
RSE などの Java アプリケーションは、ストレージを直接割り振るのではなく、Java メモリー管理サービスを使用します。これらのサービスは、ストレージの割り振り、ストレージの解放、およびガーベッジ・コレクションと同様に、Java ヒープの限度内で機能します。ヒープの最小サイズと最大サイズは、Java 始動時に (暗黙的または明示的に) 定義されます。64 ビット・モードで実行中の場合、Java は、境界より下のスペースを解放して、2 GB 境界より上のヒープを割り振ろうとします。
つまり、使用可能なアドレス・スペース・サイズを最大限に活用することは、z/OS 用に不定量 (アクティブなスレッド数に依存します) のシステム制御ブロックを保管できる余裕を確保しながら、大きなヒープ・サイズを定義するというバランスを考慮した両立案になります。
図 3 は、Developer for System z のさまざまなタスクで使用されるセキュリティー資格情報の所有者の基本的概要を示しています。
タスクの所有権は、2 つの部分に分けることができます。開始タスクは、ご使用のセキュリティー・ソフトウェアで開始タスクに割り当てられているユーザー ID が所有します。それ以外のすべてのタスク (RSE スレッド・プール (RSEDx) は例外) は、クライアント・ユーザー ID が所有します。
図 3 は、Developer for System z の開始タスク (DBGMGR、JMON、および RSED) およびサンプルの開始タスクと、Developer for System z が通信するシステム・サービスを示しています。 Application Deployment Manager (ADM) が CICS 領域内でアクティブになっています。USS REXEC タグは、z/OS UNIX REXEC (または SSH) サービスを表します。
RSE デーモン (RSED) は、クライアント要求を処理するために RSE スレッド・プール・アドレス・スペース (RSEDx) を 1 つ以上作成します。各 RSE スレッド・プールは、複数のクライアントをサポートし、RSE デーモンと同じユーザーによって所有されます。各クライアントには、スレッド・プール内に専用のスレッドがあり、これらのスレッドはクライアント・ユーザー ID が所有します。
クライアントが実行するアクションによっては、1 つ以上の追加のアドレス・スペース (いずれもクライアント・ユーザー ID が所有) を開始して要求されたアクションを実行できます。これらのアドレス・スペースにできるのは、MVS バッチ・ジョブ、APPC トランザクション、または z/OS UNIX 子プロセスです。z/OS UNIX 子プロセスは、z/OS UNIX イニシエーター (BPXAS) 内でアクティブとなり、JES では開始タスクとして表示されることに注意してください。
これらのアドレス・スペースの作成は、ほとんどの場合、スレッド・プール内のユーザー・スレッドによって、直接的に、あるいは ISPF などのシステム・サービスを使用してトリガーされます。ただし、アドレス・スペースはサード・パーティーが作成する可能性もあります。例えば、z/OS UNIX でビルドを開始する際には、z/OS UNIX REXEC または SSH が関与します。
ユーザー固有のアドレス・スペースは、タスクが完了するか、または非アクティブ・タイマーの期限が切れると終了します。開始タスクはアクティブなままとなります。 図 3 に示されているアドレス・スペースは、表示の対象となるほど長くシステムに残ります。ただし、z/OS UNIX の設計仕様のために、存続期間の短い一時的なアドレス・スペースもいくつか存在することに注意してください。
上記の説明は、RSE のスレッド指向の設計を示しています。ユーザー単位でアドレス・スペースを開始するのではなく、複数のユーザーが単一のスレッド・プール・アドレス・スペースでサービスされます。スレッド・プール内では、各マイナー (ユーザー固有のサービス) が、ユーザーのセキュリティー・コンテキストが割り当てられたそのマイナー専用のスレッドでアクティブとなるため、セキュアなセットアップが確保されます。この設計は、リソース使用量を制限しながら多数のユーザーに対応しますが、各クライアントが複数のスレッド (実行されるタスクによっては 17 以上) を使用することを実際には意味しています。
認証を必要とするすべての z/OS サービスに PassTicket が使用されるので、Developer for System z は、パスワードを保管したりユーザーに毎回パスワードを要求したりすることなく、これらのサービスを呼び出すことができます。また、すべての z/OS サービスに PassTicket を使用することで、ログオン時にワンタイム・パスワードや X.509 証明書などの代替認証方式を使用することもできます。
Developer for System z は CARMA サーバーを始動する複数の方式をサポートしています。 それぞれの方式には利点と欠点があります。Developer for System z も、複数の Repository Access Manager (RAM) を提供します。これらは実動 RAM とサンプル RAM という 2 つのグループに分けられます。 事前構成されたセットアップとして、 RAM とサーバー始動方式のさまざまな組み合わせが可能です。
すべてのサーバー始動方式は共通の構成ファイル CRASRV.properties を共有します。このファイルは (特に) どの始動方式を使用するかを指定します。
「CRASTART」方式は、CARMA サーバーを RSE 内のサブタスクとして始動します。この方式では、CARMA サーバーを始動するために必要なデータ・セット割り振りとプログラム呼び出しを別個の構成ファイルで定義し、その構成ファイルを使用するので、非常に柔軟なセットアップが可能です。この方式では最良のパフォーマンスが得られ、使用するリソースも最少で済みますが、モジュール CRASTART を LPA 内に配置する必要があります。
RSE は、ロード・モジュール CRASTART を呼び出します。これは crastart*.conf の定義を使用してバッチ TSO と ISPF コマンドを実行するのに有効な環境を作成します。 Developer for System z はこの環境を使用して、CARMA サーバー CRASERV を稼働させます。Developer for System z は複数の crastart*.conf ファイルを提供します。これらのファイルは、それぞれ特定の RAM 用に事前構成されています。
「バッチ実行依頼」方式は、ジョブを実行依頼することによって CARMA サーバーを始動します。これが、提供されたサンプル構成ファイルで使用されるデフォルトの方式です。この方式の利点は、ジョブ出力内で CARMA ログに簡単にアクセスできることです。また、開発者自身が保守する開発者ごとのカスタム・サーバー JCL を使用できます。ただし、この方式では、CARMA サーバーを始動した開発者ごとに 1 つずつ JES イニシエーターが使用されます。
RSE は CLIST CRASUB* を呼び出します。これは次に組み込み JCL を実行依頼して、バッチ TSO と ISPF コマンドを実行するのに有効な環境を作成します。 Developer for System z はこの環境を使用して、CARMA サーバー CRASERV を実行します。Developer for System z は、複数の CRASUB* メンバーを提供します。これらのメンバーは、それぞれ特定の RAM 用に事前構成されています。
複数のユーザーが単一のスレッド・プール・アドレス・スペースに割り当てられる、Developer for System z のシングル・サーバー・セットアップでは、z/OS が「DISPLAY GRS,RES=(*,dataset*)」オペレーター・コマンドを使用してデータ・セットまたはメンバーに設定されているロックの所有者を追跡できません。システム・コマンドはアドレス・スペース・レベル、つまりスレッド・プールで停止します。
この問題に対処する方法として、「ホスト構成ガイド」(SC88-5663) の『オペレーター・コマンド』で説明されているように、Developer for System z は「MODIFY rsed APPL=DISPLAY OWNER,DATASET=dataset」オペレーター・コマンドを提供します。オペレーター・コマンドは、RSE ユーザーがデータ・セットおよびメンバーに設定したすべてのロック、および ISPF などの他の製品が設定したロックを解決できます。
通常の環境では、データ・セットまたはメンバーは、クライアントが編集モードでオープンしたときにロックされ、クライアントが編集セッションを終了したときに解放されます。
一定のエラー条件によって、このメカニズムが設計どおりに機能しなくなることがあります。この場合は、ロックを保持しているユーザーを RSE の modify cancel オペレーター・コマンドで取り消すことができます。これについては 「ホスト構成ガイド」 (SC88-5663)の『オペレーター・コマンド』で説明しています。このユーザーに属しているアクティブなデータ・セット・ロックが、プロセスの中で解放されます。
図 8 は、Developer for System z が使用する z/OS UNIX ディレクトリーの概要を示しています。以下のリストでは、Developer for System z が関与する各ディレクトリー、ロケーションの変更方法、および内部のデータを保守する当事者について説明します。
/var/rdz/pushtoclient/ 内のデータは、z/OS UNIX で多数の更新特権を持たない可能性のあるプロジェクト・マネージャーなどの非システム管理者によって保守されます。したがって、実際的だがセキュアなセットアップを確実に行うために、z/OS UNIX において、ファイル作成時にどのようにアクセス権限が設定されるのかを理解することが重要です。
UNIX 標準では、所有者、グループ、およびその他という 3 つのタイプのユーザーに対して権限を設定できることが定められています。 読み取り権限、書き込み権限、および実行権限は、各タイプに対して個別に設定できます。
各サイトでは、それぞれ独自のデフォルト・アクセス許可マスクを設定できますが、共通マスクは、所有者に読み取り権限と書き込み権限を許可し、グループとその他のユーザーに読み取り権限を許可します。
/var/rdz/pushtoclient/ 内のデータは、pushtoclient.properties の file.permission ディレクティブに定義されたアクセス許可マスクを使用して作成されます。デフォルト値では、所有者とグループに対して読み取り権限と書き込み権限が許可され、その他のユーザーに読み取り権限が許可されます。すべてのユーザーが実行権限を持ちます。最終的なアクセス権限では、すべてのユーザーに対し読み取り権限と実行権限を許可し、データを保守する Developer for System z クライアント管理者にはさらに書き込み権限を許可する必要があります。
/var/rdz/pushtoclient/projects/ 内のデータは、特定のアクセス許可マスクを使用せずに作成されます。最終的なアクセス権限では、すべてのユーザーに対し読み取り権限を許可し、データを保守するプロジェクト・マネージャーにはさらに書き込み権限を許可する必要があります。
ADDGROUP RDZPROJ OMVS(GID(1200))
CONNECT IBMUSER GROUP(RDZPROJ)
ALTUSER IBMUSER DFLTGRP(RDZPROJ)
ls -lR /var/rdz/pushtoclient/
chown –R IBMUSER /var/rdz/pushtoclient/
chgrp -R RDZPROJ /var/rdz/pushtoclient/
chmod -R 775 /var/rdz/pushtoclient/
以下のシナリオでは、すべての開発プロジェクト・マネージャーと 3 人のチームが、Developer for System z クライアント管理者の役割を担います。
# chmod 775 /var/rdz/pushtoclient
# ls -ld /var/rdz/pushtoclient
drwxrwxr-x 2 IBMUSER SYS1
/var/rdz/pushtoclient
# chgrp RDZPROJ /var/rdz/pushtoclient
# ls –ld /var/rdz/pushtoclient
drwxrwxr-x 2 IBMUSER RDZPROJ
/var/rdz/pushtoclient
これで、/var/rdz/pushtoclient 書き込み権限をシステム・プログラマー (IBMUSER) とプロジェクト・マネージャー (RDZPROJ) に制限するのに必要なセットアップは終わりです。
Developer for System z では、メインフレーム以外のワークステーション上にいるユーザーがメインフレームにアクセスできます。 このため、接続要求の妥当性検査、ホストとワークステーション間のセキュアな通信の提供、およびアクティビティーの許可と監査が、製品構成の重要な側面となります。
Developer for System z サーバーとサービスが使用するセキュリティー・メカニズムは、それが存在するデータ・セットとファイル・システムがセキュアであることに依存しています。つまり、信頼されたシステム管理者のみがプログラム・ライブラリーと構成ファイルを更新できる状態でなければなりません。
この章では、以下のトピックについて説明します。
Developer for System z の基本的な設計概念については、Developer for System z についてを参照してください。
Developer for System z は、接続時にクライアントが提供するユーザー ID を認証するために、複数の方法をサポートしています。
クライアントは接続時に、ユーザー ID とそれに一致するパスワードを提供します。そのユーザー ID とパスワードは、使用しているセキュリティー製品でのユーザーの認証に使用されます。
ワンタイム・パスワードは、固有のトークンを基に、サード・パーティー製品で生成できます。ワンタイム・パスワードでは、ユーザーが知らないうちに固有のトークンをコピーして使用することはできないため、セキュリティーのセットアップが向上し、またパスワードをインターセプトしても、それは一回限り有効であるため役に立ちません。
クライアントは接続時に、ユーザー ID とワンタイム・パスワードを提供します。このパスワードは、サード・パーティーが提供するセキュリティー出口で、ユーザー ID の認証に使用されます。このセキュリティー出口では、通常の処理時に認証要求を満たすために使用された PassTicket を無視することが見込まれます。 PassTicket は、ご使用のセキュリティー・ソフトウェアによって処理する必要があります。
クライアントは接続時に、ユーザー ID とそれに一致するパスフレーズを提供します。そのユーザー ID とパスフレーズは、使用しているセキュリティー製品でのユーザーの認証に使用されます。
サード・パーティーは、ユーザーの認証に使用できる 1 つ以上の X.509 証明書を提供できます。X.509 証明書を機密保護機能のあるデバイスに保管すると、セキュアなセットアップとユーザーにとっての操作性 (ユーザー ID やパスワードが不要であること) を同時に実現できます。
接続時に、クライアントは選択された証明書と選択された拡張 (オプション) を提供します。これを使用して、ご使用のセキュリティー製品でユーザー ID の認証が行われます。
クライアント認証は、クライアントの接続要求の一環として、RSE デーモン (または REXEC/SSH) によって行われます。ユーザーが認証されると、JES ジョブ・モニターへの自動ログオンも含め、その後のすべての認証要求には、自己生成された PassTicket が使用されます。
JES ジョブ・モニターは、RSE によって提供されたユーザー ID と PassTicket の妥当性検査を行うためには、PassTicket の評価を許可されている必要があります。 これは、以下のことを意味します。
クライアント認証は、クライアントの接続要求の一環として、RSE デーモン (または REXEC/SSH) によって行われます。ユーザーが認証されると、デバッグ・マネージャーへの自動ログオンも含め、その後のすべての認証要求には、自己生成された PassTicket が使用されます。
デバッグ・マネージャーが、RSE から提供されたユーザー ID と PassTicket を妥当性検査するためには、PassTicket を評価できる必要があります。これは、ロード・モジュール AQEZPCM (デフォルトではロード・ライブラリー FEK.SFEKAUTH 内にある) に APF 許可が必要であることを意味します。
クライアント・ベースのデバッグ・エンジンがデバッグ・マネージャーに接続する際には、認証用の有効なセキュリティー・トークンを提示する必要があります。
Developer for System z は一部のサービスの提供を、TN3270 サーバーなどのサード・パーティー製品に依存します。接続セキュリティー・オプションについては、関連する製品資料を参照してください。
システム・プログラマーは、RSE サーバーがクライアントと通信できるポートを指定できます。デフォルトでは、使用可能な任意のポートが使用されます。このポート範囲は、RSE デーモン・ポートとは関係ありません。
RSE を通過するすべての外部 Developer for System z データ・ストリームを、Secure Sockets Layer (SSL) またはトランスポート層セキュリティー (TLS) を使用して暗号化できます。暗号化通信の使用は、SSL/TLS 暗号化通信に説明されているように、ssl.properties 構成ファイル内の設定によって制御されます。rsed.envvars の _RSE_JAVAOPTS ディレクティブの DSTORE_SSL_ALGORITHM 変数によって、SSL とその後継の TLS を暗号化方式として選択できます。詳しくは、「ホスト構成ガイド」(SC88-5663) の『_RSE_JAVAOPTS での追加 Java 始動パラメーターの定義』を参照してください。
クライアントの統合デバッガー・エンジンは、ホスト上のデバッグ・マネージャーに接続します。SSL または TLS の使用は Application Transparent TLS (AT-TLS) ポリシーによって制御されます。
クライアント上の Host Connect Emulator は、ホスト上の TN3270 サーバーに接続します。SSL または TLS の使用は TN3270 によって制御されます。これについては、「Communications Server IP 構成ガイド」(SC88-8926) に説明があります。
z/OS UNIX サブプロジェクトのリモート (ホスト・ベースの) アクションでは、ホスト上の REXEC サーバーまたは SSH サーバーを使用します。SSH 通信は常に SSL を使用して暗号化します。
Application Deployment Manager クライアントは、CICS TS Web サービスまたは RESTful インターフェースを使用して、Application Deployment Manager ホスト・サービスを起動します。SSL の使用は、CICS TS によって制御されます。これについては、「RACF Security Guide for CICS TS」に説明があります。
Developer for System z は Port Of Entry (POE) 検査をサポートしています。これにより、ホストは信頼できる TCP/IP アドレスにのみアクセスできます。POE の使用は、Port Of Entry (POE) 検査で説明されているように、セキュリティー・ソフトウェア内の特定のプロファイルの定義と、rsed.envvars 内の enable.port.of.entry ディレクティブによって制御されます。
POE をアクティブにすると、POE 検査をサポートしている他の TCPIP アプリケーション (INETD など) に影響が出ることに注意してください。
ログオン後、PassTicket を使用して RSE サーバー内のスレッドのセキュリティーが確立されます。このフィーチャーを使用不可にすることはできません。PassTicket は、有効期間が約 10 分のシステム生成パスワードです。生成される PassTicket は、DES 暗号化アルゴリズム、ユーザー ID、アプリケーション ID、時刻と日付のスタンプ、および秘密鍵に基づいています。この秘密鍵は 64 ビットの数値 (16 個の 16 進文字) で、これは、使用するセキュリティー・ソフトウェアに対して定義されている必要があります。さらなるセキュリティーのために、z/OS セキュリティー・ソフトウェアは 1 回限りのパスワードとして、デフォルトで PassTicket を処理します。
クライアントの実際のパスワードは、初期認証後は不要になります。SAF 準拠のセキュリティー製品は、PassTicket と正規のパスワードのどちらも評価できるからです。RSE サーバーはパスワードが必要になるたびに、PassTicket を生成して使用します。その結果、PassTicket はクライアントの (一時的に) 有効なパスワードになります。
PassTicket を使用すると、RSE はユーザー固有のセキュリティー環境を任意にセットアップでき、すべてのユーザーの ID とパスワードをテーブルに保管する (これはセキュリティーを脅威にさらす可能性があります) 必要がなくなります。また、X.509 証明書など、再使用可能なパスワードを使用しないクライアント認証方式も使用できるようになります。
PassTicket を使用できるようにするには、APPL クラスと PTKTDATA クラスのセキュリティー・プロファイルが必要です。これらのプロファイルはアプリケーション固有のものであるため、現在使用しているシステムのセットアップに影響を及ぼしません。
PassTicket がアプリケーション固有のものであることは、RSE と JES ジョブ・モニターの両方が、同じアプリケーション ID (APPLID) を使用する必要があることを意味します。 デフォルトでは、どちらのサーバーも FEKAPPL を APPLID として使用しますが、これは変更でき、そのためには、RSE の場合は rsed.envvars 内で、JES ジョブ・モニターの場合は FEJJCNFG 内で、それぞれ APPLID ディレクティブを使用します。
OMVSAPPL はアプリケーション ID として使用しないでください。これは、大部分の z/OS UNIX アプリケーションの秘密鍵を公開するからです。また、デフォルトの MVS アプリケーション ID (MVS の直後にシステムの SMF ID を続けたもの) も使用しないでください。これは、大部分の MVS アプリケーション (ユーザー・バッチ・ジョブを含む) の秘密鍵を公開するからです。
PassTicket のタイム・スタンプの最小単位は 1 秒です。つまり、同一のアプリケーションが同一のユーザー ID に対して 1 秒以内に生成する PassTicket はすべて同じになるということです。このため、1 回限りのパスワードとして PassTicket を処理する z/OS セキュリティー・ソフトウェアと組み合わされると、複数の PassTicket が 1 秒以内に要求されることになるので、ログオン中に Developer for System z に問題が発生します。したがって、Developer for System z では、生成された PassTicket の再利用を許可するフラグを PassTicket 定義に設定する必要があります。
重要: PassTicket が正しくセットアップされていないと、クライアントの接続要求は失敗します。
|
Developer for System z は、RSE デーモンによって管理されるアクションの監査ロギングをサポートしています。監査ログは、CSV (コンマ区切り値) 形式のテキスト・ファイルとしてデーモン・ログ・ディレクトリーに保管されます。
modify switch オペレーター・コマンドを使用して、 「ホスト構成ガイド」 (SC88-5663)の『オペレーター・コマンド』の説明にあるように、新しい監査ログ・ファイルに手動で切り替えることができます。
監査ログ・ファイルを保持しているファイル・システムのフリー・スペースが少なくなった場合は、コンソールへ警告メッセージが送信されます。このコンソール・メッセージ (FEK103E) は、スペース不足の問題が解決されるまで定期的に繰り返されます。
新しい監査ログ・ファイルは、あらかじめ定められた時間が経過した後、または modify switch オペレーター・コマンドが発行されたときに開始されます。古いログ・ファイルは、audit.log.yyyymmdd.hhmmss として保存されます。ここで、yyyymmdd.hhmmss は、そのログが閉じられたときの日付/タイム・スタンプです。ファイルへ割り当てられたシステム日付/タイム・スタンプは、ログ・ファイルの作成を示しています。これら 2 つの日付の組み合わせが、この監査ログ・ファイルの記録期間を示しています。
rsed.envvars の audit.action* ディレクティブを使用すると、監査ログが閉じられたときに RSE によって呼び出されるユーザー出口 (z/OS UNIX シェル・スクリプト、z/OS UNIX REXX、または z/OS UNIX プログラム) を指定できます。このユーザー出口では、監査ログ内のデータを処理できます。
監査ログ・ファイルの許可ビット・マスクは、rsed.envvars の audit.log.mode ディレクティブで変更されていない場合は、640 (-rw-r-----) に設定されています。 これは、所有者 (RSE デーモン z/OS UNIX uid) が読み取りアクセス権と書き込みアクセス権を持ち、所有者の (デフォルト) グループが読み取りアクセス権を持つことを意味します。それ以外のアクセスの試みは、すべて拒否されます。ただし、スーパーユーザー (UID 0) または UNIXPRIV セキュリティー・クラスの SUPERUSER.FILESYS プロファイルに対する十分な権限を持つユーザーが試みた場合を除きます。
yyyy/mm/dd hh:mm:ss.sss,userid,action,dataset_name[,returncode]
[,additional_information]]
yyyy/mm/dd hh:mm:ss.sss,userid,action,dataset_name,returncode,create%nmodify%n…
Developer for System z では、クライアントは JES ジョブ・モニターを通じて JES スプールにアクセスできます。サーバーは基本的なアクセス制限を行い、この制限は、ご使用のセキュリティー製品の標準スプール・ファイル保護フィーチャーによって拡張できます。スプール・ファイルに対するオペレーター・アクション (「保留」、「保留解除」、「キャンセル」、および「パージ」) は EMCS コンソールを通じて行われ、このコンソールについて、条件付きの許可をセットアップする必要があります。
JES ジョブ・モニターは、Developer for System z ユーザーに JES スプールへのフル・オペレーター・アクセスを提供するわけではありません。保留、保留解除、キャンセル、パージの各コマンドのみが使用可能で、しかも、デフォルトでは、そのユーザーが所有しているスプール・ファイルの場合だけです。コマンドは、クライアント・メニュー構造で該当するオプションを選択することによって発行されます (コマンド・プロンプトはありません) 。コマンドのスコープは、セキュリティー・プロファイルを使用してコマンドの使用対象となるジョブを定義することにより、広げることができます。
SDSF の SJ アクション文字と同じように、JES ジョブ・モニターは「JCL の表示」コマンドもサポートしています。このコマンドは、選択されたジョブ出力を作成した JCL を取り出して、エディター・ウィンドウに表示します。JES ジョブ・モニターは JES から JCL を取り出せるので、元の JCL メンバーを容易に見つけることができない状況で役立ちます。
アクション | JES2 | JES3 |
---|---|---|
保留 | $Hx(jobid) x = {J、S、または T} |
*F,J=jobid,H |
保留解除 | $Ax(jobid) x = {J、S、または T} |
*F,J=jobid,R |
キャンセル | $Cx(jobid) x = {J、S、または T} |
*F,J=jobid,C |
パージ | $Cx(jobid),P
x = {J、S、または T} |
*F,J=jobid,C |
JCL の表示 | 適用外 | 適用外 |
表 1 にリストした使用可能な JES コマンドは、デフォルトでは、そのユーザーが所有しているジョブだけに制限されます。これは、「ホスト構成ガイド」 (SC88-5663) の『FEJJCNFG、JES ジョブ・モニター構成ファイル』で説明されているように、LIMIT_COMMANDS ディレクティブを使用して変更できます。
ジョブ所有者 | ||
---|---|---|
LIMIT_COMMANDS | ユーザー | その他 |
USERID (デフォルト) | 許可される | 許可されない |
LIMITED | 許可される | セキュリティー・プロファイルによって明示的に許可された場合にのみ許可される |
NOLIMIT | 許可される | セキュリティー・プロファイルによって許可された場合、または JESSPOOL クラスがアクティブでない場合は許可される |
JES は、JESSPOOL クラスを使用して SYSIN/SYSOUT データ・セットを保護します。 SDSF と同じように、JES ジョブ・モニターは JESSPOOL クラスの用途を拡張し、ジョブ・リソースの保護も行います。
コマンド | JESSPOOL プロファイル | 必要なアクセス権 |
---|---|---|
保留 | nodeid.userid.jobname.jobid | ALTER |
保留解除 | nodeid.userid.jobname.jobid | ALTER |
キャンセル | nodeid.userid.jobname.jobid | ALTER |
パージ | nodeid.userid.jobname.jobid | ALTER |
JCL の表示 | nodeid.userid.jobname.jobid.JCL | READ |
nodeid | ターゲット JES サブシステムの NJE ノード ID |
userid | ジョブ所有者のローカル・ユーザー ID |
jobname | ジョブの名前 |
jobid | JES ジョブ ID |
JESSPOOL クラスがアクティブでない場合、LIMIT_COMMANDS の LIMITED および NOLIMIT 値の動作は、「ホスト構成ガイド」 (SC88-5663) の『FEJJCNFG、JES ジョブ・モニター構成ファイル』の表『LIMIT_COMMANDS コマンド許可マトリックス』の説明のように異なります。 JESSPOOL がアクティブの場合、動作は同じです。クラスは、デフォルトでは、プロファイルが定義されていなければ許可を拒否するからです。
許可されたターゲットを指定した後の、JES スプール・コマンド・セキュリティーの第 2 フェーズには、オペレーター・コマンドを実際に実行するために必要な許可が含まれます。この実行許可は、z/OS および JES のセキュリティー検査によって行われます。
「JCL の表示」は、他の JES ジョブ・モニター・コマンド (「保留」、「保留解除」、「キャンセル」、および「パージ」) のようなオペレーター・コマンドでないため、次のリストに挙げる制限が (それ以上のセキュリティー検査が存在しないので) 適用されないことに注意してください。
JES ジョブ・モニターは、ユーザーが要求したすべての JES オペレーター・コマンドを、拡張 MCS (EMCS) コンソールを通じて発行します。このコンソールの名前は、「ホスト構成ガイド」 (SC88-5663) の『FEJJCNFG、JES ジョブ・モニター構成ファイル』の説明にあるように、CONSOLE_NAME ディレクティブによって制御されます。
JES ジョブ・モニターを使用すると、LIMIT_CONSOLE ディレクティブを使用して EMCS コンソールに付与する権限の程度を定義できます。この説明は、「ホスト構成ガイド」(SC88-5663) の『FEJJCNFG - JES ジョブ・モニター構成ファイル』に説明されています。
LIMIT_CONSOLE | OPERCMDS クラス内のアクティブなプロファイル | OPERCMDS クラス内のアクティブでないプロファイル |
---|---|---|
LIMITED (デフォルト) | 許可される (セキュリティー・プロファイルで許可されている場合) | 許可されない |
NOLIMIT | 許可される (セキュリティー・プロファイルで許可されている場合) | 許可される |
TSO セッションから JMON コンソールを作成することによって JES ジョブ・モニター・サーバーの ID を装うことは、セキュリティー・ソフトウェアによって防止されます。コンソールを作成できる場合でも、(JES ジョブ・モニターと TSO とでは) 入り口点が異なります。この資料で説明されているとおりにセキュリティーがセットアップされており、ユーザーが他の手段によって JES コマンドに対する権限を持っていない場合は、そのコンソールから発行された JES コマンドはセキュリティー検査で不合格になります。
オペレーター・コマンド保護の詳細については、「Security Server RACF セキュリティー管理者のガイド」(SA88-8613) を参照してください。
JES ジョブ・モニターは、デフォルトでは、すべてのスプール・ファイルへの参照アクセスを許可します。これは、「ホスト構成ガイド」 (SC88-5663) の『FEJJCNFG、JES ジョブ・モニター構成ファイル』で説明されているように、LIMIT_VIEW ディレクティブを使用して変更できます。
ジョブ所有者 | ||
---|---|---|
LIMIT_VIEW | ユーザー | その他 |
USERID | 許可される | 許可されない |
NOLIMIT (デフォルト) | 許可される | セキュリティー・プロファイルによって許可された場合、または JESSPOOL クラスがアクティブでない場合は許可される |
ユーザーを JES スプール上のそのユーザー自身のジョブだけに制限するには、JES ジョブ・モニター構成ファイル FEJJCNFG で "LIMIT_VIEW=USERID" ステートメントを定義します。 すべてのジョブではありませんが、より広範囲のジョブへのアクセスをユーザーが必要とする場合は、使用しているセキュリティー製品の標準スプール・ファイル保護フィーチャー、例えば、JESSPOOL クラスなどを使用します。
さらに保護を定義するときは、JES ジョブ・モニターがスプールへのアクセスに SAPI (SYSOUT アプリケーション・プログラム・インターフェース) を使用することに留意してください。これは、ユーザーが単にブラウズ機能を使用するだけでも、最低限、スプール・ファイルに対する UPDATE アクセス権が必要になることを意味します。この必要条件は、z/OS 1.7 (JES3 の場合は z/OS 1.8) 以上を実行している場合には適用されません。この場合、ブラウズ機能を使用するには、READ 権限で十分です。
JES スプール・ファイルの保護の詳細については、「Security Server RACF セキュリティー管理者のガイド」(SA88-8613) を参照してください。
RSE を使用した外部 (クライアント/ホスト) 通信を、SSL (Secure Sockets Layer) またはトランスポート層セキュリティー (TLS) を使用して暗号化できます。このフィーチャーは、デフォルトでは使用不可に設定され、ssl.properties 内の設定によって制御されます。 「ホスト構成ガイド」 (SC88-5663) の『(オプション) ssl.properties、RSE SSL 暗号』を参照してください。
RSE デーモンおよび RSE サーバーは、両者間のアーキテクチャーの違いから、証明書の保管に関して異なるメカニズムをサポートしています。これは、RSE デーモンと RSE サーバーの両方に SSL 定義と証明書が必要であることを意味しています。RSE デーモンと RSE サーバーが同じ証明書管理方式を使用する場合は、共用証明書を使用できます。
証明書ストレージ | 作成者および管理者 | RSE デーモン | RSE サーバー |
---|---|---|---|
鍵リング | SAF 準拠のセキュリティー製品 | サポート | サポート |
鍵データベース | z/OS UNIX の gskkyman | サポート | / |
鍵ストア | Java の keytool | / | サポート |
SAF 準拠の鍵リングでは、証明書の秘密鍵が、セキュリティー・データベースに保管されるか、または System z 暗号化ハードウェアとのインターフェースである ICSF (Integrated Cryptographic Service Facility) を使用して保管されます。
ICSF は、非 ICSF の秘密鍵管理よりもセキュアなソリューションであるため、デジタル証明書に関連する秘密鍵の保管には ICSF の使用をお勧めします。ICSF では、確実に、秘密鍵が ICSF マスター・キーで暗号化され、かつその秘密鍵へのアクセスが CSFKEYS および CSFSERV セキュリティー・クラスの一般リソースによって制御されます。さらに、ICSF はハードウェア Cryptographic Coprocessor (暗号化コプロセッサー) を使用するため、操作上のパフォーマンスが向上します。ICSF の詳細と、暗号鍵およびサービスの使用者を制御する方法については、「Cryptographic Services ICSF Administrator's Guide」(SA22-7521) を参照してください。
RSE デーモンは、System SSL の機能を使用して SSL 暗号化通信を管理します。 これは SYS1.SIEALNKE が、ご使用のセキュリティー・ソフトウェアによってプログラム制御されることが必要で、LINKLIST または rsed.envvars 内の STEPLIB ディレクティブを介して RSE から使用可能でなければならないことを意味しています。
rsed.envvars の _RSE_JAVAOPTS ディレクティブの DSTORE_SSL_ALGORITHM 変数によって、SSL とその後継の TLS を暗号化方式として選択できます。詳しくは、「ホスト構成ガイド」(SC88-5663) の『_RSE_JAVAOPTS での追加 Java 始動パラメーターの定義』を参照してください。
Developer for System z 用に SSL をアクティブにする方法について詳しくは、SSL および X.509 認証のセットアップを参照してください。
デフォルトでは、RSE デーモンは、サポートされる暗号化プロトコルおよび暗号スイートの定義に関して System SSL のデフォルトに依存しています。 これらのデフォルトは、rsed.envvars に GSK_PROTOCOL_* および GSK_V3_CIPHER_SPECS* 環境変数を指定することによって変更できます。 これらの環境変数については、「Cryptographic Services System SSL プログラミング」(SD88-6252) を参照してください。
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Direction Inbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef RDz_Debug_Manager
}
TTLSEnvironmentAction RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Keyring dbgmgr.racf # Keyring must be owned by the Debug Manager
}
}
TTLSGroupAction grp_Production
{
TTLSEnabled On
Trace 2
}
RSE デーモンは、X.509 証明書で自分自身を認証するユーザーをサポートしています。この機能の場合、SSL 暗号化通信の使用は前提条件です。この機能は、SSL で使用される証明書でのホスト認証を拡張したものだからです。
RSE デーモンは、クライアント証明書の妥当性を検査することによって、クライアント認証プロセスを開始します。検査される重要な点は、証明書が有効である日付、および、証明書の署名に使用された認証局 (CA) の信頼性などです。オプションとして、(サード・パーティーの) 証明書失効リスト (CRL) を調べることもできます。
RSE デーモンが証明書の妥当性を検査した後、認証のために証明書が処理されます。証明書は、rsed.envvars ディレクティブの enable.certificate.mapping が false に設定されている場合を除き、使用しているセキュリティー製品へ渡され、その時点で RSE デーモンは認証を行います。
認証プロセスが成功した場合、そのユーザー ID をこのセッションに使用することが決定され、その後、RSE デーモンはユーザー ID をテストし、RSE デーモンが稼働しているホスト・システム上で使用可能であるかどうかを確認します。
最終検査 (X.509 証明書だけでなく、すべての認証メカニズムで行われます) では、ユーザー ID が Developer for System z の使用を許可されていることが検証されます。
TCP/IP が使用する SSL セキュリティー区分に詳しければ、上記の検証ステップの組み合わせが「レベル 3 クライアント認証」仕様 (使用可能な最高レベル) に相当することがわかるはずです。
証明書の妥当性検査の一環として、証明書にユーザーの信頼する証明局 (CA) の署名があるかどうかが検査されます。 それを行うために、RSE デーモンは CA を識別する証明書にアクセスできなければなりません。
SSL 接続に gskkyman 鍵データベースを使用している場合は、鍵データベースに CA 証明書を追加する必要があります。
RACDCERT コマンドの詳細については、「Security Server RACF コマンド言語解説書」(SA88-8617) を参照してください。
重要: セキュリティー・ソフトウェアではなく RSE デーモンでユーザーを認証する場合は、SAF 鍵リングまたは gskkyman 鍵データベース内で TRUST 状況と HIGHTRUST 状況の CA が混在しないように注意する必要があります。RSE デーモンは、この 2 つを区別できないので、TRUST 状況の CA によって署名された証明書がユーザー ID 認証用に有効になります。 |
これらの環境変数、および z/OS System SSL によって使用されるその他の環境変数の詳細については、「Cryptographic Services System SSL (Secure Sockets Layer) プログラミング」(SD88-6252) を参照してください。
RACF は、いくつかの検査を行って証明書を認証し、関連するユーザー ID を返します。他のセキュリティー製品では、これが異なる方法で行われる場合があることに注意してください。認証 (照会モード) を行うために使用される initACEE 機能の詳細については、使用しているセキュリティー製品の資料を参照してください。
RACDCERT ID(userid) ADD(dsn) TRUST WITHLABEL('label')
id-ce-hostIdMappings OBJECT IDENTIFIER::= {1 3 18 0 2 18 1}
HostIdMappings::= SET OF HostIdMapping
HostIdMapping::= SEQUENCE{
hostName IMPLICIT[1] IA5String,
subjectId IMPLICIT[2] IA5String,
proofOfIdPossession IdProof OPTIONAL
}
IdProof::= SEQUENCE{
secret OCTET STRING,
encryptionAlgorithm OBJECT IDENTIFIER
}
X.509 証明書、RACF によるその管理方法、および証明書名フィルターの定義方法について詳しくは、「Security Server RACF セキュリティー管理者のガイド」(SA88-8613) を参照してください。 RACDCERT コマンドの詳細については、「Security Server RACF コマンド言語解説書」(SA88-8617) を参照してください。
Developer for System z では、ご使用のセキュリティー製品に依存せずに基本的な X.509 証明書認証を行うことができます。RSE デーモンによって行われる認証では、ユーザー ID とホスト名が証明書拡張内で定義されている必要があり、しかも、rsed.envvars 内の enable.certificate.mapping ディレクティブが FALSE に設定されている場合にのみ、認証がアクティブになります。
この機能は、使用しているセキュリティー製品が X.509 証明書に基づいたユーザーの認証をサポートしていない場合、または、使用しているセキュリティー製品によって行われるテストに証明書が合格できない場合 (例えば、証明書の HostIdMappings 拡張の ID に誤りがあり、DIGTCERT 内に名前フィルターや定義がない場合) に使用するためのものです。
クライアントはユーザーに対し、使用すべき拡張 ID (OID) を照会し、その ID は、デフォルトでは HostIdMappings OID の {1 3 18 0 2 18 1} です。
RSE デーモンは HostIdMappings 拡張のフォーマットを使用して、そこからユーザー ID とホスト名を抽出します。このフォーマットについては、使用しているセキュリティー・ソフトウェアによる認証に説明があります。
重要: RSE デーモンに既知のすべての CA を「高度に信頼できる」ものと保証するのは、セキュリティー管理者の責任です。RSE デーモンはクライアント証明書の署名者が「高度に信頼できる」か単なる「信頼できる」かを検査できないからです。アクセス可能な CA 証明書の詳細については、認証局 (CA) の妥当性検査を参照してください。
|
POE 検査を使用したネットワーク・アクセス制御の詳細については、「Communications Server IP 構成ガイド」(SC88-8926) を参照してください。
Developer for System z クライアント・バージョン 8.5.1 以降は、SAF セキュリティー・プロファイルのアクセス権限をチェックでき、結果に基づいてユーザーに対し、関連する関数の有効化または無効化を行います。
Developer for System z は、ユーザーに対してどのオプションを有効または無効にするかを決定するため、表 7 にリストされているプロファイルに対してアクセス権限を検証します。
FACILITY プロファイル | 固定長 | 必要なアクセス権 | 結果 |
---|---|---|---|
FEK.USR.OFF.REMOTECOPY.MVS.sysname | 27 | READ | クライアントは、MVS データ・セットのコピーおよび関連した関数を無効にします。 |
sysname の値は、ターゲット・システムのシステム名と一致します。
「固定長」列は、関連するセキュリティー・プロファイルの固定部分の長さについて説明しています。
デフォルトでは、Developer for System z は、FEK.* プロファイルが FACILITY セキュリティー・クラスに存在していると想定します。FACILITY クラス内のプロファイルには 39 文字までの文字数制限があることに注意してください。プロファイルの固定部分 (FEK.USR.<key>) の長さと、プロファイルのサイト固有部分(sysname) の長さの合計がこの制限数を超過する場合は、プロファイルを別のクラス内に置き、代わりにこのクラスを使用するように Developer for System z に指示してください。これを行うには、rsed.envvars にある _RSE_FEK_SAF_CLASS をコメント解除して、適切なクラス名を指定します。
RDEFINE FACILITY (FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT CONTROL')
PERMIT FEK.USR.OFF.REMOTECOPY.MVS.CDFMVS08 CLASS(FACILITY) -
ID(RESTRICT) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
ユーザーが FEK.USR.OFF.REMOTECOPY.MVS.sysname プロファイルの READ アクセス権限を持っている場合、Developer for System z クライアント・バージョン 8.5.1 以降では、MVS データ・セットに対するドラッグ、コピー、別名保存およびオフライン作業ができなくなります。結果として、ユーザーはシステム上のデータ・セットへアクセスできますが、ワークステーション上にデータ・セットのローカル・コピーを作成することはできません。 これは、ローカル・ワークステーションの紛失や盗難があった場合に、機密情報の漏えいを防ぐのに役立ちます。
Developer for System z クライアント・バージョン 8.0.1 以上は、接続時にホストからクライアントの構成ファイルとアップグレード情報を取り出すことができるので、すべてのクライアントの設定が共通になり、最新のものになります。
バージョン 8.0.3 以降、クライアント管理者は、異なる開発者グループのニーズに適合するように、複数のクライアント構成のセットと複数のクライアント更新シナリオを作成できるようになりました。 これにより、ユーザーは、LDAP グループのメンバーシップやセキュリティー・プロファイルに対する許可などの基準に基づいてカスタマイズされたセットアップを受け取れるようになります。
セキュリティー・データベースの定義を選択手段として使用する場合 (pushtoclient.properties のディレクティブに SAF 値が指定されている場合)、Developer for System z は 表 8 にリストされているプロファイルへのアクセス権限を検証して、ユーザーが所属している開発者グループを判別したり、ユーザーが更新の拒否を許可されているかどうかを判別します。
FACILITY プロファイル | 固定長 | 必要なアクセス権 | 結果 |
---|---|---|---|
FEK.PTC.CONFIG.ENABLED. |
23 | READ | クライアントは指定されたグループ用の構成の更新を受諾する |
FEK.PTC.PRODUCT. |
24 | READ | クライアントは指定されたグループ用の製品の更新を受諾する |
FEK.PTC.REJECT.CONFIG. |
30 | READ | ユーザーは構成の更新を拒否できる |
FEK.PTC.REJECT.PRODUCT. |
31 | READ | ユーザーは製品の更新を拒否できる |
devgroup 値は、特定の開発者グループに割り当てられたグループ名と一致します。 グループ名は、Developer for System z クライアントに表示されることに注意してください。
sysname の値は、ターゲット・システムのシステム名と一致します。
「固定長」列は、関連するセキュリティー・プロファイルの固定部分の長さについて説明しています。
デフォルトでは、Developer for System z は、FEK.* プロファイルが FACILITY セキュリティー・クラスに存在していると想定します。FACILITY クラス内のプロファイルには 39 文字までの文字数制限があることに注意してください。プロファイルの固定部分 (FEK.PTC.<key>) の長さと、プロファイルのサイト固有部分 (sysname または sysname.devgroup) の長さの合計が、この制限数を超過する場合は、プロファイルを別のクラス内に置き、代わりにこのクラスを使用するように Developer for System z に指示してください。これを行うには、rsed.envvars にある _RSE_FEK_SAF_CLASS をコメント解除して、適切なクラス名を指定します。
関連するクライアントへのプッシュ・メタデータを定義および管理するために、クライアント管理者は FEK.PTC.*.ENABLED.* プロファイルのアクセス・リストに記載されている必要があります。 これは、グループ・サポートを伴うクライアントへのプッシュを実装するには、(少なくとも) アクセス・リストに記載されたクライアント管理者と一緒に、事前にプロファイルを定義しておく必要がある、ということです。
複数グループのサポートを有効にする方法についての詳細は、「ホスト構成ガイド」(SC88-5663) の『(オプション) pushtoclient.properties、ホスト・ベースのクライアント制御』を参照してください。クライアントへのプッシュの概念と実装について詳しくは、クライアントへのプッシュの考慮事項を参照してください。
デフォルトで、Developer for System z で作成されるログ・ディレクトリーおよびログ・ファイルにセキュア・アクセス権が存在するのは、所有者がアクセス権 (読み取りおよび書き込み) を持っている場合のみです。サーバー (および監査) ログの場合、所有者は RSED 開始タスクのユーザー ID です。ユーザー・ログの場合、所有者は、ログオン時にエンド・ユーザーによって提供されるユーザー ID です。rsed.envvars の log.file.mode ディレクティブを使用して、異なるアクセス権を設定できます。監査ファイルのアクセス権は別個に制御され、rsed.envvars の audit.log.mode ディレクティブによって設定されることに注意してください。
ログ・ディレクトリーに書き込む前に、Developer for System z はファイルの所有権を検証し、別のユーザーがそのファイルを所有している場合には書き込みに失敗します。 この動作はバージョン 9.1.0 の新機能であり、既存のログ・ファイル構造の変更が必要になる場合があります。rsed.envvars の log.secure.mode ディレクティブを使用して、所有権検査を無効にすることができます。
サンプル JCL FEKPBITS を使用して、既存のログ・ファイル・インフラストラクチャーのアクセス権および所有権を変換することができます。FEKPBITS は FEK.#CUST.JCL に置かれます。ただし、FEK.SFEKSAMP(FEKSETUP) ジョブをカスタマイズして実行依頼したときに別のロケーションを指定した場合は除きます。詳しくは、「ホスト構成ガイド」(SC88-5663) の『カスタマイズのセットアップ』を参照してください。
RSED 開始タスクは、Developer for System z ホスト・ログおよびセットアップ情報を収集するために、MODIFY LOGS オペレーター・コマンドをサポートしています。 収集したデータは、z/OS UNIX ファイルである $TMPDIR/feklogs%sysname.%jobname に配置されます。ここで、$TMPDIR は rsed.envvars の TMPDIR ディレクティブの値 (デフォルトは /tmp)、%sysname はご使用の z/OS システムの名前、%jobname は RSED 開始タスクの名前です。
Developer for System z は、セキュリティー製品で FEK.CMD.LOGS.** プロファイルに対するアクセス権を照会し、指定されたログの収集をリクエスターが許可されているかどうかを判別します。 デフォルトでは、リクエスターは RSED 開始タスクのユーザー ID です (OWNER オプションが指定されている場合を除く)。 リクエスターだけが、収集したデータを収容しているファイルに対するアクセス権を保持します。
FACILITY プロファイル | 固定長 | 必要なアクセス権 | 結果 |
---|---|---|---|
FEK.CMD.LOGS.AUDIT.jobname | 19 | READ | リクエスターは、jobname の監査ログを収集できます。 |
FEK,CMD.LOGS.SERVER.jobname | 20 | READ | リクエスターは、jobname のサーバー・ログを収集できます。 |
FEK,CMD.LOGS.USER.userid | 18 | READ | リクエスターは、userid のユーザー・ログを収集できます。 |
FEK,CMD.LOGS.OWNER.userid | 19 | READ | リクエスターは、RSED 開始タスクのユーザー ID から userid に変更されます。 |
jobname の値は、RSED 開始タスクの名前と一致します。userid の値は、有効なユーザー ID と一致します。
「固定長」列は、関連するセキュリティー・プロファイルの固定部分の長さについて説明しています。
デフォルトでは、Developer for System z は、FEK.* プロファイルが FACILITY セキュリティー・クラスに存在していると想定します。FACILITY クラス内のプロファイルには 39 文字までの文字数制限があることに注意してください。 プロファイルの固定部分 (FEK.CMD.LOGS.<key>) の長さと、プロファイルのサイト固有部分 (jobname または userid) の長さの合計がこの制限数を超過する場合は、プロファイルを別のクラス内に置き、代わりにこのクラスを使用するように Developer for System z に指示することができます。 これを行うには、rsed.envvars にある _RSE_FEK_SAF_CLASS をコメント解除して、適切なクラス名を指定します。
アクセス違反は、コンソール・メッセージ FEK302E で報告されます。
以下のサンプル・セキュリティー定義を使用すると、すべてのユーザーがホスト・ログを使用できますが、監査データを収集できるのはグループ SYSPROG だけです。
RDEFINE FACILITY (FEK.CMD.LOGS.**) UACC(READ) -
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - LOGS OPERATOR COMMAND')
RDEFINE FACILITY (FEK.CMD.LOGS.AUDIT.**) UACC(NONE) –
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - LOGS OPERATOR COMMAND')
PERMIT FEK.CMD.LOGS.AUDIT.** CLASS(FACILITY) -
ID(SYSPROG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
MODIFY LOGS オペレーター・コマンドは、RSED 開始タスクのユーザー ID を使用して、ホスト・ログおよびセットアップ情報を収集します。また、デフォルトで、セキュア・ファイル・アクセス権 (所有者のみがアクセス権を保持する) を使用して、ユーザー・ログ・ファイルが作成されます。 セキュア・ユーザー・ログ・ファイルを収集できるようにするには、RSED 開始タスクのユーザー ID が、それらのファイルを読み取る許可を持っていなければなりません。
MODIFY LOGS オペレーター・コマンドの OWNER 引数を指定すると、指定されたユーザー ID が、収集されたデータの所有者になります。所有権を変更するには、RSED 開始タスクのユーザー ID が、CHOWN z/OS UNIX サービスを使用する許可を持っていなければなりません。
RSED 開始タスクのユーザー ID にこれらの許可を適用する方法は 3 つあります。 この 3 つの方法を優先順に示します。
UNIXPRIV クラスは、セキュリティー管理者が、z/OS UNIX に関連したすべての許可をスーパーユーザー方式で付与するのではなく、z/OS UNIX に関連した特別な許可を選択的に割り当てるためのプロファイルを保持しています。
プロファイル | 許可 | 結果 |
---|---|---|
SUPERUSER.FILESYS | READ | すべてのファイルまたはディレクトリーの読み取りがユーザーに許可されています。 |
SUPERUSER.FILESYS.ACLOVERRIDE | READ | ACLOVERRIDE がすでに定義済みの場合にのみ、許可が必要です。許可を受けると、ユーザーは、ACL 定義にかかわらず、すべてのファイルまたはディレクトリーの読み取りを行うことができます。 |
SUPERUSER.FILESYS.CHOWN | READ | すべてのファイルまたはディレクトリーの所有者を変更することがユーザーに許可されています。 |
FACILITY クラスの BPX.SUPERUSER プロファイルに対する READ アクセス権を持っている場合、RSED 開始タスクのユーザー ID は一時的に z/OS UNIX スーパーユーザーになることができ、z/OS UNIX ファイル・アクセス許可にはカウントされません。
RSED 開始タスクのユーザー ID の OMVS セグメントで UID 0 が指定されている場合、これは z/OS UNIX スーパーユーザーであり、z/OS UNIX ファイル・アクセス許可にはカウントされません。 ただし、UID 0 は共有 UID であると思われるため、この方法は推奨されません。他のアクセス権がこの ID にも付与されることを考慮して、RSED 開始タスクのユーザー ID には固有の UID を付与することをお勧めします。(例えば、z/OS UNIX 管理者は、特定のシステム管理タスクのために UID 0 を必要とします。)
オプションの統合デバッガーでは、ユーザーは、指定されたセキュリティー・プロファイルに対する十分なアクセス権限を持っている必要があります。ユーザーが必要な権限を持っていない場合、デバッグ・セッションは開始しません。
Developer for System z は、表 10 にリストされたプロファイルへのアクセスを確認して、デバッグ権限が付与されているかを判別します。
FACILITY プロファイル | 必要なアクセス権 | 結果 |
---|---|---|
AQE.AUTHDEBUG.STDPGM | READ | ユーザーは問題プログラム状態のアプリケーションをデバッグ可能 |
AQE.AUTHDEBUG.AUTHPGM | READ | ユーザーは問題プログラム状態かつ許可済みであるアプリケーションをデバッグ可能 |
RDEFINE FACILITY (AQE.AUTHDEBUG.STDPGM) -
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEM Z – DEBUG PROBLEM-STATE')
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) -
ID(RDZDEBUG) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
オプションの統合デバッガーを使用すると CICS トランザクションをデバッグできます。詳しくは、CICS トランザクションのデバッグ を参照してください。
Developer for System z では、Application Deployment Manager を通じて、開発者が編集可能な CICS リソース定義とそのデフォルト値、および CICS リソース定義の表示を、CICS 管理者が CICS リソース定義 (CRD) サーバーによって制御できます。必要な CICS TS セキュリティー定義の詳細については、CICSTS に関する考慮事項を参照してください。
CRD サーバー・リポジトリー VSAM データ・セットは、すべてのデフォルト・リソース定義を保持しています。したがって、更新されないように保護する必要がありますが、開発者は、そこに保管された値の読み取りを許可される必要があります。
Developer for System z は、CICS リソースの定義および照会時に、CRD サーバーが使用する複数のトランザクションを提供します。トランザクションが接続すると、CICS リソース・セキュリティー検査機能 (使用可能な場合) により、ユーザー ID にはそのトランザクション ID を実行する許可が与えられます。
Application Deployment Manager クライアントは、CICS TS Web サービスまたは RESTful インターフェースを使用して、CRD サーバーを起動します。この通信への SSL の使用は、CICS TS TCPIPSERVICE 定義によって制御されます。詳しくは「RACF Security Guide for CICS TS」を参照してください。
SCLM Developer Toolkit サービスは、ビルド、プロモート、およびデプロイ機能に対するオプションのセキュリティー機能を提供します。
SCLM 管理者による機能に対してセキュリティーが有効の場合、保護された機能を呼び出し元ユーザー ID または代理ユーザー ID で実行する権限を確認するために、SAF 呼び出しが行われます。
必要な SCLM セキュリティー定義の詳細については、「SCLM Developer Toolkit 管理者ガイド」(SC88-5664) を参照してください。
アドレス・スペースが RACF に、DATASET クラスのような RACLIST 処理 (メモリー内に保管) されていないリソース・クラスへのアクセスを指示する初回に、RACF は、ユーザーのアドレス・スペースにある関連するすべての総称プロファイルを取り出し、GATE (Generic Anchor Table Entry) と呼ばれるリストに保管します。z/OS 1.12 までは、RACF は総称アンカーをアドレス・スペースごとに 4 つ、独自の ACEE を持つ MVS TCB ごとに 4 つ維持します。4 つすべてを使い果たしたとき、RACF は、新しいものが入ってきたときに、最も長い間参照されていないものを置き換えます。
ユーザーが頻繁に 4 つを超えるデータ・セットの高位修飾子にアクセスする場合、RACF は使用可能なアンカー・スロットを介して新規エントリーを順番に使用する必要があるので、RSE スレッド・プール (スレッドを使用して複数のユーザーにユーザー固有の ACEE を提供する) で、GATE の処分が発生する可能性があります。
z/OS 1.12 では、RACF に「SET」コマンドの「GENERICANCHOR」オプションが導入され、これによりテーブルのサイズを大きくすることができます。これはシステム全体に、または各ジョブ名ごとに設定できます。
Developer for System z では、pthread_security_np() や __passwd() などの z/OS UNIX カーネル・サービスを使用します。これらは InitACEE セキュリティー・サービスを使用するため、結果として「管理 ACEE」セキュリティー管理ブロックになります。管理 ACEE (Accessor Environment Element) は、セキュリティー製品によってキャッシュされるので、特定の変更 (Developer for System z の外部で行ったパスワードの変更など) はキャッシュの期限が切れるまでセキュリティー製品によって無視されます (期限が切れるまでに数分かかることがあります)。
セキュリティーを変更した後には、管理 ACEE キャッシュを更新して、確実に新しいデータが Developer for System z で使用されるようにしてください。
RACF は、VLF (仮想ルックアサイド機能) を使用して ACEE (Accessor Environment Elements) を保存し、後ほどそれらを使用するために検索することができます。Developer for System z は、同一ユーザーに対して複数のセキュリティー環境 (ACEE) を (RSE スレッド・プール内のユーザー固有のスレッドごとに 1 つずつ) 構築するようセキュリティー・ソフトウェアに要求するので、ACEE キャッシングによるメリットを得ることができます。
ACEE キャッシングについて詳しくは、「Security Server RACF システム・プログラマーのガイド」(SA88-8611) の『ACEE および VLF の考慮事項』を参照してください。
セキュリティーおよび監査のセットアップに影響するディレクティブは、Developer for System z の複数の構成ファイルに存在します。この章の情報に基づいて、セキュリティー管理者およびシステム・プログラマーは、以下のディレクティブの設定内容を決定することができます。
どのジョブに対してアクションを実行できるかを定義します (ブラウズと実行依頼は除く)。詳しくは、ジョブに対するアクション - ターゲットの制限 を参照してください。
アクションの実行に使用される EMCS コンソールの権限レベルを定義します。詳しくは、ジョブに対するアクション - ターゲットの制限 を参照してください。
どのスプール・ファイルをブラウズできるかを定義します。詳しくは、スプール・ファイルへのアクセス を参照してください。
この z/OS システム外から JES ジョブ・モニターにアクセスできるかどうかを定義します。詳しくは、「ホスト構成ガイド」(SC88-5663) の章『基本的なカスタマイズ』の『FEJJCNFG、 JES ジョブ・モニター構成ファイル』を参照してください。
PassTicket の作成と妥当性検査に使用するアプリケーション ID。 詳しくは、PassTicket の使用 を参照してください。
FEK.** プロファイルを保持するセキュリティー・クラス。詳しくは、クライアントへのプッシュの開発者グループ および クライアント関数の変更 を参照してください。
ユーザーがホスト・パスワードをクライアント上に保存することを禁止します。詳しくは、「ホスト構成ガイド」 (SC88-5663) の 『_RSE_JAVAOPTS での追加 Java 始動パラメーター』 を参照してください。
活動停止中のクライアントを切断するタイマー。詳しくは、「ホスト構成ガイド」 (SC88-5663) の 『_RSE_JAVAOPTS での追加 Java 始動パラメーター』 を参照してください。
PassTicket の作成と妥当性検査に使用するアプリケーション ID。 詳しくは、PassTicket の使用 を参照してください。
Port Of Entry 検査を使用可能にします。詳しくは、Port Of Entry (POE) 検査 を参照してください。
通信の暗号化方式として SSL か TLS を選択します。詳しくは、SSL/TLS 暗号化通信 を参照してください。
セキュリティー製品を使用して、X.509 証明書でユーザーを認証します。詳しくは、クライアント認証、X.509 証明書を使用した を参照してください。
GSK_LDAP_SERVER=*
GSK_LDAP_PORT={389 | *}
GSK_LDAP_USER=*
GSK_LDAP_PASSWORD=*
X.509 認証のための追加のセキュリティー検査。詳しくは、(オプション) 証明書失効リスト (CRL) に対する照会 を参照してください。
ホスト・ログ・ファイルおよびディレクトリーのファイル・アクセス許可マスク。
ホスト・ログ・ファイルおよびディレクトリーの追加のセキュリティー検査 (所有権など)。
監査ログ・ファイルに至るパス。詳しくは、監査ロギング を参照してください。
監査ログ・ファイルのファイル・アクセス許可マスク。詳しくは、監査ロギング を参照してください。
(_RSE_JAVAOPTS) -Daudit.action.id=<userid>
監査ログを処理する z/OS UNIX ベースのユーザー出口。詳しくは、監査ロギング を参照してください。
RSE デーモン証明書のロケーション。詳しくは、SSL/TLS 暗号化通信 を参照してください。
RSE デーモン証明書の名前。詳しくは、SSL/TLS 暗号化通信 を参照してください。
RSE サーバー証明書のロケーション。詳しくは、SSL/TLS 暗号化通信 を参照してください。
RSE サーバー証明書の名前。詳しくは、SSL/TLS 暗号化通信 を参照してください。
使用される鍵ストアのタイプ (Java 鍵ストアまたは SAF 鍵リング)。詳しくは、SSL/TLS 暗号化通信 を参照してください。
reject.config.updates={true | false | SAF | LDAP}
Developer for System z クライアント構成ファイルをホスト・ベースで制御します。詳しくは、クライアントへのプッシュの考慮事項 を参照してください。
reject.product.updates={true | false | SAF | LDAP}
Developer for System z クライアント製品更新をホスト・ベースで制御します。詳しくは、クライアントへのプッシュの考慮事項 を参照してください。
サンプル FEKRACF メンバーをカスタマイズし、実行依頼してください。このメンバーには、Developer for System z 用の基本セキュリティー定義を作成する、サンプルの RACF および z/OS UNIX コマンドが含まれています。
FEKRACF は FEK.#CUST.JCL に置かれます。ただし、FEK.SFEKSAMP(FEKSETUP) ジョブをカスタマイズして実行依頼したときに別のロケーションを指定した場合は除きます。詳しくは、「IBM Rational Developer for System z ホスト構成ガイド」の『カスタマイズのセットアップ』を参照してください。
RACF コマンドの詳細については、「RACF コマンド言語解説書」(SA88-8617) を参照してください。
以下のセクションでは、必要なステップ、オプションの構成、および可能な代替策について説明します。
説明 |
|
値 |
---|---|---|
Developer for System z 製品の高位修飾子 |
|
|
Developer for System z カスタマイズ高位修飾子 |
|
|
統合デバッガー開始タスク名 |
|
|
JES ジョブ・モニター開始タスク名 |
|
|
RSE デーモン開始タスク名 |
|
|
アプリケーション ID |
|
重要: 「WHEN PROGRAM」がアクティブの場合、一部の製品 (FTP など) はプログラムで制御することが必要です。このプログラム制御は、実動システム上でアクティブにする前にテストしてください。 |
Developer for System z のユーザーごとに、有効なゼロ以外の z/OS UNIX ユーザー ID (UID)、ホーム・ディレクトリー、およびシェル・コマンドを指定する RACF OMVS セグメントまたは同等のものを定義する必要があります。また、ユーザーのデフォルト・グループも、グループ ID を持つ OMVS セグメントを必要とします。
オプションの統合デバッガーを使用するときには、デバッグするアプリケーションをアクティブ化したユーザー ID、およびそのデフォルト・グループにも、有効な RACF OMVS セグメントまたは同等のものが必要です。
以下のサンプルの RACF コマンドでは、#userid、#user-identifier、#group-name、および #group-identifier の各プレースホルダーを実際の値に置き換えてください。
ALTUSER #userid
OMVS(UID(#user-identifier) HOME(/u/#userid) PROGRAM(/bin/sh) NOASSIZEMAX)
以下のサンプル RACF コマンドは、保護されたユーザー ID ( STCDBM、STCJMON、および STCRSE) とそれらに割り当てられたグループ FEKD、DBGMGR、JMON、および RSED の各開始タスクを作成します。 #group-id および #user-id-* プレースホルダーは、有効な OMVS ID に置き換えてください。
ADDGROUP STCGROUP OMVS(AUTOGID)
DATA('GROUP WITH OMVS SEGMENT FOR STARTED TASKS')
ADDUSER STCDBM DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ – DEBUG MANAGER')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCJMON DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ - JES JOBMONITOR')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDUSER STCRSE DFLTGRP(STCGROUP) NOPASSWORD NAME('RDZ - RSE DAEMON')
OMVS(AUTOUID HOME(/tmp) PROGRAM(/bin/sh) ASSIZEMAX(2147483647) )
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE STARTED DBGMGR.* DATA('RDZ – DEBUG MANAGER')
STDATA(USER(STCDBM) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED JMON.* DATA('RDZ - JES JOBMONITOR')
STDATA(USER(STCJMON) GROUP(STCGROUP) TRUSTED(NO))
RDEFINE STARTED RSED.* DATA('RDZ - RSE DAEMON')
STDATA(USER(STCRSE) GROUP(STCGROUP) TRUSTED(NO))
ALTUSER STCRSE RESTRICTED
制限されたユーザーが「その他の」許可ビットによって z/OS UNIX ファイル・システム・リソースにアクセスできないよう、UNIXPRIV クラス内に RESTRICTED.FILESYS.ACCESS プロファイルを UACC(NONE) で定義します。ユーザー ID を制限する方法の詳細については、「Security Server RACF セキュリティー管理者のガイド」(SA88-8613) を参照してください。
重要: 制限されたユーザー ID を使用している場合は、TSO の PERMIT コマンドか、z/OS UNIX setfacl コマンドを使用して、リソースにアクセスする許可を明示的に追加します。リソースには、Developer
for System z 資料が UACC を使用するリソース (PROGRAM クラス内の ** プロファイルなど)、またはそれが共通の z/OS UNIX 規則 (全員が Java ライブラリーの読み取り権限と実行権限を持つなど) に依存するリソースが含まれます。実動システム上でアクティブにする前にアクセスのテストをしてください。
|
RSE は、クライアントのスレッドのセキュリティー環境を作成または削除するためには、BPX.SERVER プロファイルに対する UPDATE アクセス権を必要とします。このプロファイルが定義されていない場合は、UID(0) が RSE に必要です。このステップは、クライアントが接続可能になるために必要です。
統合デバッガーは、デバッグ・スレッドのセキュリティー環境を作成または削除するため、BPX.SERVER プロファイルに対する UPDATE アクセス権を必要とします。このプロファイルが定義されない場合、STCDBM 開始タスク・ユーザー ID 用に UID(0) が必要です。この許可は、オプションの統合デバッガー・フィーチャーが使用される場合にのみ必要です。
重要: BPX.SERVER プロファイルを定義すると、z/OS UNIX 全体が UNIX レベルのセキュリティーから、より安全な z/OS UNIX レベルのセキュリティーに切り替わります。この切り替えによって、他の z/OS UNIX アプリケーションと操作が影響を受ける場合もあります。セキュリティーは、実動システム上でアクティブにする前にテストしてください。さまざまなセキュリティー・レベルの詳細については、「UNIX System Services 計画」(GA88-8639) を参照してください。
|
BPX.SERVER に対する権限を持つサーバーは、クリーンなプログラム制御環境で実行する必要があります。この要件は、RSE によって呼び出されるすべてのプログラムも、プログラムで制御する必要があることを意味します。MVS ロード・ライブラリーの場合、プログラム制御はセキュリティー・ソフトウェアによって管理されます。このステップは、クライアントが接続可能になるために必要です。
オプションのサービスを使用できるようにするには、以下の前提条件の追加ライブラリーがプログラムで制御されるようにする必要があります。このリストには、Developer for System z が対話する製品 (IBM File Manager など) に固有のデータ・セットは含まれていません。
クライアントのパスワードまたは、X.509 証明書などのその他の識別手段は、接続時に ID を検査するためにのみ使用されます。その後は、スレッド・セキュリティーを維持するために PassTicket が使用されます。このステップは、クライアントが接続可能になるために必要です。
RDEFINE PTKTDATA FEKAPPL UACC(NONE) SSIGNON(KEYMASKED(key16))
APPLDATA('NO REPLAY PROTECTION – DO NOT CHANGE')
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE PTKTDATA IRRPTAUTH.FEKAPPL.* UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT IRRPTAUTH.FEKAPPL.* CLASS(PTKTDATA) ACCESS(UPDATE) ID(STCRSE)
SETROPTS RACLIST(PTKTDATA) REFRESH
RSE は、FEKAPPL 以外のアプリケーション ID の使用をサポートしています。これをアクティブにするには、「IBM Rational Developer for System z ホスト構成ガイド」の『_RSE_JAVAOPTS での追加 Java 始動パラメーターの定義』の説明に従って、rsed.envvars 内の「APPLID=FEKAPPL」オプションをコメント解除してカスタマイズします。PTKTDATA クラス定義は、RSE が使用する実際のアプリケーション ID と一致している必要があります。
重要: パスチケットが正しくセットアップされていないと、クライアント接続要求は失敗します。
|
MODIFY LOGS オペレーター・コマンドは、RSED 開始タスクのユーザー ID を使用して、ホスト・ログおよびセットアップ情報を収集します。 また、デフォルトで、セキュア・ファイル・アクセス許可 (所有者のみがアクセス権を保持する) を使用して、ユーザー・ログ・ファイルが作成されます。セキュア・ユーザー・ログ・ファイルを収集できるようにするには、RSED 開始タスクのユーザー ID が、それらのファイルを読み取る許可を持っていなければなりません。
MODIFY LOGS オペレーター・コマンドの OWNER 引数を指定すると、指定されたユーザー ID が、収集されたデータの所有者になります。所有権を変更するには、RSED 開始タスクのユーザー ID が、CHOWN z/OS UNIX サービスを使用する許可を持っていなければなりません。
SUPERUSER.FILESYS.ACLOVERRIDE プロファイルが定義されている場合、ACL (アクセス制御リスト) で定義されているアクセス許可は、SUPERUSER.FILESYS を介して付与された許可よりも優先される点に注意してください。 ACL 定義をバイパスする場合、RSED 開始タスクのユーザー ID には、SUPERUSER.FILESYS.ACLOVERRIDE プロファイルに対する READ アクセス権が必要になります。
クライアントがログオンするときに、RSE デーモンはユーザーがアプリケーションの使用を許可されていることを検証します。
RDEFINE APPL FEKAPPL UACC(READ) DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
SETROPTS RACLIST(APPL) REFRESH
BPX.SERVER に対する権限を持つサーバーは、クリーンなプログラム制御環境で実行する必要があります。この要件は、RSE によって呼び出されるすべてのプログラムも、プログラムで制御する必要があることを意味します。z/OS UNIX ファイルの場合、プログラム制御は extattr コマンドによって管理されます。このコマンドを実行するには、 FACILITY クラス内の BPX.FILEATTR.PROGCTL に対する READ アクセス権を持つか、または UID(0) であることが必要です。
$ ls -Eog /usr/lib/libIRRRacf*.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf.so
-rwxr-xr-x aps- 2 69632 Oct 5 2007 /usr/lib/libIRRRacf64.so
JES ジョブ・モニターは、ユーザーが要求したすべての JES オペレーター・コマンドを、拡張 MCS (EMCS) コンソールを通じて発行します。このコンソールの名前は、「IBM Rational Developer for System z ホスト構成ガイド」の『FEJJCNFG - JES ジョブ・モニター構成ファイル』の説明にあるように、CONSOLE_NAME ディレクティブによって制御されます。
RDEFINE OPERCMDS MVS.MCSOPER.#console UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
RDEFINE OPERCMDS JES%.** UACC(NONE)
PERMIT JES%.** CLASS(OPERCMDS) ACCESS(UPDATE) WHEN(CONSOLE(JMON)) ID(*)
SETROPTS RACLIST(OPERCMDS) REFRESH
重要: ご使用のセキュリティー・ソフトウェアで汎用アクセス NONE を使用して JES コマンドを定義すると、他のアプリケーションや操作に影響が出る場合があります。セキュリティーは、実動システム上でアクティブにする前にテストしてください。
|
表 12 および表 13 は、JES2 および JES3 について発行されたオペレーター・コマンドと、それらを保護するために使用できる個別セキュリティー・プロファイルを示しています。
アクション | コマンド | OPERCMDS プロファイル | 必要なアクセス権 |
---|---|---|---|
保留 | $Hx(jobid) x = {J、S、または T} |
|
UPDATE |
保留解除 | $Ax(jobid) x = {J、S、または T} |
|
UPDATE |
キャンセル | $Cx(jobid) x = {J、S、または T} |
|
UPDATE |
パージ | $Cx(jobid),P
x = {J、S、または T} |
|
UPDATE |
アクション | コマンド | OPERCMDS プロファイル | 必要なアクセス権 |
---|---|---|---|
保留 | *F,J=jobid,H |
|
UPDATE |
保留解除 | *F,J=jobid,R |
|
UPDATE |
キャンセル | *F,J=jobid,C |
|
UPDATE |
パージ | *F,J=jobid,C |
|
UPDATE |
TSO セッションから JMON コンソールを作成することによって JES ジョブ・モニター・サーバーの ID を装うことは、セキュリティー・ソフトウェアによって防止されます。コンソールを作成できても、例えば、JES ジョブ・モニターと TSO とでは、エントリー・ポイントが異なります。この資料で説明されているとおりにセキュリティーがセットアップされており、ユーザーが他の手段によって JES コマンドに対する権限を持っていない場合は、そのコンソールから発行された JES コマンドはセキュリティー検査で不合格になります。
ユーザーが問題プログラム状態のプログラムのデバッグに統合デバッガーを使用できるようになるには、リストされている AQE.AUTHDEBUG.* プロファイルのいずれかに対する READ アクセス権が必要です。AQE.AUTHDEBUG.AUTHPGM プロファイルへのアクセスが許可されているユーザーは、APF 許可済みのプログラムをデバッグすることもできます。#apf プレースホルダーは、許可済みプログラムのデバッグが許可されているユーザーの、有効なユーザー ID または RACF グループ名に置き換えてください。
RDEFINE FACILITY AQE.AUTHDEBUG.STDPGM UACC(NONE)
PERMIT AQE.AUTHDEBUG.STDPGM CLASS(FACILITY) ACCESS(READ) ID(*)
RDEFINE FACILITY AQE.AUTHDEBUG.AUTHPGM UACC(NONE)
PERMIT AQE.AUTHDEBUG.AUTHPGM CLASS(FACILITY) ACCESS(READ) ID(#apf)
SETROPTS RACLIST(FACILITY) REFRESH
ほとんどの Developer for System z データ・セットの場合、ユーザーには READ アクセス権限、システム・プログラマーには ALTER アクセス権限で十分です。 #sysprog プレースホルダーは、有効なユーザー ID または RACF グループ名に置き換えてください。また、正しいデータ・セット名については、製品をインストールおよび構成したシステム・プログラマーに問い合わせてください。FEK は、インストール時に使用されたデフォルトの高位修飾子で、FEK.#CUST はカスタマイズ・プロセスで作成されたデータ・セットのデフォルトの高位修飾子です。
ADDGROUP (FEK) OWNER(IBMUSER) SUPGROUP(SYS1)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB')
ADDSD 'FEK.*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
PERMIT 'FEK.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(UPDATE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.CRA*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(READ)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#cicsadmin)
SETROPTS GENERIC(DATASET) REFRESH
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(UPDATE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
SETROPTS GENERIC(DATASET) REFRESH
ADDGROUP (FEK)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - HLQ STUB')
OWNER(IBMUSER) SUPGROUP(SYS1)"
ADDSD 'FEK.*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKAUTH' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLOAD' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKLMOD' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.SFEKPROC' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.PARMLIB' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.CNTL' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.SQL' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z')
ADDSD 'FEK.#CUST.LSTRANS.*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - SCLMDT')
ADDSD 'FEK.#CUST.CRA*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CARMA')
ADDSD 'FEK.#CUST.ADNREP*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
ADDSD 'FEK.#CUST.ADNMAN*.**' UACC(NONE)
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - ADN')
PERMIT 'FEK.*.** CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKAUTH CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLOAD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKLMOD CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKPROC CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.PARMLIB CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CNTL CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.SQL CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(ALTER) ID(#sysprog)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKPROC' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.CNTL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.SQL' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.SFEKAUTH' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.PARMLIB' CLASS(DATASET) ACCESS(READ) ID(STCJMON)
PERMIT 'FEK.#CUST.LSTRANS.*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.#CUST.CRA*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#ram-developer)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(READ) ID(*)
PERMIT 'FEK.#CUST.ADNREP*.**' CLASS(DATASET) ACCESS(UPDATE) ID(#cicsadmin)
PERMIT 'FEK.#CUST.ADNMAN*.**' CLASS(DATASET) ACCESS(UPDATE) ID(*)
PERMIT 'FEK.SFEKLOAD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#cicsts)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#ims)
PERMIT 'FEK.SFEKLMOD' CLASS(DATASET) ACCESS(READ) ID(#batch)
SETROPTS GENERIC(DATASET) REFRESH
セキュリティーに関連するカスタマイズの結果を表示するには、以下のサンプル・コマンドを使用します。
Developer for System z では、TCP/IP を使用して、非メインフレーム・ワークステーションのユーザーに、メインフレームからアクセスすることができます。 また、各種コンポーネントと他の製品との通信にも TCP/IP が使用されます。
ほとんどの Developer for System z 機能は z/OS UNIX をベースにしているため、TCP/IP は z/OS UNIX 検索順序を使用して、構成ファイルを検索します。 詳しくは、TCP/IP のセットアップを参照してください。
図 10 は、Developer for System z で使用できる TCP/IP ポートを示しています。矢印は、バインドの実行元 (矢印の先) と接続元を示しています。
Developer for System z が使用するポートを予約するのに PROFILE.TCPIP 内の PORT ステートメントまたは PORTRANGE ステートメントを使用する場合、RSE スレッド・プール内でアクティブなスレッドによって多数のバインドが行われることに注意してください。RSE スレッド・プールのジョブ名は、RSEDx です。ここで、RSED は RSE 開始タスクの名前で、x はランダムな 1 桁の数値です。したがって、定義内にワイルドカードが必要です。
PORT 4035 TCP RSED ; Developer for System z - RSE daemon
PORT 6715 TCP JMON ; Developer for System z - JES job monitor
PORT 5335 TCP DBGMGR ; Developer for System z – Integrated
debugger
PORT 5336 TCP DBGMGR ; Developer for System z – Integrated
debugger
PORTRange 8108 11 TCP RSED* ; Developer for System z - _RSE_PORTRANGE
;PORTRange 5227 100 TCP RSED* ; Developer for System z - CARMA
CARMA (Common Access Repository Manager) は、ホスト・ベースの Software Configuration Manager (SCM) (CA Endevor® SCM など) にアクセスするために使用されます。ほとんどの場合、サーバーは RSE デーモンの場合と同様に、ポートにバインドし、接続要求を listen します。しかし CARMA は別の方法を使用します。これは、クライアントが接続要求を開始した時点で CARMA サーバーがまだアクティブでないためです。
クライアントから接続要求が送信されると、RSE スレッド・プール内でユーザー・スレッドとしてアクティブとなっている CARMA マイナーは、一時ポートを要求するか、CRASRV.properties 構成ファイルに指定されている範囲から空いているポートを見つけ、そのポートにバインドします。次にこのマイナーは、CARMA サーバーを始動してポート番号を渡します。これによって、サーバーは接続先のポートを認識します。サーバーが接続されると、クライアントはサーバーに要求を送信して結果を受信できるようになります。
TCP/IP の観点では、RSE (CARMA マイナー経由) がポートにバインドするサーバーであり、CARMA サーバーがそのポートに接続するクライアントです。
CARMA が使用するポート範囲を予約するのに PROFILE.TCPIP 内の PORT ステートメントまたは PORTRANGE ステートメントを使用する場合、CARMA マイナーが RSE スレッド・プール内でアクティブになっていることに注意してください。RSE スレッド・プールのジョブ名は、RSEDx です。ここで、RSED は RSE 開始タスクの名前で、x はランダムな 1 桁の数値です。したがって、定義内にワイルドカードが必要です。
PORTRange 5227 100 RSED* ; Developer for System z - CARMA
遅延 ACK では、TCP パケットの受信確認応答を最大 200 ミリ秒遅らせます。 この遅延により、受信したパケットに対する応答と共に ACK を送信できる機会が多くなり、ネットワーク・トラフィックを削減できるようになります。ただし、送信側が ACK を受信するまで新規パケットを送信しない場合 (例えば、Nagle アルゴリズムを実装したため) に、送信されたパケットに対する応答が存在しないと (例えば、そのパケットがファイル転送の一部である場合)、通信に不必要な遅延を招きます。
Developer for System z では、遅延 ACK 機能を使用不可にできます。これを実行するには、ホスト側の rsed.envvars にある DSTORE_TCP_NO_DELAY ディレクティブを使用します。詳しくは「ホスト構成ガイド」(SC88-5663) を参照してください。
z/OS Communication Server を使用すると、単一のシステム上で同時に複数の TCP/IP スタックをアクティブにすることができます。これは、CINET セットアップと呼ばれます。
デフォルトのスタック上で Developer for System z がアクティブになっていない場合、選択した Developer for System z 機能は失敗することがあります。スタックのアフィニティーを使用することがこの問題を解決する確実な方法です。スタックのアフィニティーは、使用可能なすべての TCP/IP スタック (これは開始タスクのデフォルトです) ではなく、特定の TCP/IP スタックのみを使用するように Developer for System z に指示します。
スタックのアフィニティーは、rsed.envvars 構成ファイル内の _BPXK_SETIBMOPT_TRANSPORT ディレクティブをコメント解除およびカスタマイズすることにより、RSED 開始タスク用に設定されます。 この構成ファイルのカスタマイズの詳細については、「ホスト構成ガイド」 (SC88-5663) の『第 2 章 基本的なカスタマイズ』内の関連するセクションを参照してください。
CARMA (Common Access Repository Manager) は、ホスト・ベースの Software Configuration Manager (SCM) (CA Endevor® SCM など) にアクセスするために使用されます。これを行うために、CARMA はユーザー固有のサーバーを始動します。したがって、スタックのアフィニティーを強制的に設定するために追加の構成が必要になります。
Developer for System z 開始タスクと同様に、CARMA サーバーのスタックのアフィニティーは、_BPXK_SETIBMOPT_TRANSPORT 変数を使用して設定されます。 この変数は LE (言語環境プログラム) に渡される必要があります。これは、アクティブな crastart*.conf または CRASUB* 構成ファイル内の始動コマンドを調整することにより実行可能です。
... PARM(&CRAPRM1. &CRAPRM2.)
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &CRAPRM1. &CRAPRM2.)
... PARM(&PORT &TIMEOUT)
... PARM(ENVAR("_BPXK_SETIBMOPT_TRANSPORT=TCPIP") / &PORT &TIMEOUT)
Distributed DVIPA (Dynamic Virtual IP Addressing) では、 ご使用のシスプレックス内の別々のシステムで、同一の Developer for System z セットアップを同時に実行し、また、オプションで、WLM を使用して、TCP/IP に、これらのシステム間でクライアント接続を分散させることができます。
このため、Developer for System z は、RSE サーバー・スレッドが使用するポートが必ずシスプレックス内で固有であるようにするために、VIPADISTRIBUTE ステートメントに SYSPLEXPORTS を定義する必要があります。
JES ジョブ・モニター、CARMA、および他の Developer for System z サーバーは、ローカル RSE としか対話しないため、DVIPA のセットアップを必要としません。
統合デバッガーはローカル RSE と対話するので、DVIPA のセットアップを必要としません。デバッグ・セッションが正しいホストと通信することを保証するため、デバッグ・マネージャーは使用しなければならない TCP/IP アドレスをクライアントに指示するので、DVIPA のセットアップは必要としません。
Distributed DVIPA は、ご使用の TCP/IP プロファイルの VIPADynamic ブロックの VIPADEFine キーワードと VIPABackup キーワードで定義されます。 VIPADISTribute キーワードは、必要なシスプレックス・ディストリビューター定義を追加します。 Distributed DVIPA では、参加しているすべてのスタックがシスプレックスを認識する必要があります。これは、ご使用の TCP/IP プロファイルの IPCONFIG ブロックの SYSPLEXRouting キーワードと DYNAMICXCF キーワードを経由して行われます。 これらのディレクティブの詳細については、「Communications Server IP 構成解説書」(SC88-8927) を 参照してください。
ご使用のカップリング・ファシリティーに EZBEPORTS 構造をセットアップする方法についての詳細は、「MVS シスプレックスのセットアップ」(SA88-8591) および「Communication Server: SNA ネットワーク・インプリメンテーション・ガイド」(SC88-8928) を参照してください。
SYSPLEXPORTS を使用することは、TCP/IP が 2 次接続に一時ポートを選択することを暗黙に示しています。 一時ポートは、必ず、空き状態かつ予約がされていない状態でなくてはなりません。一時ポートを利用すると、ファイアウォールのベスト・プラクティスとの相性が悪く、通信用にオープンにオープンされるポートを制限してしまいます。その理由は、どのポートが使用されるか不明になるからです。
この問題を回避するには、Developer for System z に対しシステムごとに固有の _RSE_PORTRANGE を定義することで 2 次接続に既知のポートを強制的に割り当てます。その際使用されるポートの範囲は、すべてのシステム上で使用される Developer for System z 用に予約されていることを確認します。この回避方法を実行するには、TCP/IP APAR PM63379 が必須であることに注意してください。
TCP/IP が 2 次接続を正しいシステムに確実に経路指定するには、 Developer for System z は各システム上で固有のポート範囲を使用する必要があります。このことは、そのシステムに共有された、同一のセットアップが使用できないということを暗に示しています。これは、rsed.envvars 内にある _RSE_PORTRANGE は、固有でなくてはならないからです。同じコードを利用する場合、異なる構成ファイルを使用して複数のサーバーをセットアップする方法については、複数のインスタンスの実行内、同一のソフトウェア・レベル、異なる構成ファイルを参照してください。異なったシステムに対して同一のファイルを確実に使用するには、rsed.envvars のマスター・コピーと、システム固有のセットアップに合わせてその調整とコピーを行うためのスクリプトを使用する必要があります。
$ oedit /etc/rdz/rsed.envvars
-> add the following at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/update.sh
$ chmod 755 /etc/rdz/update.sh
#! /bin/sh
# Licensed materials - Property of IBM
# 5724-T07 Copyright IBM Corp. 2012
# clone rsed.envvars and set PORTRANGE for use with RDz & DDVIPA
file=rsed.envvars #; echo file $file
sys=${1:-$(sysvar SYSNAME)} #; echo sys $sys
dir=$(dirname $0) #; echo dir $dir
# if sysname has a special char, precede it with \ (eg. SYS\$1)
case "$sys" in # #### CUSTOMIZE THIS SECTION ####
"SYS1") range=8108-8118;;
"SYS2") range=8119-8129;;
esac #; echo range $range
echo "setting port range $range for $sys using $dir/$file"
if test ! $range ; then
echo ERROR: no port range defined for $sys ; exit 12 ; fi
if test ! -e $dir/$file ; then
echo ERROR: file $dir/$file does not exist ; exit 12 ; fi
if test ! -d $dir/$sys ; then
echo ERROR: directory $dir/$sys does not exist ; exit 12 ; fi
mv $dir/$sys/$file $dir/$sys/prev.$file 2>/dev/null
sed="/_RSE_PORTRANGE/s/.*/_RSE_PORTRANGE=$range/"
sed "$sed" $dir/$file > $dir/$sys/$file
if test ! -s $dir/$sys/$file ; then
echo ERROR creating $dir/$sys/$file, restoring backup
mv $dir/$sys/prev.$file $dir/$sys/$file ; exit 8 ; fi
$ mkdir /etc/rdz/SYS1 /etc/rdz/SYS2
$ /etc/rdz/update.sh SYS1
setting port range 8108-8118 for SYS1 using
/etc/rdz/rsed.envvars
$ /etc/rdz/update.sh SYS2
setting port range 8119-8129 for SYS2 using
/etc/rdz/rsed.envvars
// CNFG='/etc/rdz/&SYSNAME.'
PORTRange 8108 22 RSED* ; 8108-8129 - Developer for System z
; - secondary connection
接続のフロー で記されているように、_RSE_PORTRANGE 内のポート範囲は小さい可能性があります。 RSE サーバーはクライアント接続の期間中に、ポートを独占的に必要とすることはありません。 他の RSE サーバーがそのポートにバインドできないのは、(サーバーの) バインドから (クライアントの) 接続までの間だけです。つまり、ほとんどの接続が範囲内の最初のポートを使用し、同じ範囲内の残りのポートは、同時に複数のログオンが発生したときのバッファーになる、ということです。
以下のサンプル・セットアップには、SYS1 と SYS2 という、2 つの z/OS システムがあり、これらはシスプレックスの一部となっています。 システム SYS1 は、通常、Developer for System z の Distributed DVIPA 用のシスプレックス・ディストリビューターをホストするシステムとして定義されます。
Distributed DVIPA を定義した後、Developer for System z をシステムで始動して、システム間でロード・バランシング・クライアント接続を行うことができます。 JES ジョブ・モニターは、ローカル RSE としか対話しないため、DVIPA のセットアップを必要としません。 クライアントは、IP アドレス 10.10.10.1 のポート 4035 に接続します。
IPCONFIG
SYSPLEXRouting
; SYSPLEXROUTING is required as this stack needs sysplex communication
DYNAMICXCF 9.9.9.1 255.255.255.0 1
; DYNAMICXCF defines device/link with home address 9.9.9.1 as needed
IGNORERedirect
VIPADYNAMIC
VIPADEFINE 255.255.255.0 10.10.10.1
; VIPADEFINE defines 10.10.10.1 as main DVIPA on SYS1 for RDz
VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE makes 10.10.10.1 a distributed DVIPA, must match SYS2
SYSPLEXPORTS ; RDz prereq
DISTMETHOD BASEWLM ; BASEWLM or ROUNDROBIN
10.10.10.1 ; DVIPA address used by RDz clients
PORT 4035 ; port used by RDz clients
DESTIP 9.9.9.1 9.9.9.2 ; RDz active on SYS1 and SYS2
ENDVIPADYNAMIC
IPCONFIG
SYSPLEXRouting
; SYSPLEXROUTING is required as this stack needs sysplex communication
DYNAMICXCF 9.9.9.2 255.255.255.0 1
; DYNAMICXCF defines device/link with home address 9.9.9.2 as needed
IGNORERedirect
VIPADYNAMIC
VIPABACKUP 255.255.255.0 10.10.10.1
; VIPABACKUP defines 10.10.10.1 as backup DVIPA on SYS2 for RDz
VIPADISTRIBUTE DEFINE
; VIPADISTRIBUTE makes 10.10.10.1 a distributed DVIPA, must match SYS1
SYSPLEXPORTS ; RDz prereq
DISTMETHOD BASEWLM ; BASEWLM or ROUNDROBIN
10.10.10.1 ; DVIPA address used by RDz clients
PORT 4035 ; port used by RDz clients
DESTIP 9.9.9.1 9.9.9.2 ; RDz active on SYS1 and SYS2
ENDVIPADYNAMIC
従来の z/OS アプリケーションとは異なり、Developer for System z は、ワークロード・マネージャー (WLM) で容易に識別できる一体構造のアプリケーションではありません。Developer for System z は、クライアントがホスト・サービスとデータにアクセスできるようにするために相互に作用する、複数のコンポーネントで構成されています。 Developer for System z についてで説明しているように、これらのサービスの一部は異なるアドレス・スペースでアクティブとなるため、WLM 分類も異なることになります。
図 13 は、Developer for System z ワークロードが WLM に提示されるときに経由するサブシステムの基本的概要を示しています。
Application Deployment Manager (ADM) は CICS 領域でアクティブになるため、WLM での CICS 分類規則に従います。
RSE デーモン (RSED)、デバッグ・マネージャー (DBGMGR)、および JES ジョブ・モニター (JMON) は、Developer for System z の開始タスク (または長期実行バッチ・ジョブ) であり、それぞれが専用のアドレス・スペースを使用します。
Java アプリケーションとしての RSEで説明しているように、RSE デーモンは RSE スレッド・プール・サーバー (不定数のクライアントをサポート) ごとに子プロセスを spawn します。各スレッド・プールは個別のアドレス・スペースでアクティブになります (z/OS UNIX イニシエーター BPXAS を使用)。これらは spawn されたプロセスであるため、開始タスクの分類規則ではなく、WLM OMVS の分類規則を使用して分類されます。
ユーザーが実行するアクションによっては、スレッド・プール内でアクティブなクライアントが他のアドレス・スペースを多数作成する可能性があります。Developer for System z の構成によっては、TSO コマンド・サービス (TSO cmd) や CARMA などの一部のワークロードが、異なるサブシステムで実行される可能性があります。
図 13 に示されているアドレス・スペースは、表示の対象となるほど長くシステムに残りますが、z/OS UNIX の設計仕様のために、存続期間の短い一時的なアドレス・スペースもいくつか存在することに注意してください。これらの一時的なアドレス・スペースは、OMVS サブシステム内でアクティブになります。
RSE スレッド・プールは RSE デーモンと同じユーザー ID および同様のジョブ名を使用しますが、スレッド・プールによって開始されるアドレス・スペースはいずれも、アクションを要求しているクライアントのユーザー ID によって所有されることに注意してください。このクライアント・ユーザー ID は、スレッド・プールによって開始されるすべての OMVS ベース・アドレス・スペースのジョブ名 (の一部) としても使用されます。
Developer for System z が使用するその他のサービス (File Manager (FMNCAS) や z/OS UNIX REXEC (USS ビルド) など) によって、さらにアドレス・スペースが作成されます。
WLM は、分類規則を使用して、システムに入ってきた作業をサービス・クラスにマッピングします。この分類は、作業修飾子に基づいています。最初の (必須) 修飾子は、作業要求を受け取るサブシステム・タイプです。表 14 に、Developer for System z ワークロードを受け取る可能性があるサブシステム・タイプを示します。
サブシステム・タイプ | 作業の説明 |
---|---|
ASCH | 作業要求には、IBM 提供の APPC/MVS トランザクション・スケジューラー ASCH によってスケジュールされるすべての APPC トランザクション・プログラムが含まれます。 |
CICS | 作業要求には、CICS によって処理されるすべてのトランザクションが含まれます。 |
JES | 作業要求には、JES2 または JES3 が開始するすべてのジョブが含まれます。 |
OMVS | 作業要求には、z/OS UNIX システム・サービスで fork された子のアドレス・スペースで処理される作業が含まれます。 |
STC | 作業要求には、START および MOUNT コマンドによって開始されるすべての作業が含まれます。STC には、システム・コンポーネント・アドレス・スペースも含まれます。 |
表 15 に、ワークロードを特定のサービス・クラスに割り当てるために使用できる追加の修飾子を示します。リストされている作業修飾子の詳細については、「MVS 計画: ワークロード管理」(SA88-8574) を参照してください。
ASCH | CICS | JES | OMVS | STC | ||
---|---|---|---|---|---|---|
AI | アカウント情報 | x | x | x | x | |
LU | LU 名 (*) | x | ||||
PF | 実行 (*) | x | x | |||
PRI | 優先順位 | x | ||||
SE | スケジューリング環境名 | x | ||||
SSC | サブシステム・コレクション名 | x | ||||
SI | サブシステム・インスタンス (*) | x | x | |||
SPM | サブシステム・パラメーター | x | ||||
PX | シスプレックス名 | x | x | x | x | x |
SY | システム名 (*) | x | x | x | ||
TC | トランザクション/ジョブ・クラス (*) | x | x | |||
TN | トランザクション/ジョブ名 (*) | x | x | x | x | x |
UI | ユーザー ID (*) | x | x | x | x | x |
ワークロード分類で説明しているように、Developer for System z はシステム上でさまざまなタイプのワークロードを作成します。これらの各種タスクは互いに通信します。つまり、タスク間接続でのタイムアウトの問題を回避するためには、実際の経過時間が重要になります。このため、Developer for System z のタスクは、ハイパフォーマンスのサービス・クラスに配置するか、または優先順位の高い適度なパフォーマンスのサービス・クラスに配置する必要があります。
したがって、現行の WLM の目標を改訂または更新することをお勧めします。これは特に、従来の MVS 作業現場で時間依存型の OMVS ワークロードを初めて扱う場合に当てはまります。
表 16 は、Developer for System z が使用するアドレス・スペースを示しています。z/OS UNIX では、「タスク名」列の「x」がランダムな 1 桁の数値で置き換えられます。
説明 | タスク名 | ワークロード |
---|---|---|
デバッグ・マネージャー | DBGMGR | STC |
JES ジョブ・モニター | JMON | STC |
RSE デーモン | RSED | STC |
RSE スレッド・プール | RSEDx | OMVS |
ISPF クライアント・ゲートウェイ (TSO コマンド・サービスおよび SCLMDT) | <userid>x | OMVS |
TSO コマンド・サービス (APPC) | FEKFRSRV | ASCH |
CARMA (バッチ) | CRA<port> | JES |
CARMA (crastart) | <userid>x | OMVS |
CARMA (ISPF クライアント・ゲートウェイ) | <userid> および <userid>x | OMVS |
MVS ビルド (バッチ・ジョブ) | * | JES |
z/OS UNIX ビルド (シェル・コマンド) | <userid>x | OMVS |
z/OS UNIX シェル | <userid> | OMVS |
Application Deployment Manager | CICSTS | CICS |
Developer for System z の開始タスクである RSE デーモンおよび JES ジョブ・モニターはいずれも、リアルタイムのクライアント要求を処理します。
説明 | タスク名 | ワークロード |
---|---|---|
JES ジョブ・モニター | JMON | STC |
デバッグ・マネージャー | DBGMGR | STC |
RSE デーモン | RSED | STC |
JES ジョブ・モニターは、ジョブの実行依頼、スプール・ファイルの表示、JES オペレーター・コマンドの実行など、すべての JES 関連サービスを提供します。ハイパフォーマンスの 1 期間の速度目標を指定する必要があります。これは、タスクが WLM に個々のトランザクションを報告しないためです。リソース使用量は、ユーザー・アクションに大きく依存するため変動しますが、最少から中程度と予想されます。
デバッグ・マネージャーは、デバッグされるプログラムと、それらをデバッグするクライアントとを接続するためのサービスを提供します。ハイパフォーマンスの 1 期間の速度目標を指定する必要があります。これは、タスクが WLM に個々のトランザクションを報告しないためです。リソース使用量は、ユーザー・アクションに大きく依存するため変動しますが、最少と予想されます。
RSE デーモンは、クライアントのログオンと認証を処理し、複数の RSE スレッド・プールを管理します。ハイパフォーマンスの 1 期間の速度目標を指定する必要があります。これは、タスクが WLM に個々のトランザクションを報告しないためです。リソース使用量は、作業日の開始点をピークとして、中程度と予想されます。
OMVS ワークロードは 2 つのグループ、つまり RSE スレッド・プールとそれ以外に分けることができます。これは、RSE スレッド・プールを除くすべてのワークロードが、クライアント・ユーザー ID をアドレス・スペース名のベースとして使用するためです (z/OS UNIX では、「タスク名」列の「x」がランダムな 1 桁の数値で置き換えられます)。
説明 | タスク名 | ワークロード |
---|---|---|
RSE スレッド・プール | RSEDx | OMVS |
ISPF クライアント・ゲートウェイ (TSO コマンド・サービスおよび SCLMDT) | <userid>x | OMVS |
CARMA (crastart) | <userid>x | OMVS |
CARMA (ISPF クライアント・ゲートウェイ) | <userid> および <userid>x | OMVS |
z/OS UNIX ビルド (シェル・コマンド) | <userid>x | OMVS |
z/OS UNIX シェル | <userid> | OMVS |
RSE スレッド・プールは、Developer for System z の中枢であると言えます。ほぼすべてのデータがスレッド・プールを通過し、スレッド・プール内のマイナー (ユーザー固有のスレッド) によって、他の Developer for System z 関連タスクのほとんどが制御されます。ハイパフォーマンスの 1 期間の速度目標を指定する必要があります。これは、タスクが WLM に個々のトランザクションを報告しないためです。リソース使用量は、ユーザー・アクションに大きく依存するため変動しますが、相当量と予想されます。
残りのワークロードは、アドレス・スペース命名規則が共通であるために、すべて同じサービス・クラスに割り当てられることになります。このサービス・クラスには、複数期間の目標を指定する必要があります。最初の期間にはハイパフォーマンスのパーセンタイル応答時間目標を指定し、最後の期間には適度なパフォーマンスの速度目標を指定する必要があります。ISPF クライアント・ゲートウェイなどの一部のワークロードは、個々のトランザクションを WLM に報告しますが、それ以外のワークロードはこれを行いません。
ISPF クライアント・ゲートウェイは、Developer for System z が非対話式の TSO コマンドと ISPF コマンドを実行するために呼び出す ISPF サービスです。これには、クライアントが発行する明示的なコマンドと、Developer for System z が発行する暗黙的なコマンド (PDS メンバー・リストの取得など) が含まれます。リソース使用量は、ユーザー・アクションに大きく依存するため変動しますが、最少と予想されます。
CARMA はオプションの Developer for System z サーバーで、CA Endevor® SCM などのホスト・ベースの Software Configuration Manager (SCM) と対話するために使用されます。Developer for System z では、CARMA サーバーをさまざまな方式で始動することができ、その一部は OMVS ワークロードになります。リソース使用量は、ユーザー・アクションに大きく依存するため変動しますが、最少と予想されます。
クライアントが z/OS UNIX プロジェクトのビルドを開始すると、z/OS UNIX REXEC (または SSH) によって、ビルドを実行するための多数の z/OS UNIX シェル・コマンドを実行するタスクが開始されます。リソース使用量は、ユーザー・アクションに大きく依存するため変動しますが、プロジェクトのサイズに応じて中程度から相当量と予想されます。
このワークロードは、クライアントによって発行される z/OS UNIX シェル・コマンドを処理します。リソース使用量は、ユーザー・アクションに大きく依存するため変動しますが、最少と予想されます。
JES で管理されるバッチ処理は、Developer for System z によってさまざまに使用されます。最も一般的な用途は、MVS ビルドです。ここでは、ジョブが実行依頼され、終了のタイミングを判別するためにモニターされます。ただし、Developer for System z は、CARMA サーバーをバッチで始動し、TCP/IP を使用してそのサーバーと通信することもできます。
説明 | タスク名 | ワークロード |
---|---|---|
CARMA (バッチ) | CRA<port> | JES |
MVS ビルド (バッチ・ジョブ) | * | JES |
CARMA はオプションの Developer for System z サーバーで、CA Endevor® SCM などのホスト・ベースの Software Configuration Manager (SCM) と対話するために使用されます。Developer for System z では、CARMA サーバーをさまざまな方法で始動することができ、その一部は JES ワークロードになります。ハイパフォーマンスの 1 期間の速度目標を指定する必要があります。これは、タスクが WLM に個々のトランザクションを報告しないためです。リソース使用量は、ユーザー・アクションに大きく依存するため変動しますが、最少と予想されます。
現行の Developer for System z バージョンでは、ISPF クライアント・ゲートウェイを使用して、非対話式の TSO コマンドと ISPF コマンドが実行されます。歴史的理由から、Developer for System z は APPC トランザクションによるこれらのコマンドの実行もサポートしています。APPC 方式は推奨されないことに注意してください。
説明 | タスク名 | ワークロード |
---|---|---|
TSO コマンド・サービス (APPC) | FEKFRSRV | ASCH |
TSO コマンド・サービスは、非対話式の TSO コマンドと ISPF コマンドを実行するために、Developer for System z によって APPC トランザクション・プログラムとして開始することができます。これには、クライアントが発行する明示的なコマンドと、Developer for System z が発行する暗黙的なコマンド (PDS メンバー・リストの取得など) が含まれます。このサービス・クラスには、複数期間の目標を指定する必要があります。最初の期間には、ハイパフォーマンスのパーセンタイル応答時間目標を指定してください。最後の期間には適度なパフォーマンスの速度目標を指定してください。リソース使用量は、ユーザー・アクションに大きく依存するため変動しますが、最少と予想されます。
Application Deployment Manager は、CICS Transaction Server 領域内でアクティブになるオプションの Developer for System z サーバーです。
説明 | タスク名 | ワークロード |
---|---|---|
Application Deployment Manager | CICSTS | CICS |
CICSTS 領域でアクティブになるオプションの Application Deployment Manager サーバーでは、選択した CICSTS 管理タスクを開発者に安全にオフロードすることができます。リソース使用量は、ユーザー・アクションに大きく依存するため変動しますが、最少と予想されます。使用すべきサービス・クラスのタイプは、当該 CICS 領域内でアクティブな他のトランザクションによって異なるため、ここでは詳しく説明しません。
CICS アドレス・スペースを管理するサービス・クラスに目標が設定されます。ユーザーは、このサービス・クラスの実行速度目標のみを使用できます。WLM は、アドレス・スペースに対する JES または STC の分類規則を使用しますが、トランザクションに対する CICS サブシステムの分類規則は使用しません。
単一のトランザクションまたはトランザクションのグループに割り当てられたサービス・クラスにおいて、応答時間目標を設定することができます。WLM は、アドレス・スペースに対する JES または STC の分類規則、およびトランザクションに対する CICS サブシステムの分類規則を使用します。
Developer for System z についてで説明されているように、RSE (リモート・システム・エクスプローラー) は、Developer for System z の中核です。クライアントからの接続とワークロードを管理するために、RSE は、スレッド・プーリング・アドレス・スペースを制御するデーモン・アドレス・スペースから構成されています。デーモンは接続と管理のためのフォーカル・ポイントとして機能し、スレッド・プールはクライアント・ワークロードを処理します。
このため、RSE は Developer for System z セットアップをチューニングする場合の主要な対象となります。ただし、それぞれが 17 個以上のスレッドを使用する何百人ものユーザー、ある程度の大きさのストレージ、そして場合によっては 1 つ以上のアドレス・スペースを保守するには、Developer for System z と z/OS の両方を適切に構成する必要があります。
このセクションの情報を使用して、Developer for System z の標準のリソース使用量と最大のリソース使用量を見積もり、それに合わせてシステム構成を計画することができます。
このセクションで示す数値と数式を使用してシステム限度を定義するときには、使用する見積もり値がきわめて正確であることに留意してください。システム限度を設定するときは、一時タスクやその他のタスク、あるいは同じホストに同時に複数回接続する (例えば RSE と TN3270 経由で) ユーザーがリソースを使用できるように、十分なゆとりを残すようにします。
開始タスク | アドレス・スペース数 | プロセス数 | スレッド数 |
---|---|---|---|
JMON | 1 | 1 | 3 |
DBGMGR | 1 | 1 | 4 |
RSED | 1 | 3 | 16 |
RSEDx | (a) 1 + 2 | 1 + 3 | 1 + 14 |
必要なソフトウェア | アドレス・スペース数 | プロセス数 | スレッド数 |
---|---|---|---|
ISPF クライアント・ゲートウェイ | 1 | 2 | 4 |
APPC | 1 | 1 | 2 |
ユーザーのアクション | アドレス・スペース数 ユーザー ID |
プロセス数 ユーザー ID |
スレッド数 |
||
---|---|---|---|---|---|
ログオン | - | - | - | 17 | 1 |
アイドル・タイムアウト用のタイマー | - | - | - | 1 | - |
検索 | - | - | - | 1 | - |
PDS(E) の拡張 | ISPF | ISPF | ISPF | - | - |
データ・セットのオープン | ISPF | ISPF | ISPF | 1 | - |
TSO コマンド | ISPF | ISPF | ISPF | - | - |
z/OS UNIX シェル | 1 | 1 | 1 | 6 | - |
MVS ビルド | 1 | - | - | - | - |
z/OS UNIX ビルド | 3 | 3 | 3 | - | - |
CARMA (バッチ) | 1 | 1 | 2 | 1 | - |
CARMA (crastart) | 1 | 1 | 2 | 1 | - |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
CARMA (ispf) | 4 | 4 | 7 | 5 | - |
SCLMDT | ISPF | ISPF | ISPF | - | - |
数 | 説明 | タスク名 | 共用 | 終了のタイミング |
---|---|---|---|---|
1 | JES ジョブ・モニター | JMON | はい | なし |
1 | デバッグ・マネージャー | DBGMGR | はい | なし |
1 | RSE デーモン | RSED | はい | なし |
1 | RSE デーモン (APF 許可済み) | RSEDx | はい | なし |
(a) | RSE スレッド・プール | RSEDx | はい | なし |
(a) | RSE スレッド・プール (APF 許可済み) | RSEDx | はい | なし |
1u | ISPF クライアント・ゲートウェイ (TSO コマンド・サービスおよび SCLMDT) | <userid>x | いいえ | 15 分後またはユーザー・ログオフ後 |
1u | TSO コマンド・サービス (APPC) | FEKFRSRV | いいえ | 60 分後またはユーザー・ログオフ後 |
1u | CARMA (バッチ) | CRA<port> | いいえ | 7 分後またはユーザー・ログオフ後 |
1u | CARMA (crastart) | <userid>x | いいえ | 7 分後またはユーザー・ログオフ後 |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
4u | CARMA (ispf、非推奨) | (1)<userid> または (3)<userid>x | いいえ | 7 分後またはユーザー・ログオフ後 |
(b) | 1 人のユーザーによる ISPF クライアント・ゲートウェイの同時使用 | <userid>x | いいえ | タスク完了後 |
1u | MVS ビルド (バッチ・ジョブ) | * | いいえ | タスク完了後 |
3u | z/OS UNIX ビルド (シェル・コマンド) | <userid>x | いいえ | タスク完了後 |
1u | z/OS UNIX シェル | <userid> | いいえ | ユーザー・ログオフ後 |
X | SCLMDT | クライアント・ゲートウェイ経由の TSO | APPC 経由の TSO |
---|---|---|---|
1 | いいえ | いいえ | はい |
1 | いいえ | はい | いいえ |
1 | はい | はい | いいえ |
y | |
---|---|
0 | CARMA なし |
1 | CARMA (バッチ) |
1 | CARMA (crastart) |
![]() ![]() |
![]() ![]() |
4 | CARMA (ispf、非推奨) |
ロケーション | 限度 | 影響を受けるリソース |
---|---|---|
rsed.envvars | maximum.threadpool.process | RSE スレッド・プールの数を制限します。 |
IEASYMxx | MAXUSER | アドレス・スペースの数を制限します。 |
ASCHPMxx | MAX | TSO コマンド・サービス (APPC) での APPC イニシエーターの数を制限します。 |
プロセス数 | アドレス・スペース数 | 説明 | ユーザー ID |
---|---|---|---|
1 | 1 | JES ジョブ・モニター | STCJMON |
1 | 1 | デバッグ・マネージャー | STCDBM |
3 | 1 | RSE デーモン | STCRSE |
1 | 1 | RSE デーモン (APF 許可済み) | STCRSE |
2 | (a) | RSE スレッド・プール | STCRSE |
1 | (a) | RSE スレッド・プール (APF 許可済み) | STCRSE |
2 | (b) | ISPF クライアント・ゲートウェイ (TSO コマンド・サービスおよび SCLMDT) | <userid> |
2 | (a) | RSE スレッド・プール | STCRSE |
1 | 1u | TSO コマンド・サービス (APPC) | <userid> |
1 | 1u | CARMA (バッチ) | <userid> |
1 | 1u | CARMA (crastart) | <userid> |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
1 | 1u | CARMA (ispf、非推奨) | <userid> |
1 | 3u | z/OS UNIX ビルド (シェル・コマンド) | <userid> |
1 | 1u | z/OS UNIX シェル | <userid> |
(5) | (u) | SCLM Developer Toolkit | <userid> |
X | SCLMDT | クライアント・ゲートウェイ経由の TSO | APPC 経由の TSO |
---|---|---|---|
1 | いいえ | いいえ | はい |
2 | いいえ | はい | いいえ |
7 | はい | はい | いいえ |
y | |
---|---|
0 | CARMA なし |
1 | CARMA (バッチ) |
1 | CARMA (crastart) |
![]() ![]() |
![]() ![]() |
4 | CARMA (ispf、非推奨) |
ロケーション | 限度 | 影響を受けるリソース |
---|---|---|
BPXPRMxx | MAXPROCSYS | プロセスの総数を制限します。 |
BPXPRMxx | MAXPROCUSER | z/OS UNIX UID ごとのプロセスの数を制限します。 |
OMVS セグメント | PROCUSERMAX | ユーザー ID のプロセスの数を制限します。 |
スレッド数 |
ユーザー ID | 説明 | ||
---|---|---|---|---|
RSEDx | アクティブ | ブートストラップ | ||
- | (f) 3 + 1u | - | STCJMON | JES ジョブ・モニター |
- | 4 | - | STCDBM | デバッグ・マネージャー |
- | 14 | 2 | STCRSE | RSE デーモン |
- | 1 | - | STCRSE | RSE デーモン (APF 許可済み) |
(a,g) 12 + 8u | - | (a) 1 | STCRSE | RSE スレッド・プール (単一スレッド・マイナー) |
(a,g) 12 + 19u | - | (a) 1 | STCRSE | RSE スレッド・プール (マルチスレッド・マイナー) |
- | (a) 1 | - | STCRSE | RSE スレッド・プール (APF 許可済み) |
- | (b) 4u | (b) 1u | <userid> | ISPF クライアント・ゲートウェイ (TSO コマンド・サービスおよび SCLMDT) |
- | 2u | - | <userid> | TSO コマンド・サービス (APPC) |
1u | 2u | - | STCRSE および <userid> | CARMA (バッチ) |
![]() ![]() |
2u | - | STCRSE および <userid> | CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
5u | 4u | 3u | STCRSE および <userid> | CARMA (ispf、非推奨) |
- | (c) 1u | 2u | <userid> | z/OS UNIX ビルド (シェル・コマンド) |
6u | 1u | - | STCRSE および <userid> | z/OS UNIX シェル |
(d) 1 | - | - | STCRSE | ダウンロード |
(e) 1 | - | - | STCRSE | 検索 |
- | (5) | - | <userid> | SCLM Developer Toolkit |
1u | - | - | STCRSE | アイドル・タイムアウト用のタイマー |
X | SCLMDT | クライアント・ゲートウェイ経由の TSO | APPC 経由の TSO | タイムアウト |
---|---|---|---|---|
0 | いいえ | いいえ | はい | いいえ |
0 | いいえ | はい | いいえ | いいえ |
0 | はい | はい | いいえ | いいえ |
1 | いいえ | いいえ | はい | はい |
1 | いいえ | はい | いいえ | はい |
1 | はい | はい | いいえ | はい |
y | |
---|---|
0 | CARMA なし |
1 | CARMA (バッチ) |
![]() ![]() |
CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
5 | CARMA (ispf、非推奨) |
ロケーション | 限度 | 影響を受けるリソース |
---|---|---|
OMVS セグメント | THREADSMAX | ユーザー ID のスレッドの数を制限します |
BPXPRMxx | MAXTHREADS | プロセス内のスレッドの数を制限します。 |
BPXPRMxx | MAXTHREADTASKS | プロセス内の MVS タスクの数を制限します。 |
BPXPRMxx | MAXASSIZE | アドレス・スペース・サイズを制限し、それによってスレッドに関連する制御ブロックで使用可能なストレージの大きさを制限します。 |
rsed.envvars | Xmx | Java ヒープ・サイズの最大値を設定します。このストレージは予約され、スレッドに関連する制御ブロックには使用できなくなります。 |
rsed.envvars | maximum.clients | RSE スレッド・プール内のクライアント (およびそのスレッド) の数を制限します。 |
rsed.envvars | maximum.threads | RSE スレッド・プール内のクライアント・スレッドの数を制限します。 |
FEJJCNFG | MAX_THREADS | JES ジョブ・モニターでのスレッドの数を制限します。 |
この前までのセクションで説明したリソース使用量は、Developer for System z の存続期間に対して永続的、または特定のユーザー固有のタスクに対して半永続的です。
スレッド数 |
ユーザー ID | 説明 | ||
---|---|---|---|---|
RSEDx | アクティブ | ブートストラップ | ||
- | (f) 3 + 1u | - | STCJMON | JES ジョブ・モニター |
- | 4 | - | STCDBM | デバッグ・マネージャー |
- | 14 | 2 | STCRSE | RSE デーモン |
- | 1 | - | STCRSE | RSE デーモン (APF 許可済み) |
(a,g) 12 + 8u | - | (a) 1 | STCRSE | RSE スレッド・プール (単一スレッド・マイナー) |
(a,g) 12 + 19u | - | (a) 1 | STCRSE | RSE スレッド・プール (マルチスレッド・マイナー) |
- | (a) 1 | - | STCRSE | RSE スレッド・プール (APF 許可済み) |
- | (b) 4u | (b) 1u | <userid> | ISPF クライアント・ゲートウェイ (TSO コマンド・サービスおよび SCLMDT) |
- | 2u | - | <userid> | TSO コマンド・サービス (APPC) |
1u | 2u | - | STCRSE および <userid> | CARMA (バッチ) |
![]() ![]() |
2u | - | STCRSE および <userid> | CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
![]() ![]() |
5u | 4u | 3u | STCRSE および <userid> | CARMA (ispf、非推奨) |
- | (c) 1u | 2u | <userid> | z/OS UNIX ビルド (シェル・コマンド) |
6u | 1u | - | STCRSE および <userid> | z/OS UNIX シェル |
(d) 1 | - | - | STCRSE | ダウンロード |
(e) 1 | - | - | STCRSE | 検索 |
- | (5) | - | <userid> | SCLM Developer Toolkit |
1u | - | - | STCRSE | アイドル・タイムアウト用のタイマー |
X | SCLMDT | クライアント・ゲートウェイ経由の TSO | APPC 経由の TSO | タイムアウト |
---|---|---|---|---|
0 | いいえ | いいえ | はい | いいえ |
0 | いいえ | はい | いいえ | いいえ |
0 | はい | はい | いいえ | いいえ |
1 | いいえ | いいえ | はい | はい |
1 | いいえ | はい | いいえ | はい |
1 | はい | はい | いいえ | はい |
y | |
---|---|
0 | CARMA なし |
1 | CARMA (バッチ) |
![]() ![]() |
CARMA (crastart) |
![]() ![]() ![]() ![]() |
![]() ![]() |
5 | CARMA (ispf、非推奨) |
ロケーション | 限度 | 影響を受けるリソース |
---|---|---|
OMVS セグメント | THREADSMAX | ユーザー ID のスレッドの数を制限します |
BPXPRMxx | MAXTHREADS | プロセス内のスレッドの数を制限します。 |
BPXPRMxx | MAXTHREADTASKS | プロセス内の MVS タスクの数を制限します。 |
BPXPRMxx | MAXASSIZE | アドレス・スペース・サイズを制限し、それによってスレッドに関連する制御ブロックで使用可能なストレージの大きさを制限します。 |
rsed.envvars | Xmx | Java ヒープ・サイズの最大値を設定します。このストレージは予約され、スレッドに関連する制御ブロックには使用できなくなります。 |
rsed.envvars | maximum.clients | RSE スレッド・プール内のクライアント (およびそのスレッド) の数を制限します。 |
rsed.envvars | maximum.threads | RSE スレッド・プール内のクライアント・スレッドの数を制限します。 |
FEJJCNFG | MAX_THREADS | JES ジョブ・モニターでのスレッドの数を制限します。 |
RSE は Java アプリケーションであるため、Developer for System z でのストレージ (メモリー) 使用量を計画する際には、ストレージの割り振りに関する 2 つの限度を考慮に入れる必要があります。それは、Java ヒープ・サイズとアドレス・スペース・サイズです。
Java は、Java アプリケーションのコーディング作業を軽減する多数のサービスを提供しています。そのサービスの 1 つがストレージ管理です。
Java のストレージ管理では、大きなストレージ・ブロックが割り振られ、アプリケーションからの保管要求に使用されます。Java で管理されるこのストレージは、Java ヒープと呼ばれます。定期的なガーベッジ・コレクション (デフラグ) が、ヒープ内の使用されていないスペースをレクラメーション処理して、そのサイズを小さくします。CPU サイクルを節約するため、ガーベッジ・コレクションは、占有しているストレージが実際に必要になるまで待機することがよくあり、すでに使用されていないストレージを、必要以上に長い時間割り振られたままにしている (ページアウトになっている)ことに注意してください。
Java ヒープ・サイズの最大値は、rsed.envvars 内の Xmx ディレクティブで定義されます。このディレクティブが指定されていない場合、Java はデフォルト・サイズの 512 MB を使用します。256 MB 以上の値を指定する必要があります。64 ビット・モードで実行中の場合、Java は、境界より下のスペースを解放して、2 GB 境界より上のヒープを割り振ろうとします。
各 RSE スレッド・プール (クライアントのアクションをサービスします) は独立した Java アプリケーションであり、そのために専用の Java ヒープを使用します。スレッド・プールはいずれも同じ rsed.envvars 構成ファイルを使用するため、Java ヒープ・サイズの限度が同じであることに注意してください。
スレッド・プールによる Java ヒープの使用量は、接続されているクライアントが実行するアクションによって大きく異なります。最適なヒープ・サイズの限度を設定するには、ヒープの使用量を定期的にモニターすることが必要です。RSE スレッド・プールによる Java ヒープの使用量をモニターするには、modify display process オペレーター・コマンドを使用します。
Java アプリケーションを含むすべての z/OS アプリケーションは、アドレス・スペース内でアクティブとなるため、アドレス・スペース・サイズの限度によって制約を受けます。
RSE スレッド・プールは、RSE デーモンからアドレス・スペース・サイズの限度を継承します。アドレス・スペース・サイズは、Java ヒープ、Java 自体、共通ストレージ域、およびシステムがスレッド・プール・アクティビティーをサポートするために作成する全制御ブロック (スレッドごとの TCB (タスク制御ブロック) など) を収容できるだけの大きさであることが必要です。このストレージの使用量の一部は 16 MB 境界より下にあるので注意してください。64 ビット・モードで実行中の場合、Java は、境界より下のスペースを解放して、2 GB 境界より上のヒープを割り振ろうとします。
アドレス・スペース・サイズに影響する設定 (Java ヒープのサイズや 1 つのスレッド・プールでサポートされるユーザー数など) を変更する前に、実際のアドレス・スペース・サイズをモニターする必要があります。Developer for System z による実際のストレージ使用量を追跡するには、通常使用しているシステム・モニター・ソフトウェアを使用します。専用のモニター・ツールがない場合は、SDSF DA ビューや TASID などのツール (ISPF の「Support and downloads」Web ページで入手できる無保証のシステム情報ツール) で基本情報を収集できます。
RSE の始動時に、コンソール・メッセージ FEK004I で、現行の Java ヒープおよびアドレス・スペース・サイズの限度が表示されるので注意してください。
参照用に、表 33 には、 実際の Developer for System z カスタマーが、 キー rsed.envvars 設定として使用する値を示します。これはストレージ使用量に影響を与えます。
xmx (最大 Java ヒープ) | maximum.clients | 主な開発のタイプ |
---|---|---|
512M | 30 | PL/I |
512M | 10 | COBOL |
384M | 12 | COBOL |
800M (64 ビット) | 20 | 指定なし |
Max Heap Size=10MB and private AS Size=1,959MB
startup
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(7%) Clients(0)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2740 72
RSED 4.47 32.8M 15910
RSED8 1.15 27.4M 12612
logon 1
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 81
RSED 4.55 32.8M 15980
RSED8 3.72 55.9M 24128
logon 2
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(23%) Clients(2)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.02 2944 86
RSED 4.58 32.9M 16027
RSED8 4.20 57.8M 25205
logon 3
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(37%) Clients(3)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.02 3020 91
RSED 4.60 32.9M 16076
RSED8 4.51 59.6M 26327
logon 4
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(41%) Clients(4)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.02 3108 96
RSED 4.61 32.9M 16125
RSED8 4.77 62.3M 27404
logon 5
BPXM023I (STCRSE)
ProcessId(268 ) Memory Usage(41%) Clients(4)
ProcessId(33554706) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.03 3184 101
RSED 4.64 32.9M 16229
RSED8 4.78 62.4M 27413
RSED9 4.60 56.6M 24065
Max Heap Size=10MB and private AS Size=1,959MB
startup
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(7%) Clients(0)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2736 71
RSED 4.35 32.9M 15117
RSED8 1.43 27.4M 12609
logon
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 80
RSED 4.48 33.0M 15187
RSED8 3.53 53.9M 24125
expand large MVS tree (195 data sets)
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.01 2864 80
RSED 4.58 33.1M 16094
RSED8 4.28 56.1M 24740
expand small PDS (21 members)
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
IBMUSER2 0.22 2644 870
JMON 0.01 2864 80
RSED 4.61 33.1M 16108
RSED8 4.40 56.2M 24937
open medium sized member (86 lines)
BPXM023I (STCRSE)
ProcessId(212 ) Memory Usage(13%) Clients(1)
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
IBMUSER2 0.22 2644 870
JMON 0.01 2864 80
RSED 4.61 33.1M 16108
RSED8 8.12 62.7M 27044
DD ステートメントに書き込まれない Developer for System z 関連データのほとんどは、最終的に z/OS UNIX ファイルに格納されます。システム・プログラマーは、どのデータが書き込まれ、どこに格納されるかを制御できます。ただし、書き込まれるデータの量を制御することはできません。
デフォルトでは、エラー・メッセージと警告メッセージだけがログに書き込まれます。そのため、すべてが計画したとおりに進めば、上記のディレクトリーにはほとんど、またはまったくファイルが存在しないはずです (監査ログは対象外です)。
情報メッセージのロギングを有効にすることができますが (本来は IBM サポートの指示の下で行います)、ログ・ファイルのサイズが著しく増大します。
startup
$ ls -l /var/rdz/logs/server
total 144
-rw-rw-rw- 1 STCRSE STCGRP 33642 Jul 10 12:10 rsedaemon.log
-rw-rw-rw- 1 STCRSE STCGRP 1442 Jul 10 12:10 rseserver.log
logon
$ ls -l /var/rdz/logs/server
total 144
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 1893 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 160
-rw------- 1 IBMUSER SYS1 3459 Jul 10 12:11 ffs.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log
-rw------- 1 IBMUSER SYS1 303 Jul 10 12:11 ffslock.log
-rw------- 1 IBMUSER SYS1 7266 Jul 10 12:11 rsecomm.log
logoff
$ ls -l /var/rdz/logs/server
total 80
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 2208 Jul 10 12:11 rseserver.log
$ ls -l /var/rdz/logs/IBMUSER
total 296
-rw------- 1 IBMUSER SYS1 6393 Jul 10 12:11 ffs.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsget.log
-rw------- 1 IBMUSER SYS1 0 Jul 10 12:11 ffsput.log
-rw------- 1 IBMUSER SYS1 609 Jul 10 12:11 ffslock.log
-rw------- 1 IBMUSER SYS1 45157 Jul 10 12:11 rsecomm.log
stop
$ ls -l /var/rdz/logs/server
total 80
-rw------- 1 STCRSE STCGRP 36655 Jul 10 12:11 rsedaemon.log
-rw------- 1 STCRSE STCGRP 2490 Jul 10 12:12 rseserver.log
監査ログ以外のログ・ファイルは、再始動 (RSE 開始タスクの場合) またはログオン (クライアントの場合) のたびに上書きされて、合計サイズを抑えます。監査ログは、audit.retention.period で指定された間隔が経過すると削除されます。 この動作は、rsed.envvars 内の keep.last.log ディレクティブによって多少変わります。このディレクティブでは、前のログのコピーを残すように RSE に指示できるからです。それより古いコピーは必ず除去されます。rsed.envvars 内の keep.all.logs ディレクティブが有効になると、すべてのログの名前にタイム・スタンプが追加され、log.retention.period で指定された間隔が経過するとファイルが削除されます。
ログ・ファイルを保持しているファイル・システムのフリー・スペースが不足してくると、コンソールに警告メッセージが送信されます。このコンソール・メッセージ (FEK103E) は、スペース不足の問題が解決されるまで定期的に繰り返されます。ファイル・システムがスペース不足になると、RSE は既存のログ・ファイルを削除してスペースを解放しようとします。 監査ログはこの処理の影響を受けません。
ロケーション | ディレクティブ | 機能 |
---|---|---|
resecomm.properties | debug_level | デフォルトのログ詳細レベルを設定します。 |
rsecomm.properties | USER | 指定されたユーザーに対して debug_level 2 を使用可能にします。 |
rsed.envvars | keep.all.logs | 開始/ログオン前に、前のログのコピーを保存します。 |
rsed.envvars | keep.last.log | 開始/ログオン前に、前のログのコピーを保存します。 |
rsed.envvars | enable.audit.log | クライアント・アクションの監査トレースを保存します。 |
rsed.envvars | enable.standard.log | スレッド・プール (1 つまたは複数) の stdout および stderr ストリームをログ・ファイルに書き込みます。 |
rsed.envvars | DSTORE_TRACING_ON | DataStore アクションのロギングを有効にします。 |
rsed.envvars | DSTORE_MEMLOGGING_ON | DataStore メモリー使用量のロギングを有効にします。 |
オペレーター・コマンド | modify rsecommlog <level> | rsecomm.log のログ詳細レベルを動的に変更します。 |
オペレーター・コマンド | modify rsedaemonlog <level> | rsedaemon.log のログ詳細レベルを動的に変更します。 |
オペレーター・コマンド | modify rseserverlog <level> | rseserver.log のログ詳細レベルを動的に変更します。 |
オペレーター・コマンド | modify rsestandardlog {on|off} | std*.*.log の更新を動的に変更します。 |
オペレーター・コマンド | modify trace {on|off} USER=userid | 指定されたユーザーに対して debug_level 2 を使用可能にします。 |
オペレーター・コマンド | modify trace {on|off} SERVER=pid | 指定されたユーザーに対して debug_level 2 を使用可能にします。 |
オペレーター・コマンド | modify trace clear | トレースのセットアップを使用不可にします。 |
オペレーター・コマンド | modify logs | ホスト・ログおよびセットアップ情報を収集します。 |
rsed.envvars | daemon.log | RSE 開始タスク・ログおよび監査ログのホーム・パス。 |
rsed.envvars | user.log | ユーザー・ログのホーム・パス |
rsed.envvars | CGI_ISPWORK | ISPF クライアント・ゲートウェイ・ログのホーム・パス |
rsed.envvars | TMPDIR | IVP ログおよび modify logs オペレーター・コマンドのディレクトリー |
rsed.envvars | _CEE_DMPTARG | Java ダンプのディレクトリー |
これに加えて、Developer for System z は、ISPF クライアント・ゲートウェイなどの必要なソフトウェアとともに、一時データを /tmp および /var/rdz/WORKAREA に書き込みます。ユーザー・アクションの結果としてここに書き込まれるデータの量は予測不能であるため、これらのディレクトリーを保持するファイル・システムに十分なフリー・スペースを確保しておく必要があります。
Developer for System z は、これらの一時ファイルのクリーンアップを常時試みますが、「ホスト構成ガイド」 (SC88-5663)の『(オプション) WORKAREA と /tmp クリーンアップ』で説明しているように、手動でのクリーンアップも随時実行できます。
ロケーション | ディレクティブ | 機能 |
---|---|---|
rsed.envvars | CGI_ISPWORK | 一時データのホーム・パス |
rsed.envvars | TMPDIR | 一時データのディレクトリー |
rsed.envvars で定義されている環境変数は、RSE、Java、および z/OS UNIX によって使用されます。Developer for System z 付属のサンプル・ファイルは、Developer for System z のオプション・コンポーネントを必要としない小規模から中規模のインストール済み環境を対象としています。サンプル・ファイルに定義されている各変数については、「ホスト構成ガイド」 (SC88-5663) の『rsed.envvars、RSE 構成ファイル』で説明していますが、以下の変数には特に注意が必要です。
RSE は Java アプリケーションであるため、z/OS UNIX 環境でアクティブになります。このため、z/OS UNIX の環境とファイル・システムを制御するパラメーターを含んでいる BPXPRMxx は、非常に重要な parmlib メンバーとなります。BPXPRMxx については、「MVS 初期設定およびチューニング解説書」(SA88-8564) で説明されています。Developer for System z に影響することがわかっているディレクティブは以下のとおりです。
値の範囲: nnnnn は 5 から 32767 までの 10 進値です。
デフォルト: 900
値の範囲: nnnnn は 3 から 32767 までの 10 進値です。
デフォルト: 25
値の範囲: nnnnnn は 0 から 100000 までの 10 進値です。
デフォルト: 200
値の範囲: nnnnn は 0 から 32768 までの 10 進値です。
デフォルト: 1000
値の範囲: nnnnn は 1 から 32767 までの 10 進値です。
デフォルト: 200
値の範囲: nnnnn は 10485760 (10 MB) から 2147483647 (2 GB) までの
10 進値です。
デフォルト: 209715200 (200 MB)
値の範囲: nnnnnn は 3 から 524287 までの 10 進値です。
デフォルト: 64000
値の範囲: nnnnn は 1 から 16777216 までの 10 進値です。
デフォルト: 40960
元の BPXPRMxx 変数の値を動的に (次回の IPL まで) 増減させるには、オペレーター・コマンド SETOMVS または SET OMVS を使用します。永続的な変更を加える場合は、IPL に使用される BPXPRMxx メンバーを編集します。これらのオペレーター・コマンドの詳細については、「MVS システム・コマンド」(SA88-8593) を参照してください。
以下の定義は、NETWORK ステートメントのサブパラメーターです。
値の範囲: nnnnnnnn は 0 から 16777215 までの 10 進値です。
デフォルト: 100
値の範囲: nnnn は 1 から 4000 までの 10 進値です。
デフォルト: INADDRANYPORT と INADDRANYCOUNT がどちらも
指定されていない場合、INADDRANYCOUNT の
デフォルトは 1000 です。
それ以外の場合はポートが予約されません (0)。
以下の定義は、Developer for System z サーバーの JCL の EXEC カードに追加することをお勧めします。
FEJJCNFG で定義されている環境変数は、JES ジョブ・モニターで使用されます。Developer for System z 付属のこのサンプル・ファイルは、小規模から中規模のインストール済み環境を対象としています。サンプル・ファイルに定義されている各変数については、「ホスト構成ガイド」 (SC88-5663) の『FEJJCNFG、JES ジョブ・モニター構成ファイル』で説明していますが、以下の変数には特に注意が必要です。
IEASYSxx はシステム・パラメーターを保持するもので、「MVS 初期設定およびチューニング解説書」(SA88-8564) に説明があります。Developer for System z に影響することがわかっているディレクティブは以下のとおりです。
値の範囲: nnnnn は 0 から 32767 までの 10 進値です。
MAXUSER、RSVSTRT、および RSVNONR の各システム・
パラメーターに指定された値の合計は 32767 以下で
なければならないので注意してください。
デフォルト値: 255
IVTPRMxx は通信ストレージ・マネージャー (CSM) のパラメーターを設定するもので、「MVS 初期設定およびチューニング解説書」(SA88-8564) に説明があります。Developer for System z に影響することがわかっているディレクティブは以下のとおりです。
値の範囲: 1024K から 2048M までの値。
デフォルト: 100M
値の範囲: 1024K から 2048M までの値。
デフォルト: 100M
ASCHPMxx parmlib メンバーは、ASCH トランザクション・スケジューラーのスケジューリング情報を格納するもので、「MVS 初期設定およびチューニング解説書」(SA88-8564) に説明があります。Developer for System z に影響することがわかっているディレクティブは以下のとおりです。
値の範囲: nnnnn は 1 から 64000 までの 10 進値です。
デフォルト: 1
ユーザーのワークロードによってシステム・リソースの必要性が変わる可能性があるため、ユーザーの要件に応じて Rational Developer for System z とシステムの構成を調整できるように、定期的にシステムをモニターしてリソース使用量を測定する必要があります。このモニター処理に役立つコマンドを以下に示します。
FEK004I RseDaemon: Max Heap Size=65MB and private AS Size=1,959MB
f rsed,appl=d p
BPXM023I (STCRSE)
ProcessId(16777456) Memory Usage(33%) Clients(4) Order(1)
f rsed,appl=d p,detail
BPXM023I (STCRSE)
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1)
PROCESS LIMITS: CURRENT HIGHWATER LIMIT
JAVA HEAP USAGE(%) 10 56 100
CLIENTS 0 25 30
MAXFILEPROC 83 103 64000
MAXPROCUSER 97 99 200
MAXTHREADS 9 14 1500
MAXTHREADTASKS 9 14 1500
f rsed,appl=d p,cpu
BPXM023I (STCRSE)
ProcessId(33555087) ASId(002E) JobName(RSED8) Order(1)
USERID THREAD-ID TCB@ ACC_TIME TAG
STCRSE 0EDE540000000000 005E6B60 822 1/ThreadPoolProcess
STCRSE 0EDE870000000001 005E69C8 001
STCRSE 0EDE980000000002 005E6518 1814
STCRSE 0EDEBA0000000003 005E66B0 2305
STCRSE 0EDECB0000000004 005E62F8 001
STCRSE 0EDEDC0000000005 005E60D8 001
STCRSE 0EDF860000000006 005C2BF8 628 6/ThreadPoolMonitor$Memory
UsageMonitor
STCRSE 0EDF970000000007 005C2D90 003 7/ThreadPoolMonitor
IBMUSER 0EE2C70000000024 005C08B0 050 38/JESMiner
IBMUSER 0EE2B60000000026 005C0690 004 40/FAMiner
IBMUSER 0EE30B0000000027 005C0250 002 41/LuceneMiner
IBMUSER 0EE31C0000000028 005C0030 002 42/CDTParserMiner
IBMUSER 0EE32D0000000029 005BDE00 002 43/MVSLuceneMiner
IBMUSER 0EE33E000000002A 005BDBE0 002 44/CDTMVSParserMiner
Developer for System z に関係する z/OS UNIX の限度のほとんどは、オペレーター・コマンドを使用して表示できます。一部のコマンドでは、特定の限度に関する現在の使用率と最高水準点も示されます。これらのコマンドの詳細については、「MVS システム・コマンド」(SA88-8593) を参照してください。
d omvs,o
BPXO043I 13.10.16 DISPLAY OMVS 066
OMVS 000D ETC/INIT WAIT OMVS=(M7)
CURRENT UNIX CONFIGURATION SETTINGS:
MAXPROCSYS = 256 MAXPROCUSER = 16
MAXFILEPROC = 256 MAXFILESIZE = NOLIMIT
MAXCPUTIME = 1000 MAXUIDS = 200
MAXPTYS = 256
MAXMMAPAREA = 256 MAXASSIZE = 209715200
MAXTHREADS = 200 MAXTHREADTASKS = 1000
MAXCORESIZE = 4194304 MAXSHAREPAGES = 4096
IPCMSGQBYTES = 2147483647 IPCMSGQMNUM = 10000
IPCMSGNIDS = 500 IPCSEMNIDS = 500
IPCSEMNOPS = 25 IPCSEMNSEMS = 1000
IPCSHMMPAGES = 25600 IPCSHMNIDS = 500
IPCSHMNSEGS = 500 IPCSHMSPAGES = 262144
SUPERUSER = BPXROOT FORKCOPY = COW
STEPLIBLIST =
USERIDALIASTABLE=
SERV_LINKLIB = POSIX.DYNSERV.LOADLIB BPXLK1
SERV_LPALIB = POSIX.DYNSERV.LOADLIB BPXLK1
PRIORITYPG VALUES: NONE
PRIORITYGOAL VALUES: NONE
MAXQUEUEDSIGS = 1000 SHRLIBRGNSIZE = 67108864
SHRLIBMAXPAGES = 4096 VERSION = /
SYSCALL COUNTS = NO TTYGROUP = TTY
SYSPLEX = NO BRLM SERVER = N/A
LIMMSG = NONE AUTOCVT = OFF
RESOLVER PROC = DEFAULT
AUTHPGMLIST = NONE
SWA = BELOW
d omvs,l
BPXO051I 14.05.52 DISPLAY OMVS 904
OMVS 0042 ACTIVE OMVS=(69)
SYSTEM WIDE LIMITS: LIMMSG=SYSTEM
CURRENT HIGHWATER SYSTEM
USAGE USAGE LIMIT
MAXPROCSYS 1 4 256
MAXUIDS 0 0 200
MAXPTYS 0 0 256
MAXMMAPAREA 0 0 256
MAXSHAREPAGES 0 10 4096
IPCMSGNIDS 0 0 500
IPCSEMNIDS 0 0 500
IPCSHMNIDS 0 0 500
IPCSHMSPAGES 0 0 262144 *
IPCMSGQBYTES --- 0 262144
IPCMSGQMNUM --- 0 10000
IPCSHMMPAGES --- 0 256
SHRLIBRGNSIZE 0 0 67108864
SHRLIBMAXPAGES 0 0 4096
このコマンドで PID=processid キーワードを指定すると、個々のプロセスの最高水準点と現行の使用量が表示されます。
d,omvs,l,pid=16777456
BPXO051I 14.06.28 DISPLAY OMVS 645
OMVS 000E ACTIVE OMVS=(76)
USER JOBNAME ASID PID PPID STATE START CT_SECS
STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914
LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs -
PROCESS LIMITS: LIMMSG=NONE
CURRENT HIGHWATER PROCESS
USAGE USAGE LIMIT
MAXFILEPROC 83 103 256
MAXFILESIZE --- --- NOLIMIT
MAXPROCUSER 97 99 200
MAXQUEUEDSIGS 0 1 1000
MAXTHREADS 9 14 200
MAXTHREADTASKS 9 14 1000
IPCSHMNSEGS 0 0 500
MAXCORESIZE --- --- 4194304
MAXMEMLIMIT 0 0 16383P
d omvs,p
BPXO046I 14.35.38 DISPLAY OMVS 092
OMVS 000E ACTIVE OMVS=(33)
PFS CONFIGURATION INFORMATION
PFS TYPE DESCRIPTION ENTRY MAXSOCK OPNSOCK HIGHUSED
TCP SOCKETS AF_INET EZBPFINI 50000 244 8146
UDS SOCKETS AF_UNIX BPXTUINT 64 6 10
ZFS LOCAL FILE SYSTEM IOEFSCM
14:32.00 RECYCLING
HFS LOCAL FILE SYSTEM GFUAINIT
BPXFTCLN CLEANUP DAEMON BPXFTCLN
BPXFTSYN SYNC DAEMON BPXFTSYN
BPXFPINT PIPE BPXFPINT
BPXFCSIN CHAR SPECIAL BPXFCSIN
NFS REMOTE FILE SYSTEM GFSCINIT
PFS NAME DESCRIPTION ENTRY STATUS FLAGS
TCP41 SOCKETS EZBPFINI ACT CD
TCP42 SOCKETS EZBPFINI ACT
TCP43 SOCKETS EZBPFINI INACT SD
TCP44 SOCKETS EZBPFINI INACT
PFS PARM INFORMATION
HFS SYNCDEFAULT(60) FIXED(50) VIRTUAL(100)
CURRENT VALUES: FIXED(55) VIRTUAL(100)
NFS biod(6)
d omvs,pid=16777456
BPXO040I 15.30.01 DISPLAY OMVS 637
OMVS 000E ACTIVE OMVS=(76)
USER JOBNAME ASID PID PPID STATE START CT_SECS
STCRSE RSED8 007E 16777456 67109106 HF---- 20.00.56 113.914
LATCHWAITPID= 0 CMD=java -Ddaemon.log=/var/rdz/logs -
THREAD_ID TCB@ PRI_JOB USERNAME ACC_TIME SC STATE
0E08A00000000000 005E6DF0 OMVS .927 RCV FU
0E08F00000000001 005E6C58 .001 PTX JYNV
0E09300000000002 005E6AC0 7.368 PTX JYNV
0E0CB00000000008 005C2CF0 OMVS 1.872 SEL JFNV
0E192000000003CE 005A0B70 OMVS IBMUSER 14.088 POL JFNV
0E18D000000003CF 005A1938 IBMUSER .581 SND JYNV
Developer for System z は、z/OS UNIX ファイル・システムを使用して、ログや一時ファイルなどのさまざまなタイプのデータを保管します。z/OS UNIX の df コマンドを使用すると、基礎となる HFS または zFS データ・セットの次のエクステントを作成する前に、まだ使用可能なファイル記述子の数とフリー・スペースの残量を確認することができます。
$ df
Mounted on Filesystem Avail/Total Files Status
/tmp (OMVS.TMP) 1393432/1396800 4294967248 Available
/u/ibmuser (OMVS.U.IBMUSER) 1248/1728 4294967281 Available
/usr/lpp/rdz (OMVS.LPP.FEK) 3062/43200 4294967147 Available
/var (OMVS.VAR) 27264/31680 4294967054 Available
デフォルトでは、Developer for System z は単一のスレッド・プールに 30 ユーザーを追加しようとします。ただし上記の要件では、非アクティブ・タイムアウトをアクティブにするように指定しています。このために、接続されているクライアントごとに 1 つずつスレッドが追加されることが 表 31 からわかります。このスレッドはタイマー・スレッドであるため、常にアクティブです。したがって 10+30*(17+1)=550 となり、かつ maximum.threads がデフォルトで 520 に設定されているので、RSE は単一スレッド・プールに 30 ユーザーを配置できなくなります。
maximum.threads を増やすことはできますが、ユーザー当たりの Java ヒープを平均 20 MB にするという要件があるため、maximum.clients を 25 (10+25*18 = 460) まで下げることにしました。これで Java ヒープ・サイズの最大値がデフォルトの 512 MB 以内に収まります (20*25 = 500)。
スレッド・プール当たりのクライアント数が 25 であり、サポートの必要な接続数が 500 であることから、必要なスレッド・プール・アドレス・スペースの数は 20 であることがわかりました。
3 + 2*A + N*(x + y + z) + (2 + N*0.01)
3 + 2*20 + 500*1 + 200*1 + 300*1 + (2 + 500*0.01) = 1050
x + y + z
1 + 1 + 1 = 3
6 + 3*A + N*(x + y + z) + (10 + N*0.05)
6 + 3*20 + 500*2 + 200*1 + 300*0 + (10 + 500*0.05) = 1591
4 + 3*A
4 + 3*20 = 64
(x + y + z) + 5*s
(2 + 1 + 0) + 5*0 = 3
12 + N*(19 + x + y + z) + (20 + N*0.1)
12 + 25*(19 + 1 + 4 + 0) + (20 + 25*0.1) = 635
3 + N+ (20 + N*0.1)
3 + 500+ (20 + 500*0.1) = 573
4
4
500 + 3 = 503
追加されている 3 つのユーザー ID は、Developer for System z 開始タスクのユーザー ID である STCJMON、STCDBM、および STCRSE です。
変更なし
変更なし
この変更はオプションです。RSE は必要に応じて新しいスレッド・プールを開始します。
最小は 1591、Developer
for System z 以外のタスク用にバッファーを追加
最小は 64、RSE スレッド・プールによってサポートされる
クライアント数が予測の 25 を下回る場合にバッファーを追加
ユーザー ID STCRSE の OMVS セグメント内の THREADSMAX を使用して
RSE の限度 (最小は 635) が設定されている場合、必ず最小は
573 (JES ジョブ・モニター用)
ユーザー ID STCRSE の OMVS セグメント内の THREADSMAX を使用して
RSE の限度 (最小は 635) が設定されている場合、
必ず最小は 573 (JES ジョブ・モニター用)
最小は 503、Developer
for System z
以外のタスク用にバッファーを追加
変更なし (システム・デフォルトは 200 MB)、ここでは
ユーザー ID STCRSE の OMVS セグメント内で ASSIZEMAX を使用
最小は 1050、Developer
for System z 以外のタスク用にバッファーを追加
2 GB
限度の定義の説明に従ってシステム限度を定義したら、Developer for System z によるリソース使用量のモニターを開始して、変数の調整が必要かどうかを確認できます。図 31 は、499 人のユーザーがログオンした後のリソース使用量を示しています。(この図の例はログオンだけを示しています。ユーザー・アクションは示されていません)。
F RSED,APPL=D P
BPXM023I (STCRSE)
ProcessId(83886168) Memory Usage(17%) Clients(25) Order(1)
ProcessId(91 ) Memory Usage(17%) Clients(25) Order(2)
ProcessId(122 ) Memory Usage(17%) Clients(25) Order(3)
ProcessId(16777348) Memory Usage(17%) Clients(25) Order(4)
ProcessId(16777358) Memory Usage(17%) Clients(25) Order(5)
ProcessId(16777368) Memory Usage(17%) Clients(25) Order(6)
ProcessId(16777378) Memory Usage(17%) Clients(25) Order(7)
ProcessId(16777388) Memory Usage(17%) Clients(25) Order(8)
ProcessId(16777398) Memory Usage(17%) Clients(25) Order(9)
ProcessId(33554622) Memory Usage(17%) Clients(25) Order(10)
ProcessId(16777416) Memory Usage(17%) Clients(25) Order(11)
ProcessId(16777426) Memory Usage(17%) Clients(25) Order(12)
ProcessId(16777436) Memory Usage(9%) Clients(25) Order(13)
ProcessId(16777446) Memory Usage(17%) Clients(25) Order(14)
ProcessId(16777456) Memory Usage(17%) Clients(25) Order(15)
ProcessId(16777466) Memory Usage(17%) Clients(25) Order(16)
ProcessId(16777476) Memory Usage(17%) Clients(25) Order(17)
ProcessId(16777487) Memory Usage(17%) Clients(25) Order(18)
ProcessId(16777497) Memory Usage(17%) Clients(25) Order(19)
ProcessId(16777507) Memory Usage(16%) Clients(24) Order(20)
F RSED,APPL=D P,D
BPXM023I (STCRSE)
ProcessId(83886168) ASId(0022) JobName(RSED857 ) Order(1)
PROCESS LIMITS: CURRENT HIGHWATER LIMIT
JAVA HEAP USAGE(%) 17 17 100
CLIENTS 25 25 25
MAXFILEPROC 365 366 64000
MAXPROCUSER 64 64 100
MAXTHREADS 362 363 1500
MAXTHREADTASKS 363 363 1500
TASID
Jobname Cpu time Storage EXCP
-------- ----------- ------- ----------
JMON 0.00 1780 73
RSED 5.88 95.2M 41958
RSED1 8.26 190.1M 58669
RSED1 8.17 187.0M 58605
RSED2 8.06 185.3M 58653
RSED2 8.19 183.1M 60209
RSED3 8.12 189.1M 58650
RSED3 8.03 186.7M 58590
RSED4 8.15 188.2M 58646
RSED4 5.50 182.5M 58585
RSED5 7.72 184.4M 58631
RSED5 7.82 184.1M 58576
RSED6 7.14 184.1M 58622
RSED6 6.27 186.9M 58583
RSED7 5.17 185.1M 58804
RSED7 6.57 185.2M 58621
RSED7 5.86 182.8M 58565
RSED8 0.36 1560 2459
RSED8 7.94 184.1M 58615
RSED8 7.45 181.8M 58548
RSED9 8.16 190.6M 58802
RSED9 7.62 183.8M 58610
RSED9 7.36 177.7M 57478
z/OS は高度にカスタマイズ可能なオペレーティング・システムであり、システムの (場合によっては小さな) 変更で全体のパフォーマンスに大きな影響を与えることができます。この章では、Developer for System z のパフォーマンスを向上させるために行うことができるいくつかの変更を中心に説明します。
システムのチューニングの詳細については、「MVS 初期設定およびチューニング ガイド」(SA88-8563)、および 「UNIX System Services 計画」(GA88-8639) を参照してください。
zFS の詳細については、「UNIX System Services 計画」(GA88-8639) を参照してください。
親から子へ、または exec を越えて伝搬される STEPLIB を持つ z/OS UNIX プロセスは、それぞれが約 200 バイトの拡張共通ストレージ域 (ECSA) を消費します。STEPLIB 環境変数が定義されなかった場合、または STEPLIB=CURRENT として定義された場合、z/OS UNIX は現在アクティブなすべての TASKLIB、STEPLIB、および JOBLIB 割り振りを、fork()、spawn()、または exec() 関数の実行中に伝搬します。
Developer for System z では、rsed.envvars 構成ファイルの中で説明されているように、STEPLIB=NONE がデフォルトとして rsed.envvars 内にコーディングされています。上記の理由から、このディレクティブを変更するのではなく、代わりにターゲット・データ・セットを LINKLIST または LPA (リンク・パック域) の中に置いてください。
特定のシステム・ライブラリーとロード・モジュールは、z/OS UNIX およびアプリケーション開発アクティビティーによって頻繁に使用されます。それらをリンク・パック域 (LPA) に追加するなどの方法でアクセスを改善すると、システムのパフォーマンスを向上させることができます。以下で説明する SYS1.PARMLIB メンバーの変更について詳しくは、「MVS 初期設定およびチューニング解説書」(SA88-8564) を参照してください。
C プログラム (z/OS UNIX シェルを含む) は、実行されると、言語環境プログラム (LE) ランタイム・ライブラリーからのルーチンを頻繁に使用します。 平均すると、LE 対応プログラムを実行する 1 つのアドレス・スペースごとに約 4 MB のランタイム・ライブラリーがメモリーにロードされ、すべてのフォークにコピーされます。
CEE.SCEELPA
CEE.SCEELPA データ・セットには、z/OS UNIX によって頻繁に使用される LE ランタイム・ルーチンのサブセットが入っています。 最大のパフォーマンス向上を実現するために、このデータ・セットを SYS1.PARMLIB(LPALSTxx) に追加する必要があります。そうすることにより、モジュールはディスクから 1 回だけ読み取られ、共用ロケーションに保管されます。
LPA ADD MASK(*) DSNAME(CEE.SCEELPA)
また、データ・セットを SYS1.PARMLIB(LNKLSTxx) または SYS1.PARMLIB(PROGxx) に追加することにより、LE ランタイム・ライブラリーを CEE.SCEERUN および CEE.SCEERUN2 に配置することもお勧めします。これにより、z/OS UNIX STEPLIB のオーバーヘッドがなくなり、LLA および VLF、またはそれらと同様な製品による管理のための入出力を削減できます。
これらのライブラリーを LINKLIST 内に置かない場合は、rsed.envvars 構成ファイルの中の説明に従い、適切な STEPLIB ステートメントを rsed.envvars 内にセットアップする必要があります。この方式では、常に追加の仮想ストレージが使用されますが、LE ランタイム・ライブラリーを LLA またはそれに類似した製品に対して定義することにより、パフォーマンスを改善できます。これにより、モジュールをロードするために必要な入出力が削減されます。
アプリケーション開発が主なアクティビティーであるシステムでは、以下の行を SYS1.PARMLIB(PROGxx) に追加して、リンケージ・エディターを動的 LPA の中に置くと、パフォーマンスが向上する場合もあります。
LPA ADD MODNAME(CEEBINIT,CEEBLIBM,CEEEV003,EDCZV) DSNAME(CEE.SCEERUN)
LPA ADD MODNAME(IEFIB600,IEFXB603) DSNAME(SYS1.LINKLIB)
C/C++ 開発用に、CBC.SCCNCMP コンパイラー・データ・セットを SYS1.PARMLIB(LPALSTxx) に追加することもできます。
上記のステートメントは、考えられる LPA 候補の例ですが、必要性はご使用のサイトによって異なる場合があります。他の LE ロード・モジュールを動的 LPA 内に配置する方法については、「Language Environment カスタマイズ」(SA88-8552) を参照してください。C/C++ コンパイラー・ロード・モジュールを動的 LPA の中に配置する方法については、「UNIX System Services 計画」(GA88-8639) を参照してください。
それぞれのサイトには固有の必要性があり、それを満たすために、z/OS オペレーティング・システムをカスタマイズして、使用可能なリソースを最大限に活用することができます。ワークロード管理を使用すると、パフォーマンスの最終目標を定義し、各目標にビジネスの重要度を割り当てることができます。作業の最終目標をビジネス用語で定義し、システムでは、その目標を達成するために、CPU やストレージなどのリソースをどれくらい作業に割り当てればよいかを決定します。
Developer for System z のパフォーマンスは、プロセスに正しい目標を設定することによってバランスをとることができます。以下に、いくつかの一般ガイドラインを示します。
この件について詳しくは、「MVS 計画: ワークロード管理」(SA88-8574) を参照してください。
固定サイズのヒープを使用すると、ヒープの拡張や縮小が発生しないため、状態によっては、パフォーマンスの大幅な向上につながります。ただし、固定サイズのヒープを使用することは、通常ではお勧めできません。その理由は、ヒープが満杯になるまでガーベッジ・コレクションの開始が遅延し、開始された時点では、それがメジャー・タスクになるからです。また、フラグメント化の危険も増し、ヒープの圧縮が必要になります。したがって、固定サイズのヒープは、適正なテストの後か、IBM サポートからの指示の下でのみ使用してください。ヒープ・サイズとガーベッジ・コレクションの詳細については、「Java Diagnostics Guide」(SC34-6650) を参照してください。
z/OS Java 仮想マシン (JVM) の初期ヒープ・サイズおよび最大ヒープ・サイズは、Java コマンド行オプションの -Xms (初期) および -Xmx (最大) で設定できます。
Developer for System z では、Java コマンド行オプションは、「ホスト構成ガイド」 (SC88-5663) の『_RSE_JAVAOPTS での追加 Java 始動パラメーター』の説明のように、rsed.envvars の _RSE_JAVAOPTS ディレクティブで定義されます。
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xms128m -Xmx128m"
-Xquickstart オプションは、一部の Java アプリケーションの起動時間を改善するために使用できます。-Xquickstart を指定すると、JIT (Just In Time) コンパイラーが最適化のサブセット、つまりクイック・コンパイルを使用して実行されます。このクイック・コンパイルでは、起動時間を改善できます。
-Xquickstart オプションは、実行期間が短いアプリケーション、特に実行時間が少数のメソッドに集中していないアプリケーションに適しています。-Xquickstart は、ホット・メソッドを含んでいる実行期間が長いアプリケーションに対して使用すると、パフォーマンスを低下させる場合があります。
_RSE_JAVAOPTS="$_RSE_JAVAOPTS -Xquickstart"
IBM Java 仮想マシン (JVM) バージョン 5 以上では、ブートストラップ・クラスおよびアプリケーション・クラスを共用メモリー内のキャッシュに保管することにより、それらを JVM 間で共用できます。クラス共用は、複数の JVM がキャッシュを共用している場合、全体的な仮想メモリーの消費を削減します。また、クラス共用はキャッシュが作成された後、JVM の起動時間を短縮します。
共用クラス・キャッシュはアクティブな JVM に依存せず、キャッシュを作成した JVM の存続期間を越えて持続します。共用クラス・キャッシュは JVM の存続期間を越えて持続するので、JAR またはファイル・システム上のクラスに加えられたすべての変更が反映されるよう、キャッシュは動的に更新されます。
新しいキャッシュの作成とデータの取り込みを行うためのオーバーヘッドは最小限で済みます。時間的な JVM 始動コストは、単一の JVM の場合、ロードされるクラスの数によって異なりますが、クラス共用を使用しないシステムに比べて 0 から 5 % の低下が一般的です。 キャッシュにデータが取り込まれた場合の JVM 起動時間の改善は、オペレーティング・システムおよびロードされるクラス数によって異なりますが、クラス共用を使用しないシステムに比べて 10 % から 40 % の高速化となって現れます。複数の JVM を並行して実行すると、全体的な起動時間がさらに改善されます。
クラス共用の詳細については、「Java SDK and Runtime Environment User Guide」を参照してください。
_RSE_CLASS_OPTS=-Xshareclasses:name=RSE,groupAccess,nonFatal
#_RSE_CLASS_OPTS="$_RSE_CLASS_OPTS -Xscmx6m
_RSE_JAVAOPTS="$_RSE_JAVAOPTS $_RSE_CLASS_OPTS"
理論上の最大共用キャッシュ・サイズは 2 GB です。指定できるキャッシュのサイズは、システムで使用できる物理メモリーとスワップ・スペースの容量によって制限されます。プロセスの仮想アドレス・スペースは共用クラス・キャッシュと Java ヒープの間で共用されるので、Java ヒープの最大サイズを大きくすると、作成できる共用クラス・キャッシュのサイズが小さくなります。
共用クラス・キャッシュへのアクセスは、オペレーティング・システムの許可および Java セキュリティー許可によって制限されます。
デフォルトでは、クラス・キャッシュはユーザー・レベル・セキュリティーを使用して作成されるため、キャッシュを作成したユーザーだけがキャッシュにアクセスできます。z/OS UNIX では、groupAccess というオプションがあり、これはキャッシュを作成したユーザーの 1 次グループに属するすべてのユーザーにアクセス権を与えます。しかし、使用されたアクセス・レベルに関係なく、キャッシュを破棄できるのは、そのキャッシュを作成したユーザーかルート・ユーザー (UID 0) だけです。
Java SecurityManager を使用した追加セキュリティー・オプションの詳細については、「Java SDK and Runtime Environment User Guide」を参照してください。
これらの設定は、JVM で使用できる共用メモリー・ページの量に影響します。31 ビット z/OS UNIX システム・サービスの共用ページ・サイズは、4 KB に固定されています。共用クラスは、デフォルトでは 16 MB のキャッシュを作成しようとします。したがって、IPCSHMMPAGES は 4096 より大きく設定してください。
-Xscmx を使用してキャッシュ・サイズを設定する場合、JVM は最も近いメガバイト値まで切り上げを行います。 使用するシステム上で IPCSHMMPAGES を設定するときは、このことを考慮する必要があります。
これらの設定は、UNIX プロセスで使用できるセマフォーの量に影響します。共用クラスは、IPC セマフォーを使用して JVM 間の通信を行います。
共用クラス・キャッシュは、システム上に存在するキャッシュの識別情報を保管するために、ディスク・スペースを必要とします。この情報は /tmp/javasharedresources に保管されます。識別情報ディレクトリーが削除された場合、JVM はシステム上の共用クラスを識別できないため、キャッシュの再作成が必要になります。
$ java -Xshareclasses:listAllCaches
Shared Cache OS shmid in use Last detach time
RSE 401412 0 Mon Jun 18 17:23:16 2007
Could not create the Java virtual machine.
$ java -Xshareclasses:name=RSE,printStats
Current statistics for cache "RSE":
base address = 0x0F300058
end address = 0x0F8FFFF8
allocation pointer = 0x0F4D2E28
cache size = 6291368
free bytes = 4355696
ROMClass bytes = 1912272
Metadata bytes = 23400
Metadata % used = 1%
# ROMClasses = 475
# Classpaths = 4
# URLs = 0
# Tokens = 0
# Stale classes = 0
% Stale classes = 0%
Cache is 30% full
Could not create the Java virtual machine.
$ java -Xshareclasses:name=RSE,destroy
JVMSHRC010I Shared Cache "RSE" is destroyed
Could not create the Java virtual machine.
Developer for System z クライアント・バージョン 8.0.1 以上は、接続時にホストからクライアントの構成ファイルと製品の更新情報を取り出すことができるので、すべてのクライアントの設定が共通になり、最新のものになります。
バージョン 8.0.3 以降、クライアント管理者は、異なる開発者グループのニーズに適合するように、複数のクライアント構成のセットと複数のクライアント更新シナリオを作成できるようになりました。 これにより、ユーザーは、LDAP グループのメンバーシップやセキュリティー・プロファイルに対する許可などの基準に基づいてカスタマイズされたセットアップを受け取れるようになります。
z/OS プロジェクトは、クライアント上の「z/OS プロジェクト」パースペクティブで個別に定義できます。または、z/OS プロジェクトをホスト上で集中的に定義してクライアントに対して個々のユーザー単位で伝搬することもできます。それらの「ホスト・ベースのプロジェクト」は、クライアント上で定義されたプロジェクトと外観も機能もまったく同じですが、クライアントは、それらの構造、メンバー、およびプロパティーを変更できず、ホストに接続している場合にのみ、それらのプロジェクトにアクセスできます。
pushtoclient.properties はクライアントに対し、これらの機能が使用可能であるか、関連のデータがどこに保管されているかを伝達します。詳しくは、「ホスト構成ガイド」(SC88-5663) の『(オプション) pushtoclient.properties、ホスト・ベースのクライアント制御』を参照してください。
クライアント管理者と開発プロジェクト・マネージャーがそれぞれに割り当てられたタスクを実行する方法について詳しくは、Developer for System z インフォメーション・センター (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html) を参照してください。
クライアントへのプッシュは、システム固有のデータをシステムごとに保管し、一方で共通の (全体的な) データは単一のシステム (1 次システム) 上で維持して管理上の負担を軽減するように設計されています。1 次システムは、pushtoclient.properties の primary.system ディレクティブで識別されます。 デフォルトは false です。
1 つのシステムのみを 1 次システムとして定義するようにしてください。Developer for System z クライアント管理者は、ターゲット・システムが 1 次システムでなければ、グローバル構成データをエクスポートできなくなります。Developer for System z クライアントは、構成が同期していない複数の 1 次システムに接続する場合、不規則な動作を示すことがあります。
この唯一の規則は、複数のシステムが Developer for System z 構成 (/etc/rdz) およびクライアントへのプッシュ・メタデータ (/var/rdz/pushtoclient) を共有する場合には適用されません。 構成が共有されるため、関与するすべてのシステムは 1 次システムとして識別されます。 ただし、すべてのシステムがメタデータも共有していれば、この重複が問題になることはありません。
クライアントへのプッシュ・メタデータが格納されるベース・ディレクトリーは、pushtoclient.properties の pushtoclient.folder ディレクティブで識別します。デフォルトは /var/rdz/pushtoclient です。
ベース・ディレクトリーには、ルートのクライアントへのプッシュ構成ファイルである keymapping.xml が保持されます。その他すべてのメタデータは、サブディレクトリーに保持されます。
ほとんどのサブディレクトリーは、クライアント管理者がクライアントへのプッシュ・ワークスペース構成をエクスポートするときに動的に作成されます。これらのサブディレクトリーによって、マッピングや設定などのサブジェクトごとにメタデータをグループ化します。クライアントへのプッシュによる管理に適した Developer for System z クライアント・コンポーネント数が多くなるほど、より多くのサブディレクトリーが動的に作成されるようになります。これらのサブディレクトリーに何が格納されているのかを調べるには、Developer for System z クライアントでエクスポート・ウィザード (「ファイル」> 「エクスポート…」>「Rational Developer for System z」>「構成ファイル」) を参照してください。
これらのサブディレクトリーの作成について詳しくは、「ホスト構成ガイド」(SC88-5663) の章『基本的なカスタマイズ』の『カスタマイズのセットアップ』を参照してください。
デフォルト (pushtoclient.properties の file.permission ディレクティブで確認できます) では、ベース・ディレクトリーに作成されるすべてのファイルとディレクトリーに対して許可ビット・マスク 775 (rwxrwxr-x) が設定されます。これにより、所有者と所有者のデフォルト・グループは、そのディレクトリー構造と、そこに含まれるファイルに対する読み取りアクセスと書き込みアクセスが許可されます。 その他のユーザーは、そのディレクトリー構造と、そこに含まれるファイルに対する読み取り権限のみを持ちます。
クライアントへのプッシュのセットアップを開始する前に、これらのディレクトリーに適切な所有者 UID (ユーザー ID) と GID (グループ ID) を設定することが重要です。
ADDGROUP RDZADMIN OWNER(IBMUSER) SUPGROUP(SYS1) –
DATA('RATIONAL DEVELOPER FOR SYSTEM Z - CLIENT ADMIN')
ALTGROUP RDZADMIN OMVS(GID(2))
CONNECT RDZADM1 GROUP(RDZADMIN) AUTH(USE)
ALTUSER RDZADM1 DFLTGRP(RDZADMIN) OMVS(UID(6))
chown –R rdzadm1:rdzadmin /var/rdz/pushtoclient
chmod –R 775 /var/rdz/pushtoclient
サンプル RACF コマンドの詳細については、「Security Server RACF コマンド言語解説書」(SA88-8617) を参照してください。サンプル z/OS UNIX コマンドについて詳しくは、「UNIX System Services コマンド解説書」(SA88-8641) を参照してください。追加情報については、z/OS UNIX ディレクトリー構造を参照してください。
クライアントへのプッシュ・メタデータは z/OS UNIX のディスク・スペースをそれほど大量には使用しません。これは、このメタデータの大部分が UTF-8 でエンコードされた XML ファイルであるためです。 クライアントの更新シナリオに使用する製品コードは、ネットワーク上のどこにでも保管できることに注意してください。この製品コードを z/OS UNIX に保管する必要はありません。関連するクライアントへのプッシュ・メタデータ (応答ファイルと呼びます) によって、クライアントは正しいロケーションをポイントするようになります。
Developer for System z クライアント (バージョン 8.0.1 以降) は、ホストへの接続時に pushtoclient.properties にある定義を読み取ります。ディレクティブ config.enabled が有効にされている場合、クライアントは、そのクライアントの現行の構成とクライアントへのプッシュ・メタデータ内の定義を比較します。差異が検出されると、そのクライアントは必要なデータを取り出すウィザードを開始し、クライアントへのプッシュによる指示に従ってセットアップをアクティブ化します。
pushtoclient.properties の reject.config.updates ディレクティブでは、クライアントへのプッシュによって送信される構成の更新をユーザーが拒否できるようにするかどうかを制御します。
Developer for System z クライアント (バージョン 8.0.1 以降) には、クライアント管理者が使用するウィザードがあります。このウィザードを使用すると、現行の構成をエクスポートできます。このエクスポートした構成は、クライアントへのプッシュによってすべての Developer for System z クライアントにインポートできます。この機能は、すべてのクライアントで使用可能になることに注意してください。そのため、クライアントへのプッシュ・メタデータを保持する z/OS UNIX のディレクトリー (/var/rdz/pushtoclient) に対する書き込みアクセス権は、必ずクライアント管理者にのみ付与してください。
グループ・サポートを使用可能にするには、クライアントとホストの両方がバージョン 8.0.3 以降である必要があります。詳しくは、複数の開発者グループを参照してください。
Developer for System z クライアント (バージョン 8.0.1 以降) は、ホストへの接続時に pushtoclient.properties にある定義を読み取ります。ディレクティブ product.enabled が有効にされている場合、クライアントは、そのクライアントの現行の製品バージョンとクライアントへのプッシュ・メタデータ内の定義を比較します。 差異が検出されると、そのクライアントは必要なデータを取り出すウィザードを開始し、クライアントへのプッシュによる指示に従ってセットアップをアクティブ化します。
pushtoclient.properties の reject.product.updates ディレクティブでは、クライアントへのプッシュによって送信される製品の更新をユーザーが拒否できるようにするかどうかを制御します。
グループ・サポートを使用可能にするには、クライアントとホストの両方がバージョン 8.0.3 以降である必要があります。詳しくは、複数の開発者グループを参照してください。
バージョン 8.0.3 以降、クライアント管理者は、異なる開発者グループのニーズに適合するように、複数のクライアント構成のセットと複数のクライアント更新シナリオを作成できるようになりました。 これにより、ユーザーは、LDAP グループのメンバーシップやセキュリティー・プロファイルに対する許可などの基準に基づいてカスタマイズされたセットアップを受け取れるようになります。
各グループが独自のクライアント構成とクライアント更新の要件を持つ複数の開発者グループに対するサポートは、表 36 に示されているように、pushtoclient.properties に含まれる関連ディレクティブ (config.enabled および product.enabled) に適切な値を割り当てることで使用可能になります。
*.enabled の値 | 機能の有効化 | 複数のグループのサポート |
---|---|---|
False | いいえ | いいえ |
True | はい | いいえ |
LDAP | はい | はい。LDAP グループ FEK.PTC.*.ENABLED.sysname.devgroup のメンバーシップに基づきます。 |
SAF | はい | はい。セキュリティー・プロファイル FEK.PTC.*.ENABLED.sysname.devgroup に基づきます。 |
この機能を有効化すると (これには TRUE 値が含まれます)、開発者は必ずデフォルト・グループに所属することになるため、注意が必要です。 開発者は、1 つまたは複数の追加グループに所属することも、追加グループに所属しないこともできます。
表 37 に示すように、条件付きで更新を拒否することもできます。
reject.*.updates の値 | 機能の有効化 |
---|---|
False | いいえ |
True | はい |
LDAP | LDAP グループ・メンバーシップ FEK.PTC.REJECT.*.UPDATES.sysname.** に依存します。 |
SAF | セキュリティー・プロファイル FEK.PTC.REJECT.*.UPDATES.sysname.** に対する許可に依存します。 |
pushtoclient.properties のディレクティブは相互に独立して機能することに注意してください。 サポートされている値は、どのディレクティブにでも割り当てることができます。 設定を一様に保つ必要はありません。
それぞれの機能に必要なセットアップについて詳しくは、LDAP ベースのグループ選択および SAF ベースのグループ選択を参照してください。複数グループのサポートを有効にする方法についての詳細は、「ホスト構成ガイド」(SC88-5663) の『(オプション) pushtoclient.properties、ホスト・ベースのクライアント制御』を参照してください。
pushtoclient.properties の *.enabled 機能が有効な場合 (TRUE 値を含む)、開発者は関連する機能のデフォルト・グループに必ず所属しています。 開発者は、1 つまたは複数の追加グループに所属することも、追加グループに所属しないこともできます。
複数のグループで定義された変更を適用する際の複雑性を制限するために、Developer for System z では、ユーザーが行った選択に基づいて、使用される定義を制限します。
追加グループ | 使用する定義 |
---|---|
なし | デフォルト |
1 つ | デフォルト、または (デフォルト + グループ) |
複数 | デフォルト、または (デフォルト + 1 グループ) |
開発者が複数のグループに同時に所属することはできますが、開発者のアクティブ・ワークスペースを複数のグループにバインドすることはできません。 アクティブ・ワークスペースは、構成の更新または製品の更新を受信するために、特定の構成グループおよび特定の製品グループにバインドする必要があります (これらは、デフォルト・グループでも構いません)。 完了したバインドは、元に戻すことができません。 新規のグループ・バインディングが必要な場合には、新規のワークスペースを作成する必要があります。
構成グループ・バインディングのないワークスペースがホストに接続するときに、config.enabled でそのワークスペースのクライアントへのプッシュ機能がアクティブであることが示されていると、Developer for System z はユーザーが所属しているグループを特定するためにすべての構成グループを照会して、グループを選択するように促すプロンプトをユーザーに表示します。 それ以降の接続時には、グループ・メンバーシップが依然として有効であるかどうかを確認するために、選択したグループのみが照会されます。
config.enabled | この構成更新グループにバインドされたワークスペース |
---|---|
False | なし |
True | デフォルト |
LDAP | デフォルトまたはグループ (プロンプトが出された後) |
SAF | デフォルトまたはグループ (プロンプトが出された後) |
構成グループ・バインディングのないワークスペースがホストに接続するときに、product.enabled でそのワークスペースのクライアントへのプッシュがアクティブであることが示されていると、Developer for System z はユーザーが所属しているグループを特定するためにすべての構成グループを照会して、グループを選択するように促すプロンプトをユーザーに表示します。 それ以降の接続時には、グループ・メンバーシップが依然として有効であるかどうかを確認するために、選択したグループのみが照会されます。
product.enabled | この製品更新グループにバインドされたワークスペース |
---|---|
False | なし |
True | デフォルト |
LDAP | デフォルトまたはグループ (プロンプトが出された後) |
SAF | デフォルトまたはグループ (プロンプトが出された後) |
reject.*.updates ディレクティブは、グループ定義を使用してもしなくても機能します。reject.*.updates にグループを使用する場合は、関連した *.enabled ディレクティブのグループ・バインディングが使用されます。更新が提示されると、Developer for System z はユーザーが更新の拒否を許可されているかどうかを判別して、それに応じた動作を実行します。
reject.*.updates ディレクティブのグループ・サポートはバージョン 9.1.0 の新機能であり、これには Developer for System z ホストとクライアントの両方がバージョン 9.1.0 以降である必要があります。このサポートでは、LDAP キーワードおよび SAF キーワードの処理方法を変更します。
バージョン 9.1.0 より前では、ワークスペース・グループ・バインディングにかかわらず、FEK.PTC.REJECT.*.UPDATES.sysname のアクセス・リストに名前が記載されているだけで、更新は拒否されていました。 バージョン 9.1.0 以降、FEK.PTC.REJECT.*.UPDATES.sysname は、デフォルトのグループにバインドされたワークスペースによる更新を拒否する場合にのみ使用されます。 グループにバインドされているワークスペースで更新を拒否するには、FEK.PTC.REJECT.*.UPDATES.sysname.groupname のアクセス・リストにユーザー名を記載する必要があります。
製品の初期カスタマイズでは、/var/rdz/pushtoclient/ 内に grouping/ ディレクトリーが作成されます。/var/rdz/pushtoclient/grouping/ に <devgroup>/ ディレクトリーを追加することは、クライアント管理者の責任です。
製品の初期カスタマイズ中に、projects/、install/ および install/responsefiles/ の各ディレクトリーが /var/rdz/pushtoclient/ 内に作成されることに注意してください。 クライアント管理者は、/var/rdz/pushtoclient/grouping/<devgroup>/ 内で、これらのディレクトリー作成操作を繰り返す必要があります (グループ固有の製品アップグレード・シナリオやグループ固有のホスト・ベースのプロジェクトに必要になる場合)。
以下に示す z/OS UNIX コマンドのサンプル・シーケンスでは、適切な権限ビット・マスクを使用してサブディレクトリーを作成します。 このコマンドは、所有権の問題を避けるために、クライアント管理者が実行する必要があります。
saved_umask=$(umask)
umask 0000
cd /var/rdz/pushtoclient/grouping/
mkdir –m775 <devgroup>
cd <devgroup>
mkdir –m775 install
mkdir –m775 install/responsefiles
mkdir –m775 projects
umask $saved_umask
サンプル z/OS UNIX コマンドについて詳しくは、「UNIX System Services コマンド解説書」(SA88-8641) を参照してください。
/var/rdz/pushtoclient/grouping/<devgroup>
ディレクトリーをクライアントへのプッシュ・グループごとに作成します。
LDAP (Lightweight Directory Access Protocol) は TCP/IP ベースのプロトコルの名前ですが、分散ディレクトリー・サービスのセットを表現するために一般に使用されています。 データベースと同様に、ディレクトリーは構造化されたレコードのコレクションです。 Developer for System z では、各グループが 1 人以上のメンバーを保持する単純な階層データベースとして、LDAP サーバーを使用できます。
LDAP サーバーの定義を選択手段として使用する場合 (pushtoclient.properties のディレクティブに LDAP 値が指定されている場合)、Developer for System z は 表 41 にリストされているグループ名のメンバーシップを検証して、ユーザーが所属している開発者グループを判別したり、ユーザーが更新の拒否を許可されているかどうかを判別します。
グループ名 (cn=) | 結果 |
---|---|
FEK.PTC.CONFIG.ENABLED.sysname.devgroup | クライアントは指定されたグループ用の構成の更新を受諾する |
FEK.PTC.PRODUCT.ENABLED.sysname.devgroup | クライアントは指定されたグループ用の製品の更新を受諾する |
FEK.PTC.REJECT.CONFIG.UPDATES.sysname | デフォルト・グループにワークスペースがバインドされている場合、ユーザーは構成の更新を拒否できます。 |
FEK.PTC.REJECT.CONFIG.UPDATES.sysname.devgroup | 指定されたグループにワークスペースがバインドされている場合、ユーザーは構成の更新を拒否できます。 |
FEK.PTC.REJECT.PRODUCT.UPDATES.sysname | デフォルト・グループにワークスペースがバインドされている場合、ユーザーは製品の更新を拒否できます。 |
FEK.PTC.REJECT.PRODUCT.UPDATES.sysname.devgroup | 指定されたグループにワークスペースがバインドされている場合、ユーザーは製品の更新を拒否できます。 |
devgroup 値は、特定の開発者グループに割り当てられたグループ名と一致します。 グループ名は、Developer for System z クライアントに表示されることに注意してください。
sysname の値は、ターゲット・システムのシステム名と一致します。
pushtoclient.properties の config.enabled が SAF または LDAP に設定されている場合、ユーザーは、構成の更新用にワークスペースをデフォルト・グループにバインドできます。config.enabled が TRUE に設定されている場合、ワークスペースは自動的にデフォルト・グループにバインドされます。
pushtoclient.properties の product.enabled が SAF または LDAP に設定されている場合、ユーザーは、製品の更新用にワークスペースをデフォルト・グループにバインドできます。product.enabled が TRUE に設定されている場合、ワークスペースは自動的にデフォルト・グループにバインドされます。
reject.*.updates ディレクティブのグループ・サポートはバージョン 9.1.0 の新機能であり、LDAP キーワードおよび SAF キーワードが処理される方法を変更します。
図 32 は、LDIF 形式で表現されたグループとユーザーの LDAP 定義の例です。
# Group Definition
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA,o=PTC,c=DeveloperForZ
objectClass: groupOfUniqueNames
objectClass: top
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.GROUPA
description: Project A
uniqueMember: uid=mborn,ou=Users,dc=example,dc=com
# User Definition
dn: uid=mborn,ou=Users,dc=example,dc=com
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: top
cn: May Born
sn: Born
uid: mborn
facsimiletelephonenumber: +1 800 982 6883
givenname: May
mail: mborn@example.com
ou: Users
使用可能な商用 LDAP サーバーおよびフリーの LDAP サーバーには、数多くの選択肢があります。 その一例として、IBM Tivoli® Directory Server (http://www-01.ibm.com/software/tivoli/products/directory-server/) があります。 また、LDAP サーバーを管理するためのコマンド行ツールおよび GUI ベースのツールにも、数多くの選択肢があります。
LDAP スキーマで説明されているように、各ユーザーは LDAP サーバーに定義されている必要があります。 管理作業を軽減するための最善策は、すべてのユーザー定義にアクセス可能になっている LDAP サーバーで、クライアントへのプッシュ・スキーマを実施することです。 例えば、SDBM データベース (セキュリティー・データベースのラッパー) を使用する z/OS 上でアクティブな IBM Tivoli Directory Server が使用できます。
サイト・ポリシーによっては、LDAP サーバーでのクライアントへのプッシュ・スキーマをクライアント管理者が管理することになります。 このような配置は、コラボレーションの必要性と、遅延や通信エラーの可能性を減少できます。
クライアント管理者による LDAP 管理が推奨される理由は、クライアントへのプッシュ・スキーマが機密情報やセキュリティー関連の情報を一切保持しないためです。 その他のスキーマによって LDAP サーバーがユーザー定義を使用できる場合には、Developer for System z LDAP オブジェクトは、開発者が選択しているワークスペースのレイアウトと Developer for System z クライアント製品の自動更新を判断するだけになります。
LDAP プロトコルをサポートする任意のデータベース・サーバーを、Developer for System z のクライアントへのプッシュ・スキーマのホストに使用できます。 そのため、Developer for System z では、LDAP サーバーへの接続に必要な情報を指定できます。 また、LDAP サーバー内でデータベースを一意に特定するサフィックスを指定することもできます。
rsed.envvars ディレクティブ | デフォルト |
---|---|
_RSE_LDAP_SERVER | ローカル・ホスト・システム |
_RSE_LDAP_PORT | 389 |
_RSE_LDAP_PTC_GROUP_SUFFIX | "O=PTC,C=DeveloperForZ" |
ある企業がシステム CDFMVS08 上で Developer for System z をアクティブにしていると仮定します。また、LDAP サーバーとして使用される IBM Tivoli Directory Server も CDFMVS08 上でアクティブだと仮定します。 この LDAP サーバーは、クライアントへのプッシュ・バックエンドの LDAP への追加 で説明されているように構成されています。
各開発者グループは特定のクライアント構成ファイルを必要とします。また、すべての開発者は同一のクライアント・バージョン制御の管理下にあります。 クライアント管理者とは異なり、開発者はクライアントへのプッシュが提示する変更を拒否することは許可されません。
クライアント管理者と LDAP 管理者は、構成の更新にグループ名 BANKING および INSURANCE を使用することについて同意する必要があります。
# filename ds.conf
# restart GLDSRV started task to pick up changes
# global section
adminDN "cn=LDAP admin"
adminPW password
listen ldap://:389
schemaPath /etc/ldap
# SDBM back-end section (RACF)
database SDBM GLDBSD31/GLDBSD64
suffix "cn=RACF,o=IBM,c=US"
# LDBM back-end section (z/OS UNIX files)
database LDBM GLDBLD31/GLDBLD64 LDBM-RDZ
suffix "o=PTC,c=DeveloperForZ"
databaseDirectory /var/ldap/ldbm/rdz
mkdir -p /var/ldap/ldbm/rdz
ldapmodify -D "cn=LDAP admin" -w password -f
/usr/lpp/ldap/etc/schema.user.ldif
ldapmodify -D "cn=LDAP admin" -w password -f
/usr/lpp/ldap/etc/schema.IBM.ldif
ldapadd -D "cn=LDAP admin" -w password -f
/u/ibmuser/ptc_root.ldif
上記の /u/ibmuser/ptc_root.ldif は、以下の項目を保持します。dn: o=PTC,c=DeveloperForZ
objectclass: top
objectclass: organization
o: PTC
スキーマに異なる LDAP グループ・オブジェクトを追加し、クライアント管理者をそれらの一部にします。ユーザー ID RDZADM1 のユーザー定義は、RACF スキーマから取り出します。
ldapadd -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_setup.ldif
# banking workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# insurance workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# reject configuration updates
dn: cn=FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.CONFIG.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
# reject product updates
dn: cn=FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08,o=PTC,c=DeveloperForZ
objectclass: groupOfUniqueNames
cn: FEK.PTC.REJECT.PRODUCT.UPDATES.CDFMVS08
description: Developer for System z push-to-client
# give client administrator access
uniqueMember: racfID=RDZADM1,profileType=user,cn=RACF,o=IBM,c=US
開発者を LDAP グループ・オブジェクトに追加します。ユーザー ID のユーザー定義は、RACF スキーマから取り出されます。
ldapmodify -D "cn=LDAP admin" -w password -f /u/ibmuser/ptc_add.ldif
ここでは、/u/ibmuser/ptc_add.ldif は以下の情報を保持します。# banking workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=BNK010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=BNK014,profileType=user,cn=RACF,o=IBM,c=US
# insurance workspace configuration
dn: cn=FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE,o=PTC,c=DeveloperForZ
changeType: modify
add: uniqueMember
uniqueMember: racfID=INS010,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS011,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS012,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS013,profileType=user,cn=RACF,o=IBM,c=US
uniqueMember: racfID=INS014,profileType=user,cn=RACF,o=IBM,c=US
# BANKING and INSURANCE have different configuration needs
config.enabled=LDAP
# everyone receives product updates
product.enabled=TRUE
# only RDZADMIN can reject configuration updates
reject.config.updates=LDAP
# only RDZADMIN can reject product updates
reject.product.updates=LDAP
個別化された製品更新のシナリオは存在しないため、クライアント管理者が /var/rdz/pushtoclient/grouping/<devgroup> の install/ および install/responsefiles/ サブディレクトリーを作成または更新する必要はありません。
クライアント管理者は、製品の更新に必要な応答ファイルをデフォルト・グループ・ディレクトリー /var/rdz/pushtoclient/install/responsefiles/ 内に作成する必要があります。
SAF (Security Access Facility) は、あらゆる z/OS セキュリティー製品にアクセスするためのインターフェースです。Developer for System z では、このインターフェースを使用して、ご使用のセキュリティー製品を照会したり、クライアントへのプッシュに関連した情報を取得することができます。
セキュリティー・データベースの定義を選択手段として使用する場合 (pushtoclient.properties のディレクティブに SAF 値が指定されている場合)、Developer for System z は 表 42 にリストされているプロファイルへのアクセス権限を検証して、ユーザーが所属している開発者グループを判別したり、ユーザーが更新の拒否を許可されているかどうかを判別します。
FACILITY プロファイル | 固定長 | 必要なアクセス権 | 結果 |
---|---|---|---|
FEK.PTC.CONFIG.ENABLED. |
23 | READ | クライアントは指定されたグループ用の構成の更新を受諾する |
FEK.PTC.PRODUCT.ENABLED. |
24 | READ | クライアントは指定されたグループ用の製品の更新を受諾する |
FEK.PTC.REJECT.CONFIG. |
30 | READ | デフォルト・グループにワークスペースがバインドされている場合、ユーザーは構成の更新を拒否できます。 |
FEK.PTC.REJECT.CONFIG. UPDATES.sysname.devgroup | 30 | READ | 指定されたグループにワークスペースがバインドされている場合、ユーザーは構成の更新を拒否できます。 |
FEK.PTC.REJECT.PRODUCT. |
31 | READ | デフォルト・グループにワークスペースがバインドされている場合、ユーザーは製品の更新を拒否できます。 |
FEK.PTC.REJECT.PRODUCT. UPDATES.sysname.devgroup | 31 | READ | 指定されたグループにワークスペースがバインドされている場合、ユーザーは製品の更新を拒否できます。 |
devgroup 値は、特定の開発者グループに割り当てられたグループ名と一致します。 グループ名は、Developer for System z クライアントに表示されることに注意してください。
sysname の値は、ターゲット・システムのシステム名と一致します。
pushtoclient.properties の config.enabled が SAF または LDAP に設定されている場合、ユーザーは、構成の更新用にワークスペースをデフォルト・グループにバインドできます。config.enabled が TRUE に設定されている場合、ワークスペースは自動的にデフォルト・グループにバインドされます。
pushtoclient.properties の product.enabled が SAF または LDAP に設定されている場合、ユーザーは、製品の更新用にワークスペースをデフォルト・グループにバインドできます。product.enabled が TRUE に設定されている場合、ワークスペースは自動的にデフォルト・グループにバインドされます。
「固定長」列は、関連するセキュリティー・プロファイルの固定部分の長さについて説明しています。
デフォルトでは、Developer for System z は、FEK.* プロファイルが FACILITY セキュリティー・クラス内に存在していると想定します。FACILITY クラス内のプロファイルには 39 文字までの文字数制限があることに注意してください。プロファイルの固定部分 (FEK.PTC.<key>) の長さと、プロファイルのサイト固有部分 (sysname または sysname.devgroup) の長さの合計が、この制限数を超過する場合は、プロファイルを別のクラス内に置き、代わりにこのクラスを使用するように Developer for System z に指示してください。これを行うには、rsed.envvars にある _RSE_FEK_SAF_CLASS をコメント解除して、適切なクラス名を指定します。
各開発者グループは特定のクライアント構成ファイルを必要とします。また、すべての開発者は同一のクライアント・バージョン制御の管理下にあります。 クライアント管理者とは異なり、開発者はクライアントへのプッシュが提示する変更を拒否することは許可されません。拒否ルールは、将来の拡張に備えて、すべてのシステムに対して有効にします。
クライアント管理者とセキュリティー管理者は、クライアントへのプッシュ・グループ名 BANKING および INSURANCE を構成の更新に使用することについて同意する必要があります。
# allow RDZADMIN and DEVBANK to select push-to-client group BANKING
RDEFINE XFACILIT (FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.BANKING CLASS(XFACILIT) –
ID(RDZADMIN DEVBANK) ACCESS(READ)
# allow RDZADMIN and DEVINSUR to select push-to-client group INSURANCE
RDEFINE XFACILIT (FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.CONFIG.ENABLED.CDFMVS08.INSURANCE CLASS(XFACILIT) –
ID(RDZADMIN DEVINSUR) ACCESS(READ)
# RDZADMIN can reject configuration updates on any system and for any group
RDEFINE XFACILIT (FEK.PTC.REJECT.CONFIG.UPDATES.**) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.CONFIG.UPDATES.** CLASS(XFACILIT) –
ID(RDZADMIN) ACCESS(READ)
# RDZADMIN can reject product updates on any system system and for any group
RDEFINE XFACILIT (FEK.PTC.REJECT.PRODUCT.UPDATES.**) –
UACC(NONE) DATA('RATIONAL DEVELOPER FOR SYSTEN Z - PUSH-TO-CLIENT')
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(RDZADMIN) ACCESS(READ)
# activate changes
SETROPTS RACLIST(XFACILIT) REFRESH
# BANKING and INSURANCE have different configuration needs
config.enabled=SAF
# everyone receives product updates
product.enabled=TRUE
# only RDZADMIN can reject configuration updates
reject.config.updates=SAF
# only RDZADMIN can reject product updates
reject.product.updates=SAF
_RSE_FEK_SAF_CLASS=XFACILIT
個別化された製品更新のシナリオは存在しないため、クライアント管理者が /var/rdz/pushtoclient/grouping/<devgroup>/ の install/ および install/responsefiles/ サブディレクトリーを作成または更新する必要はありません。
クライアント管理者は、製品の更新に必要な応答ファイルをデフォルト・グループ・ディレクトリー /var/rdz/pushtoclient/install/responsefiles/ 内に作成する必要があります。
サンプル・セットアップがアクティブ状態のときに、重要な修正を含む Developer for System z 修正パッケージが使用可能になったとします。ただし、銀行プロジェクトの開発者の多くが、このタイミングで各自のワークステーションに直ちに何らかの変更を加えることに難色を示したとします。
この問題を解決するために、セキュリティー管理者は、すべての DEVBANK 開発者に対して猶予期間を与えて、開発者が更新の延期 (拒否) を選択できるようにします。
# start of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(DEVBANK) ACCESS(READ)
# activate changes
SETROPTS RACLIST(FACILITY) REFRESH
# end of grace period
PERMIT FEK.PTC.REJECT.PRODUCT.UPDATES.** CLASS(XFACILIT) –
ID(DEVBANK) DELETE
# activate changes
SETROPTS RACLIST(FACILITY) REFRESH
z/OS プロジェクトは、クライアント上の「z/OS プロジェクト」パースペクティブで個別に定義できます。または、z/OS プロジェクトをホスト上で集中的に定義してクライアントに対して個々のユーザー単位で伝搬することもできます。それらの「ホスト・ベースのプロジェクト」は、クライアント上で定義されたプロジェクトと外観も機能もまったく同じですが、クライアントは、それらの構造、メンバー、およびプロパティーを変更できず、ホストに接続している場合にのみ、それらのプロジェクトにアクセスできます。
ホスト・ベースのプロジェクトのベース・ディレクトリー (クライアント管理者が定義する) は、/var/rdz/pushtoclient/keymapping.xml で定義され、デフォルトでは /var/rdz/pushtoclient/projects になっています。
ホスト・ベースのプロジェクトは、複数の開発者グループで説明されている複数グループのセットアップに加えることもできます。 つまり、ホスト・ベースのプロジェクトは /var/rdz/pushtoclient/grouping/<devgroup>/projects/ で定義することもできるということです。
ワークスペースが特定のグループにバインドされているときに、このグループとデフォルト・グループに同一ユーザーのプロジェクト定義が存在すると、そのユーザーはデフォルト・グループとその特定のグループの両方からのプロジェクト定義を受け取ります。
Developer for System z では、この問題に対処するため、CICS 管理者が Application Deployment Manager の一部である CICS リソース定義 (CRD) サーバーを使用して、 CICS リソース定義のデフォルトおよび CICS リソース定義パラメーターの表示プロパティーを制御できるようにしています。
例えば、CICS 管理者は、アプリケーション開発者が更新できない特定の CICS リソース定義パラメーターを提供できます。その他の CICS リソース定義パラメーターは更新可能で、デフォルトが提供される場合もされない場合もあります。あるいは、無用な複雑さを避けるために、CICSリソース定義パラメーターを非表示にすることもできます。
アプリケーション開発者は、CICS リソース定義に満足できたら、それらの定義を稼働中の CICS テスト環境に直ちにインストールするか、さらに CICS 管理者による編集と承認を受けるために、マニフェストにエクスポートすることができます。 CICS 管理者は、管理ユーティリティー (バッチ・ユーティリティー) またはマニフェスト処理ツールを使用して、リソース定義の変更を実装できます。
ホスト・システムに Application Deployment Manager をセットアップするために必要となるタスクの詳細については、「ホスト構成ガイド」 (SC88-5663) の『(オプション) Application Deployment Manager』を参照してください。
Application Deployment Manager CICS リソース定義 (CRD) サーバーは、CRD サーバー自体と、CRD リポジトリー、関連する CICS リソース定義、および Web サービス・インターフェースを使用する場合は、Web サービス・バインド・ファイルとサンプルのパイプライン・メッセージ・ハンドラーから構成されます。CRD サーバーは、Developer for System z 資料で CICS 主接続領域として参照されている Web Owning Region (WOR) 内で稼働する必要があります。
現行リリースの Developer for System z で使用可能な Application Deployment Manager のサービスの詳細については、Developer for System z インフォメーション・センター (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html) を参照してください。
CICS Transaction Server バージョン 4.1 以上では、Representational State Transfer (RESTful) の原則に従って設計された HTTP インターフェースをサポートしています。現在この RESTful インターフェースは、戦略的な CICSTS インターフェースとしてクライアント・アプリケーションで使用されています。従来の Web サービス・インターフェースはすでに安定化しており、今後は RESTful インターフェースのみが機能拡張の対象となります。
Application Deployment Manager は、この指示書に従い、Developer for System z バージョン 7.6 以上で新たに導入されたすべてのサービスに RESTful CRD サーバーを必要とします。
必要であれば、1 つの CICS 領域で RESTful インターフェースと Web サービス・インターフェースを同時にアクティブにすることができます。この場合、その領域で 2 つの CRD サーバーがアクティブになります。両サーバーは、同じ CRD リポジトリーを共用します。2 番目のインターフェースを領域に対して定義すると、CICS から定義の重複に関する警告が発行されるので注意してください。
CICS テスト環境は、いくつかの Multi-Region Option (MRO) 接続領域から構成される場合があります。時の経過と共に、それらの領域を分類するために非公式の指定が使用されてきました。一般的な指定は、Terminal Owning Region (TOR)、Web Owning Region (WOR)、Application Owning Region (AOR)、および Data Owning Region (DOR) です。
Web Owning Region は、CICS Web サービス・サポートを実装するために使用され、Application Deployment Manager CICS リソース定義 (CRD) サーバーをこの領域内で実行する必要があります。この領域は、Application Deployment Manager に対しては CICS 主接続領域として認識されます。CRD クライアントは、CICS 主接続領域への Web サービス接続を実装します。
CICS 非主接続領域は、CRD サーバーのサービス対象となる、それ以外のすべての領域です。このサービスには、IBM CICS エクスプローラーを使用したリソースの表示と、CICS リソース定義エディターを使用したリソースの定義が含まれます。
CICSPlex® SM ビジネス・アプリケーション・サービス (BAS) を使用して CICS 主接続領域の CICS リソース定義を管理する場合は、BAS によって管理される、その他のすべての CICS 領域を CRD サーバーのサービス対象とすることができます。
BAS で管理されていない CICS 領域を CRD サーバーによってサービス可能にするには、追加の変更が必要です。
CRD サーバーが CICS リソースに対して行ったアクションは、CICS CSDL TD キューの中にログとして記録されます。一般に、このキューは、使用している CICS 領域の DD MSGUSR を指します。
CICSPlex SM ビジネス・アプリケーション・サービス (BAS) を使用して CICSリソース定義を管理する場合、ログを作成するには、CICSPlex SM EYUPARM ディレクティブ BASLOGMSG を (YES) に設定する必要があります。
CRD サーバー・リポジトリー VSAM データ・セットは、すべてのデフォルト・リソース定義を保持しています。したがって、更新されないように保護する必要がありますが、開発者は、そこに保管された値の読み取りを許可される必要があります。CRD リポジトリーを保護するためのサンプルの RACF コマンドについては、データ・セット・プロファイルを定義するを参照してください。
CICS が Web サービス・インターフェースを通じて SOAP メッセージを受信した場合、そのメッセージはパイプラインによって処理されます。パイプラインは順番に実行される一連のメッセージ・ハンドラーです。CICS は、パイプライン構成ファイルを読み取って、パイプライン内でどのメッセージ・ハンドラーを起動すればよいかを判別します。メッセージ・ハンドラーは、その中で、Web サービスの要求および応答の特別な処理を実行できるプログラムです。
Application Deployment Manager は、メッセージ・ハンドラーと SOAP ヘッダー処理プログラムの起動を指定する、サンプルのパイプライン構成ファイルを提供します。
パイプライン・メッセージ・ハンドラー (ADNTMSGH) は、SOAP ヘッダー内のユーザー ID とパスワードを処理することにより、セキュリティーのために使用されます。ADNTMSGH は、サンプルのパイプライン構成ファイルによって参照されるため、CICS RPL 連結の中に入れる必要があります。
CPIH はデフォルトのトランザクション ID で、パイプラインによって起動されたアプリケーションは、この ID の下で実行されます。多くの場合、CPIH は最小レベルの許可用に設定されます。
Developer for System z は、CICS リソースの定義および照会時に、CRD サーバーが使用する複数のトランザクションを提供します。これらのトランザクション ID は、要求された操作に応じて CRD サーバーが設定します。トランザクション ID のカスタマイズについて詳しくは、「ホスト構成ガイド」 (SC88-5663) の『(オプション) Application Deployment Manager』を参照してください。
トランザクション | 説明 |
---|---|
ADMS | マニフェスト処理ツールからの CICS リソース変更要求用。一般に、これは CICS 管理者が使用するためのものです。このトランザクションは高いレベルの許可を必要とします。 |
ADMI | CICS リソースを定義、インストール、またはアンインストールする要求用。 このトランザクションは、サイトのポリシーにもよりますが、中程度の許可を必要とすると考えられます。 |
ADMR | CICS の環境情報またはリソース情報を取り出す、上記以外のすべての要求用。このトランザクションは、サイトのポリシーにもよりますが、最小レベルの許可を必要とすると考えられます。 |
CRD サーバー・トランザクションによって行われるリソース定義要求の一部、または全部を、セキュリティーで保護してください。最低でも、更新コマンド (デフォルトの Web サービス・パラメーター、デフォルトの記述子パラメーター、およびファイル名からデータ・セット名へのバインディング) をセキュリティーで保護し、CICS 管理者のみが、グローバル・リソースのデフォルトの設定に使用されるこれらのコマンドを発行できるようにしてください。
トランザクションが接続すると、CICS リソース・セキュリティー検査機能 (使用可能な場合) により、ユーザー ID にはそのトランザクション ID を実行する許可が与えられます。
リソース検査は、稼働中のトランザクションの RESSEC オプション、RESSEC システム初期化パラメーターによって制御され、CRD サーバーの場合は XPCT システム初期化パラメーターによっても制御されます。
リソース検査は、XPCT システム初期化パラメーターの値が NO 以外で、かつ TRANSACTION 定義の RESSEC オプションが YES であるかまたは、RESSEC システム初期化パラメーターが ALWAYS である場合にのみ実行されます。
RALTER GCICSTRN SYSADM UACC(NONE) ADDMEM(ADMS)
PERMIT SYSADM CLASS(GCICSTRN) ID(#cicsadmin)
RALTER GCICSTRN DEVELOPER UACC(NONE) ADDMEM(ADMI)
PERMIT DEVELOPER CLASS(GCICSTRN) ID(#cicsdeveloper)
RALTER GCICSTRN ALLUSER UACC(READ) ADDMEM(ADMR)
SETROPTS RACLIST(TCICSTRN) REFRESH
Application Deployment Manager クライアントが Web サービス・インターフェースを使用して CRD サーバーを起動するときは、データ・ストリームの SSL 暗号化がサポートされます。この通信への SSL の使用は、CICSTS TCPIPSERVICE 定義の SSL(YES) キーワードによって制御されます。詳しくは、「RACF Security Guide for CICSTS」を参照してください。
CICSTS は、リソースを保護する機能と、リソースを操作するコマンドを提供しています。セキュリティーを完全に構成していない状態でアクティブにすると、一部の Application Deployment Manager アクションが失敗する場合があります (例えば、新しいリソース・タイプを操作する権限を付与するアクションなど)。
Application Deployment Manager で機能が失敗した場合は、以下のようなメッセージがないか CICS ログを調べ、「RACF Security Guide for CICSTS」の説明に従って修正を行ってください。
DFHXS1111 %date %time %applid %tranid Security violation by user
%userid at netname %portname for resource %resource in class
%classname. SAF codes are (X'safresp',X'safreas'). ESM codes are
(X'esmresp',X'esmreas').
Developer for System z が提供する管理ユーティリティーを使用して、CICS 管理者は CICS リソース定義のデフォルト値を指定できます。これらのデフォルトは、読み取り専用とするか、アプリケーション開発者による編集を可能にすることができます。
管理ユーティリティーは、データ・セット FEK.#CUST.JCL 内のサンプル・ジョブ ADNJSPAU によって呼び出されます。このユーティリティーを使用するには、CRD リポジトリーに対する UPDATE アクセス権が必要です。
ADNJSPAU は FEK.#CUST.JCL に置かれます。ただし、z/OS システム・プログラマーが、ジョブ FEK.SFEKSAMP(FEKSETUP)をカスタマイズして実行依頼したときに別のロケーションを指定した場合は除きます。詳しくは、「ホスト構成ガイド」 (SC88-5663) の『カスタマイズ・セットアップ』を参照してください。
UPDATE | このキーワードの直後にある属性は、Developer for System z を使用するアプリケーション開発者によって更新可能になります。これは、省略された属性のデフォルトでもあります。 |
PROTECT | このキーワードの直後にある属性は、表示されますが、Developer for System z を使用するアプリケーション開発者による更新から保護されます。 |
HIDDEN | このキーワードの直後にある属性は表示されず、Developer for System z を使用するアプリケーション開発者による更新からも保護されます。 |
以下の ADNJSPAU コード・サンプルを参照してください。
//ADNJSPAU JOB <JOB PARAMETERS>
//*
//ADNSPAU EXEC PGM=ADNSPAU,REGION=1M
//STEPLIB DD DISP=SHR,DSN=FEK.SFEKLOAD
//ADMREP DD DISP=OLD,DSN=FEK.#CUST.ADNREPF0
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
*
* CICSPlex SM parameters
*
DEFINE CPSMNAME( )
*DEFINE STAGINGGROUPNAME(ADMSTAGE)
*
* Manifest export rule
*
DEFINE MANIFESTEXPORTRULE(installOnly)
*
* CICS resource definition defaults
* Omitted attributes default to UPDATE.
*
* DB2TRAN default attributes
*
DEFINE DB2TRAN()
UPDATE DESCRIPTION()
ENTRY()
TRANSID()
*
* DOCTEMPLATE default attributes
*
DEFINE DOCTEMPLATE()
UPDATE DESCRIPTION()
TEMPLATENAME()
FILE() TSQUEUE() TDQUEUE() PROGRAM() EXITPGM()
DDNAME(DFHHTML) MEMBERNAME()
HFSFILE()
APPENDCRLF(YES) TYPE(EBCDIC)
*
* File default attributes
*
DEFINE FILE()
UPDATE DESCRIPTION()
RECORDSIZE() KEYLENGTH()
RECORDFORMAT(V) ADD(NO)
BROWSE(NO) DELETE(NO) READ(YES) UPDATE(NO)
REMOTESYSTEM() REMOTENAME()
PROTECT DSNAME() RLSACCESS(NO) LSRPOOLID(1) STRINGS(1)
STATUS(ENABLED) OPENTIME(FIRSTREF)
DISPOSITION(SHARE) DATABUFFERS(2) INDEXBUFFERS(1)
TABLE(NO) MAXNUMRECS(NOLIMIT)
READINTEG(UNCOMMITTED) DSNSHARING(ALLREQS)
UPDATEMODEL(LOCKING) LOAD(NO)
JNLREAD(NONE) JOURNAL(NO)
JNLSYNCREAD(NO) JNLUPDATE(NO)
JNLADD(NONE) JNLSYNCWRITE(YES)
RECOVERY(NONE) FWDRECOVLOG(NO)
BACKUPTYPE(STATIC)
PASSWORD() NSRGROUP()
CFDTPOOL() TABLENAME()
*
* Mapset default attributes
*
DEFINE MAPSET()
UPDATE DESCRIPTION()
PROTECT RESIDENT(NO) STATUS(ENABLED)
USAGE(NORMAL) USELPACOPY(NO)
** Processtype default attributes
*
DEFINE PROCESSTYPE()
UPDATE DESCRIPTION()
FILE(BTS)
PROTECT STATUS(ENABLED)
AUDITLOG() AUDITLEVEL(OFF)
*
* Program default attributes
*
DEFINE PROGRAM()
UPDATE DESCRIPTION()
CEDF(YES) LANGUAGE(LE370)
REMOTESYSTEM() REMOTENAME() TRANSID()
PROTECT API(CICSAPI) CONCURRENCY(QUASIRENT)
DATALOCATION(ANY) DYNAMIC(NO)
EXECKEY(USER) EXECUTIONSET(FULLAPI)
RELOAD(NO) RESIDENT(NO)
STATUS(ENABLED) USAGE(NORMAL) USELPACOPY(NO)
HIDDEN JVM(NO) JVMCLASS() JVMPROFILE(DFHJVMPR)
*
* TDQueue default attributes
*
DEFINE TDQUEUE()
UPDATE DESCRIPTION()
TYPE(INTRA)
* Extra partition parameters
DDNAME() DSNAME()
REMOTENAME() REMOTESYSTEM() REMOTELENGTH(1)
RECORDSIZE() BLOCKSIZE(0) RECORDFORMAT(UNDEFINED)
BLOCKFORMAT() PRINTCONTROL() DISPOSITION(SHR)
* Intra partition parameters
FACILITYID() TRANSID() TRIGERRLEVEL(1)
USERID()
* Indirect parameters
INDIRECTNAME()
PROTECT WAIT(YES) WAITACTION(REJECT)
* Extra partition parameters
DATABUFFERS(1)
SYSOUTCLASS() ERROROPTION(IGNORE)
OPENTIME(INITIAL) REWIND(LEAVE) TYPEFILE(INPUT)
* Intra partition parameters
ATIFACILITY(TERMINAL) RECOVSTATUS(NO)
*
* Transaction default attributes
*
DEFINE TRANSACTION()
UPDATE DESCRIPTION()
PROGRAM()
TWASIZE(0)
REMOTESYSTEM() REMOTENAME() LOCALQ(NO)
PROTECT PARTITIONSET() PROFILE(DFHCICST)
DYNAMIC(NO) ROUTABLE(NO)
ISOLATE(YES) STATUS(ENABLED)
RUNAWAY(SYSTEM) STORAGECLEAR(NO)
SHUTDOWN(DISABLED)
TASKDATAKEY(USER) TASKDATALOC(ANY)
BREXIT() PRIORITY(1) TRANCLASS(DFHTCL00)
DTIMOUT(NO) RESTART(NO) SPURGE(NO) TPURGE(NO)
DUMP(YES) TRACE(YES) CONFDATA(NO)
OTSTIMEOUT(NO) WAIT(YES) WAITTIME(00,00,00)
ACTION(BACKOUT) INDOUBT(BACKOUT)
RESSEC(NO) CMDSEC(NO)
TRPROF()
ALIAS() TASKREQ()
XTRANID() TPNAME() XTPNAME()
*
* URDIMAP attributes
*
DEFINE URIMAP()
UPDATE USAGE(CLIENT)
DESCRIPTION()
PATH(/required/path)
TCPIPSERVICE()
TRANSACTION()
PROGRAM()
PROTECT ANALYZER(NOANALYZER)
ATOMSERVICE()
CERTIFICATE()
CHARACTERSET()
CIPHERS()
CONVERTER()
HFSFILE()
HOST(host.mycompany.com)
HOSTCODEPAGE()
LOCATION()
MEDIATYPE()
PIPELINE()
PORT(NO)
REDIRECTTYPE(NONE)
SCHEME(HTTP)
STATUS(ENABLED)
TEMPLATENAME()
USERID()
WEBSERVICE()
*
* Optional file name to VSAM data set name binding
*
*DEFINE DSBINDING() DSNAME()
/*
Developer for System z バージョン 7.6.1 では、管理ユーティリティーに URIMAP サポートが追加されています。URIMAP サポートを使用できるようにするには、CRD リポジトリー VSAM データ・セットを最大レコード・サイズ 3000 で割り振る必要があります。Developer for System z バージョン 7.6.1 までは、サンプルの CRD リポジトリー割り振りジョブは、最大レコード・サイズ 2000 を使用します。
以下のメッセージは、管理ユーティリティーが SYSPRINT DD に対して発行します。メッセージ CRAZ1803E、CRAZ1891E、CRAZ1892E、 および CRAZ1893E は、ファイル状況コード、VSAM 戻りコード、VSAM 機能コード、および VSAM フィードバック・コードを含んでいます。VSAM 戻りコード、機能コード、およびフィードバック・コードについては、「DFSMS Macro Instructions for Data Sets」(SC26-7408) に説明があります。ファイル状況コードについては、「Enterprise COBOL for z/OS 言語解説書」(SC88-9117) に説明があります。
説明: システム・プログラマー管理ユーティリティーは、正常に完了しました。
ユーザー応答: なし。
説明: システム・プログラマー管理ユーティリティーは、制御ステートメントの処理時に 1 つ以上の警告を検出して完了しました。
ユーザー応答: 他の警告メッセージを調べてください。
説明: システム・プログラマー管理ユーティリティーは、重大エラーを検出しました。
ユーザー応答: 他の警告メッセージを調べてください。
説明: システム・プログラマー管理ユーティリティーは、CRD リポジトリーをオープンしようとして重大エラーを検出しました。
ユーザー応答: VSAM 状況コード、戻りコード、機能コード、およびフィードバック・コードを調べてください。
説明: システム・プログラマー管理ユーティリティーは、認識できない入力制御ステートメントを検出しました。
ユーザー応答: DEFINE コマンドの直後に 1 つのスペースと、その直後に CPSMNAME、 STAGINGGROUPNAME、MANIFESTEXPORTRULE、DSBINDING、DB2TRAN、DOCTEMPLATE、FILE、MAPSET、PROCESSTYPE、PROGRAM、TDQUEUE、TRANSACTION のいずれかのキーワードがあったかどうかを調べてください。
説明: システム・プログラマー管理ユーティリティーは、DEFINE キーワード入力制御ステートメントを処理しています。
ユーザー応答: なし。
説明: システム・プログラマー管理ユーティリティーは、無効なマニフェスト・エクスポート規則を検出しました。
ユーザー応答: MANIFESTEXPORTRULE キーワードの値が「installOnly」、「exportOnly」、「both」のいずれかであることを確認してください。
説明: システム・プログラマー管理ユーティリティーが処理しようとした DEFINE DSBINDING 制御ステートメントに DSNAME キーワードがありませんでした。
ユーザー応答: DEFINE DSBINDING 制御ステートメントに DSNAME キーワードが含まれているかどうか調べてください。
説明: システム・プログラマー管理ユーティリティーが DEFINE 制御ステートメントを処理しようとして、指定されたキーワードに無効な値を検出しました。
ユーザー応答: 指定されたキーワードの長さと値が正しいかどうか調べてください。
説明: システム・プログラマー管理ユーティリティーが DEFINE 制御ステートメントを処理しようとして、キーワードまたはキーワード値の構文エラーを検出しました。
ユーザー応答: キーワード値が小括弧で囲まれていて、キーワードの直後に存在することを確認してください。キーワードおよびキーワード値は両方とも同じ行になければなりません。
説明: システム・プログラマー管理ユーティリティーは、CRD リポジトリーに書き込もうとして重複キー・エラーを検出しました。
ユーザー応答: VSAM 状況コード、戻りコード、機能コード、およびフィードバック・コードを調べてください。
説明: システム・プログラマー管理ユーティリティーは、CRD リポジトリーに書き込もうとして重大エラーを検出しました。
ユーザー応答: VSAM 状況コード、戻りコード、機能コード、およびフィードバック・コードを調べてください。
説明: システム・プログラマー管理ユーティリティーは、CRD リポジトリーから読み取ろうとして重大エラーを検出しました。
ユーザー応答: VSAM 状況コード、戻りコード、機能コード、およびフィードバック・コードを調べてください。
AQECSD サンプル CSD アップデート・ジョブの記述に従って、デバッガーを CICS 領域に定義します。AQECSD は FEK.#CUST.JCL に置かれます。ただし、z/OS システム・プログラマーが、ジョブ FEK.SFEKSAMP(FEKSETUP) をカスタマイズして実行依頼したときに別のロケーションを指定した場合は除きます。 詳しくは、「ホスト構成ガイド」(SC88-5663) の『カスタマイズのセットアップ』を参照してください。
この章は、出口ルーチンの作成による Developer for System z の機能強化についてユーザーを支援します。
Developer for System z は、選択された Developer for System z イベントに対して出口点を提供します。 出口点は、1 つの機能の処理での特定点であり、ここでその機能が出口ルーチン (ある場合) を呼び出します。出口ルーチンを作成することで追加の処理を実行できます。
従来の多くの出口点とは異なり、Developer for System z 出口点は、機能の動作の変更ができないことに注意してください。出口ルーチンが存在する場合、その出口ルーチンは機能が完了すると非同期的に呼び出されます。Developer for System z 処理は出口ルーチンの終了を待ちません。また、完了状況もチェックしません。
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<exit_point>.action=<user_exit>"
#_RSE_JAVAOPTS="$_RSE_JAVAOPTS -D<exit_point>.action.id=<userid>"
デフォルトでは、RSE デーモンの割り当てられたユーザー ID は指定された出口ルーチンを実行するために使用されます。ユーザー ID をアンコメントして指定し、ユーザー出口を実行するためにその指定した ID を使用してください。パスワードを指定する必要はありません。RSE は、指定されたユーザー ID に切り替えるときにパスワードとして使用するパスチケットを生成します。
ユーザー出口ルーチンは、場合により 1 つ以上の引数が付いた z/OS UNIX シェル・コマンドとして呼び出されます。これは、開発する出口ルーチンが z/OS UNIX コマンド行から実行可能でなければならないことを意味します。共通コーディング技法には、z/OS UNIX シェル・スクリプトおよび z/OS UNIX REXX exec が含まれますが、C/C++ のようなコンパイルされたコードも使用可能です。
z/OS UNIX シェル・スクリプトについて詳しくは、「UNIX System Services ユーザーズ・ガイド」(SA88-8640) を参照してください。REXX 言語に対する z/OS UNIX 固有の拡張子について詳しくは、「REXX および z/OS UNIX システム・サービスの使い方」(SA88-8644) を参照してください。
$ chmod 755 process_logon.sh
$ ls -l process_logon.sh
-rwxr-xr-x 1 IBMUSER SYS1 2228 Feb 28 23:44 process_logon.sh
rsed.envvars の定義は、環境変数としてユーザー出口ルーチンに使用可能です。
RSE は、単一の引数ストリングを持つユーザー出口ルーチンを呼び出します。 引数ストリングは、複数のブランクで区切られたキーワードと値をもつ単一値でも単一のストリングでもかまいません。詳しくは、使用可能な出口点 を参照してください。
Developer for System z はコンソール・メッセージ ID FEK910I を使用して、ユーザー出口に関連するデータを表示します。
FEK910I <EXIT_POINT> EXIT: invoking <exit_point> processing exit
in thread <thread_id>
FEK910I <EXIT_POINT> EXIT: <message>
FEK910I <EXIT_POINT> EXIT: completed <exit_point> processing exit
in thread <thread_id>
Developer for System z では、開始タスクのユーザー ID または指定されたユーザー ID を使用して、出口ルーチンを実行できます。ただし、ログオン出口ルーチンのクライアント・ユーザーなどの別のユーザー ID を使用する出口ルーチンでは、なんらかのアクションの実行が必要となる場合があります。これは、以下のサンプルに示されているように、標準の z/OS UNIX サービスを使用して実行できます。
#! /bin/sh
myID=ibmuser
echo a $(id)
echo 'echo b $(id)' | su -s $myID
echo "echo c \$(id)" | su -s $myID
cat /u/ibmuser/iefbr14
echo "submit /u/ibmuser/iefbr14" | su -s $myID
開始タスクユーザー ID により実行されるこのサンプルのログオン出口プログラムは、以下のコンソール・メッセージを生成します。
+FEK910I LOGON EXIT: invoking logon processing exit in thread 411
+FEK910I LOGON EXIT: a uid=8(STCRSE) gid=1(STCGROUP)
+FEK910I LOGON EXIT: b uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: c uid=1(IBMUSER) gid=0(SYS1)
+FEK910I LOGON EXIT: //IEFBR14 JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1)
+FEK910I LOGON EXIT: //IEFBR14 EXEC PGM=IEFBR14
$HASP100 IEFBR14 ON INTRDR FROM STC03919
IBMUSER
IRR010I USERID IBMUSER IS ASSIGNED TO THIS JOB.
+FEK910I LOGON EXIT: JOB JOB03926 submitted from path '/u/ibmuser/iefbr14'
ICH70001I IBMUSER LAST ACCESS AT 00:46:13 ON MONDAY, MARCH 19, 2012
$HASP373 IEFBR14 STARTED - INIT 2 - CLASS A - SYS CD08
IEF403I IEFBR14 - STARTED - TIME=00.46.14
+FEK910I LOGON EXIT: completed logon processing exit in thread 411
IEFBR14 IEFBR14 IEFBR14 0000
IEF404I IEFBR14 - ENDED - TIME=00.46.14
$HASP395 IEFBR14 ENDED
$HASP309 INIT 2 INACTIVE ******** C=BA
/* rexx */
myID='ibmuser'
say userid()
address SYSCALL 'getpwnam' myID 'pw.'
say pw.1 pw.2 pw.3 pw.4 pw.5
address SYSCALL 'seteuid' pw.2 /* PW_UID = 2 */
say retval errno errnojr
say userid()
開始タスクユーザー ID により実行されるこのサンプルのログオン出口プログラムは、以下のコンソール・メッセージを生成します。
+FEK910I LOGON EXIT: invoking logon processing exit in thread 515
+FEK910I LOGON EXIT: STCRSE
+FEK910I LOGON EXIT: IBMUSER 1 0 / /bin/sh
+FEK910I LOGON EXIT: 0 0 0
+FEK910I LOGON EXIT: IBMUSER
+FEK910I LOGON EXIT: completed logon processing exit in thread 515
監査ユーザー出口は、アクティブ監査ログ・ファイルがクローズされるときに呼び出されます。(監査は、新しい監査ログ・ファイルに切り替えられた RSE として続行します。)
/usr/lpp/rdz/samples/process_audit.rex
このサンプルの z/OS UNIX REXX exec は、クローズされた監査ログを処理するバッチ・ジョブをビルドします。
ログオン・ユーザー出口は、ユーザーがログオン・プロセスを完了したときに呼び出されます。
/usr/lpp/rdz/samples/process_logon.sh
このサンプルの z/OS UNIX シェル・スクリプトはログオン・メッセージをコンソールへ書き込みます。
この章は、Developer for System z で TSO 環境に DD ステートメントとデータ・セットを追加することにより、TSO ログオン・プロシージャーを模倣するのに役立ちます。
TSO コマンド・サービスは、TSO コマンドと (バッチ) ISPF コマンドを実行し、結果を要求側クライアントへ返す Developer for System z コンポーネントです。 それらのコマンドは、本製品が非明示的に要求するか、ユーザーが明示的に要求できます。
Developer for System z で提供されるサンプル・メンバーは、最小の TSO/ISPF 環境を作成します。ご使用のワークショップ内の開発者がカスタム・ライブラリーまたはサード・パーティー・ライブラリーへのアクセスを必要とする場合、z/OS システム・プログラマーは必要な DD ステートメントおよびライブラリーを TSO コマンド・サービス環境に追加する必要があります。Developer for System z での実装は異なりますが、その背後にあるロジックは TSO ログオン・プロシージャーと同一です。
ISPF.conf 構成ファイル (デフォルトでは /etc/rdz/ に置かれます) は、Developer for System z に使用する TSO/ISPF 環境を定義します。 アクティブな ISPF.conf 構成ファイルは 1 つだけ存在し、すべての Developer for System z ユーザーによって使用されます。
sysproc=ISP.SISPCLIB,FEK.SFEKPROC
ispmlib=ISP.SISPMENU
isptlib=ISP.SISPTENU
ispplib=ISP.SISPPENU
ispslib=ISP.SISPSLIB
ispllib=ISP.SISPLOAD
myDD=HLQ1.LLQ1,HLQ2.LLQ2
#_RSE_ISPF_OPTS="$_RSE_ISPF_OPTS&ISPPROF=&SYSUID..ISPPROF"
この機能を使用するには、このステートメントをコメント解除 (先行ポンド記号 (#) 文字を除去) し、既存の ISPF プロファイルの完全修飾データ・セット名を指定します。
*allocjob = ISP.SISPSAMP(ISPZISP2)
ISPF.conf は 1 つの割り振り exec の呼び出しだけをサポートしていますが、その exec が別の exec を呼び出すことに制限はありません。また、パラメーターとして渡されるクライアントのユーザー ID によって、個人別の割り振り exec を呼び出すことができます。例えば、メンバー USERID’.EXEC(ALLOC)’ が存在するかどうかを検査し、実行することができます。
前記のセクションで説明した割り振り exec シナリオで特定の要求を処理できない場合は、Developer for System z の RSE 通信サーバーのさまざまなインスタンスを作成し、それぞれに独自の ISPF.conf ファイルを使用することができます。以下に述べる方式の主な欠点は、Developer for System z ユーザーが、希望の TSO 環境を得るために同じホスト上の異なるサーバーに接続する必要があることです。
$ cd /etc/rdz
$ mkdir /etc/rdz/tso2
$ cp rsed.envvars /etc/rdz/tso2
$ cp ISPF.conf /etc/rdz/tso2
$ ls /etc/rdz/tso2
ISPF.conf rsed.envvars
$ oedit /etc/rdz/tso2/rsed.envvars
-> change: _RSE_RSED_PORT=4037
-> change: CGI_ISPCONF=/etc/rdz/tso2
-> change: -Ddaemon.log=/var/rdz/logs/tso2
-> change: -Duser.log=/var/rdz/logs/tso2
-> add at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/tso2/ISPF.conf
-> change: change as needed
前の例のコマンドは、変更が必要な Developer for System z 構成ファイルを、新規に作成された tso2 ディレクトリーにコピーします。 rsed.envvars 内の CGI_ISPCONF 変数を更新して新しい ISPF.conf ホーム・ディレクトリーを定義し、daemon.log および user.log を更新して新しいログ・ロケーション (これは、存在しなければ自動的に作成されます) を定義する必要があります。_RSE_RSED_PORT の更新により、既存の RSE デーモンと新規の RSE デーモンの両方が確実に固有のポート番号を使用するようになります。CLASSPATH の更新により、tso2 にコピーされなかった構成ファイルを RSE が確実に検出できるようにします。ISPF.conf ファイル自体を、必要性に合わせて更新できます。ISPF 作業域 (rsed.envvars 内の変数 CGI_ISPWORK ) を両方のインスタンスで共用できることに注意してください。
この時点で残っている作業は、新しいポート番号と新しい /etc/rdz/tso2 構成ファイルを使用する RSE 用の新規開始タスクを作成することです。rsed.envvars で _RSE_RSED_PORT が変更されていない場合、新規開始タスクは始動引数として、新規のポートを指定する必要がある点に注意してください。
このセクションで前述したアクションについて詳しくは、「IBM Rational Developer for System z ホスト構成ガイド」(SC88-5663) を参照してください。
同じシステム上で Developer for System z の複数のインスタンスをアクティブにしたい場合があります。例えば、アップグレードをテストするときなどです。しかし、TCP/IP ポートなど、一部のリソースは共用できないため、デフォルトが常に適用可能であるとは限りません。このセクションの情報を使用して Developer for System z のさまざまなインスタンスの共存を計画してください。その後、この構成ガイドを使用して、それらのインスタンスをカスタマイズすることができます。
Developer for System z の特定の部分は、2 つ (以上) のインスタンスで共用が可能ですが、それらのソフトウェア・レベルが同一で、しかも変更点が構成メンバー内に限られている場合を除いて、共用はお勧めできません。Developer for System z には、オーバーラップしない複数のインスタンスを作成するためのカスタマイズの余地が十分に残されており、それらのフィーチャーを使用することを強くお勧めします。
限定された一連の環境においては、カスタマイズ可能な部分 (の一部) を除くすべてを共用できます。1 つの例は、オンサイト使用のために非 SSL アクセスを提供し、オフサイト使用のために SSL エンコード通信を提供することです。
重要: 共用セットアップは、保守、テクニカル・プレビュー、または新規リリースのテストには、安全に使用できません。
|
アクティブな Developer for System z インストール済み環境の別のインスタンスをセットアップするには、現行セットアップとのオーバーラップを避けるため、異なるデータ・セット、ディレクトリー、およびポートを使用して、異なる部分のカスタマイズ・ステップを再実行します。
上記の SSL サンプルでは、現行 RSE デーモンのセットアップのクローンを作成でき、その後、クローンのセットアップを更新できます。次に、RSE デーモン始動 JCL のクローンを作成し、新しい TCP/IP ポートと更新した構成ファイルのロケーションを使用してカスタマイズすることができます。MVS カスタマイズ (JES ジョブ・モニターなど) は、SSL インスタンスと非 SSL インスタンスの間で共用できます。結果として、アクションは以下のようになります。
$ cd /etc/rdz
$ mkdir /etc/rdz/ssl
$ cp rsed.envvars /etc/rdz/ssl
$ cp ssl.properties /etc/rdz/ssl
$ ls /etc/rdz/ssl/
rsed.envvars ssl.properties
$ oedit /etc/rdz/ssl/rsed.envvars
-> change: _RSE_RSED_PORT=4047
-> change: -Ddaemon.log=/var/rdz/logs/ssl
-> change: -Duser.log=/var/rdz/logs/ssl
-> add at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ oedit /etc/rdz/ssl/ssl.properties
-> change: change as needed
上記のコマンドは、変更が必要な Developer for System z 構成ファイルを、新規に作成された ssl ディレクトリーにコピーします。rsed.envvars 内の daemon.log および user.log 変数を更新して、新しいログ・ロケーション (これは、存在しなければ自動的に作成されます) を定義する必要があります。CLASSPATH の更新により、ssl にコピーされなかった構成ファイルを RSE が確実に検出できるようにします。ssl.properties ファイル自体を、必要性に合わせて更新できます。
この時点で残っている作業は、新しいポート番号と新しい /etc/rdz/ssl 構成ファイルを使用する RSE 用の新規開始タスクを作成することです。
このセクションで前述したアクションについて詳しくは、「IBM Rational Developer for System z ホスト構成ガイド」(SC88-5663) の関連セクションを参照してください。
先述の SSL サンプルでは、非 SSL と SSL 使用可能 RSE デーモンの違いはわずかであり、rsed.envvars ファイルの同期状態を保つためのプロセスを自動化することが可能です。こうすることで、rsed.envvars ファイル 1 つだけを維持すればよいので、サービスのロールアウトがシンプルになります。
以下の例は、RSED ポート番号をログ・ディレクトリー名に追加し、CLASSPATH を更新することによって、複製が残りの構成ファイルを検出します。 さらに、この例では、SSL 使用可能 RSE デーモンの開始タスク JCL を拡張して、始動時に非 SSL の RSE デーモンの rsed.envvars を複製して、プロセスのポート番号を更新します。 ポート番号はログ・ディレクトリー名に組み込まれるため、両方のデーモンの間で自動的に差異が生じることになります。
$ oedit /etc/rdz/rsed.envvars
-> change: -Ddaemon.log=/var/rdz/logs/$RSE_RSED_PORT
-> change: -Duser.log=/var/rdz/logs/$RSE_RSED_PORT
-> add at the END:
# -- NEEDED BY CLONES TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
$ mkdir /etc/rdz/ssl
$ cp /etc/rdz/ssl.properties /etc/rdz/etc/rdz/ssl
$ oedit /etc/rdz/ssl/ssl.properties
-> change: change as needed
//*
//* RSE DAEMON - SSL
//*
//RSED PROC IVP=, * 'IVP' to do an IVP test
// HOME='/usr/lpp/rdz',
// CNFG='/etc/rdz/ssl'
//*
// SET SED='"/RSED_PORT/s/4035/4034/"'
// SET FILE='rsed.envvars'
//*
//* copy /etc/rdz/rsed.envvars to /etc/rdz/ssl/rsed.envvars
//* and alter RSED_PORT
//*
//CLONE EXEC PGM=BPXBATCH,REGION=0M,COND=(4,LT),
// PARM='SH cd &CNFG;sed &SED ../&FILE>&FILE'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//*
//* start RSED with the newly created rsed.envvars
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,COND=(4,LT),
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
// PEND
//*
コードの変更が関与する場合 (保守、テクニカル・プレビュー、新規リリース)、または変更がかなり複雑な場合は、Developer for System z の別のインストールを実行する必要があります。ここでは、さまざまなインストール間で発生する可能性がある競合点について説明します。
次のリストは、Developer for System z の複数のインスタンス間で異なるものにする必要があるか、そうすることが強く推奨される項目の要約です。
以下で、これらの概要を説明します。
資料「Developer for System z メッセージとコード・ガイド」(SA88-4565) には、Developer for System z のコンポーネントが生成するメッセージおよび戻りコードについて記載されています。Developer for System z 共通ホスト構成と保守に関する問題への回答 (SA88-5113) では、様々な問題のシナリオと、その解決方法が記載されています。
詳細は、Developer for System z Web サイト (http://www-03.ibm.com/software/products/us/en/developerforsystemz/) の Support セクションで入手できます。このサイトには、弊社のサポート・チームからの最新情報をもたらす技術情報が掲載されています。
この Web サイト (http://www-01.ibm.com/support/docview.wss?uid=swg27038517) のライブラリー・セクションには、Developer for System z 資料の最新バージョンが、ホワイト・ペーパーも含めて掲載されています。
Developer for System z インフォメーション・センター (http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html) では、Developer for System z クライアント、およびそのクライアントとホストとの対話の方法が (クライアントの視点から) 説明されています。
また、z/OS インターネット・ライブラリー (http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/) にも有益な情報があります。
https://www.ibm.com/developerworks/support/rational/rfe/
RSED 開始タスクは、Developer for System z ホスト・ログおよびセットアップ情報を収集するために、MODIFY LOGS オペレーター・コマンドをサポートしています。 収集したデータは、z/OS UNIX ファイルである $TMPDIR/feklogs.%sysname.%jobname に配置されます。ここで、$TMPDIR は rsed.envvars の TMPDIR ディレクティブの値 (デフォルトは /tmp)、%sysname はご使用の z/OS システムの名前、%jobname は RSED 開始タスクの名前です。
デフォルトでは、サーバー・ログだけが収集されます。コマンド・オプションを使用すると、さまざまなログを収集できます。
USER | 指定したユーザー ID のログ・ファイルを収集する |
AUDIT | 監査ログを収集する |
NOSERVER | サーバー・ログを収集しない |
Developer for System z は、セキュリティー製品で FEK.CMD.LOGS.** プロファイルに対するアクセス権を照会し、指定されたログの収集をリクエスターが許可されているかどうかを判別します。 デフォルトでは、リクエスターは RSED 開始タスクのユーザー ID です (OWNER オプションが指定されている場合を除く)。 リクエスターだけが、収集したデータを収容しているファイルに対するアクセス権を保持します。
RSED 開始タスクが開始可能になる前にデータを収集するために、Developer for System z にはサンプル・ジョブ FEKLOGS が用意されています。このサンプル・ジョブは、すべての z/OS UNIX ログ・ファイルのほか、Developer for System z のインストールと構成に関する情報を収集します。
サンプル・ジョブ FEKLOGS は、FEK.#CUST.JCL に置かれます。ただし、ジョブ FEK.SFEKSAMP(FEKSETUP) をカスタマイズして実行依頼したときに別のロケーションを指定した場合は除きます。詳しくは、「ホスト構成ガイド」 (SC88-5663) の『カスタマイズ・セットアップ』を参照してください。
FEKLOGS のカスタマイズは、JCL 内で記述されています。このカスタマイズでは、いくつかの主要な変数を準備します。
Developer for System z は、お客様と IBM サポートによる問題の識別と解決に役立つログ・ファイルを作成します。次のリストは、z/OS ホスト・システム上に作成できるログ・ファイルの概要です。これらの製品固有のログとは別に、SYSLOG に関連するメッセージがないかどうか、必ず確認してください。
MVS ベースのログは、該当する DD ステートメントによって見つけることができます。z/OS UNIX ベースのログ・ファイルは、以下のディレクトリーに置かれます。
ユーザー固有のログ・ファイルは、userlog/$LOGNAME に置かれます。ここで、userlog は rsed.envvars 内の user.log ディレクティブと DSTORE_LOG_DIRECTORY ディレクティブを組み合わせた値で、$LOGNAME はログオン・ユーザー ID (大文字) です。user.log ディレクティブがコメント化されているか存在しない場合は、ユーザーのホーム・パスが使用されます。ホーム・パスはユーザー ID の OMVS セキュリティー・セグメントで定義されます。DSTORE_LOG_DIRECTORY ディレクティブがコメント化されているか存在しない場合は、user.log の値に .eclipse/RSE/ が付加されます。
RSE デーモンおよび RSE スレッド・プールに固有のログ・ファイルは、daemon-home/server に置かれます。ここで、daemon-home は rsed.envvars 内の daemon.log ディレクティブの値になります。daemon.log ディレクティブがコメント化されているか存在しない場合は、RSED 開始タスクに割り当てられているユーザー ID のホーム・ディレクトリーが使用されます。ホーム・ディレクトリーはユーザー ID の OMVS セキュリティー・セグメントで定義されます。
この変数が rsed.envvars で定義されている場合は、IVP 固有のログ・ファイル (インストール検査プログラム) は、TMPDIR で参照されるディレクトリーに置かれます。この変数が定義されない場合、そのファイルは /tmp に作成されます。RSED 開始タスクの MODIFY LOGS オペレーター・コマンドも、出力をこのディレクトリー内に作成します。
トレース・ロギングおよび通常操作のロギング。 サンプル JCL FEK.#CUST.PROCLIB(DBGMGR) のデフォルト値は SYSOUT=* です。
通常操作のロギング。サンプル JCL FEK.#CUST.PROCLIB(JMON) 内のデフォルト値は SYSOUT=* です。
トレース・ロギング。サンプル JCL FEK.#CUST.PROCLIB(JMON) 内のデフォルト値は SYSOUT=* です。 トレースは -TV パラメーターでアクティブにされます。詳細については、JES ジョブ・モニターのトレースを参照してください。
RSE デーモンの Java 標準出力 stdout のリダイレクトされたデータ。サンプル JCL FEK.#CUST.PROCLIB(RSED) 内のデフォルト値は SYSOUT=* です。
RSE デーモンの Java 標準エラー出力 stderr のリダイレクトされたデータ。サンプル JCL FEK.#CUST.PROCLIB(RSED) 内のデフォルト値は SYSOUT=* です。
RSE デーモンおよび RSE スレッド・プールに固有のログ・ファイルは、daemon-home に置かれます。ここで、daemon-home は rsed.envvars 内の daemon.log ディレクティブの値になります。daemon.log ディレクティブがコメント化されているか存在しない場合は、RSED 開始タスクに割り当てられているユーザー ID のホーム・ディレクトリーが使用されます。ホーム・ディレクトリーはユーザー ID の OMVS セキュリティー・セグメントで定義されます。
RSE に関連するコンポーネントによって作成される複数のログ・ファイルがあります。これらはいずれも userlog/$LOGNAME に置かれます。ここで、userlog は rsed.envvars 内の user.log ディレクティブと DSTORE_LOG_DIRECTORY ディレクティブを組み合わせた値で、$LOGNAME はログオン・ユーザー ID (大文字) です。user.log ディレクティブがコメント化されているか存在しない場合は、ユーザーのホーム・パスが使用されます。ホーム・パスはユーザー ID の OMVS セキュリティー・セグメントで定義されます。DSTORE_LOG_DIRECTORY ディレクティブがコメント化されているか存在しない場合は、user.log の値に .eclipse/RSE/ が付加されます。
SCLM Developer Toolkit の通信ロギング。ここで、userlog は rsed.envvars 内の user.log ディレクティブと DSTORE_LOG_DIRECTORY ディレクティブを組み合わせた値で、$LOGNAME はログオン・ユーザー ID (大文字) です。user.log ディレクティブがコメント化されているか存在しない場合は、ユーザーのホーム・パスが使用されます。ホーム・パスはユーザー ID の OMVS セキュリティー・セグメントで定義されます。DSTORE_LOG_DIRECTORY ディレクティブがコメント化されているか存在しない場合は、user.log の値に .eclipse/RSE/ が付加されます。
バッチ・インターフェースを使用して CARMA との接続を開くと、FEK.#CUST.SYSPROC(CRASUBMT) は CRAport というサーバー・ジョブを (ユーザーの、所有者としてのユーザー ID を使用して) 開始します。ここで、port は使用される TCP/IP ポートです。
選択された CARMA 始動方式で DD ステートメント CARMALOG が指定されている場合、CARMA ロギングはサーバー・ジョブでその DD ステートメントへリダイレクトされ、指定されていない場合は SYSPRINT へ送られます。
サーバー・ジョブの SYSPRINT DD は、DD ステートメント CARMALOG が定義されていない場合、CARMA ロギングを保持します。
サーバー・ジョブの SYSTSPRT DD は、CARMA サーバー始動のシステム (TSO) メッセージを保持します。
CARMA の通信ロギング。ここで、userlog は rsed.envvars 内の user.log ディレクティブと DSTORE_LOG_DIRECTORY ディレクティブを組み合わせた値で、$LOGNAME はログオン・ユーザー ID (大文字) です。user.log ディレクティブがコメント化されているか存在しない場合は、ユーザーのホーム・パスが使用されます。ホーム・パスはユーザー ID の OMVS セキュリティー・セグメントで定義されます。DSTORE_LOG_DIRECTORY ディレクティブがコメント化されているか存在しない場合は、user.log の値に .eclipse/RSE/ が付加されます。
fekfivpc コマンド (CARMA 関連の IVP テスト) は、 fekfivpc.log ファイルを作成して、RSE と CARMA の間の通信を文書化します。この変数が rsed.envvars で定義されている場合は、ログは TMPDIR で参照されるディレクトリーに作成されます。この変数が定義されない場合は、そのファイルは /tmp に作成されます。
fekfivpi -file コマンドの出力 (TSO/ISPF クライアント・ゲートウェイ関連の IVP テスト)。この変数が rsed.envvars で定義されている場合は、ログは TMPDIR で参照されるディレクトリーに作成されます。この変数が定義されない場合は、そのファイルは /tmp に作成されます。
fekfivps -file コマンドの出力 (SCLMDT 関連の IVP テスト)。この変数が rsed.envvars で定義されている場合は、ログは TMPDIR で参照されるディレクトリーに作成されます。この変数が定義されない場合は、そのファイルは /tmp に作成されます。
コード・レビュー・プロシージャーを呼び出すステップの SYSTSPRT DD は、コード分析プロセスを開始する、フロントエンドのメッセージを保持します。
コード・レビュー・プロシージャーを呼び出すステップの WORKSPCE DD は、コード分析プロセスの Eclipse ワークスペース・ログ・メッセージを保持します。
コード・レビュー・プロシージャーを呼び出すステップの ERRMSGS DD は、コード分析プロセスの stderr 出力を保持します。
コード・レビュー・プロシージャーを呼び出すステップの SYSTSPRT DD は、コード分析プロセスを開始する、フロントエンドのメッセージを保持します。
コード・レビュー・プロシージャーを呼び出すステップの WORKSPCE DD は、コード分析プロセスの Eclipse ワークスペース・ログ・メッセージを保持します。
コード・レビュー・プロシージャーを呼び出すステップの ERRMSGS DD は、コード分析プロセスの stderr 出力を保持します。
製品が異常終了した場合、問題判別を支援するためにストレージ・ダンプが作成されます。これらのダンプの可用性とロケーションは、サイト固有の設定に大きく依存します。ダンプは作成されない場合や、次のセクションで述べるロケーションとは別のロケーションに作成される場合があります。
プログラムを MVS 内で実行している場合は、システム・ダンプ・ファイルを検査し、JCL に以下の DD ステートメント (製品によって異なります) があるかどうかを確認してください。
これらの DD ステートメントの詳細については、「MVS JCL 解説書」(SA88-8569) および「Language Environment デバッグ・ガイド」(GA88-8548) を参照してください。
z/OS UNIX では、大部分の Developer for System z ダンプが Java 仮想マシン (JVM) によって制御されます。
JVM は、デフォルトでは初期化時にダンプ・エージェント・セット (SYSTDUMP と JAVADUMP) を作成します。このダンプ・エージェント・セットは、JAVA_DUMP_OPTS 環境変数を使用してオーバーライドでき、さらに、コマンド行で -Xdump を使用することによってオーバーライドできます。JVM コマンド行オプションは、rsed.envvars の _RSE_JAVAOPTS ディレクティブで定義されます。IBM サポートから指示された場合以外は、ダンプの設定を一切変更しないでください。
ダンプは、%uid.JVM.TDUMP.%job.D%y%m%d.T%H%M%S という書式のデフォルト名、または JAVA_DUMP_TDUMP_PATTERN 環境変数の設定によって決まるデフォルト名を使用して、順次 MVS データ・セットに書き込まれます。
変数 | 使用法 |
---|---|
%uid | ユーザー ID |
%job | ジョブ名 |
%y | 年 (2 桁) |
%m | 月 (2 桁) |
%d | 日 (2 桁) |
%H | 時間 (2 桁) |
%M | 分 (2 桁) |
%S | 秒 (2 桁) |
ダンプは CEEDUMP.yyyymmdd.hhmmss.pid という名前の z/OS UNIX ファイルに書き込まれます。ここで、yyyymmdd は現在の日付で、hhmmss は現在の時刻、pid は現行プロセス ID です。このファイルの可能なロケーションについては、z/OS UNIX ダンプ・ロケーションに説明があります。
ダンプは HEAPDUMP.yyyymmdd.hhmmss.pid.TXT という名前の z/OS UNIX ファイルに書き込まれます。ここで、yyyymmdd は現在の日付で、hhmmss は現在の時刻、pid は現行プロセス ID です。このファイルの可能なロケーションについては、z/OS UNIX ダンプ・ロケーションに説明があります。
Developer for System z がオペレーター・コマンドを提供して、このダンプをトリガーすることに注意してください。詳しくは、「ホスト構成ガイド」(SC88-5663) の「オペレーター・コマンド」の章を参照してください。
ダンプは JAVADUMP.yyyymmdd.hhmmss.pid.TXT という名前の z/OS UNIX ファイルに書き込まれます。ここで、yyyymmdd は現在の日付で、hhmmss は現在の時刻、pid は現行プロセス ID です。このファイルの可能なロケーションについては、z/OS UNIX ダンプ・ロケーションに説明があります。
Developer for System z がオペレーター・コマンドを提供して、このダンプをトリガーすることに注意してください。詳しくは、「ホスト構成ガイド」(SC88-5663) の「オペレーター・コマンド」の章を参照してください。
JVM ダンプについて詳しくは、「Java Diagnostic Guide」(SC34-6358) を、また、LE 固有の情報については、「Language Environment デバッグ・ガイド」(GA88-8548) を参照してください。
JVM は、以下の各ロケーションの有無と書き込み権限を検査し、最初に使用可能なロケーションに CEEDUMP、HEAPDUMP、および JAVADUMP ファイルを保管します。 ダンプ・ファイルを正しく書き込むための十分なディスク・スペースが必要であることに注意してください。
デバッグ・マネージャーのトレースは、「ホスト構成ガイド」 (SC88-5663)の『オペレーター・コマンド』の説明にあるように、システム・オペレーターによって制御されます。
JES ジョブ・モニターのトレースは、「ホスト構成ガイド」 (SC88-5663)の『オペレーター・コマンド』の説明にあるように、システム・オペレーターによって制御されます。
RSE に関連するコンポーネントによって作成される複数のログ・ファイルがあります。そのほとんどは userlog/$LOGNAME に置かれます。ここで、userlog は rsed.envvars 内の user.log ディレクティブと DSTORE_LOG_DIRECTORY ディレクティブを組み合わせた値で、$LOGNAME はログオン・ユーザー ID (大文字) です。user.log ディレクティブがコメント化されているか存在しない場合は、ユーザーのホーム・パスが使用されます。ホーム・パスはユーザー ID の OMVS セキュリティー・セグメントで定義されます。DSTORE_LOG_DIRECTORY ディレクティブがコメント化されているか存在しない場合は、user.log の値に .eclipse/RSE/ が付加されます。
ffs*.log および rsecomm.log に書き込まれるデータの量は、modify rsecommlog オペレーター・コマンドを使用して制御するか、debug_level in rsecomm.properties を設定して制御します。 詳しくは、 「ホスト構成ガイド」 (SC88-5663) の『オペレーター・コマンド』および「ホスト構成ガイド」 (SC88-5663) の『(オプション) RSE トレース』を参照してください。
.dstore* ログ・ファイルの作成は、「ホスト構成ガイド」 (SC88-5663)の『_RSE_JAVAOPTS での追加 Java 始動パラメーター』の説明にあるように、-DDSTORE_* Java 始動オプションによって制御されます。
RSE デーモンおよび RSE スレッド・プールに固有のログ・ファイルは、daemon-home に置かれます。ここで、daemon-home は rsed.envvars 内の daemon.log ディレクティブの値になります。daemon.log ディレクティブがコメント化されているか存在しない場合は、RSED 開始タスクに割り当てられているユーザー ID のホーム・ディレクトリーが使用されます。ホーム・ディレクトリーはユーザー ID の OMVS セキュリティー・セグメントで定義されます。
rsedaemon.log および rseserver.log に書き込まれるデータの量は、modify rsedaemonlog および modify rseserverlog オペレーター・コマンドによって制御するか、rsecomm.properties で debug_level を設定することによって制御します。 詳しくは、 「ホスト構成ガイド」 (SC88-5663) の『オペレーター・コマンド』および「ホスト構成ガイド」 (SC88-5663) の『(オプション) RSE トレース』を参照してください。
serverlogs.count、stderr.*.log、および stdout.*.log は、rsed.envvars 内の enable.standard.log ディレクティブがアクティブである場合、またはこの機能が modify rsestandardlog on オペレーター・コマンドで動的にアクティブ化される場合にのみ作成されます。
ユーザーは、クライアント上の CARMA 接続のプロパティー・タブで「トレース・レベル」を設定することにより、CARMA サーバーが生成するトレース情報の量を制御できます。「トレース・レベル」の選択項目は、以下のとおりです。
エラー・ロギング
ログ・ファイルのロケーションの詳細については、ログ・ファイルを参照してください。
z/OS システム・プログラマーは、CRASRV.properties の crastart.syslog を設定したり、rsecomm.properties かオペレーター・コマンドで rsecomm.log のデバッグ・レベルを設定したりして、CARMA の CRASTART 始動メソッドが生成するトレース情報の量を制御できます。
//COBOL EXEC PGM=IGYCRCTL,REGION=2048K,
//* PARM=('EXIT(ADEXIT(ELAXMGUX))',
// PARM=('EXIT(ADEXIT(''MAXTRACE'',ELAXMGUX))',
// 'ADATA',
// 'LIB',
// 'TEST(NONE,SYM,SEP)',
// 'LIST',
// 'FLAG(I,I)'&CICS &DB2 &COMP)
ABOUT TOO OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000'
SUCCESSFUL OPEN SIDEFILE1 - NAME = 'uid.DT021207.TT110823.M0000045.C0000000'
ABOUT TOO OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001'
SUCCESSFUL OPEN SIDEFILE2 - NAME = 'uid.DT021207.TT110823.M0000111.C0000001'
ABOUT TOO OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002'
SUCCESSFUL OPEN SIDEFILE3 - NAME = 'uid.DT021207.TT110823.M0000174.C0000002'
ABOUT TOO OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
SUCCESSFUL OPEN SIDEFILE4 - NAME = 'uid.DT021207.TT110823.M0000236.C0000003'
22 //COBOL.WSEDSF1 DD DISP=MOD,
// DSN=uid.ERRCOB.member.SF.Z682746.XML
23 //COBOL.WSEDSF2 DD DISP=MOD,
// DSN=uid.ERRCOB.member.SF.Z682747.XML
Developer for System z では、z/OS UNIX ファイル・システムおよび一部の z/OS UNIX ファイルに特定の許可ビットがセットされている必要があります。
リモート・システム・エクスプローラー (RSE) は、クライアントをホストに接続するなどのコア・サービスを提供する Developer for System z コンポーネントです。これは、ユーザーのセキュリティー環境を作成するなどのタスクの実行を許可されている必要があります。
Java または z/OS UNIX バイナリーをホスティングするファイル・システムが NOSETUID パラメーターを使って組み込まれている場合、類似したエラー (BPXP014I および BPXP015I といったメッセージなど) が発生する可能性があります。
TSO の ISHELL コマンドを使用して、SETUID ビットの現行ステータスをリストします。ISHELL パネルで、「File_systems」>「1. マウント・テーブル... (1. Mount table...)」を選択して、マウントされたファイル・システムをリストします。a 行コマンドは、選択されたファイル・システムの属性を表示します。ここで、「Ignore SETUID」フィールドは 0 であることが必要です。
リモート・システム・エクスプローラー (RSE) は、クライアントをホストに接続するなどのコア・サービスを提供する Developer for System z コンポーネントです。これは、クライアントのユーザー ID への切り替えなどのタスクを実行するために、プログラム制御で実行する必要があります。
z/OS UNIX プログラム制御ビットは、SMP/E インストールのときに、必要ならば設定されます。ただし、セキュリティーに関する考慮事項の説明にあるように、セキュリティー製品への Java インターフェースは除きます。この許可ビットは、Developer for System z ディレクトリーの手動コピー中に保存しなかった場合、失われることがあります。
z/OS UNIX コマンド ls -E を使用して、拡張属性をリストします。このリストで、プログラム制御ビットには、次のサンプルに示すように英字の p のマークが付きます ($ は z/OS UNIX プロンプトです)。
$ cd /usr/lpp/rdz
$ ls -E lib/fekf*
-rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
$ cd /usr/lpp/rdz
$ su
# extattr +p lib/fekf*
# exit
$ ls -E lib/fekf*
-rwxr-xr-x -ps- 2 user group 94208 Jul 8 12:31 lib/fekfdir.dll
リモート・システム・エクスプローラー (RSE) は、クライアントをホストに接続するなどのコア・サービスを提供する Developer for System z コンポーネントです。詳細なプロセス・リソース使用量を表示するなどのタスクを実行するためには、このコンポーネントを APF 許可がある状態で実行する必要があります。
z/OS UNIX APF ビットは、SMP/E インストールのときに、必要ならば設定されます。この許可ビットは、Developer for System z ディレクトリーの手動コピー中に保存しなかった場合、失われることがあります。
拡張属性をリストするには、z/OS UNIX コマンド ls -E を使用します。このリストでは、次のサンプルに示すように、APF ビットに英字の a のマークが付きます ($ は z/OS UNIX プロンプトです)。
$ cd /usr/lpp/rdz
$ ls -E bin/fekfrivp
-rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
APF ビットを手動でセットするには、次のサンプルに示すように、z/OS UNIX コマンド extattr +a を使用します ($ および # は z/OS UNIX プロンプトです)。
$ cd /usr/lpp/rdz
$ su
# extattr +a bin/fekfrivp
# exit
$ ls -E bin/fekfrivp
-rwxr-xr-x aps- 2 user group 114688 Sep 17 06:41 bin/fekfrivp
オプションの Developer for System z サービスの中には、MVS ロード・モジュールを z/OS UNIX で使用可能にしなければならないものもあります。これを行うには、z/OS UNIX で、スティッキー・ビットをオンにしたスタブ (ダミー・ファイル) を作成します。スタブが実行されると、z/OS UNIX は同じ名前の MVS ロード・モジュールを探し、代わりにそのロード・モジュールを実行します。
z/OS UNIX スティッキー・ビットは、SMP/E インストールのときに、必要ならば設定されます。これらの許可ビットは、Developer for System z ディレクトリーの手動コピー中に保存しなかった場合、失われることがあります。
$ cd /usr/lpp/rdz
$ ls -l bin/CRA*
-rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
$ cd /usr/lpp/rdz
$ su
# chmod +t bin/CRA*
# exit
$ ls -l bin/CRA*
-rwxr-xr-t 2 user group 71 Jul 8 12:31 bin/CRASTART
netstat コマンド (TSO または z/OS UNIX) を使用すると、現在使用中のポートの概要を取得できます。このコマンドの出力は、下記の例のようになります。使用されているポートは、「Local Socket」列の最後の番号 (「..」の後) です。これらのポートは既に使用されているので、Developer for System z 構成に使用することはできません。
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 16:36:42
User Id Conn Local Socket Foreign Socket State
------- ---- ------------ -------------- -----
BPXOINIT 00000014 0.0.0.0..10007 0.0.0.0..0 Listen
INETD4 0000004D 0.0.0.0..512 0.0.0.0..0 Listen
RSED 0000004B 0.0.0.0..4035 0.0.0.0..0 Listen
JMON 00000038 0.0.0.0..6715 0.0.0.0..0 Listen
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 12:46:25
User Id Conn State
------- ---- -----
BPXOINIT 00000018 Listen
Local Socket: 0.0.0.0..10007
Foreign Socket: 0.0.0.0..0
INETD4 00000046 Listen
Local Socket: 0.0.0.0..512
Foreign Socket: 0.0.0.0..0
RSED 0000004B Listen
Local Socket: 0.0.0.0..4035
Foreign Socket: 0.0.0.0..0
JMON 00000037 Listen
Local Socket: 0.0.0.0..6715
Foreign Socket: 0.0.0.0..0
もう 1 つ存在する可能性がある制限は、予約済み TCP/IP ポートです。TCP/IP ポートを予約する一般的な場所は、以下の 2 つです。
これは TCP/IP 開始タスクの PROFILE DD ステートメントによって参照されるデータ・セットで、多くの場合、SYS1.TCPPARMS(TCPPROF) という名前が付いています。
これらのステートメントの詳細については、「Communications Server IP 構成ガイド」(SC88-8926) を参照してください。
これらの予約済みポートは、netstat portl コマンド (TSO または z/OS UNIX) でリストできます。このコマンドは、以下の例のような出力を作成します。
MVS TCP/IP NETSTAT CS VxRy TCPIP Name: TCPIP 17:08:32
Port# Prot User Flags Range IP Address
----- ---- ---- ----- ----- ----------
00007 TCP MISCSERV DA
00009 TCP MISCSERV DA
00019 TCP MISCSERV DA
00020 TCP OMVS D
00021 TCP FTPD1 DA
00025 TCP SMTP DA
00053 TCP NAMESRV DA
00080 TCP OMVS DA
03500 TCP OMVS DAR 03500-03519
03501 TCP OMVS DAR 03500-03519
NETSTAT コマンドの詳細については、「Communications Server IP システム管理者のコマンド」(SC88-9073) を参照してください。
RSE デーモンは z/OS UNIX Java プロセスであり、機能を実行するために大きな領域サイズを必要とします。したがって、OMVS アドレス・スペースに大きなストレージ限度を設定することが重要です。
RSE デーモンは、BPXBATSL (この領域サイズは 0 であることが必要です) を使用して JCL によって始動されます。
SYS1.PARMLIB(BPXPRMxx) で MAXASSIZE を設定してください。これは、デフォルトの OMVS アドレス・スペース (プロセス) 領域サイズを 2G に定義します。これは、許容される最大サイズです。これはシステム全体の限度であるため、すべての z/OS UNIX アドレス・スペースに対してアクティブとなります。これが望ましい値でない場合は、ご使用のセキュリティー・ソフトウェアで Developer for System z 独自の限度を設定できます。
デーモンのユーザー ID OMVS セグメント内で ASSIZEMAX を検査し、2147483647 に設定するか、できれば NONE に設定して SYS1.PARMLIB(BPXPRMxx) 値を使用してください。
必ず、システム出口 IEFUSI または IEALIMIT が OMVS アドレス・スペース領域サイズを制御できないようにしてください。これを実現する 1 つの方法は、SYS1.PARMLIB(SMFPRMxx) 内に SUBSYS(OMVS,NOEXITS) をコーディングすることです。
SYS1.PARMLIB(SMFPRMxx) 内の MEMLIMIT キーワードでは、64 ビット・タスクが 2 GB 境界より上に割り振ることのできる仮想ストレージの量を制限します。JCL の REGION パラメーターとは異なり、MEMLIMIT=0M は、プロセスが 2 GB 境界より上の仮想ストレージを使用できないことを意味します。
SMFPRMxx に MEMLIMIT を指定しない場合は、デフォルト値 0M が使用されるため、タスクは (31 ビット) 2 GB 境界より下の 2 GB にバインドされます。このデフォルトは z/OS 1.10 で 2G に変更されて、64 ビット・タスクが 4 GB まで使用できるようになりました (2 GB 境界より下の 2 GB および MEMLIMIT で許可される 2 GB 境界より上の 2 GB)。
MEMLIMIT は、JCL で EXEC カードのパラメーターとして指定することもできます。MEMLIMIT パラメーターを指定しない場合は、SMF に定義された値がデフォルトとなります。ただし、REGION=0M を指定した場合は、デフォルトが NOLIMIT となります。
ユーザーがコンパイル・アクション時にエラー・フィードバックを選択した場合、Developer for System z によっていくつかの一時データ・セットが作成されます。これらのデータ・セットのいずれかがスペース不足になった場合に、コンパイル・ジョブは B37-04 スペース異常終了で終了します。
ユーザーがこの問題を経験した場合は、FEK.SFEKPROC(FEKFERRF) 内のスペース割り振りを調整してください。デフォルト値は SPACE(200,40) TRACKS です。
SYS1.PARMLIB(BPXPRMxx) には、複数の Developer for System z クライアントがアクティブなときに到達する可能性がある、z/OS UNIX に関連する多数の限度が定義されています。大部分の BPXPRMxx 値は、SETOMVS および SET OMVS コンソール・コマンドで動的に変更できます。
BPXPRMxx のいずれかの限度に到達しそうなときに z/OS UNIX でコンソール・メッセージ (BPXI040I) を表示させるには、SETOMVS LIMMSG=ALL コンソール・コマンドを使用します。
このセクションは、Secure Socket Layer (SSL) のセットアップ時、または既存のセットアップの検査時や変更時に発生する可能性があるいくつかの一般的な問題に関して、ユーザーを支援するためのものです。また、このセクションには、X.509 証明書を使用したユーザー自身の認証をサポートする、サンプルのセットアップも記載されています。
セキュアな通信は、正しい通信パートナーと通信できるようにし、他の人間がデータを傍受して読み取ることが困難な方法で情報を伝送することを意味します。SSL は、TCP/IP ネットワーク内でその機能を提供します。SSL では、デジタル証明書を使用して自分自身を識別し、公開鍵プロトコルを使用して通信を暗号化します。SSL で使用されるデジタル証明書および公開鍵プロトコルの詳細については、「Security Server RACF セキュリティー管理者のガイド」(SA88-8613) を参照してください。
Developer for System z 用に SSL 通信をセットアップするために必要なアクションは、厳密な必要性、使用される RSE 通信方式、およびサイトで既に使用可能なものに応じてサイトごとに異なります。
このセクションでは、現行の RSE 定義のクローンを作成して、SSL を使用する 2 番目の RSE デーモン接続を使用できるようにします。また、RSE 接続のさまざまな部分で使用される独自のセキュリティー証明書も作成します。
以下に述べるタスクの一部では、ユーザーが z/OS UNIX 内でアクティブであることを想定しています。そのためには、TSO コマンド OMVS を発行します。TSO に戻るには、exit コマンドを使用します。
rsed.envvars の _RSE_JAVAOPTS ディレクティブの DSTORE_SSL_ALGORITHM 変数によって、SSL とその後継の TLS (トランスポート層セキュリティー) を暗号化方式として選択できます。詳しくは、「ホスト構成ガイド」(SC88-5663) の『_RSE_JAVAOPTS での追加 Java 始動パラメーターの定義』を参照してください。
SSL で使用される ID 証明書と暗号化/暗号化解除鍵は、鍵ファイルに保管されます。この鍵ファイルには、アプリケーション・タイプに応じて、さまざまな実装が存在します。
しかし、すべての実装が同じ原則に従います。あるコマンドが、鍵ペア (公開鍵とそれに関連付けられた秘密鍵) を生成します。その後、コマンドは公開鍵を X.509 自己署名証明書の中に包み込み、この証明書は単一要素の証明書チェーンとして保管されます。この証明書チェーンと秘密鍵が (別名によって識別される) 1 つの項目として、鍵ファイルに保管されます。
証明書ストレージ | 作成者および管理者 | RSE デーモン | RSE サーバー |
---|---|---|---|
鍵リング | SAF 準拠のセキュリティー製品 | サポート | サポート |
鍵データベース | z/OS UNIX の gskkyman | サポート | / |
鍵ストア | Java の keytool | / | サポート |
STEPLIB=$STEPLIB:SYS1.SIEALNKE
RACF およびデジタル証明書については、「Security Server RACF セキュリティー管理者のガイド」(SA88-8613) を参照してください。gskkyman の資料は、「System SSL プログラミング」(SD88-6252) で、keytool の資料は、http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html で入手できます。
RSE デーモン鍵データベースの作成に gskkyman を使用し、RSE サーバー鍵ストアの作成に keytool を使用する場合は、このステップを実行しないでください。
RACDCERT コマンドは、秘密鍵と証明書を RACF にインストールし、保守します。RACF は、複数の秘密鍵と証明書を 1 つのグループとして管理できます。それらのグループは、鍵リングと呼ばれます。
証明書には、自己署名付きの証明書と認証局 (CA) によって署名された証明書があります。CA によって署名された証明書は、その証明書の所有者が本人に間違いないことを CA が保証することを意味します。署名プロセスでは、CA 資格情報 (証明書でもある) がユーザーの証明書に追加され、複数要素の証明書チェーンが作成されます。
CA によって署名された証明書を使用した場合は、Developer for System z クライアントによる信頼性検証のための質問を回避できます (クライアントが既にその CA を信頼している場合)。
RACDCERT コマンドの詳細については、「Security Server RACF コマンド言語解説書」(SA88-8617) を参照してください。
# permit RSE daemon to access certificates
RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcrse)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcrse)
# refresh to make the changes visible
SETROPTS RACLIST(FACILITY) REFRESH
# create self-signed certificate
RACDCERT ID(stcrse) GENCERT SUBJECTSDN(CN('rdz rse ssl') +
OU('rdz') O('IBM') L('Raleigh') SP('NC') C('US')) +
NOTAFTER(DATE(2017-05-21)) WITHLABEL('rdzrse') KEYUSAGE(HANDSHAKE)
# (optional) additional steps required to use a signed certificate
# 1. create a signing request for the self-signed certificate
RACDCERT ID(stcrse) GENREQ (LABEL('rdzrse')) DSN(dsn)
# 2. send the signing request to your CA of choice
# 3. check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# 4. mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# 5. add the signed certificate to the database;
# this will replace the self-signed one
RACDCERT ID(stcrse) ADD(dsn) WTIHLABEL('rdzrse') TRUST
# Do NOT delete the self-signed certificate before replacing it.
# If you do, you lose the private key that goes with the certificate,
# which makes the certificate useless.
RACDCERT ID(stcrse) ADDRING(rdzssl.racf)
RACDCERT ID(stcrse) CONNECT(LABEL('rdzrse') RING(rdzssl.racf) +
DEFAULT USAGE(PERSONAL))
# additional step required to use a signed certificate
# 6. add CA certificate to key ring
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('CA cert') +
RING(rdzssl.racf))
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
上記のサンプルは始めに、必要なプロファイルを作成し、ユーザー ID STCRSE に、そのユーザー ID が所有する証明書と鍵リングへのアクセスを許可します。使用するユーザー ID は、SSL RSE デーモンを実行するために使用したユーザー ID に一致する必要があります。次のステップは、新しい自己署名証明書を rdzrse というラベルで作成することです。パスワードは必要ありません。この証明書は、その後、新規に作成された鍵リング (rdzssl.racf) に追加されます。証明書の場合と同様に、鍵リングにパスワードは必要ありません。署名付き証明書を使用するために必要なステップもリストされます。
証明書の署名に使用する CA 証明書は、同様に、別の高位の CA 証明書により署名されることもあるため、注意が必要です。その場合、当該の高位の CA 証明書も、鍵リングに追加する必要があります。このプロセスは、高位の CA 証明書がルートの CA 証明書になるまで繰り返します。ルートの CA 証明書は、必ず自己署名証明書になります。
結果は、以下の list オプションおよび listring オプションを使用して検査できます。
RACDCERT ID(stcrse) LIST
Digital certificate information for user STCRSE:
Label: rdzrse
Certificate ID: 2QjW1OXi0sXZ1aaEqZmihUBA
Status: TRUST
Start Date: 2007/05/24 00:00:00
End Date: 2017/05/21 23:59:59
Serial Number:
>00<
Issuer's Name:
>CN=my CA.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
Subject's Name:
>CN=rdz rse ssl.OU=rdz.O=IBM.L=Raleigh.SP=NC.C=US<
Private Key Type: Non-ICSF
Private Key Size: 1024
Ring Associations:
Ring Owner: STCRSE
Ring:
>rdzssl.racf<
RACDCERT ID(stcrse) LISTRING(rdzssl.racf)
Digital ring information for user STCRSE:
Ring:
>rdzssl.racf<
Certificate Label Name Cert Owner USAGE DEFAULT
-------------------------------- ------------ -------- -------
rdzrse ID(STCRSE) PERSONAL YES
CA cert CERTAUTH CERTAUTH NO
このステップでは、SSL セットアップを既存のセットアップと並行して稼働できるように、RSE 構成ファイルの新しいインスタンスを作成します。以下のサンプル・コマンドでは、構成ファイルが /etc/rdz/ に入っていることを想定しています。これは、「ホスト構成ガイド」 (SC88-5663)の『カスタマイズ・セットアップ』で使用されるデフォルトのロケーションです。
$ cd /etc/rdz
$ mkdir ssl
$ cp rsed.envvars ssl
$ cp ssl.properties ssl
$ ls ssl
rsed.envvars ssl.properties
上記の例の z/OS UNIX コマンドは ssl というサブディレクトリーを作成し、そのサブディレクトリーに変更が必要な構成ファイルを取り込みます。その他の構成ファイル、インストール・ディレクトリー、および MVS コンポーネントは、SSL 固有ではないので、共用できます。
既存の大部分の構成ファイルを再利用することにより、SSL のセットアップに実際に必要な変更に集中でき、RSE セットアップ全体を再度実行しなくても済みます。(例えば、ISPF.conf の新しいロケーションを定義せずに済みます。)
これまでのところ、定義は現行のセットアップの正確なコピーであり、これは、新しい RSE デーモンのログが現行のサーバー・ログ・ファイルと重なることを意味します。また、RSE は、ssl ディレクトリーにコピーされなかった構成ファイルがどこにあるかも知っている必要があります。 どちらの問題も、rsed.envvars に小さな変更を加えることによって対処できます。
$ oedit /etc/rdz/ssl/rsed.envvars
-> change: _RSE_RSED_PORT=4047
-> change: -Ddaemon.log=/var/rdz/logs/ssl
-> change: -Duser.log=/var/rdz/logs/ssl
-> add at the END:
# -- NEEDED TO FIND THE REMAINING CONFIGURATION FILES
CFG_BASE=/etc/rdz
CLASSPATH=.:$CFG_BASE:$CLASSPATH
# --
上記の例の変更では、新しいログ・ロケーションが定義されます (このログ・ロケーションが存在しない場合は、RSE デーモンによって作成されます)。また、これらの変更では、SSL RSE プロセスが最初に現行ディレクトリー (/etc/rdz/ssl) で構成ファイルを検索し、その後に元のディレクトリー (/etc/rdz) を検索するように CLASSPATH も更新されます。
ssl.properties を更新することにより、SSL 暗号化通信を使用して開始するように RSE に指示します。
$ oedit /etc/rdz/ssl/ssl.properties
-> change: enable_ssl=true
-> uncomment and change: daemon_keydb_file=rdzssl.racf
-> uncomment and change: daemon_key_label=rdzrse
-> uncomment and change: server_keystore_file=rdzssl.racf
-> uncomment and change: server_keystore_label=rdzrse
-> uncomment and change: server_keystore_type=JCERACFKS
上記の例の変更では SSL を使用可能に設定してから、RSE デーモンおよび RSE サーバーに対して、(共有の) 証明書が鍵リング rdzssl.racf 内のラベル rdzrse の下に保管されていることを通知します。JCERACFKS キーワードは、SAF 準拠の鍵リングが鍵ストアとして使用されることを RSE サーバーに通知します。
デーモンが使用する System SSL は、常に ICSF を使用することに注意してください (使用可能な場合)。この ICSF は System z 暗号化ハードウェアへのインターフェースです。ICSF 使用時にデーモン定義をサーバーと共有できるようにするには、server_keystore_type JCECCARACFKS を指定する必要があります。ここでは、SAF 準拠の鍵リングが公開鍵の鍵ストアとしても使用されていますが、秘密鍵は ICSF に保管されます。 「Cryptographic Services ICSF Administrator's Guide」(SA22-7521) で説明されているように、ICSF は CSFKEYS および CSFSERV セキュリティー・クラス内のプロファイルを使用して、暗号鍵と暗号サービスを使用できるユーザーを制御します。
//RSEDSSL JOB CLASS=A,MSGCLASS=A,MSGLEVEL=(1,1),USER=STCRSE
//*
//* RSE DAEMON - SSL
//*
//RSED PROC TMPDIR=,
// PORT=,
// IVP=, * 'IVP' to do an IVP test
// CNFG='/etc/rdz/ssl',
// HOME='/usr/lpp/rdz'
//*
//RSED EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT,
// PARM='PGM &HOME./bin/rsed.sh &IVP -C&CNFG -P&PORT -T&TMPDIR'
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
// PEND
//*
//RSED EXEC RSED
//*
SSL ホスト構成が完了し、前に作成したジョブ FEK.#CUST.PROCLIB(RSEDSSL) を実行依頼することにより、SSL 用の RSE デーモンを始動できます。
この時点で、Developer for System z クライアントと接続することにより、新しいセットアップをテストできます。SSL で使用するために新しい構成を (既存の構成のクローン作成によって) 作成してあるので、RSE デーモン用のポート 4047 を使用して、クライアント上に新しい接続を定義する必要があります。
接続と同時に、ホストとクライアントはセキュア・パスをセットアップするために何らかのハンドシェークを開始します。このハンドシェークの一環として、証明書の交換があります。Developer for System z クライアントは、ホスト証明書またはその証明書に署名した CA を認識できない場合、ユーザーにその証明書が信頼できるかどうかを尋ねるプロンプトを出します。
「完了」ボタンをクリックすると、この証明書を信頼できるものとして受け入れることができ、その後、接続の初期化が続行されます。
証明書がクライアントに既知となった後、このダイアログが再び表示されることはありません。 信頼できる証明書のリストは、「ウィンドウ」>「設定...」>「リモート・システム」>「SSL」を選択することによって管理できます。その場合、次のダイアログが表示されます。
SSL 通信が失敗した場合、クライアントはエラー・メッセージを返します。 詳細な情報は、RSE デーモンおよびスレッド・プールのロギング、および RSE ユーザー・ロギングの説明のように、さまざまなサーバーおよびユーザー・ログ・ファイルから入手できます。
RSE デーモンは、X.509 証明書で自分自身を認証するユーザーをサポートしています。この機能の場合、SSL 暗号化通信の使用は前提条件です。この機能は、SSL で使用される証明書でのホスト認証を拡張したものだからです。
ユーザーの証明書認証を行うには、クライアント認証、X.509 証明書を使用したの説明にあるように、複数の方法があります。以下の手順は、セキュリティー・ソフトウェアで HostIdMappings 証明書拡張を使用して証明書を認証する方式をサポートするために必要なセットアップを文書化したものです。
RACDCERT CERTAUTH ALTER(LABEL('HighTrust CA')) HIGHTRUST
RACDCERT ID(stcrse) CONNECT(CERTAUTH LABEL('HighTrust CA') +
RING(rdzssl.racf))
これで、CA 証明書のためのセキュリティー・ソフトウェアのセットアップは完了しました。
RDEFINE SERVAUTH IRR.HOST.CDFMVS08.RALEIGH.IBM.COM UACC(NONE)
PERMIT IRR.HOST.CDFMVS08.RALEIGH.IBM.COM CLASS(SERVAUTH) +
ACCESS(READ) ID(stcrse)
SETROPTS CLASSACT(SERVAUTH) RACLIST(SERVAUTH)
or
SETROPTS RACLIST(SERVAUTH) REFRESH
これで、HostIdMappings 拡張のためのセキュリティー・ソフトウェアのセットアップは完了しました。
RSE デーモンの鍵データベースに SAF 準拠の鍵リングを使用する場合は、このステップを実行しないでください。
gskkyman は z/OS UNIX シェル・ベースのメニュー方式プログラムであり、秘密鍵、証明書要求、および証明書が入っている z/OS UNIX ファイルを作成し、それにデータを取り込み、管理します。この z/OS UNIX ファイルは鍵データベースと呼ばれます。
PATH=$PATH:/usr/lpp/gskssl/bin
export NLSPATH=/usr/lpp/gskssl/lib/nls/msg/En_US.IBM-1047/%N:$NLSPATH
export STEPLIB=$STEPLIB:SYS1.SIEALNKE
$ cd /etc/rdz/ssl
$ gskkyman Database Menu
1 - Create new database
Enter option number: 1
Enter key database name (press ENTER to return to menu): rdzssl.kdb
Enter database password (press ENTER to return to menu): rsessl
Re-enter database password: rsessl
Enter password expiration in days (press ENTER for no expiration):
Enter database record length (press ENTER to use 2500):
Key database /etc/rdz/ssl/rdzssl.kdb created.
Press ENTER to continue.
Key Management Menu
6 - Create a self-signed certificate
Enter option number (press ENTER to return to previous menu): 6
Certificate Type
5 - User or server certificate with 1024-bit RSA key
Select certificate type (press ENTER to return to menu): 5
Enter label (press ENTER to return to menu): rdzrse
Enter subject name for certificate
Common name (required): rdz rse ssl
Organizational unit (optional): rdz
Organization (required): IBM
City/Locality (optional): Raleigh
State/Province (optional): NC
Country/Region (2 characters - required): US
Enter number of days certificate will be valid (default 365): 3650
Enter 1 to specify subject alternate names or 0 to continue: 0
Please wait .....
Certificate created.
Press ENTER to continue.
Key Management Menu
0 - Exit program
Enter option number (press ENTER to return to previous menu): 0
$ ls -l rdzssl.*
total 152
-rw------- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb
-rw------- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
$ chmod 644 rdzssl.*
$ ls -l rdzssl.*
-rw-r--r-- 1 IBMUSER SYS1 35080 May 24 14:24 rdzssl.kdb
-rw-r--r-- 1 IBMUSER SYS1 80 May 24 14:24 rdzssl.rdb
上記のサンプルは始めに、rdzssl.kdb という鍵データベースを、パスワード rsessl を使用して作成します。データベースの作成後、約 10 年間 (うるう日はカウントしません) 有効な新しい自己署名証明書を作成することにより、データベースにデータが取り込まれます。証明書は、rdzrse というラベルの下に、鍵データベースに使用されたのと同じパスワード (rsessl) を使用して保管されます (これは RSE の必要条件です)。
gskkyman は、鍵データベースに (非常にセキュアな) 600 許可ビット・マスク (所有者だけがアクセスできる) を割り振ります。 デーモンが鍵データベースの作成者と同じユーザー ID を使用している場合を除き、アクセス権限の設定をもっと制限の少ないものにする必要があります。chmod コマンドには、644 (所有者は読み取り/書き込み権限を持ち、全員が読み取り権限を持つ) のマスクを使用できます。
結果を検査するには、以下のように、「Manage keys and certificates」サブメニューで 「Show certificate information」オプションを選択します。
$ gskkyman
Database Menu
2 - Open database
Enter option number: 2
Enter key database name (press ENTER to return to menu): rdzssl.kdb
Enter database password (press ENTER to return to menu): rsessl
Key Management Menu
1 - Manage keys and certificates
Enter option number (press ENTER to return to previous menu): 1
Key and Certificate List
1 - rdzrse
Enter label number (ENTER to return to selection menu, p for previous list): 1
Key and Certificate Menu
1 - Show certificate information
Enter option number (press ENTER to return to previous menu): 1
Certificate Information
Label: rdzrse
Record ID: 14
Issuer Record ID: 14
Trusted: Yes
Version: 3
Serial number: 45356379000ac997
Issuer name: rdz rse ssl
rdz
IBM
Raleigh
NC
US
Subject name: rdz rse ssl
rdz
IBM
Raleigh
NC
US
Effective date: 2007/05/24
Expiration date: 2017/05/21
Public key algorithm: rsaEncryption
Public key size: 1024
Signature algorithm: sha1WithRsaEncryption
Issuer unique ID: None
Subject unique ID: None
Number of extensions: 3
Enter 1 to display extensions, 0 to return to menu: 0
Key and Certificate Menu
0 - Exit program
Enter option number (press ENTER to return to previous menu): 0
次の ssl.properties のサンプルは、daemon_* ディレクティブが、前に示した SAF 鍵リングのサンプルと異なることを示しています。
$ oedit /etc/rdz/ssl/ssl.properties
-> change: enable_ssl=true
-> uncomment and change: daemon_keydb_file=rdzssl.kdb
-> uncomment and change: daemon_keydb_password=rsessl
-> uncomment and change: daemon_key_label=rdzrse
-> uncomment and change: server_keystore_file=rdzssl.racf
-> uncomment and change: server_keystore_label=rdzrse
-> uncomment and change: server_keystore_type=JCERACFKS
上記の変更は SSL を使用可能に設定し、RSE デーモンに、パスワード rsessl を持つ鍵データベース rdzssl.kdb 内のラベル rdzrse の下に証明書が保管されることを通知します。RSE サーバーは、依然として SAF 準拠の鍵リングを使用しています。
RSE サーバーの鍵ストアに SAF 準拠の鍵リングを使用する場合は、このステップを実行しないでください。
すべての情報を 1 つのパラメーターとして渡すことができますが、コマンド行の長さに制限があるため、以下のように何らかの対話性が必要になります。
$ cd /etc/rdz/ssl
$ keytool -genkey -alias rdzrse -validity 3650 -keystore rdzssl.jks -storepass
rsessl -keypass rsessl
What is your first and last name?
[Unknown]: rdz rse ssl
What is the name of your organizational unit?
[Unknown]: rdz
What is the name of your organization?
[Unknown]: IBM
What is the name of your City or Locality?
[Unknown]: Raleigh
What is the name of your State or Province?
[Unknown]: NC
What is the two-letter country code for this unit?
[Unknown]: US
Is CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US correct? (type "yes"
or "no")
[no]: yes
$ ls -l rdzssl.*
-rw-r--r-- 1 IBMUSER SYS1 1224 May 24 14:17 rdzssl.jks
上記の例で作成した自己署名証明書は、約 10 年間有効です (うるう日はカウントしません)。これは、別名 rdzrse を使用して /etc/rdz/ssl/rdzssl.jks に保管されます。そのパスワード (rsessl) は鍵ストア・パスワードと同一であり、これは RSE の必要条件です。
結果は、以下のように -list オプションを使用して検査できます。
$ keytool -list -alias rdzrse -keystore rdzssl.jks -storepass rsessl -v
Alias name: rdzrse
Creation date: May 24, 2007
Entry type: keyEntry
Certificate chain length: 1
Certificate 1¨:
Owner: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Issuer: CN=rdz rse ssl, OU=rdz, O=IBM, L=Raleigh, ST=NC, C=US
Serial number: 46562b2b
Valid from: 5/24/07 2:17 PM until: 5/21/17 2:17 PM
Certificate fingerprints:
MD5: 9D:6D:F1:97:1E:AD:5D:B1:F7:14:16:4D:9B:1D:28:80
SHA1: B5:E2:31:F5:B0:E8:9D:01:AD:2D:E6:82:4A:E0:B1:5E:12:CB:10:1C
次の ssl.properties のサンプルは、server_* ディレクティブが、前に示した SAF 鍵リングのサンプルと異なることを示しています。
$ oedit /etc/rdz/ssl/ssl.properties
-> change: enable_ssl=true
-> uncomment and change: daemon_keydb_file=rdzssl.racf
-> uncomment and change: daemon_key_label=rdzrse
-> uncomment and change: server_keystore_file=rdzssl.jks
-> uncomment and change: server_keystore_password=rsessl
-> uncomment and change: server_keystore_label=rdzrse
-> optionally uncomment and change: server_keystore_type=JKS
上記の変更は SSL を使用可能に設定し、RSE サーバーに、パスワード rsessl を持つ鍵ストア rdzssl.jks 内のラベル rdzrse の下に証明書が保管されることを通知します。RSE デーモンは、引き続き SAF 準拠の鍵リングを使用しています。
このセクションは、Application Transparent Transport Layer Security (AT-TLS) のセットアップ時、または既存のセットアップの検査時や変更時に起きる可能性があるいくつかの一般的な問題について、ユーザーを支援するためのものです。
RFC 2246 で定義されている Transport Layer Security (TLS) プロトコルはインターネット上で通信プライバシーを提供します。その前身である Secure Socket Layer (SSL) と同様、このプロトコルは、クライアント・アプリケーションとサーバー・アプリケーションが、盗聴、改ざん、およびメッセージ偽造を防止するために設計された方法で通信を行えるようにします。Application Transparent Transport Layer Security (AT-TLS) は、z/OS ベースのアプリケーションのための TLS 実装を一か所にまとめ、TLS プロトコルの知識がなくてもすべてのアプリケーションで TLS ベースの暗号化がサポートできるようにします。AT-TLS について詳しくは、「Communications Server IP 構成ガイド」(SC88-8926) を参照してください。
IBM Rational Developer for System z の統合デバッガーは、クライアントとの暗号化通信において AT-TLS に依存します。これは、デバッグ・セッション用のデータがその他の Developer for System z クライアント/ホスト通信と同じパイプを介してフローしないためです。
AT-TLS をセットアップするために必要なアクションは、厳密な必要性、およびサイトで既に使用可能なものに応じてサイトごとに異なります。
以下に述べるタスクの一部では、ユーザーが z/OS UNIX 内でアクティブであることを想定しています。そのためには、TSO コマンド OMVS を発行します。z/OS UNIX でファイルを編集するには、oedit コマンドを使用します。 TSO に戻るには、exit コマンドを使用します。
TCP/IP 文書は、デフォルトのログ・ファイルを使用する代わりに、ポリシー・エージェントのメッセージを z/OS UNIX syslog に書き込むことを推奨しています。AT-TLS は、常にメッセージを z/OS UNIX syslog に書き込みます。
このために z/OS UNIX syslog デーモン syslogd が構成されてアクティブでなければなりません。 さらに、syslogd が作成するログ・ファイルのサイズを制御するメカニズムが必要です。
syslog 514/udp
# /etc/syslog.conf - control output of syslogd
# 1. all files with will be printed to /tmp/syslog.auth.log
auth.* /tmp/syslog.auth.log
# 2. all error messages printed to /tmp/syslog.error.log
*.err /tmp/syslog.error.log
# 3. all debug and above messages printed to /tmp/syslog.debug.log
*.debug /tmp/syslog.debug.log
# The files named must exist before the syslog daemon is started,
# unless -c startup option is used
# Start the SYSLOGD daemon for logging
# (clean up old logs)
sed -n '/^#/!s/.* \(.*\)/\1/p' /etc/syslog.conf | xargs -i rm {}
# (create new logs and add userid of message sender)
_BPX_JOBNAME='SYSLOGD' /usr/sbin/syslogd -cuf /etc/syslog.conf &
sleep 5
AT-TLS サポートは、PROFILE.TCPIP データ・セット内の TCPCONFIG ステートメントの TTLS パラメーターによってアクティブにされます。 AT-TLS はポリシー・エージェントによって管理されるため、AT-TLS ポリシーを実施するためにはポリシー・エージェントがアクティブでなければなりません。ポリシー・エージェントは TCP/IP がアクティブになるのを待機しなければならないので、PROFILE.TCPIP の AUTOSTART ステートメントはこのサーバーの始動をトリガーするのに最適の場所です。
TCPCONFIG TTLS ; Required for AT-TLS
AUTOLOG
PAGENT ; POLICY AGENT, required for AT-TLS
ENDAUTOLOG
//PAGENT PROC PRM='-L SYSLOGD' * '' or '-L SYSLOGD'
//*
//* TCP/IP POLICY AGENT
//* (PARM) (envar)
//* default cfg file: /etc/pagent.conf (-C) (PAGENT_CONFIG_FILE)
//* default log file: /tmp/pagent.log (-L) (PAGENT_LOG_FILE)
//* default log size: 300,3 (3x 300KB files) (PAGENT_LOG_FILE_CONTROL)
//*
//PAGENT EXEC PGM=PAGENT,REGION=0M,TIME=NOLIMIT,
// PARM='ENVAR("TZ=EST5DST")/&PRM'
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//*
#
# TCP/IP Policy Agent configuration information.
#
TTLSConfig /etc/pagent.ttls.conf
# Specifies the path of a TTLS policy file holding stack specific
# statements.
#
#TcpImage TCPIP /etc/pagent.conf
# If no TcpImage statement is specified, all policies will be installed
# to the default TCP/IP stack.
#
#LogLevel 31
# The sum of the following values that represent log levels:
# LOGL_SYSERR 1
# LOGL_OBJERR 2
# LOGL_PROTERR 4
# LOGL_WARNING 8
# LOGL_EVENT 16
# LOGL_ACTION 32
# LOGL_INFO 64
# LOGL_ACNTING 128
# LOGL_TRACE 256
# Log Level 31 is the default log loglevel.
#
#Codepage IBM-1047
# Specify the EBCDIC code page to be used for reading all configuration
# files and policy definition files. IBM-1047 is the default code page.
このサンプル構成ファイルは、ポリシー・エージェントがどこで TTLS ポリシーを見つけられるかを指定しています。他のステートメントについては、ポリシー・エージェントのデフォルト値を使用します。
TTLS ポリシーは、AT-TLS 規則を記述します。ポリシー・エージェント構成ファイルで定義されているように、この TTLS ポリシーは /etc/pagent.ttls.conf に配置されます。ご使用のセキュリティー・ソフトウェアで必要な定義については、後ほど扱います。
##
## TCP/IP Policy Agent AT-TLS configuration information.
##
##-----------------------------
TTLSRule RDz_Debug_Manager
{
LocalPortRange 5335
Direction Inbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef act_RDz_Debug_Manager
}
##-----------------------------
TTLSEnvironmentAction act_RDz_Debug_Manager
{
HandshakeRole Server
TTLSKeyRingParms
{
Keyring dbgmgr.racf # Keyring must be owned by the Debug Manager
}
TTLSEnvironmentAdvancedParms
{
## TLSV1.2 only for z/OS 2.1 and higher
# TLSV1.2 On # SSLv3, TLSv1 & TLSv1.1 are on by default
}
}
##-----------------------------
TTLSRule RDz_Debug_Probe-Client
{
RemotePortRange 8001
Direction Outbound
TTLSGroupActionRef grp_Production
TTLSEnvironmentActionRef act_RDz_Debug_Probe-Client
}
##-----------------------------
TTLSEnvironmentAction act_RDz_Debug_Probe-Client
{
HandshakeRole Client
TTLSKeyRingParms
{
Keyring *AUTH*/* # virtual key ring holding CA certificates
}
TTLSEnvironmentAdvancedParms
{
## TLSV1.2 only for z/OS 2.1 and higher
# TLSV1.2 On # SSLv3, TLSv1 & TLSv1.1 are on by default
}
}
##-----------------------------
TTLSGroupAction grp_Production
{
TTLSEnabled On
## TLSv1.2zOS1.13 only for z/OS 1.13
TTLSGroupAdvancedParmsRef TLSv1.2zOS1.13
Trace 3 # Log Errors to syslogd & IP joblog
#Trace 254 # Log everything to syslogd
}
##-----------------------------
TTLSGroupAdvancedParms TLSv1.2zOS1.13
{
Envfile /etc/pagent.ttls.TLS1.2zOS1.13.env
}
TTLS ポリシーでは、規則が適用される際に指定する多様なフィルターを使用できます。
デバッグ・マネージャーは、デバッグ・エンジンからの着信接続用にポート 5335 で listen するサーバーです。 この情報は RDz_Debug_Manager 規則に取り込まれます。
SSL と TLS ではサーバー証明書を使用する必要があるため、ポリシー・マネージャーが dbgmgr.racf 鍵リング (デバッグ・マネージャー開始タスクのユーザー ID が所有するもの) にある証明書を使用することを指定します。TLS v1.2 サポートはデフォルトでは使用不可なので、このポリシーはそれを明示的に使用可能にしています。
言語環境プログラム (Language Environment (LE)) オプション TEST(,,,TCPIP&&ipaddress%8001:*) を使用してデバッグ・プローブを開始した場合、デバッグ・マネージャーを使用せずに、ポート 8001 で Developer for System z クライアントに直接接続することをお勧めします。これは、TCP/IP の観点から見た場合、ホスト・ベースのデバッグ・プローブが Developer for System z クライアントでサーバー (デバッグ UI) と接続されているクライアントであることを意味します。この情報は RDz_Debug_Probe-Client 規則に取り込まれます。
ホストが TCP/IP クライアントであるため、ポリシー・マネージャーは、デバッグ UI によって提供されるサーバー証明書を検証する方法を必要とします。暗号化されたデバッグ・セッションが必要になる場合があるため、すべてのユーザーに対して均一に指定された鍵リングを使用せずに、RACF の CERTAUTH 仮想鍵リング (*AUTH*/*) を使用します。この仮想鍵リングは、認証局 (CA) の公開証明書を保持し、トラステッド CA のいずれかによって署名されたサーバー証明書がデバッグ UI によって提供された場合に使用できます。
より複雑なポリシーの場合は、IBM Configuration Assistant for z/OS Communications Server を使用してください。 これは TCP/IP のポリシー・ベースのネットワーキング機能を構成するためのガイド付きインターフェースを提供する GUI ベースのツールです。 IBM z/OS Management Facility (z/OSMF) のタスクとして、およびスタンドアロン・ワークステーション・アプリケーションとして使用可能です。
TLS v1.2 サポートは z/OS 2.1 で使用可能になりましたが、デフォルトでは使用不可です。このポリシーには明示的に使用可能にするためのコマンド (TLSV1.2 On) がありますが、ターゲット・システムでは z/OS 1.13 が使用されているため、コメントにして取り除かれています。
#
# Add TLSv1.2 support to AT-TLS
# requires z/OS 1.13 with OA39422 and PM62905
#
GSK_RENEGOTIATION=ALL
GSK_PROTOCOL_TLSV1_2=ON
AT-TLS が正しく機能するために、セキュリティー・セットアップに必要なアップデートがいくつかあります。 このセクションでは、必要なセットアップを行うためのサンプル RACF コマンドが紹介されています。
# define started task user ID
# BPX.DAEMON permit is required for non-zero UID
ADDUSER PAGENT DFLTGRP(SYS1) OMVS(UID(0) SHARED HOME('/')) +
NAME('TCP/IP POLICY AGENT') NOPASSWORD
# define started task
RDEFINE STARTED PAGENT.* STDATA(USER(PAGENT) GROUP(SYS1)) +
DATA('TCP/IP POLICY AGENT')
# refresh to make the changes visible
SETROPTS RACLIST(STARTED) REFRESH
# restrict startup of policy agent
RDEFINE OPERCMDS MVS.SERVMGR.PAGENT UACC(NONE) +
DATA('restrict startup of policy agent')
PERMIT MVS.SERVMGR.PAGENT CLASS(OPERCMDS) ACCESS(CONTROL) ID(PAGENT)
# refresh to make the changes visible
SETROPTS RACLIST(OPERCMDS) REFRESH
# block stack access between stack and AT-TLS availability
# SETROPTS GENERIC(SERVAUTH)
# SETROPTS CLASSACT(SERVAUTH) RACLIST(FACILITY)
RDEFINE SERVAUTH EZB.INITSTACK.** UACC(NONE)
# Policy Agent
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(PAGENT)
# OMPROUTE daemon
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OMPROUTE)
# SNMP agent and subagents
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(OSNMPD)
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(IOBSNMP)
# NAME daemon
PERMIT EZB.INITSTACK.** CLASS(SERVAUTH) ACCESS(READ) ID(NAMED)
# refresh to make the changes visible
SETROPTS RACLIST(SERVAUTH) REFRESH
# restrict access to pasearch command
# RDEFINE SERVAUTH EZB.PAGENT.** UACC(NONE) +
# DATA('restrict access to pasearch command')
# PERMIT EZB.PAGENT.** CLASS(SERVAUTH) ACCESS(READ) ID(tcpadmin)
# refresh to make the changes visible
# SETROPTS RACLIST(SERVAUTH) REFRESH
# permit Debug Manager to access certificates
#RDEFINE FACILITY IRR.DIGTCERT.LIST UACC(NONE)
#RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ACCESS(READ) ID(stcdbm)
# refresh to make the changes visible
SETROPTS RACLIST(FACILITY) REFRESH
# create self-signed certificate
RACDCERT ID(stcdbm) GENCERT SUBJECTSDN(CN('RDz Debug Manager') +
OU('RTP labs') O('IBM') L('Raleigh') SP('NC') C('US')) +
NOTAFTER(DATE(2015-12-31)) KEYUSAGE(HANDSHAKE) WITHLABEL('dbgmgr')
# (optional) additional steps required to use a signed certificate
# 1. create a signing request for the self-signed certificate
RACDCERT ID(stcdbm) GENREQ (LABEL('dbgmgr')) DSN(dsn)
# 2. send the signing request to your CA of choice
# 3. check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# 4. mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# 5. add the signed certificate to the database;
# this will replace the self-signed one
RACDCERT ID(stcdbm) ADD(dsn) WTIHLABEL('dbgmgr') TRUST
# Do NOT delete the self-signed certificate before replacing it.
# If you do, you lose the private key that goes with the certificate,
# which makes the certificate useless.
# create key ring
RACDCERT ID(stcdbm) ADDRING(dbgmgr.racf)
# add certificate to key ring
RACDCERT ID(stcbm) CONNECT(LABEL('dbgmgr') +
RING(dbgmgr.racf) USAGE(PERSONAL) DEFAULT)
# additional step required to use a signed certificate
# 6. add CA certificate to key ring
RACDCERT ID(stcdbm) CONNECT(CERTAUTH LABEL('CA cert') +
RING(dbgmgr.racf))
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
# check if the CA credentials (also a certificate) are already known
RACDCERT CERTAUTH LIST
# mark the CA certificate as trusted
RACDCERT CERTAUTH ALTER(LABEL('CA cert')) TRUST
# or add the CA certificate to the database
RACDCERT CERTAUTH ADD(dsn) WITHLABEL('CA cert') TRUST
# refresh to make the changes visible
SETROPTS RACLIST(DIGTCERT) REFRESH
# verify started task setup
LISTGRP SYS1 OMVS
LISTUSER PAGENT OMVS
RLIST STARTED PAGENT.* ALL STDATA
# verify Policy Agent startup permission
RLIST OPERCMDS MVS.SERVMGR.PAGENT ALL
# verify initstack protection
RLIST SERVAUTH EZB.INITSTACK.** ALL
# verify pasearch protection
RLIST SERVAUTH EZB.PAGENT.** ALL
# verify certificate setup
RACDCERT CERTAUTH LIST(LABEL('CA cert'))
RACDCERT ID(stcdbm) LIST(LABEL('dbgmgr'))
RACDCERT ID(stcdbm) LISTRING(dbgmgr.racf)
TCPCONFIG TTLS
V TCPIP,,OBEY,TCPIP.TCPPARMS(OBEY)
EZZ4249I stackname INSTALLED TTLS POLICY HAS NO RULES
S PAGENT
EZD1586I PAGENT HAS INSTALLED ALL LOCAL POLICIES FOR stackname
P DBGMGR
S DBBMGR
このセクションは、TCP/IP のセットアップ時、または既存のセットアップの検査時や変更時に発生する可能性があるいくつかの一般的な問題に関して、ユーザーを支援するためのものです。
TCP/IP 構成の詳細については、「Communications Server IP 構成ガイド」(SC88-8926) および「Communications Server IP 構成解説書」(SC88-8927) を参照してください。
TSO コマンド・サービスに APPC を使用する場合、Developer for System z は TCP/IP が初期化時に正しいホスト名を持っているかどうかに依存します。つまり、各種の TCP/IP 構成ファイルやリゾルバー構成ファイルを正しくセットアップする必要があるということです。
TCP/IP 構成は、fekfivpt インストール検査プログラム (IVP) でテストできます。このコマンドは次のサンプルのような出力を返します ($ は z/OS UNIX プロンプトです)。
$ fekfivpt
Wed Jul 2 13:11:54 EDT 2008
uid=1(USERID) gid=0(GROUP)
using /etc/rdz/rsed.envvars
-------------------------------------------------------------
TCP/IP resolver configuration (z/OS UNIX search order):
-------------------------------------------------------------
Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964
res_init Resolver values:
Global Tcp/Ip Dataset = None
Default Tcp/Ip Dataset = None
Local Tcp/Ip Dataset = /etc/resolv.conf
Translation Table = Default
UserId/JobName = USERID
Caller API = LE C Sockets
Caller Mode = EBCDIC
(L) DataSetPrefix = TCPIP
(L) HostName = CDFMVS08
(L) TcpIpJobName = TCPIP
(L) DomainOrigin = RALEIGH.IBM.COM
(L) NameServer = 9.42.206.2
9.42.206.3
(L) NsPortAddr = 53 (L) ResolverTimeout = 10
(L) ResolveVia = UDP (L) ResolverUdpRetries = 1
(*) Options NDots = 1
(*) SockNoTestStor
(*) AlwaysWto = NO (L) MessageCase = MIXED
(*) LookUp = DNS LOCAL
res_init Succeeded
res_init Started: 2008/07/02 13:11:54.755363
res_init Ended: 2008/07/02 13:11:54.755371
************************************************************************
MVS TCP/IP NETSTAT CS V1R9 TCPIP Name: TCPIP 13:11:54
Tcpip started at 01:28:36 on 06/23/2008 with IPv6 enabled
-------------------------------------------------------------
host IP address:
-------------------------------------------------------------
hostName=CDFMVS08
hostAddr=9.42.112.75
bindAddr=9.42.112.75
localAddr=9.42.112.75
Success, addresses match
リゾルバーは、プログラムに代わってネーム・サーバーにアクセスするクライアントとして機能し、名前からアドレス、またはアドレスから名前への解決を行います。要求側プログラムの照会を解決するために、リゾルバーは使用可能なネーム・サーバーにアクセスするか、ローカル定義 (例えば、/etc/resolv.conf、/etc/hosts、/etc/ipnodes、HOSTS.SITEINFO、HOSTS.ADDRINFO、または ETC.IPNODES) を使用するか、あるいはその両方の組み合わせを使用します。
リゾルバー・アドレス・スペースが開始されると、リゾルバー JCL プロシージャー内の SETUP DD カードによって指し示されている、オプションのリゾルバー・セットアップ・データ・セットが読み取られます。セットアップ情報が提供されていない場合、リゾルバーは該当するネイティブの MVS または z/OS UNIX 検索順序を使用します。その際、GLOBALTCPIPDATA、DEFAULTTCPIPDATA、GLOBALIPNODES、DEFAULTIPNODES、または COMMONSEARCH 情報は使用されません。
TCP/IP 機能によって使用される構成ファイルの検索順序と、どのようなときにデフォルトの検索順序を環境変数、JCL、またはその他の変数によってオーバーライドできるかを理解しておくことが重要です。その知識があれば、ローカル・データ・セットと HFS ファイルの命名の標準に対応することができ、問題の診断時にも、使用されている構成データ・セットまたは HFS ファイルを知るのに役立ちます。
注意すべきもう 1 つの重要な点は、いずれかの構成ファイルに検索順序が適用された場合、最初に検出されたファイルで検索が終了するということです。したがって、絶対に検出されないファイル内に構成情報を入れた場合は、検索順序内に他のファイルが先に存在するか、またはアプリケーションが選択した検索順序内にそのファイルが含まれていないために、予期しない結果になることがあります。
構成ファイルを検索するときは、JCL プロシージャーの中で DD ステートメントを使用するか環境変数を設定することにより、大部分の構成ファイルが置かれている場所を TCP/IP に明示的に指示できます。それ以外の場合は、「Communications Server IP 構成ガイド」(SC88-8926) で説明されている検索順序に基づいて、TCP/IP に構成ファイルのロケーションを動的に判別させることができます。
TCP/IP スタックの構成コンポーネントは、TCP/IP スタックの初期化時に TCPIP.DATA を使用して、スタックの HOSTNAME を判別します。 その値を取得するために、z/OS UNIX 環境の検索順序が使用されます。
検索対象となる特定のファイルまたはテーブルは、リゾルバーの構成設定およびシステム上の所定のファイルの存在に応じて、MVS データ・セットか HFS ファイルになります。
基本リゾルバー構成ファイルには、TCPIP.DATA ステートメントが入っています。 このファイルは、リゾルバー・ディレクティブだけでなく、特にこのセクションで指定されている一部の構成ファイルへのアクセスを試みるときに使用されるデータ・セット接頭部 (DATASETPREFIX ステートメントの値) を判別するために、参照されます。
基本リゾルバー構成ファイルへのアクセスに使用される検索順序は、以下のとおりです。
定義されていれば、リゾルバーの GLOBALTCPIPDATA セットアップ・ステートメントの値が使用されます (リゾルバーについても参照)。 検索は、追加構成ファイルについて続行されます。検索は、次のファイルが検出されると終了します。
環境変数の値が使用されます。この検索は、ファイルが存在しないか他の場所で排他的に割り振られている場合、失敗します。
DD 名 SYSTCPD へ割り振られたデータ・セットが使用されます。z/OS UNIX 環境では、子プロセスは SYSTCPD DD にアクセスできません。なぜなら、SYSTCPD 割り振りは親プロセスから fork() または exec 関数呼び出しで継承されないからです。
userid は、現行セキュリティー環境 (アドレス・スペース、タスク、またはスレッド) へ関連付けられているユーザー ID です。
jobname は、バッチ・ジョブの場合は JOB JCL ステートメントで指定された名前で、開始プロシージャーの場合はプロシージャー名です。
定義されていれば、リゾルバーの DEFAULTTCPIPDATA セットアップ・ステートメントの値が使用されます (リゾルバーについても参照します)。
変換テーブル (EBCDIC から ASCII、および ASCII から EBCDIC) は、使用する変換データ・セットを判別するために参照されます。この構成ファイルへのアクセスに使用される検索順序は、以下のとおりです。検索順序は、最初に検出されたファイルの位置で終了します。
userid は、現行セキュリティー環境 (アドレス・スペースまたはタスク/スレッド) へ関連付けられているユーザー ID です。
jobname は、バッチ・ジョブの場合は JOB JCL ステートメントで指定された名前で、開始プロシージャーの場合はプロシージャー名です。
hlq は、基本リゾルバー構成ファイル内で指定された DATASETPREFIX ステートメントがある場合は、そのステートメントの値を表します。ない場合、hlq はデフォルトの TCPIP になります。
デフォルトでは、リゾルバーは構成済みのドメイン・ネーム・サーバーがあれば、最初にそれを解決要求に使用しようとします。解決要求を満足できない場合は、ローカル・ホスト・テーブルが使用されます。リゾルバーの動作は、TCPIP.DATA ステートメントによって制御されます。
TCPIP.DATA リゾルバー・ステートメントは、ドメイン・ネーム・サーバーを使用するかどうか、およびその使用方法を定義します。LOOKUP TCPIP.DATA ステートメントは、ドメイン・ネーム・サーバーおよびローカル・ホスト・テーブルの使用方法を制御するためにも使用されます。TCPIP.DATA ステートメントの詳細については、「Communications Server IP 構成解説書」(SC88-8927) を参照してください。
リゾルバーは、getnetbyname API 呼び出しに対して、無条件に IPv4 固有の検索順序を使用します。sitename 情報の IPv4 固有の検索順序は、以下のとおりです。検索は、最初に検出されたファイルの位置で終了します。
この環境変数の値は、TSO MAKESITE コマンドによって作成された HOSTS.SITEINFO 情報ファイルの名前です。
この環境変数の値は、TSO MAKESITE コマンドによって作成された HOSTS.ADDRINFO 情報ファイルの名前です。
userid は、現行セキュリティー環境 (アドレス・スペースまたはタスク/スレッド) へ関連付けられているユーザー ID です。
jobname は、バッチ・ジョブの場合は JOB JCL ステートメントで指定された名前で、開始プロシージャーの場合はプロシージャー名です。
hlq は、基本リゾルバー構成ファイル内で指定された DATASETPREFIX ステートメントがある場合は、そのステートメントの値を表します。ない場合、hlq はデフォルトの TCPIP になります。
前に述べたように、APPC を使用する場合、Developer for System z は TCP/IP が初期化時に正しいホスト名を持っているかどうかに依存します。つまり、各種の TCP/IP 構成ファイルやリゾルバー構成ファイルを正しくセットアップする必要があるということです。
以下の例では、TCP/IP およびリゾルバーのいくつかの構成タスクに焦点を当てます。これは TCP/IP またはリゾルバーの完全なセットアップについて述べたものではなく、ご使用のサイトにも適用できる可能性がある、いくつかの重要な局面だけを中心に説明したものであることに注意してください。
//TCPIP PROC PARMS=’CTRACE(CTIEZB00)’,PROF=TCPPROF,DATA=TCPDATA
//*
//* TCP/IP NETWORK
//*
//TCPIP EXEC PGM=EZBTCPIP,REGION=0M,TIME=1440,PARM=&PARMS
//PROFILE DD DISP=SHR,DSN=SYS1.TCPPARMS(&PROF)
//SYSTCPD DD DISP=SHR,DSN=SYS1.TCPPARMS(&DATA)
//SYSPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//ALGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//CFGPRINT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//SYSOUT DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//CEEDUMP DD SYSOUT=*,DCB=(RECFM=VB,LRECL=132,BLKSIZE=136)
//SYSERROR DD SYSOUT=*
; HOSTNAME specifies the TCP host name of this system. If not
; specified, the default HOSTNAME will be the node name specified
; in the IEFSSNxx PARMLIB member.
;
; HOSTNAME
;
; DOMAINORIGIN specifies the domain origin that will be appended
; to host names passed to the resolver. If a host name contains
; any dots, then the DOMAINORIGIN will not be appended to the
; host name.
;
DOMAINORIGIN RALEIGH.IBM.COM
;
; NSINTERADDR specifies the IP address of the name server.
; LOOPBACK (14.0.0.0) specifies your local name server. If a name
; server will not be used, then do not code an NSINTERADDR statement.
; (Comment out the NSINTERADDR line below). This will cause all names
; to be resolved via site table lookup.
;
; NSINTERADDR 14.0.0.0
;
; TRACE RESOLVER will cause a complete trace of all queries to and
; responses from the name server or site tables to be written to
; the user’s console. This command is for debugging purposes only.
;
; TRACE RESOLVER
//RESOLVER PROC PARMS=’CTRACE(CTIRES00)’
//*
//* IP NAME RESOLVER – START WITH SUB=MSTR
//*
//RESOLVER EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS
//*SETUP DD DISP=SHR,DSN=USER.PROCLIB(RESSETUP),FREE=CLOSE
TCPIPJOBNAME TCPIP
DomainOrigin RALEIGH.IBM.COM
HostName CDFMVS08
z/OS UNIX 環境で使用される検索順序で述べたように、基本構成ファイルには TCPIP.DATA ステートメントが入っています。システム名が CDFMVS08 の場合 (TCPDATA はシステム名がホスト名として使用されることを述べていました)、/etc/resolv.conf が SYS1.TCPPARMS(TCPDATA) と同期していることが分かります。DNS 定義は存在しないため、サイト・テーブル・ルックアップが使用されます。
# Resolver /etc/hosts file cdfmvs08
9.42.112.75 cdfmvs08 # CDFMVS08 Host
9.42.112.75 cdfmvs08.raleigh.ibm.com # CDFMVS08 Host
127.0.0.1 localhost
このファイルの最低限の内容は、現行システムに関する情報です。上記の例では、z/OS システムの IP アドレスの有効な名前として、cdfmvs08 と cdfmvs08.raleigh.ibm.com の両方を定義しています。
ドメイン・ネーム・サーバー (DNS) を使用した場合は、DNS が /etc/hosts 情報を保持し、/etc/resolv.conf および SYS1.TCPPARMS(TCPDATA) には、その DNS をシステムに対して識別するステートメントが含まれることになります。
混乱を避けるために、TCP/IP 構成ファイルとリゾルバー構成ファイルを互いに同期させておく必要があります。
ファイル・タイプの説明 | 影響する API | 候補ファイル |
---|---|---|
基本リゾルバー構成ファイル | すべての API |
|
変換テーブル | すべての API |
|
ローカル・ホスト・テーブル | endhostent |
IPv4
IPv6
|
clientip(0.0.0.0) <> callerip(<host IP address>)
Resolver Trace Initialization Complete -> 2008/07/02 13:11:54.745964
res_init Resolver values:
Global Tcp/Ip Dataset = None
Default Tcp/Ip Dataset = None
Local Tcp/Ip Dataset = /etc/resolv.conf
Translation Table = Default
UserId/JobName = USERID
Caller API = LE C Sockets
Caller Mode = EBCDIC
「Local Tcp/Ip Dataset」が示すファイル (データ・セット) 内の定義が正しいことを確認してください。
このフィールドは、IP リゾルバー・ファイルに (z/OS UNIX 検索順序を使用して) デフォルト名を使用していない場合にはブランクになります。その場合は、次のステートメントを rsed.envvars に追加します。ここで、<resolver file> または <resolver data> は IP リゾルバー・ファイルの名前を表しています。
RESOLVER_CONFIG=<resolver file>
or
RESOLVER_CONFIG=’<resolver data set>’
本書では、以下の資料を参照しています。
資料名 | 資料番号 | 参照 | 参照 Web サイト |
---|---|---|---|
IBM Rational Developer for System z Program Directory | GI88-4172 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Program Directory for IBM Rational Developer for System z Host Utilities | GI88-4326 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z前提条件 | SC88-4704 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z ホスト構成クイック・スタート・ガイド | GI88-4171 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z ホスト構成ガイド | SC88-5663 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System zホスト構成リファレンス | SA88-4226 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z ホスト構成ユーティリティー・ガイド | SA88-4197 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z メッセージとコード・ガイド | SA88-4565 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z共通ホスト構成と保守に関する問題への回答 | SA88-5113 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z Common Access Repository Manager Developer's Guide | SC23-7660 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
IBM Rational Developer for System z前提条件 | SC88-4704 | Developer for System z | http://www.ibm.com/software/rational/products/developer/systemz/library/index.html |
IBM Rational Developer for System z ホスト構成クイック・スタート・ガイド | GI88-4171 | Developer for System z | http://www.ibm.com/software/rational/products/developer/systemz/library/index.html |
SCLM Developer Toolkit 管理者ガイド | SC88-5664 | Developer for System z | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Using APPC to provide TSO command services | SC14-7291 | ホワイト・ペーパー | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Using ISPF Client Gateway to provide CARMA services | SC14-7292 | ホワイト・ペーパー | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Communications Server IP 構成ガイド | SC88-8926 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP 構成解説書 | SC88-8927 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP Diagnosis Guide | GC31-8782 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server IP システム管理者のコマンド | SC88-9073 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA ネットワーク・インプリメンテーション・ガイド | SC88-8928 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Communications Server SNA オペレーション | SC88-8930 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Cryptographic Services System SSL (Secure Sockets Layer) プログラミング | SD88-6252 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS Macro Instructions for Data Sets | SC26-7408 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
DFSMS データ・セットの使用法 | SC88-9114 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
言語環境プログラム カスタマイズ | SA88-8552 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
言語環境プログラム デバッグ・ガイド | GA88-8548 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS 診断: ツールと保守援助プログラム | GA88-8561 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS 初期設定およびチューニング ガイド | SA88-8563 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS 初期設定およびチューニング解説書 | SA88-8564 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS JCL 解説書 | SA88-8569 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS 計画 APPC/MVS 管理 | SA88-8571 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS 計画: ワークロード管理 | SA88-8574 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
MVS システム・コマンド | SA88-8593 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF コマンド言語解説書 | SA88-8617 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Security Server RACF セキュリティー管理者のガイド | SA88-8613 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E カスタマイズ | SA88-8629 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
TSO/E REXX 解説書 | SA88-8635 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services コマンド解説書 | SA88-8641 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX System Services 計画 | GA88-8639 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
UNIX システム・サービス ユーザーズ・ガイド | SA88-8640 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
REXX および z/OS UNIX システム・サービスの使い方 | SA88-8644 | z/OS 1.13 | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
Java Diagnostic Guide | SC34-6650 | Java 6.0 | http://www.ibm.com/developerworks/java/jdk/diagnosis/ |
Java SDK and Runtime Environment User Guide | / | Java 6.0 | http://www-03.ibm.com/servers/eserver/zseries/software/java/ |
Resource Definition Guide | SC34-6430 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-6815 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
Resource Definition Guide | SC34-7000 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
Resource Definition Guide | SC34-7181 | CICSTS 4.2 | https://publib.boulder.ibm.com/infocenter/cicsts/ v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/ library/library_html.html |
RACF Security Guide | SC34-6454 | CICSTS 3.1 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-6835 | CICSTS 3.2 | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
RACF Security Guide | SC34-7003 | CICSTS 4.1 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
RACF Security Guide | SC34-7179 | CICSTS 4.2 | https://publib.boulder.ibm.com/infocenter/cicsts/v4r2/index.jsp?topic=/com.ibm.cics.ts.home.doc/library/library_html.html |
言語解説書 | SC88-9117 | Enterprise COBOL for z/OS | http://www-03.ibm.com/systems/z/os/zos/bkserv/zapplsbooks.html |
説明 | 参照 Web サイト |
---|---|
Developer for System z IBM Knowledge Center | http://www-01.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm.etools.getstart.wsentdev.doc/kc_version_welcome_rdz.html |
Developer for System z ライブラリー | http://www-01.ibm.com/support/docview.wss?uid=swg27038517 |
Developer for System z ホーム・ページ | http://www-03.ibm.com/software/products/en/developerforsystemz/ |
Developer for System z 推奨サービス | http://www-01.ibm.com/support/docview.wss?rs=2294&context=SS2QJ2&uid=swg27006335 |
Developer for System z 機能拡張要求 | https://www.ibm.com/developerworks/support/rational/rfe/ |
z/OS インターネット・ライブラリー | http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/ |
CICSTS IBM Knowledge Center | https://publib.boulder.ibm.com/infocenter/cicsts/v4r1/index.jsp |
IBM Tivoli Directory Server | http://www-01.ibm.com/software/tivoli/products/directory-server/ |
Problem Determination Tools Plug-ins | http://www-01.ibm.com/software/awdtools/deployment/pdtplugins/ |
Java セキュリティー情報 | http://www.ibm.com/developerworks/java/jdk/security/ |
Apache Ant のダウンロード | http://ant.apache.org/ |
Java keytool の資料 | http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html |
CA サポート・ホーム・ページ | https://support.ca.com/ |
資料名 | 資料番号 | 参照 | 参照 Web サイト |
---|---|---|---|
ABCs of z/OS System Programming Volume 9 (z/OS UNIX) | SG24-6989 | Redbook | http://www.redbooks.ibm.com/ |
System Programmer’s Guide to: Workload Manager | SG24-6472 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 1: Base Functions, Connectivity, and Routing | SG24-7532 | Redbook | http://www.redbooks.ibm.com/ |
TCPIP Implementation Volume 3: High Availability, Scalability, and Performance | SG24-7534 | Redbook | http://www.redbooks.ibm.com/ |
TCP/IP Implementation Volume 4: Security and Policy-Based Networking | SG24-7535 | Redbook | http://www.redbooks.ibm.com/ |
Tivoli Directory Server for z/OS | SG24-7849 | Redbook | http://www.redbooks.ibm.com/ |
© Copyright IBM Corporation 1992, 2013.
本書は米国 IBM が提供する製品およびサービスについて作成したものです。
本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。 日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。 本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、または サービスのみが使用可能であることを意味するものではありません。 これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の 製品、プログラム、またはサービスを使用することができます。 ただし、IBM 以外の製品とプログラムの操作またはサービスの 評価および検証は、お客様の責任で行っていただきます。
IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について 実施権を許諾することを意味するものではありません。 実施権についてのお問い合わせは、書面にて下記宛先にお送りください。
〒103-8510
東京都中央区日本橋箱崎町19番21号
日本アイ・ビー・エム株式会社
法務・知的財産
知的財産権ライセンス渉外
以下の保証は、国または地域の法律に沿わない場合は、適用されません。 IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、 商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含む すべての明示もしくは黙示の保証責任を負わないものとします。 国または地域によっては、法律の強行規定により、保証責任の制限が 禁じられる場合、強行規定の制限を受けるものとします。
この情報には、技術的に不適切な記述や誤植を含む場合があります。 本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に 記載されている製品またはプログラムに対して、改良または変更を行うことがあります。
本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部では ありません。それらの Web サイトは、お客様の責任でご使用ください。
IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、 自ら適切と信ずる方法で、使用もしくは配布することができるものとします。
本プログラムのライセンス保持者で、(i) 独自に作成したプログラムと その他のプログラム (本プログラムを含む) との間での情報交換、 および (ii) 交換された情報の相互利用を可能にすることを目的として、 本プログラムに関する情報を必要とする方は、下記に連絡してください。
Intellectual Property Dept. for Rational Software
IBM Corporation
Silicon Valley Lab
555 Bailey Avnue
San Jose, CA 95141-1003
U.S.A.
本プログラムに関する上記の情報は、適切な使用条件の下で使用すること ができますが、有償の場合もあります。
本書で説明されているライセンス・プログラムまたはその他のライセンス資 料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、 またはそれと同等の条項に基づいて、IBM より提供されます。
この文書に含まれるいかなるパフォーマンス・データも、管理環境下で 決定されたものです。 そのため、他の操作環境で得られた結果は、異なる可能性があります。 一部の測定が、開発レベルのシステムで行われた可能性がありますが、 その測定値が、一般に利用可能なシステムのものと同じである保証はありません。 さらに、一部の測定値が、推定値である可能性があります。 実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。
IBM 以外の製品に関する情報は、その製品の供給者、出版物、 もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、 他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。
IBM の将来の方向または意向に関する記述については、 予告なしに変更または撤回される場合があり、単に目標を示しているものです。
本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、 あるいは製品などの名前が含まれている場合があります。 これらの名称はすべて架空のものであり、 名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。
本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。 お客様は、サンプル・プログラムが書かれているオペレーティング・ プラットフォームのアプリケーション・プログラミング・インターフェースに 準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、 いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、 配布することができます。 このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。 従って IBM は、これらの サンプル・プログラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。 サンプル・プログラムは、現存するままの状態で提供され、いかなる保証条件も適用されません。IBM は、お客様の当該サンプル・プログラムの使用から生ずるいかなる損害に対しても一切の責任を負いません。
それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生的創作物にも、次の ように、著作権表示を入れていただく必要があります。
© (お客様の会社名) (西暦年). このコードの一部は、IBM Corp. のサンプル・プログラムから取られています。© Copyright IBM Corp. 1992, 2013.
この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は 表示されない場合があります。
サービス・ソリューションとしてのソフトウェアも含めた IBM ソフトウェア製品 (「ソフトウェア・オファリング」) では、製品の使用に関する情報の収集、エンド・ユーザーの使用感の向上、エンド・ユーザーとの対話またはその他の目的のために、Cookie はじめさまざまなテクノロジーを使用することがあります。 多くの場合、ソフトウェア・オファリングにより個人情報が収集されることはありません。 IBM の「ソフトウェア・オファリング」の一部には、個人情報を収集できる機能を持つものがあります。 ご使用の「ソフトウェア・オファリング」が、これらのCookie およびそれに類するテクノロジーを通じてお客様による個人情報の収集を可能にする場合、以下の具体的事項を確認ください。
この「ソフトウェア・オファリング」は、Cookie もしくはその他のテクノロジーを使用して個人情報を収集することはありません。
IBM、IBM ロゴおよび ibm.com は、世界の多くの国で登録された International Business Machines Corp. の商標です。 他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtml をご覧ください。
適用範囲
IBM Web サイトのご利用条件に加えて、以下のご使用条件があります。
個人使用
これらの資料は、すべての著作権表示その他の所有権表示をしていただくことを条件に、非商業的な個人による使用目的に限り複製することができます。 ただし、IBM の明示的な承諾をえずに、これらの資料またはその一部について、 二次的著作物を作成したり、配布 (頒布、送信を含む) または表示 (上映を含む) することは できません。
商業的使用
これらの資料は、すべての著作権表示その他の所有権表示をしていただくことを条件に、お客様の企業内に限り、複製、配布、および表示することができます。 ただし、IBM の明示的な承諾をえずにこれらの資料の二次的著作物を作成したり、 お客様の企業外で資料またはその一部を複製、配布、または表示することはできません。
権利
ここで明示的に許可されているもの以外に、資料や資料内に含まれる情報、データ、ソフトウェア、 またはその他の知的所有権に対するいかなる許可、ライセンス、または権利を明示的にも黙示的 にも付与するものではありません。
資料の使用が IBM の利益を損なうと判断された場合や、上記の条件が適切に守られていないと 判断された場合、IBM はいつでも自らの判断により、ここで与えた許可を撤回できるものと させていただきます。
お客様がこの情報をダウンロード、輸出、または再輸出する際には、米国のすべての輸出入 関連法規を含む、すべての関連法規を遵守するものとします。
IBM は、これらの資料の内容 についていかなる保証もしません。 これらの資料は、特定物として現存するままの状態で 提供され、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべて の明示もしくは黙示の保証責任なしで提供されます。
本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれているオペレーティング・ プラットフォームのアプリケーション・プログラミング・インターフェースに 準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、 いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、 配布することができます。 このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。 従って IBM は、これらの サンプル・プログラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。 サンプル・プログラムは、現存するままの状態で提供され、いかなる保証条件も適用されません。IBM は、お客様の当該サンプル・プログラムの使用から生ずるいかなる損害に対しても一切の責任を負いません。
IBM、IBM ロゴおよび ibm.com は、世界の多くの国で登録された International Business Machines Corp. の商標です。 他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、www.ibm.com/legal/copytrade.shtml をご覧ください。
Adobe および PostScript は、Adobe Systems Incorporated の米国およびその他の国における登録商標または商標です。
Cell Broadband Engine - Sony Computer Entertainment Inc.
Intel、Intel Centrino、Intel SpeedStep、Intel Xeon、Celeron、Itanium、および Pentium は、Intel Corporation または子会社の米国およびその他の国における商標または登録商標です。
IT Infrastructure Library は英国 Office of Government Commerce の一部である the Central Computer and Telecommunications Agency の登録商標です。
ITIL は英国 The Minister for the Cabinet Office の登録商標および共同体登録商標であって、米国特許商標庁にて登録されています。
Linear Tape-Open、LTO、および Ultrium は、HP、IBM Corp. および Quantum の米国およびその他の国における商標です。
Linux は、Linus Torvalds の米国およびその他の国における登録商標です。
Microsoft、Windows および Windows ロゴは、Microsoft Corporation の米国およびその他の国における商標です。
Java およびすべての Java 関連の商標およびロゴは Oracle やその関連会社の米国およびその他の国における商標または登録商標です。
UNIX は The Open Group の米国およびその他の国における登録商標です。