; hp; ヒューレット・パッカード;hewlett-packard; ヒューレット;コンパック;compaq; OS; OpenVMS;高い信頼性とスケーラビリティを提供するOS"> - OpenVMSのマニュアルページです。">
日本-日本語

 >  マニュアル >  V8.3ライブラリ

OpenVMS マニュアル


HP OpenVMS
HP C ランタイム・ライブラリ・
リファレンス・マニュアル (上巻)


前へ 次へ 目次 索引


例を次に示します。


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 を無効にすると, renamelogical_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

DECC$SELECT_IGNORES_INVALID_FD を有効に設定すると,記述子セットのいずれかに不正なファイル記述子が指定されている場合, selectは異常終了し, errnoは EBADF に設定されます。

DECC$SELECT_IGNORES_INVALID_FD を無効に設定すると, selectは不正なファイル記述子を無視します。

DECC$STDIO_CTX_EOL

DECC$STDIO_CTX_EOL を有効に設定すると,ストリーム・アクセスのための stdoutおよび stderrへの書き込みは,区切り文字が確認されるか,バッファが満杯になるまで実行されません。

DECC$STDIO_CTX_EOL を無効に設定すると, fwriteを実行するたびに個別に書き込みが実行され,メールボックスとレコード・ファイルの場合,個別のレコードが作成されます。

DECC$STREAM_PIPE

DECC$STREAM_PIPE を有効に設定すると,C RTL の pipe関数は, UNIX との互換性が高いストリーム入出力を使用します。

DECC$STREAM_PIPE を無効に設定すると, pipeは従来の OpenVMS のレコード入出力を使用します。これがデフォルトの動作です。

DECC$STRTOL_ERANGE

DECC$STRTOL_ERANGE を有効に設定すると, ERANGE エラーに対する strtolの動作は,文字列内の残りのすべての桁を使用するように修正されます。

DECC$STRTOL_ERANGE を無効に設定すると,問題が発生した桁にポインタを保持するというこれまでの動作が有効になります。

DECC$THREAD_DATA_AST_SAFE

C RTL には,AST のために割り振られるデータ用とは別に,非 AST レベルでスレッドによって割り振られるスレッド固有のデータのための記憶域を割り振るモードがあります。このモードでは,スレッド固有のデータにアクセスするたびに, LIB$AST_IN_PROG を呼び出す必要があり, C RTL でスレッド固有のデータにアクセスする場合,大きなオーバヘッドが発生する可能性があります。

代替モードでは,スレッド固有のデータは,別の関数がロックしている場合にだけ保護されます。このモードでは,C RTL の内部で使用中のデータは保護されますが, AST がデータを変更するのを呼び出し元で保護することはできません。

この 2 番目のモードは, strtokecvtfcvt関数の C RTL デフォルトになりました。

DECC$THREAD_DATA_AST_SAFE を有効に設定すると,従来の AST セーフ・モードを選択できます。

DECC$TZ_CACHE_SIZE

DECC$TZ_CACHE_SIZE は,メモリに保持できるタイム・ゾーンの数を指定します。

デフォルト値: 2

最大値: 2147483647

DECC$UMASK

DECC$UMASK は,アクセス許可マスク umaskのデフォルト値を指定します。デフォルト設定では,親の C プログラムは,プロセスの RMS デフォルト・アクセス許可から umaskを設定します。子プロセスは umaskの値として,親の値を継承します。

値を 8 進数として入力するには,先頭に 0 を追加します。 0 を追加しないと,10 進数として変換されます。次の例を参照してください。


$ DEFINE DECC$UMASK 026 

最大値: 0777

DECC$UNIX_LEVEL

DECC$UNIX_LEVEL 論理名を使用すると,複数の C RTL 機能論理名を一度に操作できます。設定した値は蓄積効果があり,値が大きいほど影響を受けるグループが多くなります。たとえば値を 20 に設定すると, 20,10,および 1 の DECC$UNIX_LEVEL に対応するすべての機能論理名が有効になります。

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_LEVEL で指定されたその機能のデフォルト値より優先されます。

  • C RTL の将来のリビジョンでは, DECC$UNIX_LEVEL に新しい機能論理名が追加される可能性があります。 UNIX レベルを指定するアプリケーションに対しては,デフォルトでこれらの新しい機能論理名が有効になります。



DECC$UNIX_PATH_BEFORE_LOGNAME

DECC$UNIX_PATH_BEFORE_LOGNAME を有効に設定すると,先頭がスラッシュ (/) でない UNIX ファイル名を変換するときに,この名前は現在のディレクトリのファイルまたはディレクトリに対応付けられます。このようなファイルやディレクトリが見つからず,名前が OpenVMS ファイル名で論理名として有効な場合は,論理名変換が実行されます。論理名が検索されて変換されると,ファイル名の一部として使用されます。

DECC$UNIX_PATH_BEFORE_LOGNAME を有効に設定すると, DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION の設定は無効になります。

DECC$USE_JPI$_CREATOR

DECC$USE_JPI$_CREATOR が有効の場合, JPI$_OWNER の代わりに JPI$_CREATOR 項目を使用して $GETJPI を呼び出し, getppidの親プロセス ID が決定されます。

この機能は, POSIX 形式のセッション識別子をサポートしているシステムでのみ利用できます。

DECC$USE_RAB64

DECC$USE_RAB64 を有効に設定すると,オープン関数は従来の RAB 構造体ではなく, RAB64 構造体を割り振ります。

これは,64 ビット・メモリ内のファイル・バッファに対する潜在的なサポート機能を提供します。

DECC$VALIDATE_SIGNAL_IN_KILL

DECC$VALIDATE_SIGNAL_IN_KILL を有効に設定すると, 0〜_SIG_MAX の範囲内であっても, C RTL でサポートされないシグナル値はエラーを生成し, errnoは EINVAL に設定されます。この結果, raiseと同じ動作が実行されます。

この論理名を無効に設定すると,シグナルのチェックは,シグナル値が 0〜_SIG_MAX の範囲内であるかどうかというチェックに制限されます。 sys$sigprcが異常終了すると, errnosys$sigprcの終了状態をもとに設定されます。

DECC$V62_RECORD_GENERATION

OpenVMS Version 6.2 以降では,異なる規則を使用してレコード・ファイルを出力できるようになりました。

DECC$V62_RECORD_GENERATION を有効に設定すると,出力機能は OpenVMS Version 6.2 に対して使用される規則に従います。

DECC$WRITE_SHORT_RECORDS

DECC$WRITE_SHORT_RECORDS 機能論理名は,固定長ファイルへの従来のレコードの書き込み方式をデフォルトの動作として維持しながら, fwrite関数への以前の変更 (最大レコード・サイズより小さいサイズのレコード書き込みへの対応) をサポートしています。

DECC$WRITE_SHORT_RECORDS が有効の場合, EOF に書き込まれたショート・サイズ・レコード (サイズが最大レコード・サイズ未満のレコード) は,レコードをレコード境界に合わせるために,ゼロでパディングされます。これは,OpenVMS Version 7.3-1 と,この時期の一部の ACRTL ECO に見られる動作です。

DECC$WRITE_SHORT_RECORDS が無効の場合,パディングなしでレコードを書き込む従来の動作が実行されます。これが,推奨される,デフォルトの動作です。

DECC$XPG4_STRPTIME

XPG5 での strptimeのサポートでは,ピボット年のサポートが導入され, 0〜68 の年は 21 世紀,69〜99 の年は 20 世紀であると解釈されるようになりました。

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 オペレーティング・システムのもとで単独に動作するコードを開発するのが重要なのか」という問題について検討してください。

  • UNIX との互換性が重要である場合は,最高レベルの I/O,つまり標準 I/O と UNIX I/O を使用することが必要でしょう。なぜなら,このレベルはオペレーティング・システムからの独立性がかなり高いからです。また,最高レベルの I/O は学習するのも簡単です。初心者のプログラマの場合,このことは重要な要素です。

  • UNIX との互換性が重要でない場合や,標準 I/O および UNIX I/O 方式で提供されない高度なファイル処理が必要な場合は, RMS を使用することが望ましいでしょう。

システム・レベルのソフトウェアを開発する場合,システム・サービスへの呼び出しを使用して 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 の対応関係



前へ 次へ 目次 索引



         印刷用画面へ

プライバシー 本サイト利用時の合意事項