オンライン端末のRUサイズを最適化する

By 神居 - Posted: 2008/10/28 Last updated: 2010/07/17 - Leave a Comment

MVSパフォーマンスチューニング入門に関連して追加トピックをひとつ。

オンライン端末のRUサイズ

意外と忘れられているが、オンライン端末のレスポンスに影響を与える要素の1つにRUサイズがある。MAXRUとも呼ばれ、端末->ホスト、ホスト->端末方向それぞれに設定されます。TSO、CICSやIMSなどのDCMS(TPモニター)は端末にデータを送る際に画面データをRUサイズに基づいて自ら分割して送信するか、VTAMに分割を依頼します。MSPとVOS3ではVTAMに分割処理を代行する機能(LMPEO)がないのでAIMやDCCMなどは自ら行っています。1つの画面データが分割されるとき、分割された1つ1つのデータをチェインデータと呼びます。チェインにはFIC(First In Chain)、MIC(Middle…)、LIC(Last…)、OIC(Only…)の4種類があり、分割されない時はOIC、2つ以上に分割される時はFIC,MIC,LICを組み合わせて送信データを組み立てます。

画面データの大きさは画面に表示される内容によって異なりますが、一般的な80桁24行であれば画面一杯に表示したとして文字だけで最大1920バイト、これにさまざまな制御コードが付加されます。フィールドが多い画面や、色や罫線などを多用した画面は制御コードだけでも2000バイト近くになったりもします。経験則からアプリケーション業務の画面データは2KB?4KBぐらいの大きさで構成されるものが多いです。RUサイズが小さいとホストから端末に送られる画面データ(アウトバウンド)は常に分割されてしまいます。1度で送ることができればそれだけパフォーマンスも向上します。現在では通信ネットワーク自体も早くなったり、エミュレーターによってはすべてのチェインデータを受信してから画面を組み立てたりするものあるので見た目ではわかりにくいですが、一昔前であれば体感できるほどの違いがありました。見てると画面の上からほぼ3分割されて、パカッ・パカッ・パカッ、という感じで表示されたりします。ネットワークが早くてもパッ・パッ・パッという感じです。分割されても回線やソフトのスピードが早いと人間はわかりませんが中では同じ動きをしてるでしょう。

RUサイズはVTAMのログモードに定義されます。ただしDCMS(TPモニター)によってはDCMSの端末定義などで決定されるものもあります。ログモードと端末定義のどちらを優先するかはDCMSの仕様なので必要なら確認してください。TSOはログモードでRUサイズを決定します。
ログモードのRUSIZEはMODEENTマクロのRUSIZESパラメーターで指定します。IBM社が提供する標準ログモードテーブルISTINCLMにはTN3270サーバーなどでも標準で使用されるSNA端末用ログモードエントリーであるSNX32702と言うのがあります。ここではRUサイズとしてx87F8が指定されています。最初の87は端末->ホスト方向のサイズを示し「8*2^7」で1024バイト、次のF8はホスト->端末方向のサイズを示し「15*2^8」で3840バイトです。3800バイトあればほとんどのケースで分割されることはなく一度で送信できるでしょう。適切なRUサイズがわからなければこのようなメーカーデフォルトを参考にするのも1つの方法です。

昔はハードウェアの制約などで小さいRUサイズを使っていたこともあるので、昔からの伝統的なログモードを今でもそのまま使わっているユーザーでは意外と無駄な分割をしていることもあります。分割数が多ければそれだけネットワークへのI/O回数が増えますから、端末台数が多ければ決してバカには出来ません。

Posted in オペレーション・運用 • • Top Of Page