前へ

次へ

目次

索引

メモリ常駐グローバル・セクションを使用する OpenVMS Alpha アプリケーションを構成するには，次の手順を実行します。

1. SYSMAN RESERVED_MEMORY ADD コマンドを実行し，必要な予約メモリを指定します。

2. フィードバックを伴う AUTOGEN を実行し，システムの流動ページ・カウントを適切に設定し，システムのページファイル，プロセス数，およびワーキング・セット最大サイズを適切に算出します。

3. システムを再起動することによって，予約メモリをシステムの流動ページ・カウントから除外し，連続的でアラインされたページを割り当て，必要に応じてゼロ化します。

本章では，64 ビット・アドレッシングをサポートし，RMS を使用して P2 または S2 空間への入出力操作を実現するために，RMS インタフェースに加えられた変更について示します。既存の RMS コードにわずかな変更を加えるだけで，この RMS 強化機能をすべて使用することができます。

RMS の 64 ビット・アドレッシングのサポートについての詳細は，『OpenVMS Record Management Services Reference Manual』を参照してください。

RMS ユーザ・インタフェースは，多くの制御データ構造 (FAB，RAB，NAM，XAB) で構成されています。これらは 32 ビット・ポインタで一緒にリンクされ，ファイル名文字列と項目リストに加えて入出力バッファを含む I/O バッファおよびさまざまなユーザ・データ・バッファに対する埋め込みポインタを含みます。64 ビットのアドレス指定可能リージョンをサポートする RMS を使用すると，次に示すユーザ I/O バッファで 64 ビット・アドレスを使用できます。

• UBF (ユーザ・レコード・バッファ)

• RBF (レコード・バッファ)

• RHB (固定長レコード・ヘッダ・バッファ ; VFC レコード形式の固定部分)

• KBF (ランダム・アクセス用のキー値を含むキー・バッファ)

ただし，RAB$L_PBF で示されるプロンプト・バッファは例外です。これは，ターミナル・ドライバが 64 ビット・アドレスを使用しないためです。

64 ビット・アドレッシングを実現するため，RMS インタフェースに対して次の強化が行われました。

• 次のユーザ I/O サービスのために，データ・バッファが P2 または S2 空間に存在する。

  • レコード I/O サービス : $GET, $FIND, $PUT, $UPDATE

  • ブロック I/O サービス : $READ, $WRITE

• RAB 構造が，これらのサービスで使用するレコードおよびデータ・バッファを指す。

• 既存の RAB 構造を拡張して，64 ビット・バッファ・ポインタとサイズ用に使用する。

• RMS ブロック I/O サービス($READ および $WRITE) のバッファ・サイズの最大値を，64 K バイトから 2 G バイトに増やす。ただし次の場合は例外。

  • RMS ジャーナリングの場合，ジャーナルされた $WRITE サービスは現在の最大値 (65535 からジャーナル・オーバヘッドの 99 バイトを引いた値)に制限される。最大値を超えると，RSZ エラーが返される(RAB$L_STS)。

  • 磁気テープは，デバイス・ドライバ・レベルで引き続き 65535 バイトに制限される。

  
  RMS レコード I/O サービス($GET，$PUT，$UPDATE) のバッファ・サイズの最大値に変更はない。以前の RMS オン・ディスク・レコード・サイズの制限がそのまま適用される。

残りの RMS インタフェースは現時点では 32 ビットに制限される。

• FAB，RAB，NAM，および XAB は 32 ビット空間に引き続き割り当てなければならない。

• ファイル名へのディスクリプタ，または埋め込みポインタ，項目リストなどは，引き続き 32 ビット・ポインタでなければならない。

• RMS システム・サービスへ渡される引数は，32 ビット引数のままである。64 ビット引数を渡そうとすると，エラー SS$_ARG_GTR_32_BITS が返される。

5.1 RAB64 データ構造

RMS ユーザ・インタフェース構造である RAB64 は，RAB を拡張したもので，64 ビット・バッファ・アドレスに対処することができます。RAB64 データ構造は，図 5-1 に示すように，32 ビットの RAB 構造と，これに続く 64 ビット拡張で構成されています。

図 5-1 RAB64 データ構造

RAB64 に含まれるフィールドは RAB フィールドとすべて同一ですが，フィールド名には，RAB 接頭辞ではなく RAB64 接頭辞が含まれます。RAB64 はまた，拡張部に次の新フィールドを含みます。

フィールド	このフィールドの 拡張	説明
RAB64$Q_CTX	RAB64$L_CTX	ユーザ・コンテキスト。RMS はこのフィールドを使用しないが，ユーザが使用する。CTX フィールドは，ポインタを格納しておくために使用されることがある。非同期 I/O の場合，ユーザに AST パラメータに相当する機能を提供する。
RAB64$PQ_KBF	RAB64$L_KBF	ランダム・アクセスするためのキー値を含むキーバッファ・アドレス ($GET および $FIND)。
RAB64$PQ_RBF	RAB64$L_RBF	レコード・バッファ・アドレス($PUT，$UPDATE，および $WRITE)。
RAB64$PQ_RHB	RAB64$L_RHB	レコード・ヘッダ・バッファ・アドレス(VFC レコード形式の固定部分)。
RAB64$Q_RSZ	RAB64$W_RSZ	レコード・バッファ・サイズ。
RAB64$PQ_UBF	RAB64$L_UBF	ユーザ・バッファ・アドレス($GET および $READ)。
RAB64$Q_USZ	RAB64$W_USZ	ユーザ・バッファ・サイズ。

名前に PQ タグを含むフィールドは，64 ビット・アドレス，または 32 ビット・アドレスの符合拡張による 64 ビット・アドレスのいずれも持つことができます。そのため 64 ビット・アドレスの使用に関わらず，すべてのアプリケーションでこれらのフィールドを使用することができます。

大部分のレコード I/O サービス要求では，デバイスとユーザのデータ・バッファとの間に RMS 内部バッファがあります。RMS サービスの $PUT は唯一の例外です。デバイスがユニット・レコード・デバイスでネットワーク越しにアクセスされない場合，RMS はユーザ・レコード・バッファ(RBF) のアドレスを $QIO システム・サービスに渡します。64 ビット・アドレス空間をサポートしないレコード単位取り扱い装置を対象として，64 ビット・アドレス空間に割り当てられているレコード・バッファ(RBF) を不適切に $PUT に指定すると，SS$_NOT64DEVFUNC が返されます ($QIO についての詳細は 第 7 章 を参照してください)。RMS は RAB64$L_STV の 2 番目の状態値として SS$NOT64DEVFUNC でエラー状態 RMS$_SYS を返します。

RMS システム・サービスは，RAB64 構造と RAB 構造をサポートします。

5.2 64 ビット RAB 拡張の使用

アプリケーションが 64 ビット RMS サポートを使用するには，最小限のソース・コードの変更だけが必要です。

RMS では，RAB を使用できる場所で，RAB64 を使用することを認めています。たとえば，ある RMS レコードやブロック I/O サービスに渡される先頭引数として，RAB の代わりに RAB64 を使用することができます。

RAB64 は，既存の RAB の拡張で上位互換性があります。そのため大部分のソース・モジュールは，RAB64 内のフィールドへの参照を，まるで RAB への参照であるかのように取り扱うことができます。一方，64 ビット・バッファ・アドレスの場合は，次の 2 つの条件が満たされるときに限って使用されます。

• RAB64$B_BLN フィールドが RAB64$C_BLN64 に初期化され，拡張が存在することを示している。

• RAB の 32 ビット部分内の 32 ビット・アドレス・フィールドが -1 を含んでいる。

クォドワード・サイズ・フィールド内の値は，32 ビット・アドレス・フィールドの内容がその使用を指定しているときに限って使用されます。この例を次に示します。

このアドレス・フィールドが -1 を含む場合	このフィールド内の アドレスが使用される	このフィールド内の サイズが使用される
RAB64$L_UBF	RAB64$PQ_UBF1	RAB64$Q_USZ
RAB64$L_RBF	RAB64$PQ_RBF1	RAB64$Q_RSZ
RAB64$L_KBF	RAB64$PQ_KBF	RAB64$B_KSZ
RAB64$L_RHB	RAB64$PQ_RHB	FAB$B_FSZ

RMS は，RAB を使用できる場所での RAB64 の使用を認めていますが，ソース言語によっては，ほかの制限が課せられる場合があります。詳細は，使用しているソース言語のマニュアルを参照してください。

5.3 ユーザRAB構造をサポートするマクロ

次の新しい MACRO-32 マクロおよび BLISS マクロが実装され，ユーザ RAB 構造に対する 64 ビット拡張をサポートします。

• MACRO-32 マクロ

  • $RAB64 ($RAB のカウンタパート)

  • $RAB64_STORE ($RAB_STORE のカウンタパート)

  
  これらのマクロを使用することによって，次の状態が発生する。

  • RAB$B_BLN に RAB$C_BLN64 の定数が代入される。

  • 元のロングワード I/O バッファが -1 に初期化され，USZ および RSZ ワード・サイズが 0 に初期化される。

  • UBF，USZ，RBF，RSZ，RHB，または KBF キーワードを使用して指定した値が，これらのキーワードのクォドワード・フィールドに移動する (これに対して，$RAB および $RAB_STORE マクロは，これらの値を，これらのキーワードのロングワード [またはワード] フィールドに移動する)。

• BLISS マクロ

  次の BLISS マクロは，STARLET.R64 ライブラリでだけ使用できる。これは，マクロが使用する QUAD キーワードが，BLISS-64 でだけ使用できるためである。このため，このマクロを参照する BLISS ルーチンはすべて，BLISS-64 コンパイラを使用してコンパイルされなければならない。

  • $RAB64 ($RAB のカウンタパート)

  • $RAB64_INIT ($RAB_INIT のカウンタパート)

  • $RAB64_DECL ($RAB_DECL のカウンタパート)

  
  先頭の 2 つのマクロ($RAB64 および $RAB64_INIT)を使用することによって，次の状態が発生する。

  • RAB$B_BLN に RAB$C_BLN64 の定数が代入される。

  • 元のロングワード I/O バッファが -1 に初期化され，USZ および RSZ ワード・サイズが 0 に初期化される。

  • キーワード UBF，USZ，RBF，RSZ，RHB，KBF に代入された値は，これらのキーワードのクォドワード・フィールドに移動される (これに対して，$RAB および $RAB_INIT マクロは，これらの値を，これらのキーワードのロングワード [またはワード] フィールドに移動する)。

  
  3 番目のマクロ($RAB64_DECL)は，RAB$C_BLN64 の長さのバイトのブロック構造を割り当てる。

Files-11 On-Disk Structure Level 2 (ODS-2) を実現する Extended QIO Processor (XQP) ファイル・システム，および Magnetic Tape Ancillary Control Process (MTAAACP) は共に，仮想読み込み関数と仮想書き込み関数における，64 ビット・バッファ・アドレスの使用をサポートします。

XQP および ACP は，ファイルへの仮想 I/O 要求を，デバイスへの 1 つ以上の論理 I/O 要求に変換します。XQP または ACP 要求で指定されるバッファはデバイス・ドライバに渡されるため，P2 または S2 空間内のバッファのサポートも，XQP および ACP で使用されるデバイス・ドライバに依存します。

OpenVMS が提供するディスク・ドライバおよびテープ・ドライバはすべて，仮想，論理，および物理的な読み込み関数と書き込み関数において，ディスク・デバイスとテープ・デバイスを対象とするデータ転送で 64 ビット・アドレスをサポートします。したがって，XQP および Magnetic Tape ACP は，仮想読み込み関数と仮想書き込み関数において，P2 または S2 空間内のバッファをサポートします。

XQP および ACP は，制御関数 (IO$_ACCESS，IO$_DELETE，IO$_MODIFY など) において，P2 または S2 空間内のバッファをサポートすることはしません。

64 ビット・バッファ・アドレスをサポートするデバイス・ドライバについての詳細は，第 7 章 を参照してください。

RMS サービス，$QIO システム・サービス，および OpenVMS Alpha システムが提供するほとんどのデバイス・ドライバによる入出力操作は，P2 または S2 空間と直接行われます。

本章では $QIO システム・サービスが 64 ビット・アドレスをサポートする方法について説明します。また 64 ビット・アドレスをサポートする/しない OpenVMS Alpha デバイス・ドライバ，64 ビット・アドレスをサポートする OpenVMS Alpha ディスクおよびテープ・ドライバの一覧を示します。

ユーザが作成したデバイス・ドライバは，64 ビット・アドレスをサポートするよう修正することができます。詳細は『OpenVMS Alpha Guide to Upgrading Privileged-Code Applications』を参照してください。すべての関数内で 64 ビット・バッファ・アドレスをサポートするよう修正したデバイス・ドライバの例については，SYS$EXAMPLES ディレクトリの LRDRIVER デバイス・ドライバを参照してください。

$QIO および $QIOW システム・サービスは，次の引数を取ることができます。

$QIO[W] efn,chan,func,iosb,astadr,astprm,p1,p2,p3,p4,p5,p6

これらのサービスは，( 第 3 章 で説明されている) 64 ビット・フレンドリ・インタフェースを持ち，64 ビット・アドレスをサポートすることができます。

64 ビット・アドレスのサポートを目的として，$QIO および $QIOW システム・サービス引数のデータ型に加えられた変更を 表 7-1 に示します。

表 7-1 $QIO [W] 引数の変更

引数	以前の型	新しい型	説明
efn	符号なし ロングワード	-	イベント・フラグ番号。変更なし。
chan	符号なしワード	-	チャネル番号。変更なし。
func	符号なし ロングワード	-	I/O 関数コード。変更なし。
iosb	32 ビット・ ポインタ1	64 ビット・ ポインタ	クォドワード I/O 状態ブロック (IOSB) へのポインタ。IOSB 形式は変更なし。
astadr	32 ビット・ ポインタ1	64 ビット・ ポインタ	呼び出し者の AST ルーチンのプロシージャ値。Alpha システムでは，プロシージャ値はプロシージャ・ディスクリプタへのポインタである。
astprm	符号なし ロングワード2	クォドワード	AST ルーチンの引数値。
P1	ロングワード2	クォドワード	デバイスに依存する引数。P1 はしばしばバッファ・アドレスである。
P2	ロングワード2	クォドワード	デバイスに依存する引数。下位 32 ビットだけが，P2 をバッファ・サイズとして使用するシステム提供の FDT ルーチンによって使用される。
P3	ロングワード2	クォドワード	デバイスに依存する引数。
P4	ロングワード2	クォドワード	デバイスに依存する引数。
P5	ロングワード2	クォドワード	デバイスに依存する引数。
P6	ロングワード2	クォドワード	デバイスに依存する引数。場合によって P6 は，診断バッファのアドレスを含むために使用される。

通常，$QIO P1 引数はバッファ・アドレスを指定します。読み込み関数および書き込み関数をサポートする，システム提供の上位レベル FDT ルーチンはすべて，この規則を使用します。P1 引数によって，$QIO サービスの呼び出し者が，64 ビット・サポートを要求するかどうかが決定されます。$QIO システム・サービスが 64 ビットの I/O 要求を拒否すると，次に示す回復不可能なシステム・エラー状態が返ります。

SS$_NOT64DEVFUNC 64-bit address not supported by device for this function

この回復不可能な状態値は，次の環境のもとで返されます。

• 呼び出し者が，デバイスに依存する P1 引数に 64 ビット仮想アドレスを指定したが，デバイス・ドライバが，要求された I/O 関数で 64 ビット・アドレスをサポートしない。

• 呼び出し者が，診断バッファに対して 64 ビット・アドレスを指定したが，デバイス・ドライバが，診断バッファで 64 ビット・アドレスをサポートしない。

• 64 ビット・バッファ・アドレスが P2 〜 P6 引数を使用して渡され，ドライバが，要求された I/O 関数で 64 ビット・アドレスをサポートしない場合，デバイス・ドライバによってはこの状態値を返すことがある。

$QIO，$QIOW，および $SYNCH システム・サービスについての詳細は，『OpenVMS System Services Reference Manual: GETQUI-Z』を参照してください。

前へ

次へ

目次

索引