useCurrentSchema ビルド記述子 オプションを YES に設定すると、EGL は、sqlLib.currentSchema システム変数を、 EGL で生成される SQL コードの特定の表名に追加します。このように、 EGL レコード・プロパティーや #sql ディレクティブでは、修飾されていない表名を使用でき、 実行時に修飾を付けることができます。
prepare p from "DELETE FROM " :: sqlLib.currentSchema :: "MYTBL";
EGL は、vgj.jdbc.schema Java ランタイム・プロパティーから sqlLib.currentSchema の 初期値を取得します。次には、vgj.jdbc.schema プロパティーがその値を sqlSchema ビルド記述子オプション (genProperties ビルド記述子オプション が PROGRAM または GLOBAL に設定されている場合) から取得します。
変数ストリング内に区切り文字があればそれを含めます。このトピックの後半にある例を参照してください。
ホスト・システムによって、通常、修飾されていない表名の使用が可能になり、システムによって異なる 方法でのスキーマの設定が可能になります。iSystem で表を見つけるには、 ライブラリー・リストを検索して指定された表を含むライブラリー (スキーマ) を見つけます。z/OS® では、スキーマは通常、 適切なスキーマ名を持つ BIND ステートメントに QUALIFIER オプションを組み込むことによって BIND 時に決定されます。これを EGL でシミュレートするには、useCurrentSchema ビルド記述子オプションを YES に設定し、sqlSchema ビルド記述子オプションを、 デバッグに使用するテスト・スキーマの名前に設定します。これは、 EGL デバッガーでテストを行った同じ SQL ステートメントから COBOL コードを 生成できる、ということです。
2 つ目の利点は、開発者が通常、テスト専用に使用するスキーマ (またはデータベース全体) に対して 独自のコードをテストすることです。 sqlLib.currentSchema 変数を使用することによって、すべての テストが完了するまで実際のデータへのアクセスを回避できます。 その結果 sqlSchema ビルド記述子オプションの値を変更して コードを再生成するだけで済み、独自の SQL を変更する必要はありません。
次の例では、異なる環境では、スキーマ用の異なるフォーマットが要求されます。
if(sysVar.systemType is ZOSCICS)
// ここでの変数はスキーマです
sqlLib.currentSchema = "TESTSCHEMA.";
else
if(sysVar.systemType is ISERIESJ)
// ここでの変数はユーザー・ライブラリーです
sqlLib.currentSchema = "TESTSCHEMA/";
end
end