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

前へ 次へ 目次 索引

この 2 番目のモードは， strtok， ecvt， fcvt関数の 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が異常終了すると， errnoは sys$sigprcの終了状態をもとに設定されます。

DECC$V62_RECORD_GENERATION

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

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

DECC$WRITE_SHORT_RECORDS

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

DECC$WRITE_SHORT_RECORDS が有効の場合， EOF に書き込まれたショート・サイズ・レコード (サイズが最大レコード・サイズ未満のレコード) は，レコードをレコード境界に合わせるために，ゼロでパディングされます。これは，OpenVMS バージョン 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 のバージョン 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 バージョン 7.3-2 およびそれ以降では，POSIX 形式の ID と 32 ビットの UID/GID の両方がサポートされます。 32 ビットの UID/GID を使用するように設定してアプリケーションをコンパイルした場合， UID と GID はオペレーティング・システムの以前のバージョンと同様に UIC から取得されます。場合によっては， getgroups関数の場合のように，アプリケーションで 32 ビットの GID がサポートされる場合，より多くの情報が返されることがあります。

32 ビットの UID/GID のサポートを有効にしてアプリケーションをコンパイルするには，マクロ __USE_LONG_GID_Tを定義します。 16 ビットの UID/GID をサポートするように設定したアプリケーションをコンパイルするには，マクロ _DECC_SHORT_GID_Tを定義します。

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 の対応関係

1.8.1 RMS のレコード・フォーマットとファイル・フォーマット

標準 I/O および UNIX I/O の関数とマクロの機能および制約事項を理解するには， OpenVMS RMS (Record Management Services) について理解する必要があります。

RMS では次のファイル編成がサポートされます。

順編成ファイルにはレコードが連続的に記録され，レコードとレコードの間に空のレコードは存在しません。相対編成ファイルには固定長のセルが記録され，各セルにはレコードが格納されていることも，格納されていないこともあります。索引順編成ファイルには，データ，キャリッジ制御情報，さまざまなアクセス順序を可能にするキーを格納したレコードが記録されます。

HP C RTL の関数は順編成ファイルにだけアクセスできます。他のファイル編成を使用する場合は，RMS 関数を使用する必要があります。 RMS 関数の詳細については，『HP C User's Guide for OpenVMS Systems』を参照してください。

RMS はレコードの内容を考慮せず，レコードのフォーマットを考慮します。レコードのフォーマットとは，記憶媒体の記録面にレコードが物理的に記録される方法です。

RMS では次のレコード・フォーマットがサポートされます。

固定長レコード・フォーマットはファイルの作成時に指定できます。このフォーマットでは，すべてのレコードがファイル内で同じサイズの領域を使用します。ファイルの作成後にレコード・フォーマットを変更することはできません。

可変長，VFC，ストリーム・ファイル・フォーマットのレコードの長さは，最大サイズまでの範囲で変化することができ，最大サイズはファイルの作成時に指定しなければなりません。可変長レコードまたは VFC フォーマットのファイルでは，レコードのサイズはデータ・レコードの先頭にあるヘッダ・セクションに格納されます。ストリーム・ファイルでは，キャリッジ制御文字やライン・フィード文字など，特定の文字が検出されたときに，RMS はレコードを終了します。ストリーム・ファイルはテキストを格納するのに便利です。

RMS では，ファイル内のレコードのキャリッジ制御属性を指定できます。このような属性としては，暗黙のキャリッジ・リターンや Fortran でフォーマットされたレコードがあります。ファイルを端末やライン・プリンタ，他のデバイスに出力するときに， RMS はこれらのキャリッジ制御を解釈します。キャリッジ制御情報はデータ・レコードに格納されません。

デフォルト設定では，ファイルの前のバージョンが存在する場合，ファイルは RMS レコード・フォーマット，最大レコード・サイズ，レコード属性を前のバージョンから継承します。 OpenVMS システム・プログラマの場合，継承された属性は FAB$B_RFM，FAB$W_MRS，FAB$B_RAT と呼びます。前のバージョンが存在しない場合，新たに作成されたファイルのデフォルトはストリーム・フォーマットになり，レコードの終端はライン・フィード・レコード区切り文字および暗黙のキャリッジ・リターン属性で決定されます ( 本書では，この種のファイルをストリーム・ファイルと呼びます )。ストリーム・ファイルは， HP C RTL の標準 I/O および UNIX I/O 関数を使用して操作することができます。これらのファイルや，キャリッジ制御を含まない固定長レコード・ファイルを使用する場合， fseek関数や lseek関数を使用して，ファイルのランダムなバイトまでシークする機能に制限はありません。しかし，可変長レコード・フォーマットなど，ファイルに他の RMS レコード・フォーマットのいずれかが含まれる場合は， RMS の制限により，これらの関数はレコード境界までしかシークできません。他の VAX 言語やユーティリティで使用するファイルを作成またはアクセスしなければならない場合を除き，デフォルトの VAX ストリーム・フォーマットを使用してください。

前へ 次へ 目次 索引