6.3.API基礎講座３ユーザー・スペースの扱い方

ユーザー・スペースを使うAPIを呼び出すプログラムのロジックは、すべてほとんど同じです。

まるで、ファイルにデータを書き出して、それを読み込んでいるようですよね。そうです。感覚的に、同じといってもいいのです。但し、*FILEではなく、*USRSPCがデータの蓄積場所です。

データの取り出しは、ファイルではないので、当然READやCHAINなんてできません。取り出し命令そのものは、専用のAPIプログラムがあります。それをCALLします。また、DSPPFMの代わりに、DMPOBJで内容確認ができます。見づらいですけど。

このユーザー・スペースで重要なのは、展開されたユーザー・スペース内部では、ある規則にのっとり、きちんと中身の構造が別れていることです。それは、「総称見出し」と「リスト・セクション」（変な言葉ですが、マニュアルにあわせました。）に別れます。この「リストセクション」は、さらに「入力パラメータセクション」と「見出しセクション」と「リストデータセクション」に別れます。

ややこしいのですが、「見出し」とつく名前が二つありますが、両者は別物です。

例えば、ユーザースペースは、こんな感じで利用するのです。

ユーザ空間にデータをセットする。
その総称見出しを検索して、リストセクションの開始桁と、データ長と、データ項目の数を取り出す（QUSRTVUS）。
次に、リストセクションの内部で、開始位置から、データ長取り出し（これも、QUSRTVUS)、カウントアップします。
次の開始位置は、前回の開始位置＋データ長で求まります。

この切り出されたデータの項目（ファイルで言えば、フィールドの定義）に関しては、後で説明します。

総称見出しの位置は、固定的に独立していて、そこから得られる情報で、可変的なリストデータの情報を取り出します。

マニュアルにもあるように、総称見出しからの情報で、データ検索をしたほうがいいです。リストセクションの読み込みまでもプログラム固定にしてしまうと（項目数は分からないけど、データ長は予めマニュアルで分かってしまうものがある）、将来のOSのバージョンアップなどでデータ長が変わった場合、そのプログラムは正しく動きません。V3.1ではデータ長45バイトだったのが、V4.Xなどでデータ長100バイトに変わることもありえます。それで、総称見出し内にセットされた値を使って、リスト検索をすべきなのです。

マニュアル「AS/400V3システムAPI解説書上巻」より

1.1.1 将来のリリースとの互換性

IBM は、将来のリリースにおいて、以下の 1 つがあてはまることを意図しています。

API のいずれかに対して追加の入力または出力パラメーターが指定された場合、その新しいパラメーターは現行パラメーターの後に追加され、任意選択パラメーターになります。既存の API は変更なしで作動し続けます。

追加のデータ構造が指定された場合には、新しい形式（そのデータ構造のレイアウト）が作成されます。

新規の情報が、既存の形式の終わりに追加されている可能性があります。

API は今までと同じように作動し続け、API を使用する既存の適用業務はどれも変更なしで作動し続けます。

将来のリリースとの互換性を確実により良いものとするには、リスト API によって生成されたユーザー・スペースを処理するときに、以下のすべてのものを検索して使用しなければなりません。

    リスト・データ・セクションまでのオフセット値
    リスト・データ・セクションのサイズ
    リスト項目の数
    各項目のサイズ

SEO		[PR] 爆速!無料ブログ無料ホームページ開設無料ライブ放送

6.3.API基礎講座３ ユーザー・スペースの扱い方

6.3.API基礎講座３ユーザー・スペースの扱い方