DDM のパフォーマンスに関する考慮事項

このトピックには、DDM を使用するときにパフォーマンスを向上させるための 参考情報と、ある種の機能を実行するのに DDM 以外のものを使用する場合に関する情報が記述されています。

  • DDM ファイルを CPYF コマンドに指定するとき、次の項目がすべて満たされれば、最良のパフォーマンスを得ることができます。
    • 取り出し元ファイルは論理ファイルまたは物理ファイルであり、受け入れ先 ファイルが物理ファイルである場合。
    • FMTOPT は、*NONE または *NOCHK であるか、または何も指定されていない場合。
    • INCHAR、INCREL、ERRLVL、RCDDMT(*ALL)、PRINT(*COPIED)、PRINT(*EXCLD)、SRCSEQ、 TOKEY、SRCOPT、または FROMKEY パラメーターは指定されていない場合。
    • 取り出し元ファイルが、*NONE または *START 以外の POS キーワードで 一時変更されていない場合。
    • 受け入れ先ファイルが、INHWRT(*YES) で一時変更されていない場合。
  • Open Query File (OPNQRYF) コマンドは、DDM 体系に対する System/38 拡張機能を使用します。 System/38 DDM 体系拡張機能は、DDM システム処理時間を最小化します。 次の場合には、この拡張機能を使用することはできません。
    • クライアント・システムは、System/38プラットフォームでもIBM iオペレーティング・システムでもありません
    • サーバー・システムが System/38 でも IBM i オペレーティング・システムでもない
  • IBM i コマンド OPNQRYF OPTIMIZE (*YES) などの照会機能を使用すると、システム間で転送されるデータの量を大幅に減らすことができます。 ただし、ユーザー作成アプリケーションの場合、システム間で交換されるデータ量は、 IBM iを実行していないシステムと DDM を使用して通信する場合よりも多くなります。 追加データにより、 IBM i 拡張 DDM 機能が提供され、クライアント・システムの DDM 処理オーバーヘッドも削減されます。 たとえば、通常の読み取り、書き込み、更新、追加、および削除の各操作を行う場合には、次の事項を考慮してください。
    • 標準 DDM 体系の DDM オーバーヘッド・データには、ファイル 識別コード、命令コード、および簡単な操作結果情報などの情報が含まれます。 ユーザー・プログラムのキー別読み取り操作は、キー・データの長さ以外に、約 40 文字の DDM 情報を使用します。 リモート・システムから返される データは、約 32 文字の DDM 情報と、データ・ファイル・レコードの長さ を使用します。
    • System/38 DDM アーキテクチャー拡張機能により、レコード・フォーマット識別や入出力フィードバック域情報の大部分など、追加のデータ・オーバーヘッドが生じます。 ユーザー・プログラムのキー別読み取り操作は、キー・データの長さ以外に、約 60 文字の DDM 情報を使用します。 リモート・システムから返される データは、約 80 文字の DDM 情報と、データ・ファイル・レコードの長さ を使用します。 通常、データ・ストリーム内で追加される長さは、顕著な長さではありません。 ただし、回線活動が多くなるにしたがって、このような拡張データ・ストリームを使用した方が、標準 DDM データ・ストリームを使用するよりも、回線使用率のピークには、早めに達してしまいます。
  • ターゲット DDM ジョブ優先順位は、関連サブシステム記述経路指定項目で指定 するジョブ・クラスで制御します。 次の経路指定項目は通常、すべてのターゲット (プログラム開始要求) ジョブで使用されるものです。
    ADDRTGE ... PGM(*RTGDTA) ... CMPVAL(PGMEVOKE 29)

    IBM i オペレーティング・システムに付属しているサブシステム QBASE および QCMN には、この経路指定項目があります。

    ターゲット DDM ジョブをサブシステム内で実行するときに、同じサブシステム内で他の APPC ターゲット・ジョブを 実行する場合とは異なる優先順位で実行する場合は、適切な順序番号を指定して次の経路指定項目を挿入します。
    ADDRTGE SBSD(xxx) SEQNBR(nnn) CMPVAL(QCNTEDDM 37)
        PGM(*RTGDTA) CLS(uuu)

    クラス uuu は、ターゲット・ジョブ優先順位を決めるのに使用します。

  • リモート・ファイル内のレコードを表示するときは、できる限り表示装置パススルーを使用してください。 それ以外の場合は、 Display Physical File Member (DSPPFM) コマンドで直接レコード位置決めを使用する必要があります。
  • DDM ユーザー出口セキュリティー・プログラムが CL プログラムであり、サーバー・システム・オペレーターの応答を必要とする IBM i 例外および照会メッセージを作成する場合、ユーザー出口プログラムとクライアント・システム・ジョブの両方が応答を待機する必要があります。 APPC リモート・ロケーション情報の Add Communications Entry (ADDCMNE) コマンドで指定された TDDM ジョブの記述に INQMSGRPY (*SYSRPYL) を指定して、デフォルトのシステム応答リストを使用することを検討してください。
  • Allocate Object (ALCOBJ) や Receive Message (RCVMSG)などのコマンドで使用される WAIT および WAITFILE パラメーターは、クライアント・システム・プログラムには影響しません。 これらのパラメーターは、ローカル・ファイルへアクセスする場合と同じように機能します。 クライアント・システムで実行されるコマンドに指定された待ち時間の値は、クライアント・システムでは有効になりません。これらの値は、 IBM i オペレーティング・システムまたは System/38 プラットフォームの場合にのみ、サーバー・システムに影響します。
    注:
    1. IBM i-システム間通信機能 (ICF) ファイルの作成または変更コマンドの WAITFILE パラメーターは、獲得操作または開始機能の実行時に、APPC サポートがセッション・リソースが使用可能になるのを待機する時間を決定します。 隣接システムとの接続が交換回線接続を経由している場合には、WAITFILE 値を セッション用には使用しません。 その例には、SDLC 交換回線、X.25 SVC 回線、イーサネット回線、またはトークンリング接続 などがあります。 交換回線接続を用いると、獲得操作や開始機能がタイムアウト になることはありません。
    2. APPN セッションは、リモート・システムまで達するのに複数のシステムと 回線を経由することがあるため、このような場合には、WAITFILE タイマーを調整して、時間に余裕を持たせてください。 アプリケーション・プログラムが、APPN 機能を使用するよう構成されたネットワーク内 で稼働するときには、WAITFILE パラメーターに *IMMED を指定してはなりません。 このパラメーターに指定する値は、ネットワークのサイズとタイプによって異なります。

  • すべての LU セッション・タイプ 6.2 データ交換の場合と同様、特定の SNA パラメーターは、パフォーマンスに影響を与えます。 このようなパラメーターには、パス情報単位サイズ (MAXFRAME)、要求/応答単位サイズ (MAXLENRU)、SNA ペーシング (INPACING、OUTPACING)、および X.25 の場合のパケット・サイズとウィンドウ・サイズがあります。 一般的に、使用する値が大きければ大きいほど、より良い パフォーマンスが実現されます。

  • SNA パス情報単位サイズ

    パス情報単位 (PIU) とは、2 つのシステム間でやりとりされる実際の データ伝送ブロックのサイズのことです。 APPC 制御装置記述作成 (CRTCTLAPPC) コマンド や SNA ホスト制御装置記述作成 (CRTCTLHOST) コマンド上の MAXFRAME パラメーターで、ローカル・システムが使用するパス情報単位サイズ を指定します。 セッション確立時に、両方のシステムがどのサイズを使用するかを 決めますが、サイズは常に小さい方の値になります。 リモート・システムごとに、PIU サイズに関する考慮事項が異なることもあります。

  • SNA 応答/要求単位サイズ

    応答/要求単位 (RU) サイズ (CRTMODD MAXLENRU) は、実際に伝送するパス情報単位にデータが収まるよう、システム・バッファーに入れる量を制御します。 APPC では、送信 RU および受信 RU の長さは、セッション確立時に折衝されます。 この場合も、折衝の結果は、使用されている最小値になります。 リモート・システムによっては、RU サイズに関する考慮事項が異なることもあります。

  • SNA ペーシング値

    ペーシング値は、バッファー記憶域が次の伝送を処理できるようになったことを示す応答が必要になるまでに、何回、要求/応答単位 (RU) を受信または送信できるかを決めます。 セッション確立時に、両方のシステムがどのサイズを使用するかを 決めますが、サイズは常に小さい方の値になります。

    同じ通信回線上でバッチ処理と対話式処理の両方が同時に行われる場合は、 IBM i ジョブ優先順位を使用して、バッチ処理よりも対話式処理を優先することができます。 さらに、バッチ・アプリケーションのペーシングを小さくする 一方、対話式アプリケーションの方の値を大きくして、対話式アプリケーションに回線活動の 優先レベルを与えなければならないことがあります。

    IBM i オペレーティング・システムでは、異なるアプリケーションに対して異なる MODES (Create Mode Description [CRTMODD] コマンド) を作成することにより、異なるペーシング値を指定することができます。 リモート・システム によっては、SNA ペーシング値に関する考慮事項が異なることもあります。

  • X.25 パケット

    MAXFRAME 値より小さい X.25 パケットの場合、非 X.25 データ・リンク を通してデータ伝送時間が長くなります。 一般的に X.25 では、MAXFRAME と実際に伝送されるデータ量が大きくなればなるほど、この 時間差が大きくなります。 DDM では、通常のファイル・レコード・データに DDM 制御情報が追加されるため、ローカル・ファイル処理とリモート・ファイル処理との 差や、非 X.25 データ・リンクと X.25 データ・リンクとの差に対する パケット・サイズの影響がさらに大きくなります。

    多くの非ブロック化 DDM 操作の場合、データを伝送するのに必要な パケット数が非常に多くなるため、X.25 アダプター内のパケット処理 オーバーヘッドでパフォーマンスに多大な影響が出ます。 ネットワーク と通信プロダクトでサポートされている最大 X.25 パケット・ウィンドウ・ サイズを使用して、パフォーマンスを最大限に保ちます。

    リモート・ファイルにアクセスするのに X.25 を使用しなければならないとき、80 文字より小さいレコードなどの小さい非ブロック化レコードを多数連続して 伝送すると、ユーザー・データの伝送の場合と比較して、X.25 パケット文字を X.25 アダプターが 処理するのに要する時間が釣り合わなくなることがあります。

    一般的に、X.25 パケットの処理でのオーバーヘッドのため、同じ伝送速度 を使用し、データ転送が単一方向に行われたとしても、従来の回線を用いた ときよりもスループットが低下することになります。 データを双方向に同時に転送すれば、X.25 全二重サポートの利点を生かせます。 System/38では、パケット処理のオーバーヘッドは統合 X.25 アダプター内で行われるため、全体の処理効果は最小限に抑えられます。

一般的に、DDM を使用したリモート・ファイルの処理は、ファイル・コピー (CPYF) コマンドで利用できるような アプリケーション・プログラムやユーティリティー機能から見ると、透過処理です。 ただし、通信回線を使用してリモート・ファイルへアクセスするほうが、時間 が長くかかります。 ローカル・ファイル処理とリモート・ファイル処理における パフォーマンス上の差は、パフォーマンスの測定単位あたりのリモート・ファイル へのアクセス回数、データ・レコード長、および伝送速度に比例します。

ローカル・ファイル処理とリモート・ファイル処理での別の相違点として、ローカル・ファイルに対して入力操作や出力操作を行っても、システムは、ディスク からデータ・ブロックを転送してからそのディスクにデータ・ブロックを 書き込むので、ただちに物理ディスク操作にはつながらないという点が あります。 このため、場合によっては、ユーザー・プログラムが主記憶域内の データにアクセスした時点とは別の時点で、物理入出力操作が行われることが あります。 したがって、ローカル・ファイルとリモート・ファイルでのパフォーマンスの差を最小限 にとどめるには、アプリケーション設計をよく了解し、また、DDM を使用してどのリモート・ファイルに アクセスするかを決める際に、ファイルへのアクセス量とアクセス・タイプに 対して配慮することが肝要です。

1 回のリモート・アクセスにおいて、余分な時間がかかる原因は以下のとおりです。

  • ローカル・システム・ファイル・インターフェースを、DDM 体系 インターフェースへ変換するための余分なシステム処理。
  • 通信回線を通して伝送されるデータ量。
  • リモート・システムでのファイル操作の処理量。
  • 通信回線の速度。

通信回線時間がこの余分な時間の大半を占めますが、実際にかかる時間は、回線速度と、DDM 機能の実行時における回線使用量によって異なります。

DDM 以外の場合と同様、ローカル・システムやリモート・システムのジョブ優先順位が、パフォーマンスに対して最も大きい影響を与えます。 IBM i オペレーティング・システムでは、使用されているクラスの PRIORITY および TIME SLICE 値がジョブ優先順位を制御します。 SDDM はソース・ジョブの下で稼働する一方、TDDM は、サーバー・システムのサブシステムの APPC 経路指定項目に割り当てられたクラスの下で稼働します。 複数のファイルにアクセスするアプリケーションでは、最もアクセスされる回数の多いファイルを、実行しているプログラムと同じシステムに入れ、それよりアクセス回数の少ないファイルはリモート・システムに入れておくのが最善です。 ファイルとアプリケーション・プログラムの 配置に関する主要な考慮事項を次に示します。

  • ファイル保守の第一責任担当システムを明確にしておかなければなりません。 どの複数システム・アプリケーションでも、1 つのシステムにのみファイル 保守を担当させれば、最高のパフォーマンスが得られます。 アプリケーション・プログラムが排他的 (非共用) 処理を介してファイルを保守する場合、そのアプリケーション・プログラムがそのファイルとともにシステムにあるときに、最高のパフォーマンスを実現できます。
    場合によっては、ファイルをローカル・システムへ送り返すには、次のものが必要になることがあります。
    • APPC プログラム。
    • リモート DDM ファイルを使用するプログラム。
    • DDM を使用したファイル・コピー (CPYF) コマンド。
    • オブジェクト配布機能の SNDNETF 命令と RCVNETF 命令。 対話式アプリ ケーションにおいて、転送する表示データ量が DDM を使用して送られる データベース・ファイル量よりはるかに少ない場合には、表示装置パススルーを使用できるかどうかも検討してください。
  • ファイルを配置するとき、最高のパフォーマンスを得るためにアプリケーション 処理をリモート・システムに移動しなければならない場合は、リモート・コマンド投入 (SBMRMTCMD) コマンドの使用を検討する必要があります。 このコマンドの使用は、バッチ処理入力ストリームにおいて最も効果があります。バッチ処理入力ストリームでは、いずれのプログラムも前のプログラムが完了 するまで待機させられます。 SBMRMTCMD コマンドの使用は、ソース・システムおよびサーバー・システムが IBM i または Systems/38 製品の場合にのみ有効です。 たとえば、プログラム A がローカル・ファイルへアクセスすると仮定します。 プログラム A は、ローカル・システムで稼働します。 プログラム B は、リモート・ファイルへアクセスします。 SBMRMTCMD コマンドを 用いれば、リモート・システムでプログラム B を実行することができます。
  • ファイル保守をシステム間で共用している場合、ファイルの更新、追加、および削除の操作の比率の最も大きいシステムにそのファイルを 置けば最高のパフォーマンスを得ることができます。

    場合によっては、ソース・システムとターゲット・システムの APPC プログラムをペア化 すれば、DDM を使用した場合のパフォーマンスが向上します。 たとえば、リモート・ システムにある 10 個のレコードを取り出すと仮定します。 DDM を使用している場合で、レコード・ブロック化を使用できないとき (例：ユーザー・プログラム・ランダム入力命令、変更用の順次入力、または OVRDBF SEQONLY[*NO] コマンドの使用) に、10 回のデータ伝送が行われ、10 回受信されて、合計 20 回の伝送が行われたと仮定します。 ユーザー作成 APPC プログラムは、その データ・ストリーム内に情報を追加すれば、データ要求とその データの受け取りを、20 回ではなく 2 回のデータ伝送で行えるように できます。その 2 回の内訳は、1 回が顧客 00010 のすべての レコードを求める要求、もう 1 回は顧客 00010 の 10 個のレコード の入った応答になります。

バッチ・ファイル処理と対話式ファイル処理の 2 つのサンプル・アプリケーション処理方法について検討します。