日本-日本語

製品  >  ソフトウェア  >  OpenVMS  >  マニュアル

OpenVMS マニュアル


≫ 

OpenVMS V8.3
ライブラリ

タイトルページ
目次
まえがき
第 1 章:インストールに関する注意事項
第 2 章:関連製品に関する注意事項
第 3 章:一般ユーザ向けの注意事項
第 4 章:システム管理に関する注意事項
第 5 章:プログラミングに関する注意事項
第 6 章:ハードウェアに関する注意事項
付録 A:リタイア製品情報
付録 B:インターロックされたメモリ命令の使用
索引
PDF
OpenVMS ホーム

HP OpenVMS
V8.3 リリース・ノート【翻訳版】


目次 索引

第 5 章
プログラミングに関する注意事項

この章では,OpenVMS システムでのアプリケーション・プログラミングとシステム・プログラミングに関する注意事項について説明します。

5.1 システム・サービスの変更点

V8.3

ここでは,本リリースにおけるシステム・サービスの変更点について説明します。

5.1.1 追加

以下のシステム・サービスに対して追加と変更が行われています。

  • $GETJPI--アイテム・コード JPI$_TERMINAL および JPI$_SCHED_CLASS_NAME

  • $GETRMI--説明を次のように変更。「$GETRMI は,非同期システム・サービスであり,要求した情報が利用可能であることを保証するためには, $SYNCH サービスまたは他の待ち状態同期メカニズムを使用する必要があります。このシステム・サービスの同期待ち形式はありません。」

  • $GETRMI のアイテム・コードを次のように変更。「RMI$_MODES は,システムがブートされてから,現在アクティブな CPU が各プロセッサ・モードで消費した時間の量を 10 ms 単位で返します。あるモードに対して返される時間の値は,そのモードで CPU を費やした時間 (10 ms 単位) を表します。アクティブな CPU とは,OpenVMS インスタンスが実行するプロセッサのスケジューリングに参加している CPU のことです。詳細については,『OpenVMS System Services Reference Manual』の $GETRMI システム・サービスを参照してください。」

  • $GETSYI-- Intel Itanium 2 および Intel Itanium 3 用のプロセッサ・コードを追加

  • $GETSYI-- 以下のアイテム・コードの定義を変更
    SYI$_ACTIVE_CPU_MASK
    SYI$_CPUCONF
    SYI$_IO_PREFER_CPU
    SYI$_POTENTIAL_CPU_MASK
    SYI$_POWERED_CPU_MASK
    SYI$_PRESENT_CPU_MASK

  • $INIT_VOL: いくつかのアイテム・コードを,ODS-2 だけでなく ODS-5 にも適用



5.2 システム・サービス $GETQUI および $SNDJBC のジョブ・リミット・アイテム・コードの範囲の拡大

V8.3

お客様からの要求に応え,バッチ環境の定義を簡単にするために, OpenVMS Version 8.3 では, 2 つのシステム・サービスのジョブ・リミット・アイテム・コードが拡大されました。

  • $GETQUI システム・サービスでは, QUI$_JOB_LIMIT アイテム・コードの範囲が 1 〜 65535 になりました。

  • $SNDJBC システム・サービスでは, SJC$_JOB_LIMIT アイテム・コードの範囲が 1 〜 65535 になりました。



5.3 特権プログラムの再コンパイルが必要 (Alpha のみ)

V8.2

メジャー・バージョン・リリースである OpenVMS Alpha Version 8.2 では,多くの特権データ構造体が変更されています。このため OpenVMS の内部データ構造体やルーチンを参照する /SYSEXE でリンクされた特権アプリケーションは,再コンパイルおよび再リンクを行う必要があります。

イメージの起動時やデバイス・ドライバのロード時に SYSVERDIF エラー・メッセージが出力された場合は,特権イメージや特権ドライバが,以前のバージョンのオペレーティング・システムでコンパイルおよびリンクされていることを示しています。このイメージやドライバを OpenVMS Alpha Version 8.2 で実行するためには,再コンパイルおよび再リンクが必要になります。

5.4 特権データ構造体の変更

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.4.1 KPB 拡張

V8.2

OpenVMS の以前のバージョンでは, IPL 2 より上のカーネル・モードでの KPB の使用をサポートしていました。 I64 への移行を簡単にするために,KPB の使用が,アウター・モードとすべての IPL に拡張されました。この Alpha と I64 での変更により,Alpha と I64 の両方で,以前はプライベート・スレッド・パッケージを持っていた一部のコードが, KPB を使用できるようになりました。カーネル・プロセスでのこれらの変更をサポートするために, KPB 構造体に変更を行う必要がありました。既存の Alpha コードでは,ソース・プログラムを変更する必要はありません。

5.4.2 CPU の名前空間

V8.2

OpenVMS には現在,最大の CPU ID が 31 であるという,アーキテクチャ上の制限があります。各種の内部データ構造体およびデータ・セルでは, CPU マスクに 32 ビットを割り当てています。将来のリリースでより多くの CPU ID をサポートできるように,これらのマスクに割り当てられるスペースを,Alpha では 64 ビット, I64 では 1024 ビットに増やしました。既存のロングワードの CPU マスクのシンボルおよびデータ・セルは,今後も維持されます。

当面は,特権イメージおよびドライバには影響はありません。ただし,将来的には,CPU マスクを参照する特権付き製品が, 31 個より多くの CPU ID を持つシステムをサポートするために,コードをどのように変更しなければならないかを明記する予定です。

5.4.3 64 ビットの論理ブロック番号 (LBN)

V8.2

OpenVMS はこれまで 31 ビットの LBN をサポートしています。このため,ディスク・ボリュームのサポートが 1 TB に制限されます。内部の LBN フィールドに割り当てられるスペースが 64 ビットに拡張されており,より大きなディスク・ボリュームを将来サポートできるようになります。既存のロングワードの LBN シンボルは今後も維持され,クォドワード・シンボルでオーバレイされます。

5.4.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.4.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.4.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.4.7 スレッド単位のセキュリティは特権付きコードとデバイス・ドライバに影響する

永続的な変更

セキュリティ・プロファイルを 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 ); 

デバイス・ドライバは,次の状況でこの変更を行わなければなりません。

  • デバイス・ドライバが次の状態の場合

    1. デバイス・ドライバが,既存の IRP を複製することで新しい IRP を作成する場合,かつ

    2. IOC_STD$SIMREQCOM または IOC_STD$DIRPOST1 を呼び出すことで,I/O 後処理のためにオリジナル IRP と複製 IRP の両方をキューに登録する場合


    デバイス・ドライバは IRP を複製した後,I/O 後処理のためにキューに登録する前に, NSA_STD$REFERENCE_PSB を呼び出さなければなりません。

  • デバイス・ドライバが次の状態の場合

    1. デバイス・ドライバが,既存の IRP を複製することで新しい IRP を作成する場合,かつ

    2. コピーまたはオリジナル IRP の IRP$L_PID セルにプロシージャ記述子のアドレスを格納しない場合,かつ

    3. IOC_STD$REQCOM,COM_STD$POST,COM_STD$POST_NOCNT,IOC_STD$POST_IRP を呼び出すことで,I/O 後処理のためにオリジナル IRP と複製 IRP の両方をキューに登録する場合


    デバイス・ドライバは 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 またはそれ以降で動作するように,ドライバを再コンパイルおよび再リンクしなければなりません。

OpenVMS フォーク実行スレッドを作成するためには,いくつかのルーチンを特権コードで使用します。これらのルーチンは,プロセスとは独立にシステム・コンテキストで実行されます。これらのルーチンには 4 つの形式があり,どの形式を使用するかは,直系のフォークとキューに入れられるフォークのどちらが必要かと,使用している言語インタフェースで決まります。

  • EXE$QUEUE_FORK

  • EXE_STD$QUEUE_FORK

  • EXE$PRIMITIVE_FORK

  • EXE_STD$PRIMITIVE_FORK

これらのルーチンは,実行中に,誤って別の CPU に再スケジュールされないようにするため, IPL$_RESCHED 以上で呼び出す必要があります。このような再スケジュールが行われると,システムがハングする可能性があります。

OpenVMS V7.3-1 では,SYSTEM_CHECK の値を 1 にすると,これらのルーチンによって,まずシステムの IPL がチェックされます。 IPL が IPL$_RESCHED の値よりも小さい場合,システムは SPLINVIPL バグ・チェックで失敗します。

性能上の理由から,SYSTEM_CHECK の値を 0 にすると (デフォルト), IPL は検証されません。不正なコードを使用すると,プロセス・コンテキストでこれらのルーチンの実行中に別の CPU への再スケジュールが発生したときに (IPL$_RESCHED よりも小さい値を指定した場合など),システムがハングする可能性があります。

5.5 浮動小数点型データを使用するアプリケーション

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.hpe.com/products/software/oe/openvms/technical/



V8.3

浮動小数点例外が IEEE-Std 754-1985 に完全に準拠するように, Intel では,IEEE フィルタと呼ばれる関数を提供しています。この関数を使用したいアプリケーション開発者は,通常の OpenVMS 例外ハンドラの中からこの関数を呼び出すことができます。例外が発生すると,このフィルタが,例外の原因となった浮動小数点命令, IEEE の丸めモードと精度をデコードし,例外の原因となったオペランドを特定することができます。

このフィルタのコピーを入手するには,以下の Intel の Web サイトにアクセスし, OpenVMS の見出しを探してください。

http://www.intel.com/cd/software/products/asmo-na/eng/219748.htm

このサイトにあるアプリケーション・ノートでは,フィルタについて詳細に説明しています。ソース・コード例とフィルタのオブジェクト・ライブラリは, OpenVMS のバックアップ・セーブ・セットとして提供されています。

このフィルタは,浮動小数点例外の詳細を IEEE 規格に準拠させるためにのみ必要です。通常の浮動小数点演算には必要ありません。

5.5.2 Ctrl/C と STOP ボタンを使用する場合の制限 (OpenVMS Alpha)

V8.3

問題: デバッガの制御下で実行されているプログラムでは, Ctrl/C による割り込みは 1 回しか動作しません。以後は,Ctrl/C による割り込みは無視されます。 DECwindows の STOP ボタンも同様です。最初にこのボタンを押したときだけその動作が認識されます。

回避策: なし。

5.5.3 Ada イベントのサポート (I64 のみ)

V8.3

Ada イベントのサポート (SET BREAK/EVENT=ada_event。ただし, ada_event は SHOW EVENT で説明されるイベントのいずれか) が,OpenVMS I64 で有効になりました。ただし,このサポートは不完全です。

イベント・ブレークポイントで問題が発生した場合は,回避策として, pthread イベント (SET EVENT_FACILITY pthread) に切り替えてください。すべての Ada イベントに同等の pthread 機能があるわけではありません。

5.5.4 SHOW SYMBOL/TYPE がアレイ・サイズを正しく報告するようになった (Alpha および I64)

V8.3

SHOW SYMBOL コマンドは,アレイ・タイプの全体サイズを正しく報告するようになりました。以前の SHOW SYMBOL/TYPE の動作では,次のように,誤ったサイズが報告されていました。例を次に示します。


DBG> sho sym/type z 
data MATINV\Z 
    noncontiguous array descriptor type, 2 dimensions, bounds: [0:10,0:10], size: 4 bytes 
        cell type: atomic type, IEEE single precision floating point, size: 4 bytes 
DBG> 

正しい動作は,次のとおりです。


DBG> sho symbol/type z 
data MATINV\MATINV\Z 
    noncontiguous array descriptor type, 2 dimensions, bounds: [0:10,0:10], size: 484 bytes 
        cell type: atomic type, IEEE single precision floating point, size: 4 bytes 
DBG> 



5.5.5 EXAMINE/INSTRUCTION %PREVLOC コマンドが修正された (I64 のみ)

V8.3

EXAMINE/INSTRUCTION %PREVLOC コマンド (および代替の EXAMINE/INSTRUCTION ^ コマンド) は,期待したとおりに動作するようになりました。以前はデバッガが PC をデクリメントしなかったため,同じ命令が表示されていました。

5.5.6 SHOW MODULE コマンドがモジュール・サイズを計算するようになった (I64 のみ)

V8.3

SHOW MODULE コマンドは,モジュールのサイズとしてゼロでない値を報告するようになりました。この値は推定値なので,モジュールの相対サイズを比較する際のめやすとしてだけ使用してください。

5.5.7 C++ 言語の問題 (I64 のみ)

V8.2

問題: SHOW CALLS コマンドは,C++ のデマングル化された名前ではなく,C++ のマングル化された名前を表示することがあります。

回避策: なし。

V8.3

問題: デバッガは,/OPTIMIZE でコンパイルされた C++ プログラムのデバッグをサポートしていません。

回避策: C++ プログラムを /NOOPTIMIZE でコンパイルしてください。

5.6 Ada コンパイラ (I64 のみ)

V8.2

GNAT Pro (Ada 95) は,AdaCore から入手できます。詳細は, www.adacore.com または sales@adacore.com の AdaCore にお問い合わせください。

5.7 Backup API: ジャーナリング・コールバック・イベントの制限事項

永続的な制限事項

アプリケーションがジャーナリング・イベントのいずれかに対してコールバック・ルーチンを登録する場合は,すべてのジャーナリング・コールバック・イベントに対してコールバック・ルーチンを登録しなければなりません。ジャーナリング・コールバック・イベントは次のとおりです。

BCK_EVENT_K_JOURNAL_OPEN
BCK_EVENT_K_JOURNAL_WRITE
BCK_EVENT_K_JOURNAL_CLOSE

コールバック・ルーチンの登録の詳細については,『HP OpenVMS Utility Routines Manual』の Backup API に関する章を参照してください。

5.8 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 などのシステム・インクルード・ファイルが,その中から .h ファイル・タイプのインクルード・ファイルを使用している場合は,エラーを回避できませんので注意してください。

5.9 C ランタイム・ライブラリ

ここでは,C ランタイム・ライブラリ (RTL) の変更や修正について説明します。

5.9.1 C RTL TCP/IP ヘッダ・ファイルのアップデート

V8.3

C RTL では, TCP/IP を呼び出すユーザ向けのヘッダ・ファイルを出荷しています。これらのヘッダには多くの問題があるため,簡易 TCP/IP プログラミングの域を越えて使用できないものがあります。

以前のいくつかの TCP/IP リリースでは,訂正済みのヘッダがプログラミング例と同じ場所で提供されていました。 OpenVMS Version 8.3では,訂正済みのヘッダが, C RTL のヘッダ・ライブラリ (DECC$RTLDEF.TLB) に置かれています。

このファイルへの変更の例としては,以下のものがあります。

  • メンバのアラインメントが訂正されました。この訂正により,ヘッダに定義されている構造体が,必要とされているパック化されたアラインメントに戻されました。

  • 一部の定数マクロ定義が, TCP/IP の構築で使用される定数と正しく一致するように変更されました。

  • SOCKET.H では, MSG_DONTWAIT と MSG_DONTROUTE の値が正しくなるように入れ替えられました。この問題を回避するようにコーディングしていたユーザは,この変更によるハングアップを避けるために,変更を行わなければならないことがあります。

  • 古いプログラムはデータを TCP/IP に正しく渡していなかったため,以前は,古いヘッダでコンパイルされた古いプログラムとの互換性はありませんでした。ユーザが TCP/IP と通信できるように,データ構造体が変更されました。これらの変更を行わなければ,このヘッダ・ファイルは使用できませんでした。ユーザは,新しい定義を利用するために再コンパイルを行う必要があります。

  • 製品が準拠している TCP/IP の標準で,ヘッダ・ファイルの変更が必要でした。

  • TCP/IP の新しい機能に合わせて,新しい型,マクロ,およびヘッダ・ファイルが追加されました。
    以下の C RTL ヘッダ・ファイルが変更されました。


    BITYPES.H    IN.H        NAMESER_COMPAT.H   RESOLV.H 
    IF.H         IN6.H       NETDB.H            SOCKET.H 
    IF_ARP.H     INET.H      PCAP-BPF.H         STROPTS.H 
    IF_TYPES.H   NAMESER.H   PCAP.H             TCP.H 
    



5.9.2 toascii 関数の追加

V8.3

X/Open 仕様で必要とされている toascii関数は, <ctypes.h>内でマクロとして定義されているだけでした。

本リリースでは, toascii関数のエントリ・ポイントが DECC$SHR イメージに追加されています。

5.9.3 64 ビットの sigaction の問題の修正

V8.3

sigaction関数に対して 64 ビット・ポインタを使用すると,コンパイル時に警告が出力されていました。

この修正により,通常のコンパイル, long ポインタのコンパイル (/POINTER=LONG),および short ポインタのコンパイル (/POINT=SHORT) が可能になりました。

5.9.4 一部の算術関数への,64 ビット・ポインタ機能の追加

V8.3

/POINTER_SIZE 修飾子を指定してコンパイルすることで,以下の C RTL 算術関数に 64 ビット・ポインタを渡せるようになりました。


frexp       modf 
frexpf      modff 
frexpl      modfl 



5.9.5 2 GB の malloc で何も表示せずに失敗することがなくなった

V8.3

C RTL の malloc関数は, unsigned int( size_t) をパラメータとして受け付けます。 lib$vm_mallocは,正の符号付き整数をパラメータとして受け付けます。

以前のリリースでは 2 GB (0x80000000) のメモリを割り当てようとすると,正しい量のメモリは割り当てられず,エラー通知も返されませんでした。本リリースでは,関数 malloccalloc,および reallocにチェックが追加され, 2 GB 以上のサイズを要求すると呼び出しが失敗するようになりました。

5.9.6 exec* のメモリ・リークの修正

V8.3

exec* のメモリ・リークが修正されました。

5.9.7 execl 失敗後の exit 動作の修正

V8.3

C RTL には, execlが失敗した後に _exitを呼び出して終了してはならないのに,呼び出して終了するという問題に対する修正が含まれています。

OpenVMS の vforkの実装では,子プロセスを起動する大半の UNIX システムと異なり,実際の子プロセスは起動されません。ただし,C RTL は,子プロセスの機能をまねるために,「子コンテキスト」という内部データ構造体を作成します。

vfork後,子コンテキストの中にいるときに exec関数の呼び出しが失敗すると, _exitが呼び出されることでバグが発生します。 UNIX システムでは, exec呼び出しの失敗後,子プロセスは引き続き動作します。これ以降の _exitの呼び出しで,子プロセスが終了します。 OpenVMS の実装では, exec呼び出しの失敗後,子コンテキストは終了します。これ以降の _exitの呼び出しでは,親プロセスが終了します。

C RTL の修正は,機能論理名スイッチ DECC$EXIT_AFTER_FAILED_EXEC で有効になります。この機能論理名を有効にすると,子コンテキストが引き続き動作します。

DECC$EXIT_AFTER_FAILED_EXEC が無効か定義されていない場合,現在の動作のままとなります。

5.9.8 confstr の拡張

V8.3

X/Open 仕様に準拠するために, confstr関数に長さがゼロのバッファを渡すことができるようになりました。

また, confstrは, <unistd.h>ヘッダ・ファイルに追加された,次の 3 つの HP-UX シンボリック定数をサポートするようになりました。

_CS_MACHINE_IDENT
_CS_PARTITION_IDENT
_CS_MACHINE_SERIAL


V8.3

以前は,ユーザが fopen(file, "wb+") を呼び出すと, file が,引用符で囲まれた DECNET 指定で,リモート・ファイルが存在しなかった場合, RMS はファイルをアップデート用にオープンする (新しいバージョンを作成する) のではなく,ファイル指定の構文エラーを報告していました。

この問題は,バージョン 8.3 で修正されました。

5.9.10 ファイル・ポインタ・ロックのハングアップの修正

V8.3

OpenVMS Version 8.2 では,マルチスレッドの C プログラムに対して,ファイル・ポインタ・ロック ( flockfileおよびそのシリーズ) を導入しました。 C RTL は,X/Open 仕様に準拠するために,ファイル・ポインタを内部的にロックします。

データの事前ロード中のエラー・リターンによりファイル・ポインタのロック解除が行われなかった場合,問題が発生します。

この問題が発生すると,アプリケーションは,ファイル・ポインタ I/O を使用するマルチスレッド・プログラム内でハングアップすることがあります。プログラムの状態を分析すると,ファイル・ポインタ・ロックの実装に使用されている TIS 再帰ミューテックス上でスレッドがデッドロックしていることが分かります。

この問題は,バージョン 8.3 で修正されました。

5.9.11 バックポート・ライブラリが出荷されなくなった

V8.3

以前は,古いバージョンの OpenVMS で開発者が最新の C RTL 関数を使用できるように,コンパイラ配布キットに C RTL バックポート・オブジェクト・ライブラリが含まれていました。このバックポート・オブジェクト・ライブラリは,出荷されなくなりました。

5.9.12 ヘッダ・ファイル <time.h> の変更

V8.3

以下で説明している問題が修正されました。この問題がまだ発生している場合は,正しい動作が行われるように,アプリケーションを再コンパイルする必要があります。

C RTL <time.h>ヘッダ・ファイルでは, struct tm構造体と,関数 gmtimelocaltimegmtime_r,および localtime_rが定義されています。

これらの関数のいずれかを呼び出したときに,アプリケーションと C RTL が認識している struct tmのサイズが異なると,ユーザ・アプリケーションでデータが壊れるか,アクセス違反が発生することがあります。

tm構造体には,BSD 拡張用のオプションのメンバ tm_gmtoffおよび tm_zoneが入っています。これらのメンバは,ANSI 仕様や POSIX 仕様では,古いコンパイルとの互換性のため,定義されていません。

C RTL では,上記で説明した関数に対して,3 種類の異なる定義があります。

  • ローカル・タイム (プレフィックスなし)

  • UTC 時間 (OpenVMS V7.0 以降)

    • プレフィックス __UTC_ (BSD 拡張なし)

    • プレフィックス __UTCTZ_ (BSD 拡張を使用)

プレフィックス __UTCTZ_ 付きの関数は,BSD 拡張が定義されている長い tm構造体だけを割り当てることを前提とします。

<time.h>ヘッダ・ファイルと C RTL で,認識している struc tm構造体のメンバの数が異なっていると,問題が発生します。たとえば, _ANSI_C_SOURCE を意味するコンパイル時マクロ (_POSIX_C_SOURCE など) を使用して C++ コンパイルを行うと,プレフィックス __UTC_ を使用して上記の C RTL 関数がマッピングされるため,問題が発生します。関数は短い tmデータ構造体を期待しますが,ユーザ・プログラムは長い tm構造体定義を使用します。関数から戻る際に行われるデータのコピー・バックで, C RTL が割り当てていない tmデータ・メンバへのアクセスが試みられます。これにより,意図していないメモリの使用やアクセス違反など,予期しない動作が発生することがあります。

OpenVMS Version 8.3 では, <time.h>が変更され,上記の関数に対して C RTL が適切なプレフィックスを選択するようになりました。

5.9.13 ヘッダ・ファイル <time.h> での非 ANSI の *_r 関数の参照

V8.3

X/Open 仕様で定義されている ctime_rgmtime_r,および localtime_rという C RTL 関数は ISO/ANSI C 標準では規定されておらず,厳密に ANSI 準拠のコンパイルでは参照できないようになっていなければなりません。以前の C RTL では,これらの関数を参照できていました。

この問題は修正されました。 <time.h>ヘッダにチェックが追加され,これらの関数は, ANSI 準拠のコンパイルでないときのみ参照できるようになりました。

5.9.14 ヘッダ・ファイル <decc$types.h>: time_t int 宣言

V8.3

OpenVMS システムでは,ヘッダ・ファイル <decc$types.h>で定義されている time_t構造体は,従来から unsigned long intとして宣言されていました。 UNIX プラットフォームではこれを符号付きの型として宣言することが多く, OpenVMS 上に移植されたプログラムで問題が発生する可能性があります。

UNIX との互換性のために,コンパイル・マクロ __SIGNED_INT_TIME_T を使用し, time_tintとして宣言することもできるように修正されました。

古いプログラムとの互換性を保つために,デフォルトは unsigned long intのままです。

5.9.15 新しい DECC$SHRP.EXE イメージ

V8.3

保護モードを必要とする C RTL 関数を実装するために, OpenVMS は新しい共用イメージ DECC$SHRP.EXE をインストールします。この共用イメージは,すべての Alpha プロセッサと Integrity プロセッサにインストールされ, DECC$SHR.EXE 共用イメージまたは DECC$SHR_EV56.EXE 共用イメージから呼び出されます。

5.9.16 ヘッダ・ファイル <wchar.h> と C++ %CXX-W-ENVIRSTKDIRTY メッセージ

V8.3

<wchar.h>ヘッダ・ファイルは, _XOPEN_SOURCE マクロが定義されている状態でコンパイルしたときに C++ Version 7.1 コンパイラが %CXX-W-ENVIRSTKDIRTY 警告を出力するという問題を解決するために,修正されました。

5.9.17 ヘッダ・ファイル <builtins.h> の __CMP_SWAP* と _Interlocked* が C++ から参照可能

V8.3

<builtins.h>にある比較とスワップのビルトイン (__CMP_SWAP* と _Interlocked*) は, OpenVMS Alpha C++ コンパイラを対象としていませんでした。 HP C++ Version 7.1 はこれらの関数を必要とするため,条件付きコンパイルが変更されこれらのビルトインを参照できるようになりました。

5.9.18 fcntl への余分なパラメータの無視

V8.3

期待されているパラメータが 2 個だけのとき (3 番目のパラメータを期待しないコマンド) に,オプションの 3 番目のパラメータを指定して fcntlを呼び出すと,以前はエラーが返されていました。

この問題は修正されました。必要のない 3 番目のパラメータは,無視されるようになりました。

5.9.19 システムの MAXBUF パラメータが大きい場合,stdout への fwrite が失敗する問題

V8.3

システムの MAXBUF SYSGEN パラメータが 33278 以上の場合, stdoutへの fwriteを使用すると,以前はエラーとなっていました。

失敗した fwrite呼び出しの後に perrorを使用すると,次のメッセージ ( perrorで表示されるとおり) が返されていることがあります。


Error writing output: : non-translatable vms error code: 0x186A4 
 
 %rms-f-rsz, invalid record size 

この問題は修正されました。

5.9.20 64K バイトを超えるソケット転送の読み取りと書き込みの問題

V8.3

以下のソケット・ルーチンに対し, 64K バイトを超えるソケット転送のサポートが追加されました。


send        recv         read 
sendto      recvfrom     write 
sendmsg     recvmsg 



5.9.21 I64 システムでの nanosleepの問題

V8.3

OpenVMS I64 システムでは, nanosleep関数は正しくスリープしても,不正なステータス -1 を返し, errnoに EINTR (割り込まれたシステム・コール) を設定していました。

この問題は修正されました。

5.9.22 I64 システムへのビルトイン __fci の追加

V8.3

<builtins.h>ヘッダ・ファイルがアップデートされ,新しいビルトイン __fci( fc.i命令用のビルトイン) のプロトタイプが追加され,HP C コンパイラでサポートされるようになりました。

5.9.23 _FAST_TOUPPER マクロの追加

V8.3

OpenVMS Version 8.3 から,C99 ANSI 標準および X/Open 規格に準拠するため, _tolowerマクロと _toupperマクロはデフォルトではパラメータを 2 回以上評価しないようになりました。これらのマクロは,単にそれぞれ tolower関数と toupper関数を呼び出します。これにより,式を評価する回数によって結果が異なるような副作用 (i++ や関数呼び出しの副作用など) を避けることができます。

_tolowerマクロと _toupperマクロで,以前の最適化された動作を行うには,/DEFINE=_FAST_TOUPPER を指定してコンパイルします。これにより,以前のリリースと同様に,これらのマクロは実行時呼び出しのオーバヘッドを避けるように呼び出しが最適化されます。ただし,結果を計算する方法を決定するために,マクロのパラメータは 2 回以上評価されます。これにより,望まない副作用が発生する可能性があります。

5.9.24 atof("NaN") の呼び出しで算術トラップが生成されなくなった

V8.3

OpenVMS Alpha Version 8.2 以降では, atof("NaN")に対する次の呼び出しで算術トラップが生成されます。


d = atof("NaN"); 
 
%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, 
Fmask=00000002, summary=02, PC=FFFFFFFF80BB23D4, PS=0000001B 
-SYSTEM-F-FLTINV, floating invalid operation, PC=FFFFFFFF80BB23D4, 
PS=0000001B 

この問題は OpenVMS Version 8.3 で修正され,算術トラップは生成されなくなりました。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項