[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ] [ DOC Home ]

4 OpenVMSアプリケーション開発での拡張ファイル名に関する注意点

この章では，Extended File Specificationsに関するアプリケーションのサポートを評価する方法について説明します。

4.1 現在のサポート状態の評価

OpenVMS Alphaバージョン7.2のテストの一環として，OpenVMSアプリケーションの開発者は，すべての既存のアプリケーションを評価し，テストして，Extended File Specifications の現在のサポート・レベルと，そのレベルが適切であるかどうかを確認する必要があります。サポートのレベルについては，第2.1 節を参照してください。

文書化されていないインタフェースを使用してコーディングされているアプリケーションでは，深いディレクトリまたは拡張ファイル名のサポートが提供されないことがあります。第4.1.2項では，アプリケーションが拡張ファイル名をサポートできなくなるアプリケーション属性が示されています。第4.1.3項では，アプリケーションがODS-5 ボリュームをサポートできなくなるアプリケーション属性が示されています。

これらのアプリケーションがExtended File Specificationsをサポートするように変更するか，Extended File Specifications ではこれらを使用しないようにするか，どちらかにします。Extended File Specificationsの省略時のサポートを提供するようにアプリケーションを変更する方法については，第4.2.1項を参照してください。完全サポートを行うようにアプリケーションをアップグレードする方法については，第4.2.2 項を参照してください。

4.1.1 省略時のサポート

変更されていないOpenVMSアプリケーションのほとんどは，省略時のサポートのカテゴリに分類されます。特に，このようなアプリケーションは， RMS呼び出しを実行する際に，新しいAPIではなく従来のAPIを使用します( 新しいRMS APIの詳細については，第B.2節を参照してください) 。高水準言語呼び出しを使用してファイル操作を実行するアプリケーションも，言語の実行時ライブラリが完全サポートに変更されていない限り，このカテゴリに分類されます。[1]ほとんどの場合は，これらのアプリケーションを変更しなくても，Extended File Specificationsの環境で正常に動作します。

[1] OpenVMSバージョン7.2の時点では，完全サポートにアップグレードされた言語のRTL はありません。

4.1.2 Extended File Namesの非サポート

次のいずれかに該当するアプリケーションでは，拡張ファイル名がサポートされていないことがあります。

QIOインタフェースを使用してファイル名を指定している。開発者は，すべてのレイヤード・プロダクトおよびアプリケーションを調べ，RMS インタフェースとXQPインタフェースとの間での相互作用を評価する必要がある。拡張ファイル名の形式は，それぞれのインタフェースによって異なるため，アプリケーションがRMSとXQPの両方で同じファイル名を使用できるとは限らない。さらに，XQPでは，更新されていないアプリケーションが拡張ファイル名を使用することができない。拡張ファイル名をサポートするためにXQPに追加された変更の詳細については，第B.3節を参照。有効なファイル名は，インタフェースによって異なることがある。
区切り記号や有効な文字の位置の位置など，ファイル指定の構文に関する仮定がある。
ファイル指定の大文字と小文字の区別に仮定がある。RMSは，大文字と小文字が混在しているファイル指定や，小文字だけのファイル指定をすべて大文字に変換する処理を実行しないため，文字列のマッチング処理に影響を与える可能性がある。
従来のディレクトリの深さに依存している(8レベル未満)。

4.1.3 ODS-5ボリュームの非サポート

ディレクトリの内容やファイル・ヘッダのデータのディスクでの構造など，ファイル・システムの内部知識を使用するアプリケーションは， ODS-5ボリュームでは正常に動作しません。

4.2 Extended File Specificationsサポートのためのアプリケーションのアップグレード

この後の項ではExtended File Specificationsのサポート・レベルをアップグレードするために必要な変更について説明します。アプリケーションを完全サポート・レベルにアップグレードするには，最初にそのアプリケーションが省略時のサポート・レベルを満たしていなければならないことに注意してください。

注意: RMSインタフェースやQIOインタフェースを 使用せずにディスク入出力を実行している場合，現在のアプリケーションのExtended File Specifications のサポート・レベルは，現在使用しているインタフェース(言語の実行時ライブラリなど)が完全サポートを提供しているかどうかによって決まります。

4.2.1 省略時サポートへのアップグレード

Extended File Specificationsの省略時サポートを提供するようにアプリケーションをアップグレードするには， 4.2.1.1および4.2.1.2でそれぞれ推奨されているように，少なくともそのアプリケーションがODS-5ボリューム構造と拡張ファイル命名機能の両方をサポートしている必要があります。省略時サポートについては，第2.1.2項で説明しています。

4.2.1.1 ODS-5サポートの提供

新しいODS-5ボリューム構造をサポートしていないアプリケーションは，従来型のファイル指定だけを処理した場合でも，これらのボリューム上では正常に動作しません。

ODS-5ボリューム上でアプリケーションが正常に動作しない場合には，そのアプリケーションについて次の点を確認してください。

ODS-5ボリュームにアクセスする際，このアプリケーションは物理入出力または論理入出力のどちらを使用してファイル・システムをバイパスしているのか? あるいは，BITMAP.SYSのようなメタデータ・ファイルに直接アクセスしているのか?
このようなアプリケーションは，通常，ディスク・デフラグメンタのようなシステム・プログラムか，またはディスクに直接アクセスすることによってオーバヘッドを避けようとしているプログラムです。このようなアプリケーションは，ディスク上のファイルまたはディレクトリに関する特定の知識に依存していますが，この知識は，ODS-5構造を導入したことによって，すでに変更されています。
推奨事項:アプリケーションには，できる限り文書化されたインタフェースや構造を使用します。
このアプリケーションは，ディレクトリ・ファイルに直接アクセスし，内容を解釈しているか?
そのような場合，拡張ファイル名が含まれているディレクトリをこのアプリケーションが処理するときにエラーが発生する可能性があります。
推奨事項: RMS[2]インタフェースまたはQIOインタフェース，あるいはLIB$FIND_FILEのようなLIBRTLルーチンで提供されている検索関数を使用できるようにアプリケーションを変更します。

[2] OpenVMS Alphaバージョン7.2では，RMSディレクトリのキャッシング・サイズが大幅に増加したため，大規模なディレクトリでの$SEARCH システム・サービスの性能が飛躍的に向上しました。

4.2.1.2 拡張ファイル命名機能サポートの提供

アプリケーションが拡張名を正しく処理できない場合には，そのアプリケーションについて次の点を確認してください。

このアプリケーションは，ファイル指定の構文を解析したり，その構文に関する知識を仮定して動作しようとしているか?
たとえば，アプリケーションがディレクトリ指定の先頭を探すために大括弧([) を検索したり，ファイル指定の末尾を示すスペース文字を探している場合があります。
推奨事項:アプリケーションは，ファイル指定が有効かどうかを判断するためには，実際の名前を使用して予備テストを実行するのではなく，RMS に依存するべきです。NAMブロックのUse the NAM$L_NODEフィールド，NAM$L_DEVフィールド，NAM$L_DIRフィールド，NAM$L_TYPE フィールド，およびNAM$L_VERフィールドを使用するか，またはSYS$FILESCANを使用して，この情報を取り出します。
このアプリケーションは，文字列比較演算を実行することによって，2 つのファイルが同一であるかどうかを判断しようとしているか?
ファイル名の大文字と小文字は区別されず，同じ文字を表す方法が複数あるため，2 つの文字列が同一のファイルを表している場合でも，文字列比較演算を実行するとエラーが発生する可能性があります。
推奨事項:新しいシステム・サービス$CVT_FILENAMESを使用してファイル名を比較する例については，サンプル・プログラム[SYSHLP.EXAMPLES]FILENAME_COMPARE.C を参照してください。
このアプリケーションは，NAM$L_FNBフィールドにあるNAM$V_DIR_LVLS ビットに依存して，現在のファイル指定にあるディレクトリ・レベルの数を判断しているか?
このフィールドには3ビットしかないため，指定できるのは最大で8レベルまでです。アプリケーションがこれらのビットを使用することはほとんどなく，通常，これらのビットはNAMが相対ファイル指定として指定されるときに，RMS によって使用されます。
推奨事項: OpenVMSバージョン7.2以降，NAMブロックとNAMLブロックの両方で，新しくより大きいフィールドNAM$W_LONG_DIR_LEVELS を使用することができます。ディレクトリ・レベルの正しい数を知るには，このフィールドを使用します。
このアプリケーションは，NAM$V_WILD_UFDおよびSFD1 - SFD7ビットに依存して，ワイルドカード・ディレクトリがあるかどうかを判断しているか?
このようなビットは8つしかないため，報告できるのは最初の8ディレクトリ・レベルのワイルドカードに限られます。アプリケーションがこれらのビットを使用することはほとんどなく，通常，これらのビットはNAM が相対ファイル指定として指定されるときに，RMSによって使用されます。
推奨事項: OpenVMSバージョン7.2以降，NAMブロックとNAMLブロックの両方で，新しくいフィールドNAML$W_FIRST_WILD_DIRを使用することができます。ワイルドカードが含まれている最も上のディレクトリ・レベルを知るには，このフィールドを使用します。
このアプリケーションは，ファイル・システムに対しQIOインタフェースを使用して，QIO のファイル名を直接指定したり要求しているか?
QIOインタフェースでは，拡張ファイル名を受け付けたり返すためには，アプリケーションが拡張ファイル名を認識できることを明示的に指定する必要があります。さらに，拡張ファイル名のファイル名形式は，RMS インタフェースとQIOインタフェースとでは異なっています。しかも，一部のファイル名は，2バイトのUnicode (UCS-2)文字で指定されていることがあります。アプリケーションは，2バイトを占有する1 文字を処理できるようになっていなければなりません。
推奨事項: QIOインタフェースを使用しているほとんどのアプリケーションは，RMS を使用してファイル指定を解析したり，ファイルのファイルID やディレクトリIDを取り出している。そのようなアプリケーションは，これらのIDの値を使用して，QIOインタフェースからファイルにアクセスします。このアクセス方式は，拡張名にも使用できます。この方式に変更することによって，問題を解決できます。
NAMLブロックのNAML$L_FILESYS_NAMEフィールドからQIOシステムが使用する名前を取得したり，新しいシステム・サービス(SYS$CVT_ FILENAME)を使用して，RMSファイル名とQIOファイル名との間で相互に変換することもできます。この場合には，QIOサービスで拡張FIBブロックを使用して，アプリケーションが拡張名を認識していることを指定し，バッファを最大サイズまで拡大し，2バイトのUnicode文字を処理できるように準備する必要があります。

4.2.2 完全サポートへのアップグレード

システム管理ユーティリティやディスク管理ユーティリティなど一部のOpenVMS アプリケーションでは，Extended File Specificationsの完全サポートが必要です。通常，このようなユーティリティは，DIDやFIDの短縮形を持たないすべてのファイル指定を表示し，操作しなければなりません。Extended File Specifications のすべての機能を完全にサポートするようにアプリケーションをアップグレードするには，次の操作を行います。

RMS NAMブロックの使用部分をすべて新しいNAMLブロックに変換します。
RMSで使用している入力ファイル名バッファと出力ファイル名バッファを拡張します。このためには，短いバッファ・ポインタ(NAML$L_ESA とNAML$L_RSA)ではなく，NAMLの拡張バッファ・ポインタと結果バッファ・ポインタ(NAML$L_LONG_EXPANDとNAML$L_LONG_ RESULT)を使用し，バッファ・サイズをNAM$C_MAXRSSからNAML$C_ MAXRSSに増やします。
FABファイル名のバッファ・フィールド(FAB$L_FNA)に長い(255 バイトを超える)ファイル名が指定されている場合には，NAMLのファイル名バッファ・フィールド(NAML$L_LONG_FILENAME)を代わりに使用します。FAB の省略時の名前バッファ・フィールドに(FAB$L_DNA)長いファイル名が指定されている場合には，NAML の省略時の名前バッファ・フィールド(NAML$L_LONG_DEFNAME)を代わりに使用します。
LIB$FIND_FILEルーチン，LIB$RENAMEルーチン，またはLIB$DELETE ルーチンを使用する場合には，flags引数にLIB$M_FIL_ LONG_NAMESを設定します(flagsは，LIB$DELETEルーチンの新しい引数です) 。NAMLブロックをNAMブロックの代わりに使用すると，他に変更を加えずに情報をLIB$FILE_SCAN に渡すことができることに注意してください。
LIB$FID_TO_NAMEルーチンを使用する場合には，返されるファイル指定の記述子を変更して，4095 (NAML$C_MAXRSS) バイトに増加された最大バイト数に対応するよう変更しなければならない可能性があります。
FDL$CREATEルーチン，FDL$GENERATEルーチン，FDL$PARSEルーチンまたはFDL$RELEASE ルーチンを使用する場合には，flags引数にFDL$M_LONG_NAMES を設定しなければなりません。
ソース・コードを調べて，ファイル指定が8ビットで255文字を超えないという仮定が内部的に設定されていないことを確認します。

[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ] [ DOC Home ]