作成する画面は，必要最小限のオブジェクトにし，マップを小さくすることで実行性能が向上します。マップを小さくするには，次のことに注意してください。

(a)　けい線の見直し

• むだなけい線は削除する。
• 矩形で囲んだフィールドは反転表示にして枠を取る。

(b)　テキストボックスやフィールドの見直し

• テキストなどの集約
  テキストボックスやフィールドは，まとめて定義してください。例えば，「年」「月」「日」は三つに分けるのではなく，一つにまとめることでマップが小さくなります。
  
• フィールドボックスの利用（1）
  テキストボックスで作成されている表は，フィールドボックスのフィールドとして定義してください。表示性能が向上します。
  
• フィールドボックスの利用（2）
  GUI画面でテキストボックスが多く繰り返されている場合には，フィールドボックス中にフレームを配置して，その中のフィールドとして定義してください。フィールドボックスのフレーム機能を使用すると，1フィールドの定義で複数フィールドに相当する定義ができます。また，論理マップ上ではOCCURS展開されるため，APのロジックも繰り返し指定で実現でき，効率が良くなります。
  

(c)　グラフィックデータの見直し

• 不要なグラフィックデータの削除
  グラフィックデータは，データ量が多くマップが大きくなってしまいます。グラフィックデータは，必要な個所にだけ使用するようにしてください。
  
• グラフィックデータの縮小化
  固定グラフィックの場合はファイルサイズの総和が31,000バイト以内に収まるように作成してください。出力グラフィックの場合は100KB以内を目安にして作成することをお勧めします。容量の大きいグラフィックデータを小さくするには，次の方法で対処できます。
  
  • ビットマップの縦横ドット数を小さくする
    ビットマップは，中身の図柄がどのようなものであっても，同じ縦横サイズならばファイルサイズとして，常に同じバイト数を必要とします。したがって，縦横ドット数を小さくすることで，ファイルサイズが小さくなります。実際に絵を描いていない部分もビットマップの情報として格納されますので，必要最小限の領域を取るようお勧めします。
    次に既存のビットマップの必要な部分だけをペイント（またはペイントブラシ）を用いて切り出す方法を説明します。
    1. ペイント（またはペイントブラシ）で基になるビットマップを表示する。
    2. 四角形選択ツールで（または自動選択ツール）で必要な部分を選択する。
    3. メニューバーから［編集］の［ファイルへコピー］を選択する。
    4. ファイル名を指定して保存する。
    
  • 使用する色を減らす
    ビットマップの形式として，2色，16色，256色，1,600万色（フルカラー）の色数のものがあります。色数が増えると情報量が増えるので，それだけビットマップサイズが大きくなります。また，その表示色数をサポートしていないディスプレイに表示した場合，色化けが起きたり，表示が遅くなるなどの問題が起こります。
    既存のビットマップの色数を変更するには，画像フォーマットを変換する機能を持った市販のグラフィックソフトを使用する方法があります。しかし，色数を減らすことでビットマップが見にくくなることがあります。
    したがって，初めから16色でビットマップを作成することをお勧めします。
    

(d)　プレーンサイズの見直し

ボックスに隠れているプレーンは，データがなくても表示しています。不要なサイズになっていないか見直してください。

(e)　画面サイズの見直し

画面サイズが小さい方が表示性能は高くなります。画面サイズを見直してください。

(a)　同一マップを再表示するときの方法

同一マップの画面を再表示する場合は，一部上書を指定しないと，画面中の一つ（または一部）のオブジェクトだけを書き換えるときでも全画面の再表示となり，表示性能が低下します。

一部上書と全面書換とを使い分けることをお勧めします。特に一部上書は，フィールド単位にデータを入力し，APでチェックおよび表示していくような場合に効果的です。指定方法については「7.2.3(1)(f)　MAPPING MODE句の扱い（マッピングオプション）」を参照してください。

• 前提となる定義
  
  1. ドローで，画面属性の「入力・選択状態の扱い」に「未入力・未選択」または「状態を維持」を指定します。また，該当するテキスト・フィールドの属性の「初期値」に「なし」を指定します。
  2. 1.の指定によって，データ未入力を埋字以外で判定する必要が生じた場合には，ドローセットアップの論理マップ属性ダイアログで，「初期クリア文字」に「埋字」以外を指定します。さらに，ユティリティの「セットアップ情報の反映」で，マップを再生成します。

<1回目の表示時>

• プログラム中のマッピングオプションに，「マージ」を指定します。
• TRANSCEIVE文，SEND文などで画面を表示します。

<同じ画面の再表示時>

1. プログラム中のマッピングオプションに，「論理マップだけ」を指定します。
2. 画面表示時に変更しない項目にデータ有無コードを格納します。

• 動的変更属性の指定があれば，プログラム中の制御項目（修飾名を格納する論理マップのエリア）に格納します。
• 項目データは，先頭1バイト目，またはすべての項目データに対して格納します。
• 出力論理マップがデータ有無コードでクリアされるため，表示中のデータを記憶しておく場合には別のエリアに画面情報をバックアップしておくような対処が必要です。

1. 画面表示時に変更する項目だけにデータを格納します。
2. 画面の表示形態を指定する制御項目（マップ名-CNTRLO）に，動的変更用の定数テーブル中の「XMAP-CNTRL1（標準の場合）」を格納します。
3. TRANSCEIVE文，SEND文などで1回目と同じマップ名を再表示します。

このコーディングのサンプルとして，APパターンCRLINP01.CBLを利用できます。

(b)　データ量の見直し

APでむだなデータを送っていませんか。例えば，常にスペースやゼロを送ってしまうと実行性能が劣ってしまいます。したがって，出力時の性能を上げるにはデータの量を減らすことが重要です。

• データ有無コードで論理マップをクリアします。データ有無コードについては「6.2.7　特定の入出力テキストだけを書き換える（データ有無コードの利用）」を参照してください。
• むだな初期値は指定しないようにしてください。

(c)　AP分割の見直し

XMAP3のオープン要求がどのタイミングで出されているかを見直してください。コンパイル単位で，TRANSCEIVE文または，SEND文が発行されると，画面ごとにオープンが実行されるため，処理が遅くなります。不要に画面をオープンしないためには次の点に注意してください。

• 一つのコンパイル単位にTRANSCEIVE文，SEND文をまとめ，オープンの実行は必要最低限にします。
• 共通のルーチンにまとめてTRANSCEIVE文，SEND文を発行するようにAPの構造を見直します。
• 日立COBOLの場合，AP間でオープンを引き継ぐ「CBLTERMSHAR=YES」を指定すると，AP間でオープンの引き継ぎが行われます。

詳細については「7.1.2　AP間でオープンを引き継ぐ場合」を参照してください。

日立COBOLでは，明示的にCALL文でオープンを要求する場合を除き，一つのコンパイル単位で最初のSEND文またはTRANSCEIVE文が発行されると画面がオープンされます。そのため，1画面が1実行ファイル（.EXE）のような構成にすると，実行ファイルごとに画面をオープンすることになります。この場合，オープン・クローズ，SEND文，TRANSCEIVE文を発行する実行ファイル，ビジネス処理をする実行ファイルをそれぞれ分けた方が実行性能が高くなります。

また，複数のコンパイル単位のものを合わせて一つの実行ファイルにするときは，各コンパイル単位でオープンを発行しないようにするため，日立COBOLの実行支援の環境変数で，「CBLTERMSHAR=YES」を指定します。「CBLTERMSHAR=YES」は，SEND／RECEIVE／TRANSCEIVEインタフェースのときだけ有効です。CALLインタフェースでは無効になります。

CALLインタフェースの場合，または「CBLTERMSHAR」をサポートしていないバージョンの日立COBOLを使用している場合で，AP間のオープン引き継ぎをするときは，ユーザが，XMAP3インタフェースエリアの情報を引き継ぐようなコーディングをする必要があります。サンプルコーディングとして，APパターンのGENDSP02およびGENDSP03が利用できます。

(d)　画面クローズのタイミングの見直し

画面のクローズは，明示的にCALL文でクローズするか，DISABLE文を発行したタイミングです。ただし，クローズすると次に画面を表示するときには必ずオープンしなければなりません。画面を素早く消したり，再表示したりする場合は，画面属性ダイアログの「Z位置」で「一時非表示」を指定して，見た目上は表示されていないようにしておき，次に画面を表示するときに動的変更で「Z位置」の指定を「標準表示」または「手前に表示」に変更します。このようにすると，画面をクローズ，オープンするよりも早く画面を切り替えられます。

(e)　APとの制御のやり取りの見直し

画面属性の定義で入力単位を「画面」にしているにもかかわらず，オブジェクトの属性で「自動送信」を指定して，オブジェクト単位でAPに制御を返すようなAP構造は，画面単位にAPに制御を返すAP構造と比べ オーバーヘッドが大きくなり，オブジェクト遷移（フォーカス移動）が遅くなる場合があります。このため，APとの制御のやり取りは画面単位で行うことをお勧めします。オブジェクト単位でAPと制御のやり取りをする場合は，入力単位を「フィールド」や「イベント」に設定し，できるだけ画面中のオブジェクトの数を少なくすることがポイントです。

(a)　マップの常駐化サイズの見直し

使用する物理マップを常駐するバッファサイズは変更できます。詳細については，マニュアル「XMAP3 開発・実行ガイド」を参照してください。

(b)　C/Sシステム構成時の通信データ削減

C/Sシステム構成の場合，XMAP3の通信データを圧縮する機能が利用できます。通信データの圧縮機能を利用すると，C/S間の通信量が削減できるため，画面応答のレスポンス向上が期待できます。詳細については，マニュアル「XMAP3 開発・実行ガイド」を参照してください。