OSCF/GCASTのインタフェース機能を使用した対話環境での拡張ホストアクセス機能によって，VOSK上のAPとGCASTが連携する仕組みを次の図に示します。

図15-1　対話環境でのAPとGCASTの連携

　

1. JGUOPENモジュールの呼び出し
   
   • メインフレームAPからPCに対して，CALL文でJGUOPENモジュールを呼び出します。
   • PCでは，XMAP3の仮想端末が開かれます。
2. JGUTRANSモジュールの呼び出し
   
   • メインフレームAPは，JGUOPENモジュールを呼び出したあと，APからJGUTRANSモジュールを呼び出します。
   • JGUTRANSモジュールの呼び出しを受けて，PCでは，XMAP3で画面の入出力を行います。
   • XMAP3の仮想端末からGCASTを経由して，ユーザデータをメインフレームに送信します。
   • メインフレームAPでは，データを受信し，処理します。
   業務終了まで，2.の各手順を繰り返します。
   
3. JGUCLOSEモジュールの呼び出し
   
   • 画面の送受信がすべて終了したら，メインフレームAPから，JGUCLOSEモジュールを呼び出します。
   • PC上のGCASTでは，XMAP3の仮想端末を終了します。

GCASTのインタフェース機能については，マニュアル「GUIシステム構築支援 OSCF/GCAST」を参照してください。

画面の論理マップが2,930バイトより大きい場合，メインフレームAPからの1回の画面出力に対して，メインフレームとPCのGCAST間で2,930バイトごとに分割して複数回の通信が行われます。このため，画面表示の性能が低下することがあるので，1画面分の論理マップを2,930バイト以下にすることをお勧めします。

メインフレームAPがJGUTRANSモジュールを呼び出したあとに2,930バイトより大きい論理マップを送信した場合に，画面データが分割される仕組みを次の図に示します。

図15-2　画面データが分割される仕組み（画面データが4,500バイトの場合）

1. 3,000バイト送信
   
   • メインフレームAPは，4,500バイトの画面データを送信します。
   • メインフレームのGCASTは，メインフレームAPが送信した4,500バイトの画面データを，一度に送信できるデータ量の3,000バイトと残りの1,500バイトに分割します。
   • メインフレームのGCASTは，PCのGCASTに対して，3,000バイトの画面データを送信します。
2. 1,500バイト送信
   
   • メインフレームのGCASTは，PCのGCASTに対して，残りの1,500バイトの画面データを送信します。
   • PCは，メインフレームからすべての画面データを受信したあと画面を表示します。
3. 3,000バイト返信
   
   • PCは，4,500バイトの画面データを返信します。
   • PCのGCASTは，PCが返信した4,500バイトの画面データを，一度に返信できるデータ量の3,000バイトと残りの1,500バイトに分割します。
   • PCのGCASTは，メインフレームのGCASTに対して，3,000バイトの画面データを返信します。
4. 1,500バイト返信
   
   • PCのGCASTは，メインフレームのGCASTに対して，残りの1,500バイトの画面データを送信します。
   • メインフレームのGCASTは，メインフレームAPに対して4,500バイトの画面データを返信します。