BCF/GCASTのインタフェース機能を使用した対話環境での拡張ホストアクセスによって,VOS1上のAPとGCASTが連携する仕組みを次の図に示します。
図10-6 対話環境でのAPとGCASTの連携
![[図データ]](FIGURE/ZU100001.GIF)
- JGUOPENモジュールの呼び出し
- メインフレームAPからPCに対して,CALL文でJGUOPENモジュールを呼び出します。
- PCでは,XMAP3の仮想端末が開かれます。
- JGUTRANSモジュールの呼び出し
- メインフレームAPは,JGUOPENモジュールを呼び出したあと,APからJGUTRANSモジュールを呼び出します。
- JGUTRANSモジュールの呼び出しを受けて,PCでは,XMAP3で画面を入出力します。
- XMAP3の仮想端末からGCASTを経由して,ユーザデータをメインフレームに送信します。
- メインフレームAPでは,データを受信し,処理します。
業務終了まで,2.の各手順を繰り返します。
- JGUCLOSEモジュールの呼び出し
- 画面の送受信がすべて終了したら,メインフレームAPから,JGUCLOSEモジュールを呼び出します。
- PC上のGCASTでは,XMAP3の仮想端末を終了します。
BCF/GCASTのインタフェース機能については,マニュアル「GUIシステム構築支援 BCF/GCAST」を参照してください。
画面の論理マップが2,930バイトより大きい場合,メインフレームAPからの1回の画面出力に対して,メインフレームとPCのGCAST間で2,930バイトごとに分割して複数回の通信が行われます。このため,画面表示の性能が低下することがあるので,1画面分の論理マップを2,930バイト以下にすることをお勧めします。
メインフレームAPがJGUTRANSモジュールを呼び出したあとに2,930バイトより大きい論理マップを送信した場合に,画面データが分割される仕組みを次の図に示します。
図10-7 画面データが分割される仕組み(画面データが4,500バイトの場合)
![[図データ]](FIGURE/ZU100002.GIF)
- 3,000バイト送信
- メインフレームAPは,4,500バイトの画面データを送信します。
- メインフレームのGCASTは,メインフレームAPが送信した4,500バイトの画面データを,一度に送信できるデータ量の3,000バイトと残りの1,500バイトに分割します。
- メインフレームのGCASTは,PCのGCASTに対して,3,000バイトの画面データを送信します。
- 1,500バイト送信
- メインフレームのGCASTは,PCのGCASTに対して,残りの1,500バイトの画面データを送信します。
- PCは,メインフレームからすべての画面データを受信したあと画面を表示します。
- 3,000バイト返信
- PCは,4,500バイトの画面データを返信します。
- PCのGCASTは,PCが返信した4,500バイトの画面データを,一度に返信できるデータ量の3,000バイトと残りの1,500バイトに分割します。
- PCのGCASTは,メインフレームのGCASTに対して,3,000バイトの画面データを返信します。
- 1,500バイト返信
- PCのGCASTは,メインフレームのGCASTに対して,残りの1,500バイトの画面データを送信します。
- メインフレームのGCASTは,メインフレームAPに対して4,500バイトの画面データを返信します。
All Rights Reserved. Copyright (C) 2001, 2006, Hitachi, Ltd.