HP OpenVMS Systems Documentation |
| 前へ | 次へ | 目次 | 索引 |
この章では,OpenVMS システムでのアプリケーション・プログラミングとシステム・プログラミングに関する注意事項について説明します。
5.1 プログラムの再コンパイルとリンクが必要 (I64 のみ)
V8.2
OpenVMS I64 Version 8.2 では,すべてのプログラムを再コンパイルしなければなりません。 OpenVMS I64 の以前の評価リリースや,フィールド・テスト・リリースでコンパイルおよびリンクしている場合でも,再コンパイルが必要です。 (弊社は,評価リリースに対して互換性のない変更を行う権利を有しています。) この OpenVMS I64 Version 8.2 の製品版リリースから,上位互換性を保つ弊社の通常の方針が適用されます。
Alpha プログラムの再コンパイルについては,
第 5.2 節 を参照してください。
5.2 特権プログラムの再コンパイルが必要 (Alpha のみ)
V8.2
メジャー・バージョン・リリースである OpenVMS Alpha Version 8.2 では,多くの特権データ構造体が変更されています。このため OpenVMS の内部データ構造体やルーチンを参照する /SYSEXE でリンクされた特権アプリケーションは,再コンパイルおよび再リンクを行う必要があります。
イメージの起動時やデバイス・ドライバのロード時に SYSVERDIF エラー・メッセージが出力された場合は,特権イメージや特権ドライバが,以前のバージョンのオペレーティング・システムでコンパイルおよびリンクされていることを示しています。このイメージやドライバを OpenVMS Alpha Version 8.2 で実行するためには,再コンパイルおよび再リンクが必要になります。
I64 プログラムの再コンパイルについては,
第 5.1 節 を参照してください。
5.3 特権データ構造体の変更
V8.2
OpenVMS Version 8.2 では,多数の特権データ構造体が変更されています。これらの変更は,Alpha システムと I64 システムの両方で実施されています。これらのデータ構造体の変更の大半は,オペレーティング・システムでの将来のスケーリングおよび性能強化の計画を実現するためのものです。この変更の結果,ベース・オペレーティング・システムに対してリンクされているイメージやドライバ (つまり,LINK コマンドで /SYSEXE を使用するもの) は, OpenVMS Version 8.2 で動作させるために再コンパイルと再リンクが必要となります。
特権データ構造体の変更は,すべての特権イメージやドライバに影響するとは限りません。変更されたサブシステムにリンクされているイメージやドライバだけが影響を受けます。変更されたサブシステムに関しては,サブシステムに対応するメジャー・バージョン識別番号が変更されています。変更されたサブシステムは,次のとおりです。
SYS$K_IO
SYS$K_MEMORY_MANAGEMENT
SYS$K_CLUSTERS_LOCKMGR
SYS$K_FILES_VOLUMES
SYS$K_CPU
SYS$K_MULTI_PROCESSING
SYS$K_PROCESS_SCHED
注意: I64 システムでは,これらのサブシシテムは SYS$K_VERSION_xxxx のように表示されます。
これらのサブシステムは,各種の特権システム・ルーチンおよびデータ・セルを使用しているイメージのリンク時に,そのサブシステムのバージョン番号がイメージに記録されています。 ANALYZE/IMAGE ユーティリティを使用すると,特権イメージがどの特権サブシステムにリンクされているかを調べることができます。例を次に示します。
$ ANALYZE/IMAGE IMAGE.EXE /OUTPUT=IMAGE.TXT $ SEARCH IMAGE.TXT "SYS$K_" |
変更されたサブシステムが表示された場合, OpenVMS Version 8.2 は,イメージの実行に失敗し,オペレーティング・システムの以前のバージョンにリンクされたイメージに対して SS$_SYSVERDIF (システム・バージョン不一致エラー) を出力します。
5.3.1 KPB 拡張
V8.2
OpenVMS の以前のバージョンでは, IPL 2 より上のカーネル・モードでの KPB の使用をサポートしていました。 I64 への移行を簡単にするために,KPB の使用が,アウター・モードとすべての IPL に拡張されました。この Alpha と I64 での変更により,Alpha と I64 の両方で,以前はプライベート・スレッド・パッケージを持っていた一部のコードが, KPB を使用できるようになりました。カーネル・プロセスでのこれらの変更をサポートするために, KPB 構造体に変更を行う必要がありました。既存の Alpha コードでは,ソース・プログラムを変更する必要はありません。
5.3.2 CPU の名前空間
V8.2
OpenVMS には現在,最大の CPU ID が 31 であるという,アーキテクチャ上の制限があります。各種の内部データ構造体およびデータ・セルでは, CPU マスクに 32 ビットを割り当てています。将来のリリースでより多くの CPU ID をサポートできるように,これらのマスクに割り当てられるスペースを,Alpha では 64 ビット, I64 では 1024 ビットに増やしました。既存のロングワードの CPU マスクのシンボルおよびデータ・セルは,今後も維持されます。
当面は,特権イメージおよびドライバには影響はありません。ただし,将来的には,CPU マスクを参照する特権付き製品が, 31 個より多くの CPU ID を持つシステムをサポートするために,コードをどのように変更しなければならないかを明記する予定です。
5.3.3 64 ビットの論理ブロック番号 (LBN)
V8.2
OpenVMS はこれまで 31 ビットの LBN をサポートしています。このため,ディスク・ボリュームのサポートが 1 TB に制限されます。内部の LBN フィールドに割り当てられるスペースが 64 ビットに拡張されており,より大きなディスク・ボリュームを将来サポートできるようになります。既存のロングワードの LBN シンボルは今後も維持され,クォドワード・シンボルでオーバレイされます。
5.3.4 動的スピンロックのフォーク
V8.2
OpenVMS オペレーティング・システムを大規模な SMP システムへ拡張するために,オペレーティング・システム内の多くの部分で,限られた数の静的スピンロックではなく,動的スピンロックを使用するようになっています。フォークする機能と,フォーク・ディスパッチャが動的ピンロックと同期をとる機能が必要とされます。 FKB 構造体のサイズを拡張し, FKB$L_SPINLOCK フィールドをこの構造体の最後に追加することによって,この機能を OpenVMS Version 8.2 に追加しています。このスピンロック・フィールドは, FKB$B_FLCK に値 SPL$C_DYNAMIC が設定されている場合にのみ参照されます。 FKB 構造体は,他の多くのシステム・データ構造体に埋め込まれているため,この変更は,多数の特権データ構造体のサイズとレイアウトに影響します。
FKB$B_FLCK フィールドを, OpenVMS が作成した構造体から他の FKB へコピーするアプリケーションは, FKB$L_SPINLOCK フィールド内のデータもコピーする必要があります。
FKB 構造体を割り当て,ハードコード化された値 32 をサイズとして使用していないか,特権コードをチェックしてください。コードでは,FKB のサイズとして,シンボル FKB$C_LENGTH を使用しなければなりません。
5.3.5 UCB と DDB のアップデート
V8.2
UCB 構造体と DDB 構造体には,多数のアップデートが行われました。
DDB に対応する UCB のリストは,現在は単方向リストです。 UCB を作成したり削除する場合は,適切な位置が見つかるまで,このリストをたどらなければなりません。 OpenVMS Version 8.2 では, UCB は双方向リストで DDB にリンクされるようになりました。さらに DDB は,新しいユニットを作成するときに検索を開始する位置を示すシード・ポインタを維持しており,デバイスの作成が速くなります。テンプレート UCB 内でユニット・シード・ポインタを操作しているドライバには,デバイスの作成が速くなるという利点はありません。
DDB の UCB リストを操作するコードは,正しく動作しなくなります。 UCB のリンクとリンク解除には,提供されている内部ルーチンを使用してください。 UCB リストを前方にたどるコードは,引き続き正しく動作します。
UCB$W_UNIT フィールドは現在,16 ビット・ワード・フィールドです。このフィールドには,32 ビットが割り当てられるようになりました。 UCB$W_UNIT フィールドは引き続き維持されるため,ソース・コードの変更は必要ありません。今後のリリースでは, OpenVMS はより大きいユニット番号をサポートする可能性があります。この機能をサポートできるドライバに対してだけ,この変更が行われる予定です。
ターミナル・ドライバの UCB 拡張内のバイト・フィールドとワード・フィールドは,ロングワード境界に揃えられるようになりました。
5.3.6 PCB$T_TERMINAL のサイズの拡張
V8.2
Process Control Block (PCB) 構造体には, PCB$T_TERMINAL というフィールドが含まれています。このフィールドは 8 バイトで,会話型プロセスのデバイス名 (LTA123:,RTA7:,NVA456: など) を保持します。このフィールドは,文字数付きの ASCII 文字列で, 1 バイト目が文字列の長さ,残りの 7 バイトがデバイス名です。デバイス名が 3 文字の場合,ユニット番号には 4 桁しか使用できないため, 999 より大きいユニット番号ではコロンは取り除かれます。 OpenVMS Version 8.2 では,このフィールドは 16 バイトに拡張されたため,より大きなユニット番号のデバイス名を保持できるようになりました。
JPI$_TERMINAL 項目コードを指定して $GETJPI を呼び出してこのフィールドをフェッチする場合,特に影響はありません。ただし,システム・サービスに渡すバッファを,最大 16 バイト保持できるように拡張しても構いません。
5.3.7 スレッド単位のセキュリティは特権付きコードとデバイス・ドライバに影響する
V7.3-1
セキュリティ・プロファイルを I/O Request packet (IRP) に添付するために使用する方法が,Version 7.2 で変更されました。
Version 7.2 より前のバージョンの OpenVMS では,IRP 構造体には,要求者のプロセス単位の Access Rights Block (ARB) セキュリティ構造体のアドレスが含まれていました。 OpenVMS Alpha Version 7.2 以降,新しいセキュリティ・プロファイル構造体 (Persona Security Block (PSB)) のアドレスが, ARB アドレスの機能置換として,IRP に追加されました。
I/O サブシステムは PSB へのアクセスを, PSB 内のリファレンス・カウンタを通して管理します。 I/O サブシステムは,このリファレンス・カウンタを, IRP の作成時にカウントアップし,IRP の I/O 後処理時にカウントダウンします。このカウンタが 0 になったとき,PSB 構造体は割り当て解除されます。
1 つの要求に対して複数の I/O 操作を行うために IRP のコピーを作成またはクローン化して,コピーした IRP を後処理のために I/O サブシステムに渡すデバイス・ドライバは,コードを変更して,追加した IRP 内の PSB への余分な参照に対処しなければなりません。この処理は,コピーされた IRP 内の PSB アドレスを, NSA_STD$REFERENCE_PSB ルーチンに渡すことで行います。インクルード・ファイルと,NSA_STD$REFERENCE_PSB の呼び出しは,次のとおりです。
#include <security-macros.h> /* Increment REFCNT of PSB that is now shared by both IRPs */ nsa_std$reference_psb( irp->irp$ar_psb ); |
デバイス・ドライバは,次の状況でこの変更を行わなければなりません。
デバイス・ドライバは IRP を複製した後,I/O 後処理のためにキューに登録する前に, NSA_STD$REFERENCE_PSB を呼び出さなければなりません。
デバイス・ドライバは IRP を複製した後,I/O 後処理のためにキューに登録する前に,NSA_STD$REFERENCE_PSB を呼び出さなければなりません。
これらのステップを実行するデバイス・ドライバは,たいていはプロシージャ記述子のアドレスを IRP$L_PID に格納しています。したがって, IRP を複製するほとんどのデバイス・ドライバは,ソース・コードの変更,再リンク,再コンパイルを行わなくても, OpenVMS Version 7.2 以降で正しく機能するはずです。
この状態で NSA_STD$REFERENCE_PSB を呼び出さないと, PSB 内のトラッキング情報が壊れ,システム障害となることがあります。
NSA_STD$REFERENCE_PSB を呼び出すようにデバイス・ドライバのコードを変更する場合は, OpenVMS Version 7.2 またはそれ以降で動作するように,ドライバを再コンパイルおよび再リンクしなければなりません。
5.3.8 OpenVMS フォーク・スレッド作成のための IPL 要件の強制
V7.3-1
OpenVMS フォーク実行スレッドを作成するためには,いくつかのルーチンを特権コードで使用します。これらのルーチンは,プロセスとは独立にシステム・コンテキストで実行されます。これらのルーチンには 4 つの形式があり,どの形式を使用するかは,直系のフォークとキューに入れられるフォークのどちらが必要かと,使用している言語インタフェースで決まります。
これらのルーチンは,実行中に,誤って別の CPU に再スケジュールされないようにするため, IPL$_RESCHED 以上で呼び出す必要があります。このような再スケジュールが行われると,システムがハングする可能性があります。
OpenVMS V7.3-1 では,SYSTEM_CHECK の値を 1 にすると,これらのルーチンによって,まずシステムの IPL がチェックされます。 IPL が IPL$_RESCHED の値よりも小さい場合,システムは SPLINVIPL バグ・チェックで失敗します。
性能上の理由から,SYSTEM_CHECK の値を 0 にすると (デフォルト), IPL は検証されません。不正なコードを使用すると,プロセス・コンテキストでこれらのルーチンの実行中に別の CPU への再スケジュールが発生したときに (IPL$_RESCHED よりも小さい値を指定した場合など),システムがハングする可能性があります。
5.4 浮動小数点型データを使用するアプリケーション
V8.2
Itanium® アーキテクチャでは, IEEE 単精度および IEEE 倍精度を含む,IEEE 浮動小数点形式を用いた,ハードウェアによる浮動小数点演算を実装しています。
Alpha ハードウェアでは, IEEE 浮動小数点形式と VAX 浮動小数点形式のいずれもサポートしています。 OpenVMS Alpha では,コンパイラはデフォルトで VAX 形式のコードを生成し,オプションで IEEE 形式のコードを生成します。
OpenVMS I64 では,コンパイラはデフォルトで IEEE 形式のコードを生成し,オプションで VAX 形式のコードを生成します。 Integrity サーバでは, VAX や Alpha システムで生成された VAX 形式の浮動小数バイナリ・データをアプリケーションで取り扱う必要がある場合を除き, IEEE 形式を使用することをお勧めします。 OpenVMS I64 で VAX 形式を使用する場合の詳細については,次の Web サイトのホワイト・ペーパ『Intel® Itanium® における OpenVMS 浮動小数点演算について』を参照してください。
http://h50146.www5.hp.com/products/software/oe/openvms/technical/
OpenVMS Version 8.2 では,IEEE 浮動小数点型データを扱うアプリケーション用に,新たに IEEE 浮動小数点型対応版の LIB$ と OTS$ のランタイム・ライブラリ・ルーチンを用意しました。システム提供のヘッダ・ファイルには,これらの新しい関数の関数プロトタイプ定義が含まれていません。これらの関数を使用するには,アプリケーションで関数プロトタイプを定義する必要があります。これらの関数の説明は, LIB$ と OTS$ のランタイム・ライブラリ・リファレンス・マニュアルを参照してください。これらの関数プロトタイプ定義は,今後リリースされるシステム提供のヘッダ・ファイルに含まれる予定です。
5.5 Ada コンパイラはまだ利用できない (I64 のみ)
V8.2
Ada コンパイラは,OpenVMS Alpha Version 8.2 でサポートされます。弊社では,HP Ada 83 コンパイラを Alpha から I64 に移植する作業は行っていませんが, AdaCore 社で Ada 95 コンパイラを OpenVMS I64 にポーティング中です。この製品が利用可能になる時期については,直接 AdaCore 社にお問い合わせください。
5.6 Backup API: ジャーナリング・コールバック・イベントの制限事項
アプリケーションがジャーナリング・イベントのいずれかに対してコールバック・ルーチンを登録する場合は,すべてのジャーナリング・コールバック・イベントに対してコールバック・ルーチンを登録しなければなりません。ジャーナリング・コールバック・イベントは次のとおりです。
BCK_EVENT_K_JOURNAL_OPEN
BCK_EVENT_K_JOURNAL_WRITE
BCK_EVENT_K_JOURNAL_CLOSE
コールバック・ルーチンの登録の詳細については,『OpenVMS Utility Routines Manual』の Backup API に関する章を参照してください。
5.7 C プログラム: CASE_LOOKUP=SENSITIVE を設定したコンパイル
永続的な制限事項
特性として CASE_LOOKUP=CASE=SENSITIVE が設定されているプロセスで C プログラムをコンパイルすると, .h ファイル・タイプ (小文字の「h」) で指定された C プログラム内の #include ファイルは,検出および実行されません。また,システムの #include ファイルが他の .h ファイル・タイプの #include ファイルを使用している場合,この #include ファイルは検出されず,エラーが出力されます。
この動作を防ぐには,大文字と小文字を区別しないように設定します。 case=sensitiveを設定する必要がある場合は, C プログラム内の #include ファイルにファイル・タイプを指定しないか ( 例 #include <stdio>),または大文字の H ファイル・タイプを指定してください ( 例 #include <stdio.H>)。
ただし,stdlib.h などのシステム #include ファイルが .h ファイル・タイプの #include ファイルを使用している場合は,エラーとなるので注意してください。
5.8 C ランタイム・ライブラリ
ここでは,C ランタイム・ライブラリ (RTL) の変更や修正について説明します。
5.8.1 socket_fd を使用するプログラムでのメモリ・リークの修正
V8.2
socket_fdを使用するプログラムでメモリ・リークが発生し,ページ・ファイル・クォータを消費してしまう場合がありました。この問題は解決されました。
5.8.2 vsnprintf と snprintf によるユーザ・バッファの上書きの修正
V8.2
vsnprintf関数と snprintf関数は,ユーザ・バッファ内で許されている最大数を超えて,メモリを上書きすることがありました。
たとえば,次の snprintfの呼び出しは,指定された書式付き文字列を使用し,ユーザ・バッファ tで許されている t[2]を超えて,上書きを行っていました。
snprintf(t, 3, "%2sxxxx", "a"); |
この問題は解決されました。
5.8.3 mmap と mprotect の変更
V8.2
以前は,OpenVMS Versions 7.3-1 および 7.3-2 用の C RTL を変更すると, mprotect関数用のメモリがすでに mmapでマッピング済みでないと,エラーが返されていました。
この問題は,従来の動作に戻したことで解決されました。再び,
mmapでマッピングされていないメモリに対して,
mprotectでプロテクションを設定できるようになりました。
5.8.4 getpwnam_r と getpwuid_r のポインタの問題の修正
V8.2
getpwuid_rのショート・ポインタ版 ( _getpwuid_r32) を呼び出すプログラムが,第 3 引数の (buffer) に対して,誤ってロング・ポインタ値を渡すことがありました。
このユーザ指定のバッファは,結果として出力される passwd構造体のメンバ (32 ビット・ポインタ) に割り当てられていました。このことにより,バッファがハイ・メモリにある場合は,これらのメンバ ( pw_name, pw_dir,および pw_shell) が,誤った結果になっていました。
この問題は, getpwnam_r( _getpwnam_r32) のショート・ポインタ版でも発生します。
この問題は修正されました。
_getpwnam_r32と
_getpwuid_r32のプロトタイプが変更され, buffer 引数に対して 64 ビット・ポインタを認めず, 32 ビット・ポインタだけを受け付けるようになりました。
5.8.5 _strtok_r32 と _strtok_r64 がスコープ内になった
V8.2
<string.h>をインクルードし,
_strtok_r32または
_strtok_r64を呼び出していたプログラムは,スコープ内でプロトタイプを見つけることができませんでした。この問題は修正されました。
5.8.6 iconv プロトタイプの,const 型修飾子の追加 (Alpha のみ)
V8.2
XOPEN_SOURCE 機能テスト・マクロに 500 が定義されている場合 (#DEFINE XOPEN_SOURCE 500), X/Open 標準に準拠するために, <iconv.h>内の iconv関数プロトタイプの第 2 引数に, const修飾子が追加されます。
size_t iconv (iconv_t cd, const char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);
|
5.8.7 <stddef.h> ヘッダの修正 (Alpha のみ)
V8.2
C++ コンパイラは offsetofマクロの結果を,整数定数式としては認識していなかったため,このような使い方をすると,C++ コンパイラでエラーとなっていました。
この問題は修正されました。 <stddef.h>ヘッダ・ファイルが変更され, offsetofマクロの代わりの定義が, C++ Version 6.5 およびそれ以降で使用するために用意されました。
この代替の定義は,EDG 拡張 (__INTADDR__) を使用して,この拡張がなければ非標準の変換である,ポインタから整数への変換を実行します。この解決方法は,EDG が用意して推奨していたもので,害のない名前を使用すること以外は,同じです。
5.8.8 getc マクロの引数が括弧で保護されるようになった (Alpha のみ)
V8.2
ISO C 標準 (ISO/IEC 9899) に準拠するように,
getcマクロの引数が,括弧で保護されるようになりました。
5.8.9 インライン関数 getc および getchar の CXXL 接頭辞の問題の修正 (Alpha のみ)
V8.2
C++ で getcと getcharをコンパイルすると,リンク時に未定義シンボルの警告が出ていました。特定の状況で, getcマクロ (C の場合) やインライン関数 (C++ の場合) は,実際の関数 decc$getcを呼び出していました。インライン関数 getcが,実際の関数 decc$getcの宣言を, extern_prefix "CXXL$" 下で行っていたことが問題でした。同様の問題が, getcharでも発生します。
この問題は修正されました。
<stdio.h>ヘッダ・ファイルが修正され,インライン実装の定義が CXXL$ 接頭辞のスコープ外に残されたまま,
getcと
getcharのプロトタイプが,
#pragma__extern_prefix "CXXL$"ディレクティブのスコープ内に用意されました。
5.8.10 std 名前空間での非 std 関数の宣言 (Alpha のみ)
V8.2
v*scanfや *snprintf関数を参照するソース・ファイルを C++ でコンパイルすると, %CXX-E-UNDECLARED エラーになっていました。これは, <stdio.h>ヘッダ・ファイルがこれらの関数を std名前空間で宣言し,グローバル名前空間には入れていなかったためです。
この問題は修正されました。これらの関数宣言は,
std名前空間外の位置に移動されました。
5.8.11 大きなファイル・オフセットでの lseek の問題の修正 (Alpha のみ)
V8.2
lseek関数は, ULONG_MAX (4294967295) バイトよりも大きいオフセットのファイル位置を正しく指すことができませんでした (_LARGEFILE 機能制御マクロ下)。たとえば,
lseekを 6 GB (16 メガブロック) のファイルで呼び出し,オフセットを 0x100000000 と指定すると,ファイル・ポジションは 0 になっていました。この問題は修正されました。
5.8.12 <errno.h> 内の新しい EABANDONED コード
V8.2
<errno.h>ヘッダ・ファイルに,新しい errnoコードとして EABANDONED が追加されました。
Pthreads 関数は,ターゲットのプロセス共有タイプの mutex が,すでに終了しているプロセスによってロックされている (つまり,権利を持つ所有者が mutex を開放できない状態であるため mutex が「放棄」された)とシステムで判断した場合, EABANDONED (「所有者がリソースを解放できない」) コードを返すことができるようになりました。
5.8.13 mktime の問題の修正
V8.2
UTC ベースの関数
mktimeは,構造体のメンバ
tm_mdayの値が 0 または負のときに日付を算出できませんでした。また,
mktimeは,矛盾した日付を生成することがありました。この問題が修正されています。
5.8.14 <poll.h> 内の POLLWRNORM が POLLOUT と等価になった
V8.2
<poll.h>ヘッダ・ファイルに関する X/Open のドキュメントによれば,POLLWRNORM は POLLOUT と等価でなくてはなりません。これまでは,等価ではありませんでしたが,等価になりました。
5.8.15 <in6.h> 内の IPV6 構造体がパック形式になった
V8.2
<in6.h>ヘッダ・ファイル内の IPV6 構造体
sockaddr_in6は,パック形式ではなかったため,パック形式であると想定してアプリケーションがサイズのチェックをすると問題が発生していました。メンバが自然な境界にアラインされているため,この構造体はパック形式である必要がありました。この問題は修正されました。
5.8.16 <builtins.h> 内の __PAL_BUGCHK の問題の修正
V8.2
C または C++ コンパイラを使用するときに, __PAL_BUGCHK をパラメータ付きで呼び出すと致命的なエラーになっていました。また,組み込み関数に付いている実装についてのコメントの多くが,誤解を招きやすいものでした。この点が修正されました。
5.8.17 C++ コンパイラの statvfs に関するエラーの修正
V8.2
C,C++ コンパイラ,または X/Open 標準 (XPG6) で型修飾子 restrictをサポートしている場合, <decc$types.h>および <statvfs.h>ヘッダ・ファイルにこの型修飾子が追加されます。
これにより,次の問題が解決されます。
int statvfs(const char * __restrict path, struct statvfs * __restrictbuf); ....................................^ %CXX-E-EXPRPAREN, expected a ")" |
V8.2
以下の globおよび globfreeに関する問題が修正されました。
5.8.19 DECC$SHR_EV56 が正しくリンクされた
V8.2
OpenVMS Version 7.3-2 では, DECC$SHR_EV56.EXE イメージが正しく最適化されていませんでした。
C RTL は 2 セットのオブジェクトからビルドされていました。 1 つは通常どおりにコンパイルされ,もう 1 つは Alpha EV56 プロセッサ用に最適化されていました。 DECC$SHR_EV56.EXE イメージは,最適化されたオブジェクトでリンクされていませんでした。この問題は修正されました。
5.8.20 Zone Information Compiler (zic) のアップデート
V8.2
新しい時刻インジケータが,Rule 行の AT フィールド用に追加されました。
英字 "u" (または "g","z") は, AT フィールド内の時刻が UTC であることを示します。
zicについての詳細は,『HP C ランタイム・ライブラリ・リファレンス・マニュアル』を参照してください。
| 前へ | 次へ | 目次 | 索引 |