IMS データベース互換本番 DBMS

サポートされる IMS 機能

DLI 関数

• GU、GHU、GN、GHN、GNP、GHNP、ISRT、REPL、DLET
• Fast Path：FLD、POS
• GSAM：OPEN、CLSE
• AIBTDLI：INQY
• AERTDLI：CIMS、APSB、DPSB
• CICS DL/I 呼び出し：PCB、SCHD、TERM

データベース アクセス タイプ

IMS DB にはいくつかのデータベース アクセス タイプがあり、通常はアプリケーションによって決まるベスト パフォーマンスに応じて選ばれます。

• DEDB
• GSAM
• HALDB*
• HDAM、HIDAM、HISAM、HSAM
• INDEX
• LOGICAL
• MSDB
• PHIDAM、PHDAM、PSINDEX
• SHISAM、SHSAM

* HALDB はフル機能の標準のデータベースとしてサポートされますが、HALDB の拡張機能はサポートされません。ACCESS パラメーターに HALDB データベースを指定できますが、その拡張機能に対して特別な処理は行われません。

データベース セグメント タイプ

• 一意のキー付きセグメント
• 一意ではないキー付きセグメント - 最初のルール、ここでのルール、および最後のルール
• キー付きでないセグメント - 最初のルール、ここでのルール、および最後のルール
• 固定長セグメントおよび可変長セグメント
• 2 次索引セグメントのソース データを含んでいるセグメント
• 論理子および論理親
• DEDB 順次従属 (SDEP) セグメント

データベース回復

DLI プログラム バッチ バックアウト

セグメント検索引数 (SSA)

プログラムは、検索をセグメント検索引数 (SSA) で修飾することでデータを検索します。Enterprise Server の互換 SSA サポートには次が含まれます。

• セルあたり 15 までの SSA、SSA あたり 4,000 バイトまでの制限付き
• SSA ごとに 125 までのブール演算子をサポートする SSA 関係演算子
• SSA コマンド コード

ユーザー出口

Enterprise Server 内での IMS ユーザー出口には、元のメインフレーム実装との互換性を最大化するカスタムの拡張を実現するためのメカニズムがあります。ただし、オープン システムの本番環境ではメインフレームのアセンブラーはサポートされないため、Enterprise Server では出口ルーチンはアセンブラーでなく COBOL で記述する必要があります。つまり、どのような移行であっても、アセンブラーで記述された既存のメインフレーム出口ルーチンは移行の中で COBOL に変換するかまたは COBOL で記述し直す必要があります。

次の IMS 固有ユーザー出口がサポートされます。

• MFS フィールドおよびセグメント編集ルーチン。
• スパース索引出口。
• GSAM データベース。
• データ取得出口 - EXIT 作用対象が DBD 文と SEGM 文の両方、および LOG オプションを除くすべての EXIT オプション (DATA、PATH、CASCADE オプション) でサポートされます。CASCADE のサブオプション (KEY、DATA、PATH) もサポートされます。9 つまでの出口ルーチンを任意の 1 つのセグメントに指定できます。
• XPCB および XSDB パラメーター ブロックでのすべてのフィールド。

データベースの最大サイズ

IMS 本番データベースは IDX-8 ファイルとして実装されるため、IMS データベースの論理上の最大サイズは IDX-8 ファイルの最大サイズと結び付いています。Micro Focus では、300GB を超える IMS データベースでのテストやパフォーマンス ベンチマークを実施していません。非常に大きなデータベースは、パフォーマンスやメンテナンス (リビルド時間など) の面で実用的でない場合があります。大規模なデータベースを移行する顧客の場合、プロトタイプまたは概念実証の一部としてテストのための時間を設けることをお勧めします。

Enterprise Server での内部データベース構造は、ポインターではなくシンボリック キーを使用し、冗長キー情報を維持するため、Windows、UNIX、または Linux 上の IMS データベースに必要な実質的な記憶域容量が増えます。ただし、Enterprise Server のファイル システムで実行されるキーおよびデータの圧縮によって、通常はこのオーバーヘッドが補正されます。

2 段階のコミット アーキテクチャ

IMS DB 互換の本番 DBMS では、2 段階のコミット プロトコルが使用されます。すべての登録されるリソースは送信されたコミット要求です。コミットの順序は、リソースが 2 段階の順序をサポートするかどうかに応じます。2 段階リソースでは、「Commit」段階の送信前に「Prepare」が各リソースに発行されます。すべての Prepare が成功すると、コミット処理が始まります。Prepare に失敗があると、バックアウトが開始します。リソースが prepare に対してネガティブに応答するときは、コミットは完了できないがバックアウトは完全に行えること、またはすでにバックアウトが行われていることを意味します。

Micro Focus の 2 段階コミット アーキテクチャはメインフレーム IMS の 2 段階コミット サポートに似ており、いくつかの同じ利点を共有しています。ただし、もしバックアウト処理中またはコミット処理の第 2 段階で失敗が発生してもそこから回復する機能はありません。

「単段階」コミット プロトコルに対する 2 段階プロセスの主な利点は、アプリケーションが最後にリソースにアクセスした時点からコミット処理が始まる時点までの整合性を図る期間が不要なことです。Prepare 段階ではこの期間に何らかの失敗が生じると、それを捕捉してバックアウト処理を開始します。これを単段階プロトコルを使用する 2 つの個別のリソースと比べると、単段階には Prepare 段階はなく、コミットまたはバックアウトのみがあります。最初のコミットに成功しても 2 番目のリソースに対するコミットに失敗すれば、成否両方を含む結果を得ることになります。