HP OpenVMS Systems Documentation |
| 前へ | 次へ | 目次 | 索引 |
例を次に示します。
rename("file.ext", "logical_name") /* where logical_name = dev:[dir.subdir] */
/* and :[dir.subdir] exists. */
|
次のような結果になります。
dev:[dir.subdir]file.ext |
この例では,ファイル名の変更により,あるディレクトリから別のディレクトリへファイルが移動されます。この動作は,V7.3-1 より前の OpenVMS の古い動作と同じです。またこの例では, dev:[dir.subdir]が存在しない場合, renameがエラーを返します。
DECC$RENAME_ALLOW_DIR を無効にすると, renameの logical_name 引数の変換が,より UNIX に準拠したものになります。
例を次に示します。
rename("file.ext", "logical_name") /* where logical_name = dev:[dir.subdir] */
|
次のような結果になります。
dev:[dir]subdir.ext |
この例では,logical_name 引数の subdir部分を新しいファイル名として使用して,ファイル名が変更されます。これは,UNIX システム上ではファイルからディレクトリへの名前変更 (rename) はできないためです。このため renameは内部的に "logical_name"をファイル名に変換し, to a file name, dev:[dir]subdirが最も妥当な変換結果となります。
この新しい機能には,名前をファイルに変更するのではなくディレクトリに変更するという副作用があります。次に例を示します。
rename ( "file1.ext", "dir2" ) /* dir2 is not a logical */ |
DECC$RENAME_ALLOW_DIR が無効な場合,この例では,サブディレクトリ [.dir2]が存在するかどうかにかかわらず dir2.extという結果になります。
DECC$RENAME_ALLOW_DIR が有効な場合, [.dir2]が存在しなければ dir2.extという結果になります。サブディレクトリ [.dir2]が存在する場合は, [.dir2]file1.extという結果になります。
DECC$RENAME_NO_INHERIT が有効の場合は,UNIX 準拠の動作が行われます。このため,DECC$RENAME_ALLOW_DIR は無視され,ファイルからディレクトリへの名前変更 (rename) は許されません。 |
DECC$SELECT_IGNORES_INVALID_FD を無効に設定すると, selectは不正なファイル記述子を無視します。
DECC$STDIO_CTX_EOL を無効に設定すると, fwriteを実行するたびに個別に書き込みが実行され,メールボックスとレコード・ファイルの場合,個別のレコードが作成されます。
DECC$STREAM_PIPE を無効に設定すると, pipeは従来の OpenVMS のレコード入出力を使用します。これがデフォルトの動作です。
DECC$STRTOL_ERANGE を無効に設定すると,問題が発生した桁にポインタを保持するというこれまでの動作が有効になります。
代替モードでは,スレッド固有のデータは,別の関数がロックしている場合にだけ保護されます。このモードでは,C RTL の内部で使用中のデータは保護されますが, AST がデータを変更するのを呼び出し元で保護することはできません。
この 2 番目のモードは, strtok, ecvt, fcvt関数の C RTL デフォルトになりました。
DECC$THREAD_DATA_AST_SAFE を有効に設定すると,従来の AST セーフ・モードを選択できます。
デフォルト値: 2
最大値: 2147483647
値を 8 進数として入力するには,先頭に 0 を追加します。 0 を追加しないと,10 進数として変換されます。次の例を参照してください。
$ DEFINE DECC$UMASK 026 |
最大値: 0777
UNIX 風の動作に影響する主な論理名は,次のグループに分類できます。
1 全般的な補正
10 拡張
20 UNIX 形式のファイル名
30 UNIX 形式のファイル属性
90 完全な UNIX 動作 - OpenVMS に対する配慮なし
BASH や GNV などの UNIX 風のプログラムに対しては,レベル 30 が適切です。
DECC$UNIX_LEVEL 値と,影響を受ける機能論理名のグループの対応は,次のとおりです。
General Corrections (DECC$UNIX_LEVEL 1) DECC$FIXED_LENGTH_SEEK_TO_EOF 1 DECC$POSIX_SEEK_STREAM_FILE 1 DECC$SELECT_IGNORES_INVALID_FD 1 DECC$STRTOL_ERANGE 1 DECC$VALIDATE_SIGNAL_IN_KILL 1 General Enhancements (DECC$UNIX_LEVEL 10) DECC$ARGV_PARSE_STYLE 1 DECC$EFS_CASE_PRESERVE 1 DECC$STDIO_CTX_EOL 1 DECC$PIPE_BUFFER_SIZE 4096 DECC$USE_RAB64 1 UNIX style file names (DECC$UNIX_LEVEL 20) DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION 1 DECC$EFS_CHARSET 1 DECC$FILENAME_UNIX_NO_VERSION 1 DECC$FILENAME_UNIX_REPORT 1 DECC$READDIR_DROPDOTNOTYPE 1 DECC$RENAME_NO_INHERIT 1 UNIX like file attributes (DECC$UNIX_LEVEL 30) DECC$EFS_FILE_TIMESTAMPS 1 DECC$EXEC_FILEATTR_INHERITANCE 1 DECC$FILE_OWNER_UNIX 1 DECC$FILE_PERMISSION_UNIX 1 DECC$FILE_SHARING 1 UNIX compliant behavior (DECC$UNIX_LEVEL 90) DECC$FILENAME_UNIX_ONLY 1 DECC$POSIX_STYLE_UID 1 DECC$USE_JPI$_CREATOR 1 DECC$DETACHED_CHILD_PROCESS 1 |
|
DECC$UNIX_PATH_BEFORE_LOGNAME を有効に設定すると, DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION の設定は無効になります。
この機能は, POSIX 形式のセッション識別子をサポートしているシステムでのみ利用できます。
これは,64 ビット・メモリ内のファイル・バッファに対する潜在的なサポート機能を提供します。
この論理名を無効に設定すると,シグナルのチェックは,シグナル値が 0〜_SIG_MAX の範囲内であるかどうかというチェックに制限されます。 sys$sigprcが異常終了すると, errnoは sys$sigprcの終了状態をもとに設定されます。
DECC$V62_RECORD_GENERATION を有効に設定すると,出力機能は OpenVMS Version 6.2 に対して使用される規則に従います。
DECC$WRITE_SHORT_RECORDS が有効の場合, EOF に書き込まれたショート・サイズ・レコード (サイズが最大レコード・サイズ未満のレコード) は,レコードをレコード境界に合わせるために,ゼロでパディングされます。これは,OpenVMS Version 7.3-1 と,この時期の一部の ACRTL ECO に見られる動作です。
DECC$WRITE_SHORT_RECORDS が無効の場合,パディングなしでレコードを書き込む従来の動作が実行されます。これが,推奨される,デフォルトの動作です。
DECC$XPG4_STRPTIME を有効に設定すると,XPG5 のピボット年のサポートは無効になり, 0〜99 のすべての年が現在の世紀であると解釈されます。
1.7 32 ビットの UID/GID と POSIX 形式の識別子
OpenVMS オペレーティング・システムのバージョンで POSIX 形式の識別子がサポートされる場合, POSIX 形式の識別子はユーザ識別子 (UID),グループ識別子 (GID),プロセス・グループを参照します。スコープには実識別子と実効識別子が含まれます。
HP C RTL で POSIX 形式の識別子をサポートするには, 32 ビットのユーザ ID とグループ ID のサポートが必要であり,サポートされるかどうかは,OpenVMS の基本バージョンの機能に応じて異なります。 POSIX 形式の ID は, OpenVMS Version 7.3-2 およびそれ以降でサポートされています。
POSIX 形式の識別子をサポートしているバージョンの OpenVMS でこの識別子を使用するには,アプリケーションが 32 ビット UID/GID 用にコンパイルされていなければなりません。 32 ビット UID/GID がデフォルトの OpenVMS バージョンでも,ユーザやアプリケーションは,DECC$POSIX_STYLE_UID 機能論理名を定義して, POSIX 形式の ID を有効にしなければなりません。
$ DEFINE DECC$POSIX_STYLE_UID ENABLE |
POSIX 形式の ID を有効にすると,コンパイル時に,個々の関数に対して,従来 (UIC ベース) の定義を呼び出すこともできます。この場合は, decc$が前についたエントリ・ポイント (POSIX 形式の動作を行う, decc$__long_gid_が前に付いたエントリ・ポイントではなく) を明示的に呼び出します。
POSIX 形式の ID を無効にするには,次の定義を行います。
$ DEFINE DECC$POSIX_STYLE_UID DISABLE |
OpenVMS Version 7.3-2 およびそれ以降では,POSIX 形式の ID と 32 ビットの UID/GID の両方がサポートされます。 32 ビットの UID/GID を使用するように設定してアプリケーションをコンパイルした場合, UID と GID はオペレーティング・システムの以前のバージョンと同様に UIC から取得されます。場合によっては, getgroups関数の場合のように,アプリケーションで 32 ビットの GID がサポートされる場合,より多くの情報が返されることがあります。
デフォルトで 32 ビットの UID/GID を使用するシステムで, 16 ビットの UID/GID をサポートするように設定したアプリケーションをコンパイルするには,マクロ _DECC_SHORT_GID_T に 1 を定義します。
1.8 OpenVMS システムでの入出力
HP C RTL とリンクする方法,および HP C 関数とマクロを呼び出す方法を学習したら,次に主要な目的である入出力 (I/O) のために HP C RTL を使用できるようになります。
システムごとに I/O の方法は異なっているため, OpenVMS 固有のファイル・アクセス方式を十分理解しておくことが必要です。十分理解しておけば,ソース・プログラムをあるオペレーティング・システムから別のオペレーティング・システムに移植するときに,機能上の相違点をあらかじめ予測することができます。
図 1-2 は, HP C RTL で使用できる I/O 方式を示しています。 OpenVMS システム・サービスは OpenVMS オペレーティング・システムと直接通信するため,オペレーティング・システムに最も近い位置にあります。 OpenVMS RMS (Record Management Services) 関数はシステム・サービスを使用し,それらのシステム・サービスがオペレーティング・システムを操作します。 HP C の標準 I/O および UNIX I/O 関数とマクロでは, RMS 関数を使用します。 HP C RTL 標準 I/O および UNIX I/O 関数およびマクロは,システムを操作するまでに複数の関数呼び出しのレイヤを通過しなければならないため,オペレーティング・システムから最も遠い位置にあります。
図 1-2 C プログラムからの I/O インタフェース
C プログラミング言語は UNIX オペレーティング・システムで開発されており,標準 I/O 関数は,ほとんどのアプリケーションで十分効率よく強力で便利な I/O 方式を提供できるように設計されており,さらに C 言語コンパイラが稼動するどのシステムでも関数を使用できるように,移植可能になるように設計されています。
HP C RTL では,このもともとの仕様にさらに機能が追加されています。 HP C RTL で実装されている標準 I/O 関数は,行区切り文字を認識するので, HP C RTL の標準 I/O 関数は特に,テキスト操作の場合に便利です。 HP C RTL では,一部の標準 I/O 関数はプリプロセッサ定義マクロとして実装されています。
同様に,UNIX の I/O 関数はもともと, UNIX オペレーティング・システムにより直接的にアクセス可能になるように設計されています。これらの関数では,数値のファイル記述子を使用してファイルを表現します。 UNIX システムでは,統一されたアクセス方式を可能にするために,すべての周辺デバイスがファイルとして表現されます。
HP C RTL では,もともとの仕様にさらに機能が追加されています。 HP C で実装されている UNIX I/O 関数は,特にバイナリ・データを操作するのに便利です。 HP C RTL ではまた,一部の I/O 関数はプリプロセッサ定義マクロとして実装されています。
HP C RTL には,すべての C コンパイラにある標準 I/O 関数が用意されており,その他にできるだけ多くの他の C の実装と互換性を維持するために UNIX I/O 関数も用意されています。しかし,標準 I/O と UNIX I/O のどちらも,ファイルにアクセスするために RMS を使用します。標準 I/O 関数と UNIX I/O 関数が RMS でフォーマットされたファイルを操作する方法を理解するには,RMS の基礎を学習する必要があります。 RMS ファイルに関連する標準 I/O と UNIX I/O の詳細については, 第 1.8.1 項 を参照してください。 RMS の概要については,『Guide to OpenVMS File Applications』を参照してください。
どの方法が適切であるかを判断する前に,まず,「UNIX との互換性が重要なのか, OpenVMS オペレーティング・システムのもとで単独に動作するコードを開発するのが重要なのか」という問題について検討してください。
システム・レベルのソフトウェアを開発する場合,システム・サービスへの呼び出しを使用して OpenVMS オペレーティング・システムに直接アクセスしなければならないことがあります。たとえば,$QIO (Queue I/O Request) システム・サービスを通じて,直接ユーザ作成デバイス・ドライバにアクセスしなければならないことがあります。この場合は,OpenVMS レベルの I/O を使用します。経験の豊富な OpenVMS プログラマの場合は,このレベルを推奨します。 OpenVMS システム・サービスを呼び出すプログラムの例については,『HP C User's Guide for OpenVMS Systems』を参照してください。
おそらく, RMS や OpenVMS システム・サービスを使用しないこともあるでしょう。多くのアプリケーションでは,標準 I/O 関数と UNIX I/O 関数が十分効率的に機能します。 図 1-3 は,標準 I/O 関数および UNIX I/O 関数と RMS の依存関係を示しており,使用できるさまざまな I/O 方式も示しています。
図 1-3 標準 I/O および UNIX I/O と RMS の対応関係
| 前へ | 次へ | 目次 | 索引 |