日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS
ライブラリ

タイトルページ
目次
まえがき
第 1 章:EFSの概要
第 2 章:拡張ファイル命名機能の管理
第 3 章:拡張ファイル名の特徴
第 4 章:アプリケーション開発における注意点
付録 A :EFSのユーザ向け注意点
付録 B :技術情報
付録 C :文字セット
索引
PDF
OpenVMS ホーム
OpenVMS | HPE 日本(日本ヒューレット・パッカード株式会社)

OpenVMS
Extended File Specifications の手引き


目次 索引


RMS は,NAML$L_INPUT_FLAGS フィールドから以下のフラグを読み込みます。

フラグ 意味
NAML$V_NO_SHORT_OUTPUT RMS が NAM$L_ESA または NAM$L_RSA バッファに入力を行わないようにするために,ユーザによって設定される。

RMS は,NAML$L_OUTPUT_FLAGS フィールドに以下のフラグを書き込みます。

フラグ 意味
NAML$V_FILESYS_NAME_UCS2 NAML$L_FILESYS_NAME によってポイントされる名前が 2 バイトの Unicode 文字 6 個から構成されている場合に,RMS によって設定される。
NAML$V_LONG_RESULT_DID long の結果バッファまたは拡張バッファの中に DID によって短縮されたディレクトリがある場合に,RMS によって設定される。
NAML$V_LONG_RESULT_ESCAPE long の結果バッファまたは拡張バッファの中にエスケープ文字 (^) がある場合に, RMS によって設定される。
NAML$V_LONG_RESULT_FID long の結果バッファまたは拡張バッファの中に FID によって短縮された名前がある場合に,RMS によって設定される。
NAML$V_LONG_RESULT_UNICODE long の結果バッファまたは拡張バッファの中に,1 つまたは複数の ^U シーケンスがある場合に,RMS によって設定される。

B.2.3.2.1 NAML ブロックの有効性の確認

RMS に渡された名前 (FAB$L_NAM を参照) に NAML$C_BID に等しいブロック識別子 (NAML$B_BID を参照) が含まれている場合,RMS は以下の有効性チェックを行います。

  1. NAML$B_BLN フィールドが NAML$C_BLN と正確に一致している。

  2. NAML$L_LONG_RESULT_ALLOC および NAML$L_LONG_EXPAND_ALLOC がそれぞれ NAML$C_MAXRSS 以下である。

  3. すべての未使用フィールド (MBZ が含まれたシンボリック名を持つ) に 0 (ゼロ) が含まれている。フィールドを初期化する前に全体の構造をクリアすると,この条件を満たすことができる。

これらの有効性チェックのうちいずれかが失敗すると,RMS$_NAML エラー状態が返されます。

B.2.3.2.2 NAM および NAML ブロックの使用

NAML には,すべての NAM フィールドと等価なフィールドに加えて,より長いファイル指定に対応するために 28 個の新しいフィールドが含まれています。 NAML フィールドには FDL 属性はありません。

NAML の新しいフィールドの多くは NAM フィールドに対応していますが,より長い名前を使用できるフィールドです。たとえば,NAML$L_LONG_EXPAND,NAML$L_LONG_EXPAND_ALLOC,および NAML$L_LONG_EXPAND_SIZE というフィールドは,NAM$L_ESA,NAM$B_ESS,および NAM$B_ESL に対応していますが,255 バイトを超えるより長い名前を使用できます。このような対応関係にあるフィールドがある場合には,元のフィールドは「短いフィールド」と呼ばれ,対応するフィールドは「長いフィールド」と呼ばれます。

RMS が,長いバージョンと短いバージョンの両方を持つ NAML のフィールドに情報を書き込むときには,RMS は通常,等しい情報を両方のフィールドに書き込みます。短いフィールドまたは長いフィールドのいずれか一方が小さすぎて情報を格納できない場合には,RMS はまず短いフィールドに納まるようにファイル指定を短縮しようとしますが,エラーを返します。 RMS が短いフィールドに書き込まないように指示するフラグ NAML$V_NO_SHORT_OUTPUT を指定すると,短いフィールドでのこのようなエラーの発生を防ぐことができます。ただし,NAML を使用している場合には,RMS は常に長いフィールドを使用します。RMS が長いフィールドを使用しないようにするには, NAML ではなく NAM を使用しなければなりません。

RMS が,長いバージョンと短いバージョンの両方を持つ NAML のフィールドから情報を読み込むときには,RMS は通常,長いフィールドから読み込みます。RMS が短いフィールドから読み込むようにするには,NAML ではなく NAM を使用します。RMS がこれらのフィールドから読み込むもっとも一般的なタイミングは,$PARSE の後の $SEARCH の実行中で,NAML の場合は NAML$L_LONG_EXPAND によってポイントされているバッファ,NAM の場合は NAM$L_ESA によってポイントされているバッファから RMS が読み込みを実行するときです。さらに,NAM または NAML が関連する名前ブロックとして使用されている場合,RMSは,NAML の場合は NAML$L_LONG_RESULT によってポイントされているバッファ,NAM の場合は NAM$L_RSA によってポイントされているバッファから情報を読み込みます。

RMS が NAM および NAML を処理する方法にはこのような違いがあるため, NAML に接触する可能性のあるコードは,それが NAM ではなく NAML であることを認識できることが重要です。NAM でルーチンが実行する可能性のある処理の中には, NAML では期待どおりに動作しないものがあります。たとえば,あるルーチンが NAML のコピーを作成する一方でコピーする長さとして NAM$C_BLN 定数を使用した場合,結果は無効な NAML になります。また,別のあるルーチンが,呼び出し元のルーチンに影響を与えることなく NAM を使用できると想定して NAM$L_ESA および NAM$L_RSA によってポイントされたバッファを置き換えると,NAML$L_LONG_EXPAND および NAML$L_LONG_RESULT によってポイントされたバッファが失われます。

このため,OpenVMS で提供される API が以前のバージョンの NAM を (直接,または FAB を使用して間接的に) 返していた場合,その API は,呼び出し元による明示的なアクション (通常はフラグ・ビットを設定すること) がない限り,NAML を返さないという規則に従うことになっています。他の API も同じ規則を使用することを推奨します。さらに,NAML を認識するアプリケーションが NAML を API に渡す場合には,その APIが NAM セクションだけを使用する (たとえば, NAML$V_NO_SHORT_OUTPUT ビットを設定しない) ように注意しなければなりません。

NAM または NAML のいずれかを受け付けるルーチンを作成している場合には, NAM または NAML のどちらがあるのかを判断する必要があります。NAML があり, RMS が NAML の中に残した情報を読み込む場合には,長いフィールドの情報を参照します。さらに,NAM ブロックまたは NAML ブロックを他の場所にコピーする場合は,十分注意して構造自体に格納されている長さを使用してコピーできる量を判断しなければなりません。 NAM$B_BLN にはその構造の実際の長さが含まれているため,NAM$C_BLN 定数ではなく,実際にコピーしている構造にある NAM$B_BLN フィールドを使用する必要があります。 NAM の長さであるシンボル NAM$C_BLN を使用すると,NAML の場合には短かすぎます。

B.2.3.2.3 返される条件値

表 B-7 は,NAML ブロックを使用するときにそれぞれの RMS サービスに返される条件値を示しています。

表 B-7 NAML ブロックを使用したときに返される RMS 条件値
RMS サービス 返される条件値
$CREATE RMS$_NAML
RMS$_NAMLESS
RMS$_NAMLFSINV
RMS$_NAMLFSSIZ
RMS$_NAMLRSS
$DISPLAY RMS$_NAMLESS
RMS$_NAMLFSINV
RMS$_NAMLFSSIZ
$ENTER RMS$_NAML
RMS$_NAMLFSINV
RMS$_NAMLFSSIZ
RMS$_NAMLRSS
$ERASE RMS$_NAML
RMS$_NAMLESS
RMS$_NAMLFSINV
RMS$_NAMLFSSIZ
RMS$_NAMLRSS
$OPEN RMS$_NAML
RMS$_NAMLESS
RMS$_NAMLFSINV
RMS$_NAMLFSSIZ
RMS$_NAMLRSS
$PARSE RMS$_NAML
RMS$_NAMLESS
RMS$_NAMLFSINV
RMS$_NAMLFSSIZ
$REMOVE RMS$_NAML
RMS$_NALFSINV
RMS$_NAMLFSSIZ
RMS$_NAMLRSS
$RENAME RMS$_NAML
RMS$_NAMLESS
RMS$_NAMLFSINV
RMS$_NAMLFSSIZ
RMS$_NAMLRSS
$SEARCH RMS$_NAML
RMS$_NAMLFSINV
RMS$_NAMLFSSIZ
RMS$_NAMLRSS



B.3 Files-11 XQP の変更点

注意

この項に含まれているファイル・システムに関する情報は,現在このドキュメントでのみ扱われています。

Files-11 Extended QIO Processor (XQP) ファイル・システムは,$QIO インタフェースを使用して拡張ファイル名をサポートするように強化されました。 XQP ファイル形式の規則は,RMS によって提供されているような,ファイル名を受け付ける他のシステム・サービスに適用される規則とは異なる場合があることに注意してください。 RMS で使用される新しい構文およびセマンティックの詳細については, 付録 B.2.2 項 を参照してください。

機能強化された XQP では,以下の Extended File Specifications 機能をサポートしています。

  • 8 ビットの ISO Latin-1 文字セットおよび 16 ビットの Unicode (UCS-2) 文字セットなどの,より豊富な文字の使用

  • 長いファイル名

  • ファイル名での大文字と小文字の区別の保存 (最初に作成されたとおりに保存する)

付録 B.3 節 のこの後の項では, Files-11 XQP ファイル・システムおよび $QIO インタフェースに追加された変更点についてより詳しく説明します。

B.3.1 ファイルの命名および形式の変更点

OpenVMS バージョン 7.2 以前では,Files-11 XQP でサポートされる有効なファイル名は,ファイル名およびファイル・タイプが共に 39 文字以内で,合計で 85 個の ASCII 文字3に制限されていました。拡張ファイル名をサポートするために,このような制約が緩和され,以下の内容がサポートされるようになりました。

  • ファイル名での 8 ビットの ISO Latin-1 Multinational 文字セット(ASCII はこのサブセット) のほとんどの文字の使用 (以下の例外を除く)
    C0 制御セット (16 進数の 00〜1F)
    左山括弧 (<)
    右山括弧 (>)
    コロン (:)
    スラッシュ (/)
    バックスラッシュ (\)
    縦線 (|)
    疑問符 (?)
    アスタリスク (*)

    C1 文字セット (16 進数の 80〜9F) の他,9F〜FF のグラフィック文字および他の文字も明示的に含まれていることに注意。

  • ファイル名の中のピリオド (.)

  • 16 ビットの Unicode 文字 (UCS-2) を使用してエンコードされたファイル指定およびディレクトリ指定

  • 区切り文字の 1 文字 (.) を含み,8 ビットまたは 16 ビット文字で合計 236 文字以内の,より長いファイル名およびファイル・タイプ

  • 8 ビットの 242 文字まで 4,または 16 ビットで 124 文字まで 5 のファイル指定

  • 大文字と小文字が混在したファイル指定や,小文字だけのファイル指定が,大文字に変換されることなくディスクに格納される機能 (大文字と小文字の区別の保存)

これらの変更点は,Files-11 ODS-5 形式に初期化または変換されたボリュームに関してのみ適用されます。現在 ODS-2 ボリュームで使用されているセマンティックおよび動作に依存しているアプリケーションは,引き続きこれまでと同様に機能します。

注意

3 ファイル名の 39 文字,区切り文字の 1 文字 (.),ファイル・タイプの 39 文字,区切り文字の 1 文字 (;),バージョン番号の 5 文字を合わせて 85 文字。

4 ファイル名の 236 文字,区切り文字 (.),ファイル・タイプ,区切り文字の 1 文字 (;),バージョン番号の 5 文字を合わせて 242 文字。

5 ファイル名の 118 文字,区切り文字 (.),ファイル・タイプ,区切り文字の 1 文字 (;),バージョン番号の 5 文字を合わせて 124 文字。



ファイル指定は,QIO P2 パラメータを使用し,ディスクリプタによってファイル・システムに渡されます。ディスクリプタには,ファイル指定のテキストへのポインタと,ファイル指定の長さの合計をバイト単位で表した長さのフィールドが含まれています。

ファイル指定の形式は,新しい FIB$B_NAME_FORMAT_IN フィールドで識別することができます。この形式は, 表 B-8 で示されている値のいずれかを取ります。

表 B-8 ファイル形式の FIB 定数
形式の値 形式のタイプ
FIB$C_ODS2 ODS-2 形式
FIB$C_ISO_LATIN ISO Latin-1 形式
FIB$C_UCS2 Unicode (UCS-2) 形式

指定された形式がファイル・システムで認識される形式でない場合には, SS$_BADPARAM エラーが返されます。それ以外の場合には,ファイル・システムは,指定された形式で定義された規則に従って,ファイル指定を解析しようとします。ファイル名の解析に失敗すると, SS$_BADFILENAME エラーまたは SS$_BADFILEVER エラーが返されます。

ファイル・システムに渡された FIB に FIB$B_NAME_FORMAT_IN フィールドが含まれていない場合,ファイル・システムは,指定されたファイル指定が ODS-2 形式であると想定します。これは,変更されていないプログラムとの互換性を保つために行われます。

ファイル・システムは,ファイル指定をボリュームに格納する前に,ファイル指定を最も単純な互換形式に変換します。たとえば,0x00FF より大きい文字の値が含まれていない Unicode (UCS-2) 形式で指定されたファイル指定は,ボリュームに格納される前に, ISO Latin-1 形式に変換されます。

ファイル・システムは,ファイル指定を返すときにファイル形式を新しい FIB$B_NAME_FORMAT_OUT フィールドに書き込みます。 表 B-8 に示されているいずれかの値が使用されます。

ただし,すべてのプログラムがすべての利用可能な命名形式を処理できるとは限りません。 QIO システム・サービスの呼び出し元が, 表 B-9 に示されている新しい FIB$W_NMCTL フラグを使用して,返される形式を選択することができます。

表 B-9 新しいFIB$W_NMCTL フラグ
フラグ名 解釈
FIB$V_NAMES_8BIT 呼び出し元は (8 ビットの) ODS-2 形式および ISO Latin-1 形式を受け付けることができる。
FIB$V_NAMES_16BIT 呼び出し元は (16 ビットの) Unicode (UCS-2) 形式を受け付けることができる。

これらの新しいフラグは,返されるファイル指定を以下のように制御します。

  • 両方のフラグがクリアされている場合

    ODS-2 形式の名前だけが返される。これには元は ISO Latin-1 形式または Unicode (UCS-2) 形式だったものが,ボリュームに格納される前に ODS-2 に変換されたものも含まれることに注意が必要である。すべての指定は,返される前に大文字に変換される。

  • FIB$V_ NAMES_8BIT が設定され
    FIB$V_ NAMES_16BIT がクリアされている場合

    ODS-2 形式および ISO Latin-1 形式で格納されているファイル指定だけが返される。 FIB$B_NAME_FORMAT_OUT フィールドの値は,返される特定の名前の形式を示している。 ODS-2 形式のファイル指定は,返される前に大文字に変換されない。

  • FIB$V_ NAMES_8BIT がクリアされ
    FIB$V_ NAMES_16BIT が設定されている場合

    すべてのファイル指定は Unicode (UCS-2) 形式で返される。

  • 両方のフラグが設定されている場合

    ファイル指定はボリュームに格納されているとおりの形式で返される。これは,ファイル名構文とそこに含まれる文字との互換性を保つ最も単純な形式である。たとえば,元は Unicode 形式で,ISO Latin-1 文字セットの一部である文字だけが含まれているファイル指定は,ISO Latin-1 形式で返される。



ファイル・システム操作によって返されるファイル指定は,通常は呼び出し元のプログラムが理解できる形式になっています。しかし,入力指定にワイルドカードが含まれている操作の場合にはこのようになりません。たとえば,以下の ODS-2 準拠のファイル指定の中にあるワイルドカードが,この場合に相当します。


        A*.DOC 

これは,ISO Latin-1 ファイル指定に対応している可能性があります。


        A sample name with periods.and.other;punctuation#in the name.doc;1 

返されるファイル指定には区切り文字としてのピリオドが 1 つしか含まれていないと想定するアプリケーションは,正しく動作しない可能性があります。ファイル・システムは,呼び出しもとのプログラムがエラーになるようなファイル指定を返すのではなく,代わりに疑似名を返します。実際に返される疑似名は,以下の表に示すように,疑似名が表現する名前のタイプによって異なります。

ファイル形式 疑似名の例
ISO Latin-1 (FIB$C_ISL1) \pISO_LATIN\.???
Unicode (FIB$C_UCS2) \pUNICODE\.???

ファイル・システムは,呼び出し元のプログラムがどの形式を理解できるかを, FIB$V_NAMES_8BIT および FIB$V_NAMES_16BIT フラグの設定から判断します。これらのフラグは, 表 B-10 で示すように,返される名前の形式を制御します。

表 B-10 FIB フラグの設定とそれに従って返される名前の形式
FIB フラグの設定 ファイル形式
8 ビット 16 ビット ODS-2 ISO Latin-1 Unicode
false false ODS-2 疑似名 疑似名
true false ODS-2 ISO Latin-1 疑似名
false true UCS-2 UCS-2 UCS-2
true true ODS-2 ISO Latin-1 UCS-2

ファイル・システムが疑似名を返すとき,ユーザまたは呼び出し元のアプリケーションに,直接のファイル・アクセスを許可せずに疑似名を返す対象となるファイルについて通知します。このため,疑似名には,入力ファイル指定としては 有効でない文字が含まれています。疑似名を使用してファイルを操作しようとすると,SYSTEM-F-BADFILENAME エラーが返されます。

バッファ・サイズ

表 B-11 は,すべての返される可能性のあるファイル指定を格納するために,各バッファで必要な最小サイズを示しています。

表 B-11 各ファイルの安全なバッファ・サイズ (バイト単位)
ファイル形式 QIO の最小値 XQP の最小値
ODS-2 86 86
ISO Latin-1 264 243
Unicode 538 486

個々のアプリケーションでの上限は,そのアプリケーションがサポートしている形式によって異なります。XQP の最小値は,QIO インタフェースを使用する他のファイル・システムの通常の最小値よりも小さいことに注意してください。これは, XQP によって課せられる,ファイル指定に関する 236 バイトのサイズ制限のためです。

ファイル指定が用意されたバッファよりも長い場合,ファイル・システムは,エラーを生成せずに返されたファイル指定の長さを切り捨てます。ファイル指定が用意されたバッファよりも短い場合,ファイル指定の最後からバッファの最後までの間の空きスペースには 0 (ゼロ) が埋め込まれます。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項