OpenVMS マニュアル

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

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

5.1 lib$routines.h ファイルにおけるプロトタイプ宣言の修正

V8.4

lib$routines.h で宣言されているプロトタイプ lib$stat_vm_64 は，定義と一致するように修正されています。

#ifdef __NEW_STARLET 
unsigned int lib$stat_vm_64( 
    __int64 *code, 
    unsigned __int64 *value_argument);     
#else   /* __OLD_STARLET */ 
unsigned int lib$stat_vm_64(__unknown_params); 
#endif  /* #ifdef __NEW_STARLET */ 

5.2 シンボリック・デバッガ

V8.4

OpenVMS Alpha Version 8.4 では，ブレークポイントを設定した際，デバッガはFORTRAN 関数と，別のコンパイル・ユニットで同じ名前で宣言された変数とを見分けることができません。

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

OpenVMS Version 8.3-1H1 で修正された問題は，以下のとおりです。

• ランタイム・ライブラリには，解放したメモリにアクセスして，その結果を使ってポインタを進めるという不完全なコードがありました。マルチスレッド・コードでは，元のスレッドがポインタを進める前に別のスレッドがそのメモリを再利用する可能性がありました。この問題は，ポインタを解放する前にアクセスするようにアップデートすることによって解決されました。

• 新しいプロセス・ワイドの例外処理モード (pure_unix) が導入されました。このモードでは，非 C++ 例外 (OpenVMSコンディションとも呼ばれる) が C++ のキャッチオール・ハンドラで捕捉されることはありません。このモードは，cxxl$set_condition(condition_behavior) に pure_unix 引数を付けて呼び出すことによって要求できます。

  cxxl$set_condition(pure_unix); condition_behavior enum declared in <cxx_exception.h> header has been extended to include pure_unix member.

  
  次のサンプル・プログラムを例に，pure_unix モードの動作を説明します。このプログラムは，ACCVIO でクラッシュするように記述されています。 cxxl$set_condition() の呼び出しをコメント・アウトした場合には，プログラムは "caught" を出力して終了します。

  #include <stdio.h> #include <cxx_exception.h> void generateACCVIO() { *((int*)0) = 0; } int main() { cxxl$set_condition(pure_unix); try { generateACCVIO(); } catch(...) { puts("caught"); } }

  注意 この新機能を使うためには，新バージョンの cxx_exception.h を使用する必要があります。これは V7.3 以降のコンパイラに付属している CXXL$ANSI_DEF.TLB ファイルに含まれています。

• ランタイム・ライブラリは，関数内で記憶域の存続期間が自動的に決まるオブジェクトが定義されていると，捕捉した例外によって関数が終了したときに，オブジェクトの破棄に失敗することがありました。この問題は修正されました。

• シグナルの捕捉を有効にしている場合，ランタイム・ライブラリを使うと，スレッド・キャンセル・シグナル (CMA$_ALERTED) とスレッド終了シグナル (CMA$_EXIT_THREAD) を，それぞれタイプ CXXL$PTHREAD_CANCEL (または CX6L$PTHREAD_CANCEL) と CXXL$PTHREAD_EXIT (または CX6L$PTHREAD_EXIT) へのポインタまたは参照を使って，キャッチ・ハンドラで捕捉できるようになりました。新しいタイプではこれらのシグナルは排他的に捕捉されます。

  注意 この新機能を使うためには，新バージョンの cxx_exception.h を使用する必要があります。これは V7.3 以降のコンパイラに付属している CXXL$ANSI_DEF.TLB に含まれています。

• C++ RTL では，最近の CRTL の変更に合わせて， SIGTRAP の内部マッピングが SS$_BREAK から SS$_TBIT に変更されました。

• C++ RTL では，デストラクタがスタックをアンワインドしているときに例外が発生すると，デストラクタが例外で終了していなくても，std::terminate() を呼び出していました。この問題は修正されました。

• C++ RTL は，C++ 例外の処理中に外部例外 (たとえば，非 C++ OpenVMS コンディション) が発生すると， std::terminate() を呼び出していました。この動作は，発生した OpenVMS コンディションによってスタックのアンワインドが必要になる場合にのみ std::terminate() を呼び出すように修正されました。

• OpenVMS コンディションは C++ キャッチ・ハンドラで捕捉できるため， C++ RTL はそのコンディションを C++ 例外の表現に合った内部形式に変換します。この変換により，トレースバックの際に誤った情報が表示されることがありました。この問題は修正されました。

以下の問題は，今回のバージョンの C++ Library (V7.3 以降のコンパイラ) で修正されました。

• http://issues.apache.org/jira/browse/STDCXX-397 で説明されているように， <algorithm.cc> ヘッダ内の __introsort_loop() 関数にはバグがありました。すなわち，特定の入力シーケンスで，std::sort の性能が低下することがありました。詳細は， http://issues.apache.org/jira/browse/STDCXX-397 にある問題 STDCXX-397 に対する Apache の追跡情報を参照してください。
  このバグは修正されました。ただし，特定の入力シーケンスでは，この修正により std::sort の動作が変わることがあります。つまり，同等の順位を持つエレメントがソート結果のシーケンス内で置かれる相対的位置が変わることがあります。この動作上の変化は，std::stable_sort とは異なり，std::sort では同等の順位を持つ特定のエレメントの相対的順序を保証していないため許容することはできますが，std::sort の従来の動作に依存しているアプリケーションが正常に動作しなくなる可能性があります。このような状況を避けるために，この修正は __RW_FIX_APACHE_STDCXX_397 マクロで条件付けられており，このマクロを定義してプログラムをコンパイルした場合にのみ，この修正が有効になります。

• 標準 GNU モードでコンパイルすると，ライブラリは _RWSTD_NO_IMPLICIT_INCLUSION マクロを定義するようになりました。この変更により，ライブラリ・ヘッダに対応するテンプレート定義ファイルがインクルード (#include) されるようになりました。これは，標準 GNU モードでは暗黙的な #include が無効になっているために必要になります。
  この変更を行う前は，以下のプログラムは，標準 GNU モードでコンパイルすると，未定義シンボルをリンクしていました。

  #include <vector> int main() { std::vector<int> v; v.push_back(0); }

• C++ 規格の第 27.6.1.3 項 [lib.istream.unformatted] によれば， std::basic_istream クラスの以下の get メンバ関数は，空行の場合のように，文字が何も含まれていない場合には， setstate(failbit) を呼び出すことになっています。 I64 システムではこの関数は failbit を設定していましたが， Alpha システムでは設定していませんでした。

  istream_type& get(char_type *s, streamsize n, char_type delim); istream_type& get(char_type *s, streamsize n);

5.4 プロセス/アプリケーションがハングする

lib$find_image_symbol ランタイム・ライブラリ・ルーチンの LIBRTL ドキュメントには，以下の制限事項が適用されます。

pthread (またはそれよりも古い CMA スレッド・インタフェース) を使っている共用可能イメージをアプリケーションでダイナミックにアクティベートしている場合には，メイン・イメージに pthread$rtl イメージをリンクする必要があります。

5.5 POSIX スレッドを使用しているプログラムでの AST 実行要求の明確化

V8.3-1H1

スレッド化されたプログラムで AST を利用することができます。『Guide to the POSIX Threads Library』の付録 B.12.5 では，一般的な使用上の注意が説明されています。しかし，その説明では，アップコールを無効にした (省略時の設定) プログラムでの AST 実行要求の動作が明確ではありません。

アップコールを無効にしたプログラムでは，ユーザ・モードの AST は， AST の実行が要求された時点で実行中のすべてのスレッドに割り込みます。したがって，AST サービス・ルーチンでは，実行するコンテキストに前提 (スレッド ID，利用できるスタック領域など) を設けることはできません。

また，このガイドの付録 B.12.5 内の大部分の説明では，将来提供される OpenVMS のバージョンについて記載していることに注意してください。一般化された "per-thread" やスレッドをターゲットとする AST についての説明は，将来オペレーティング・システムが拡張される可能性があることを示しています。ただし，現在までのすべての OpenVMS リリースでは，ユーザ・モードの AST は，総じてプロセスに対して要求されているものとして処理されています。

5.6 ディレクトリ・ファイルの RMS $PARSE 検証

V8.3-1H1

OpenVMS V8.3 から，$PARSE サービスは，ディレクトリ指定に該当するすべてのディレクトリを検証して，ディレクトリ特性がセットされていることを確認するようになりました。以前の OpenVMS バージョンでは， .DIR拡張子を持つがディレクトリでないファイルにアクセスを試みると，必ずしも $PARSEサービスからではなく， $OPENサービスから SS$_BADIRECTORYエラーが返されました。 V8.3 から，エラーは必ず $PARSEサービスから返されるようになりました。ただし，構文チェックだけの $PARSEについては除きます。

5.7 IOLOCK8 を使わない FibreChannel ポート・ドライバ

V8.3-1H1

多くの I/O サブシステム・コンポーネントは， IOLOCK8 スピンロックを使って CPU 間で動作の同期をとります。スピンロックを取得することにより，性能ボトルネックが発生します。 V8.3-1H1 から，各 FibreChannel ポート・ドライバ (SYS$PGQDRIVER，SYS$PGADRIVER，SYS$FGEDRIVER) デバイスでは， IOLOCK8 の代わりに独自のポート固有のスピンロックを使って内部動作の同期をとるようになりました。これにより，大部分の構成で，各 CPU の IOLOCK8 スピンロックの待ち時間が大幅に減少し，同時に FibreChannel I/O の転送速度が向上しました。

新しいポート・ドライバのいずれかに接続するクラス・ドライバには，軽微な変更が必要なので，以前のままでは動作しない非 HP クラス・ドライバを利用していないか調べる必要があります。簡単に確認する方法は， SDA コマンド CLUE SCSI/SUMMARYの出力を見て，他社製のクラス・ドライバ・デバイスの名前が，"Device" 欄の FGx0 または PGx0 ポート・デバイスのデバイス階層に表示されていないか調べることです。

詳細は，次の SDA セッション例の後の注意を参照してください。

$ ANALYZE/SYSTEM 
 
OpenVMS system analyzer 
 
SDA> CLUE SCSI /SUMMARY 
 
SCSI Summary Configuration: 
--------------------------- 
SPDT      Port  STDT   SCSI-Id  SCDT  SCSI-Lun  Device    UCB       Type    Rev 
--------------  --------------  --------------  --------  --------  ------  ---- 
81624200 FGB0 
                8162CDC0     3 
                                8162D240     0  GGA22     8162F380  HSV200 
                                8162F180     1  DGA22801  8162FD40  HSV200  6100 
                                81632900     2  DGA22802  81632AC0  HSV200  6100 
                                816354C0     3  DGA22803  81635680  HSV200  6100 
                                81638080     4  DGA22804  81638240  HSV200  6100 
                8162D400     4 
                                8162DD80     0  GGA22     8163AC40  MRD200 
                                8163B5C0     1  RJA22801  8163B780  RFD200  6100 
                                8163C840     2  RJA22802  8163CA00  RFD200  6100 
                                8163DAC0     3  RJA22803  8163DC80  RFD200  6100 
                                8163ED40     4  RJA22804  8163EF00  RFD200  6100 

解説 この出力でのすべての DGA デバイスと GGA デバイスは，それぞれ変更された HP クラス・ドライバ SYS$DKDRIVER および SYS$GKDRIVER 経由でアクセスされているので，新しいポート・ドライバと一緒に使っても安全です。 タイプが MRD200 の物理デバイスは弊社が認定したデバイスではありませんが， IOLOCK8 問題は発生しません。このデバイスは GGAx ユニット経由でアクセスされるため，変更された HP 汎用クラス・ドライバ SYS$GKDRIVER が使われるからです。 RJA デバイスは，変更された HP クラス・ドライバで制御されないため，新しいポート・ドライバでは動作しません。

5.8 C++ コンパイラ

V8.3-1H1

Integrity サーバ用の C++ Version 7.2 for OpenVMS では，マクロ __INITIAL_POINTER_SIZE に 0 が設定済みです。これは，C++ Version 7.1 Compiler では未定義のままでした。これは C++ Version 7.2 を C コンパイラと調和させ， pointer_size プラグマをサポートするための意図的な変更です。 C++ Version 7.1 ではサポートしていません。

この変更によって，ポインタ・タイプを宣言しているシステム・ヘッダ・ファイルで選択される特定の宣言を使っていて，今まで正常にコンパイルされたコードで診断メッセージが表示されることがあることに注意してください。 starlet ヘッダを使って，__NEW_STARLET を定義してコンパイルするアプリケーションで，このメッセージが表示されることがあります。

新しい宣言に合わせてアプリケーションのソース・コードを変更することができない場合には，CXX コマンド行にコマンド行修飾子 /UNDEF=__INITIAL_POINTER_SIZE を追加して， C++ Version 7.2 コンパイラによって，上記のマクロが定義されないようにし， Version 7.1 コンパイラの場合に定義しているのと同じ宣言がシステム・ヘッダで提供されるようにしてください。

5.9 DCE IDL C++ アプリケーションのビルド

V8.3-1H1

CXX Version 7.2 以降で DCE IDL C++ アプリケーションをビルドすると，リンカから未定義シンボルの警告が出力されます。これは既知の問題です。 HP サポート・サービスに連絡して，この警告が表示されないようにするために必要なパッチを要求してください。

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

V8.2

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

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

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

V8.2

OpenVMS Version 8.2 では，多数の特権データ構造体が変更されています。これらの変更は，Alpha システムと Integrity システムの両方で実施されています。これらのデータ構造体の変更の大半は，オペレーティング・システムでの将来のスケーリングおよび性能強化の計画を実現するためのものです。この変更の結果，ベース・オペレーティング・システムに対してリンクされているイメージやドライバ (つまり，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

注意 Integrity サーバでは，これらのサブシシテムは 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.11.1 KPB 拡張

V8.2

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

5.11.2 CPU の名前空間

V8.2

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

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

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

V8.4

OpenVMS はこれまで 32 ビットの LBN をサポートしています。このため，ディスク・ボリュームのサポートが 2 TB に制限されます。 LBN の内部領域は 64 ビットに拡張されており，より大きなディスク・ボリュームを将来サポートできるようになります。現在の 32 ビットの LBN は今後も維持され， 64 ビット拡張後もそのまま使えます。

5.11.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.11.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.11.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.11.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.12 浮動小数点型データを使用するアプリケーション

V8.2

Itanium® アーキテクチャでは， IEEE 単精度および IEEE 倍精度を含む，IEEE 浮動小数点形式を用いた，ハードウェアによる浮動小数点演算を実装しています。

Alpha ハードウェアでは， IEEE 浮動小数点形式と VAX 浮動小数点形式のいずれもサポートしています。 OpenVMS Alpha では，コンパイラはデフォルトで VAX 形式のコードを生成し，オプションで IEEE 形式のコードを生成します。

OpenVMS Integrity では，コンパイラはデフォルトで IEEE 形式のコードを生成し，オプションで VAX 形式のコードを生成します。 Integrity サーバでは， VAX や Alpha システムで生成された VAX 形式の浮動小数バイナリ・データをアプリケーションで取り扱う必要がある場合を除き， IEEE 形式を使用することをお勧めします。 OpenVMS Integrity で VAX 形式を使用する場合の詳細については，次の Web サイトのホワイト・ペーパ『Intel® Itanium® における OpenVMS 浮動小数点演算について』を参照してください。

http://h50146.www5.hp.com/products/software/oe/openvms/technical/

5.12.1 IEEE 浮動小数点フィルタ (Integrity のみ)

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.12.2 Ada イベントのサポート (Integrity のみ)

V8.3

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

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

5.12.3 C++ 言語の問題 (Integrity のみ)

V8.3

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

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

5.13 Ada コンパイラ (Integrity のみ)

V8.2

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

5.14 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.15 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.16 C ランタイム・ライブラリ

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

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

V8.4

C RTL では，TCP/IP を呼び出すユーザ向けのヘッダ・ファイルを提供しています。これらのヘッダ・ファイルは， C RTL のヘッダ・ライブラリ (DECC$RTLDEF.TLB) に含まれています。

TCP/IP の新機能に合わせて，以下の新しいヘッダ・ファイルが追加されています。

SCTP.H SCTP_UIO.H

これらのヘッダ・ファイルにより，SCTP (Stream Control Transmission Protocol) サポートが提供されます。 SCTP については，『HP TCP/IP Services for OpenVMS Version 5.7 Release Notes』を参照してください。

5.16.2 バックポート・ライブラリが提供されなくなった

V8.3

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

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

V8.3

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

C RTL <time.h>ヘッダ・ファイルでは， struct tm構造体と，関数 gmtime， localtime， gmtime_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.16.4 ヘッダ・ファイル <time.h> での非 ANSI の *_r 関数の参照

V8.3

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

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

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

V8.3

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

5.16.6 Integrity システムへのビルトイン __fci の追加

V8.3

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

5.16.7 DECC$*.OLB オブジェクト・ライブラリに新しいエントリがない

V8.3

OpenVMS Alpha および OpenVMS Integrity の Version 8.2 から， DECC$*.OLB オブジェクト・ライブラリに新しいエントリ・ポイントが追加されなくなりました。これは，新しい C RTL エントリ・ポイントはこれらのライブラリを通じてプレフィックス付きのエントリにマッピングされないことを意味します。たとえば，新しい OpenVMS Version 8.3 のエントリ・ポイント cryptは， /PREFIX=NONE 付きでコンパイルすると， cryptから decc$cryptにマッピングされません。

5.17 呼び出し標準規則とローテートするレジスタ (Integrity のみ)

V8.3

ここでの説明は『HP OpenVMS Calling Standard』の情報を補足するものです。

呼び出し標準規則の ICB (invocation context block) (『HP OpenVMS Calling Standard』の表 4-16 を参照) およびメカニズム・ベクタ (『HP OpenVMS Calling Standard』の図 8-7 と表 8-6 を参照) は常に，あたかも，レジスタ・リネーム・ベース (CFM.rrb) とローテート・サイズ (CFM.sor) がいずれも 0 であったかのように，汎用レジスタ，浮動小数点レジスタ，およびプレディケート・レジスタを記録しています。つまり，ローテートするレジスタを使用しているときに，ローテーションの効果が無視されます。このことは，LIB$I64_PUT_INVO_REGISTERS ルーチン (『HP OpenVMS Calling Standard』の第 4.8.3.13 項を参照) で使用するレジスタ・マスクについても同様です。というのは，これらのマスクは， ICB 構造体のフィールドによって定義されるからです。

以前は，補足的なアクセス・ルーチン LIB$I64_GET_FR, LIB$I64_SET_FR, LIB$I64_GET_GR および LIB$I64_SET_GR (『HP OpenVMS Calling Standard』の第 4.8.4 項を参照) が，レジスタ・リネーム・ベース・レジスタとローテート・サイズ・レジスタの効果を調整しないで，不適切に，そのレジスタ番号パラメータを解釈していました。この誤りは修正されました。

5.18 Common Data Security Architecture (CDSA) に関する考慮

ここでは，CDSA に関する注意事項について説明します。

5.18.1 Secure Delivery

V8.4

Version 8.4 以降，すべての OpenVMS キットは， PCSI キットおよび VMSINSTAL キットも含めて HP Code Signing Service (HPCSS) を使用して署名されます。署名および確認に CDSA は使用しません。新しい署名ファイル <full kit name>_HPC が作成され，キットと共に提供されます。この署名ファイルを使用してキットの確認が行なわれます。

新しい評価機能 HPBinarychecker がすべての OpenVMS システムにインストールされ， HP Code Signing Service を使用してキットの署名を確認します。詳細は，『HP OpenVMS V8.4 新機能説明書』を参照してください。

OpenVMS Version 8.4 よりも前のバージョンで署名されたキットは， V8.4 上の CDSA を使用して確認できます。

5.18.2 インストールと初期化に関する注意事項

V8.4

CDSA は，オペレーティング・システムのインストール時に自動的にインストールされます。

• 新しいバージョンの CDSA を，オペレーティング・システムのアップグレードとは別にインストールする場合は，次のように CDSA のアップグレード・プロシージャを実行する必要があります。

  $ @SYS$STARTUP:CDSA$UPGRADE

  
  なお，このアップグレード・プロシージャを実行する前に，すべての CDSA アプリケーションをシャットダウンしてください。
  また，システムをリブートする際にはアップグレード・プロシージャを再実行する必要はありません。また，OpenVMS スタートアップ・プロシージャにアップグレード・プロシージャを追加する必要もありません。

• 使用中のシステムから CDSA の削除は行わないでください。 CDSA を削除するように見えるオプションがありますが CDSA に対する PCSI コマンド PRODUCT REMOVE の使用はサポートされていません (このオプションはインストール時に PCSI ユーティリティで使用するためのものです)。 CDSA とオペレーティング・システムは同時にインストールされ，密接に関連付けられているので，OpenVMS から CDSA を削除しようとすると正常に動作せず，望ましくない影響が発生する可能性があります。 CDSA を削除しようとすると，次のようなメッセージが表示されます。

  The following product has been selected: HP I64VMS CDSA V2.4-315 Layered Product Do you want to continue? [YES] %PCSI-E-HRDREF, product HP I64VMS CDSA V2.4-315 is referenced by HP I64VMS OPENV MS V8.4 The two products listed above are tightly bound by a software dependency. If you override the recommendation to terminate the operation, the referenced product will be removed, but the referencing product will have an unsatisfied software dependency and may no longer function correctly. Please review the referencing product's documentation on requirements. Answer YES to the following question to terminate the PRODUCT command. However, if you are sure you want to remove the referenced product then answer NO to continue the operation.

5.19 デバッグ・モード: CPUSPINWAIT バグ・チェックの回避

恒久的な条件

OpenVMS オペレーティング・システムには，複雑なハードウェアの問題やソフトウェアの問題をデバッグするのに役立つように，多くの特殊操作モードが準備されています。一般には，これらの特殊モードを使用すれば，特別なレベルでトレース，データの記録，一貫性チェックを行うことができ，このような機能は，問題があるハードウェア構成要素やソフトウェア構成要素を突き止めるのに役立ちます。これらの操作モードは，システム・パラメータ MULTIPROCESSING， POOLCHECK，BUGCHECKFATAL，SYSTEM_CHECK によって制御されます。

一般に I/O 負荷の高い特定の状況で，これらの特殊モードのいずれかを使用している場合は ( たとえば，デバイス・ドライバや他の複雑なアプリケーションをデバッグする場合など )，CPUSPINWAIT バグ・チェックが発生することがあります。特に，スピンロックのある状態で長期間実行する特権コードに対して CPUSPINWAIT バグ・チェックが発生します。スピンロックは，クリティカル・セクションのエントリ・ポイントとイグジット・ポイントを区切るために使われ，この場合のように連続的に使うことはできません。

CPUSPINWAIT バグ・チェックを防止するには，これらのシステム・パラメータに対して，システムのデフォルト設定を使用するか，またはシステムの負荷を低下させます。

何らかの理由でデフォルトの設定を変更しなければならない場合は， SMP_ LNGSPINWAIT システム・パラメータを 9000000 に設定することで，問題が発生する可能性を減らせます。

5.20 Delta/XDelta デバッガ

ここでは，OpenVMS Alpha および Integrity システム上で動作する OpenVMS Delta および XDelta デバッガに関する注意事項について説明します。

5.20.1 XDelta のレジスタ表示に関する考慮 (Integrity のみ)

V8.2

OpenVMS Integrity 上の XDelta は，あたかも，レジスタ・リネーム・ベース (CFM.rrb) とローテート・サイズ (CFM.sor) がいずれも 0 であるかのように，汎用レジスタ，浮動小数点レジスタ，およびプレディケート・レジスタを表示します。言い換えると，ローテートするレジスタを使用しているときには，ローテイションの効果は無視されます。この状況は，今後のリリースで修正される予定です。詳細は 第 5.17 節 を参照してください。

5.21 ファイル・アプリケーション: 『Guide to OpenVMS File Applications』の訂正

恒久的な訂正

『Guide to OpenVMS File Applications』が改訂される際には，下記の訂正が反映される予定です。

• 表 1-4 は誤解を招く可能性があります。ファイル・フォーマットの比較表で，ODS-2 や ODS-5 のファイル・フォーマットでのディレクトリの制限として 256 としてあります。この説明は，256 ディレクトリ・レベル とし，ユーザが，ディレクトリ数が 256 に制限されているものと誤解しないようにする必要があります。
  『OpenVMS システム管理者マニュアル』の類似した表は Version 8.2 で訂正されました。

• 第 6.6.3 項の第 4 パラグラフ (Note はカウントしない) を，以下の内容に置き換えます。
  「プログラム内で使用するルート・デバイス論理名を， SET DEFAULT コマンドで定義する際には，DCL コマンドの DEFINE または ASSIGN で /TRANSLATION_ATTRIBUTES=CONCEALED 修飾子を使用して，この論理名が隠し装置の論理名であることを指定します。隠し装置の論理名をルート・デバイス論理名として定義するためには，ルート・ディレクトリがピリオド (.) で終わっていなければなりません (例: DUA22:[ROOT.])。また，デバイスの指定が，物理デバイス名でなければなりません。ルート・デバイス論理名の等価名には，他の論理名を含めることはできません。ディレクトリを指定するときには，ルート・ディレクトリに対して，後のピリオドだけを使用することができます。」

5.22 RMS 構造体についての HP BLISS コンパイラの警告 (Integrity のみ)

恒久的な条件

RMS ユーザ構造体 (たとえば，FAB，RAB) の割り当てに使用できる BLISS マクロ ($xxx_DECL) に，クォドワード・アラインメントが追加されました。プロセッサが高速になるほど，アラインメント・フォルトは性能に悪影響を及ぼします。アラインメントをマクロ内に直接実装することにより，これらのマクロを使用する，BLISS で書かれた多数の OpenVMS ユーティリティおよびユーザ・アプリケーションは，性能が改善されます。

該当するマクロは，$FAB_DECL，$NAM_DECL，$NAML_DECL，$RAB_DECL， $RAB64_DECL，$XABALL_DECL，$XABDAT_DECL，$XABFHC_DECL，$XABITM_DECL， $XABJNL_DECL，$XABKEY_DECL，$XABPRO_DECL，$XABRDT_DECL，$XABRU_DECL， $XABTRM_DECL，および $XABSUM_DECL です。

RMS マクロに追加されたアラインメントにより，コンパイラがアラインメント競合の警告を出力することがあります。コンパイラの警告があるプログラムでも，正しくリンクして，実行することができます。ただし，ソースに簡単な変更を加えて，警告を取り除くことをお勧めします。

これらのマクロを BLISS アプリケーション内で使用し，宣言に ALIGN 属性が含まれている場合， BLISS コンパイラは "conflicting or multiply specified attribute" という警告を出力します。たとえば，FAB: $FAB_DECL ALIGN(2) という宣言に対して，警告が出力されます。この警告は，クォドワード・アラインメント (ALIGN(3)) を指定したとしても出力されます。これらのマクロに関連する明示的な ALIGN 属性を削除する必要があります。

さらに，これらの割り当てが， ALIGN(3) と競合する明示的なアラインメント (ALIGN(3) 未満のもの) を持つ PSECT に含まれている場合，BLISS コンパイラは， "align request negative or exceeds that of psect" という警告を出力します。たとえば，次の宣言に対して警告が出力されます。

PSECT OWN = $OWN$ (..., ALIGN(2), ...) OWN FAB = $FAB_DECL, ...

BLISS アプリケーションの再コンパイル時に PSECT のアラインメントに関する警告が表示された場合， PSECT のアラインメントを ALIGN(3) (またはそれ以上) に調整してください。まれに，PSECT 間でデータが隣接していると仮定しているアプリケーションが存在することがあります。この変更により，このような仮定が成り立たなくなることがあります。そのため，コードでこのうような仮定を行っていないかチェックし，必要な変更を行ってください。

多くの OpenVMS ユーティリティが BLISS で記述されていますが， OpenVMS 全体のビルドで発生した警告はわずかでした。この警告を取り除くために OpenVMS に加えた変更は他にはありませんでした。このため，修正が必要なユーザ・アプリケーションは，ほとんどないと考えられます。

5.23 RMS の Must-Be-Zero エラーの可能性: FAB 内に新しいファイル・オプション用の場所を確保

V8.3

RMS のユーザ・ファイル・アクセス・ブロック (FAB) には，未割り当ての領域がごくわずかしかありません。 FAB を通じて実装されるファイル処理オプションを将来拡張できるように， FAB (FAB$L_FOP)内のファイル処理オプション・フィールドの最後の未割り当てビットが， FAB$V_EXTEND_FOPオプションとして定義されました。このオプションは，FAB 内で以前使用されていなかった領域に置かれる以下の 2 つの新しい FAB フィールドへの割り当てを要求し検査するために，将来使用されます。

• FAB$W_FOPEXT: ワード・フィールド FOPEXT は，将来実装が必要になる新しいファイル処理オプションの定義用として予約されています。

• FAB$W_RESERVED_MBZ: ワード・フィールド RESERVED_MBZは，将来の使用のために予約されています。その用途は現在決定されておらず，将来定義されます。

将来のリリースで新しいファイル処理オプションを実装するときには， FOPEXTフィールドの新しいオプションを利用するために， FAB$L_FOPフィールドの FAB$V_EXTEND_FOPビットをオンにする必要があります。ただし，このビットをオンにすると， FOPEXTフィールドの未定義のビットがオフで， FAB$W_RESERVED_MBZにゼロが格納されていることも示します。この条件が満たされていない状態でこのビットをオンにすると， RMS のすべてのファイル・レベル・サービスで，回復不可能なエラー (RMS-F-FOPEXTMBZ)が返されます。

EXTEND_FOPオプションの追加は完全に上位互換性があります。ただし，ユーザが FAB$L_FOPフィールドのこの最後のビットを誤ってオンにし，この 2 つの新しい FAB フィールドのいずれかがゼロでない場合は例外です。以前は， FAB$L_FOPフィールドのこの最後のビットが誤ってオンになっていた場合でも，RMS はそれを無視していました。

RMS-F-FOPEXTMBZエラーが返される場合は， FAB$L_FOPフィールドの EXTEND_FOPオプションをオフにするか， 2 つの新しいフィールド FAB$W_FOPEXTおよび FAB$W_RESERVED_MBZをクリアする必要があります。

5.24 HP COBOL ランタイム・ライブラリ (RTL)

V8.4

OpenVMS Alpha および OpenVMS Integrity Version 8.4 では， HP COBOL RTL (DEC$COBRTL) は V2.9-785 にアップデートされました。

5.24.1 COBOL CALL 文の性能改善

V8.4

COBOL CALL 文でサブルーチンを呼び出す際， OpenVMS Integrity では性能の低下が見られ， OpenVMS Alpha よりも長い時間がかかっていました。

ランタイム・ライブラリ (RTL) が修正され， COBOL CALL 文の性能が大きく改善されています。現在では OpenVMS Integrity での性能は OpenVMS Alpha での性能と同等になっています。

5.25 HP Fortran for Integrity Servers

V8.2

OpenVMS Integrity サーバ用の HP Fortran コンパイラは， OpenVMS Alpha の HP Fortran 90 を移植したものです。このコンパイラは OpenVMS Integrity システム上で動作し， OpenVMS Integrity システム用のオブジェクトを生成します。このオブジェクトは， OpenVMS Integrity 上の標準リンカを使用してリンクされます。このコンパイラは，OpenVMS Integrity Version 8.2 以降を必要とします。

OpenVMS Integrity サーバ用の HP Fortran のコマンド行オプションと言語機能は，以下の例外を除いて，OpenVMS Alpha システム用の HP Fortran 90 のものと同じです。

• 浮動小数点の計算
  要点は，ホワイト・ペーパー『Intel® Itanium® アーキテクチャにおける OpenVMS 浮動小数点演算について』を参照してください。このドキュメントは，次の Web サイトで参照できます。
  http://h71000.www7.hp.com/openvms/integrity/resources.html
  

• デフォルトの浮動小数点データ型は IEEEです。 (つまり，/FLOAT=IEEE_FLOAT がデフォルトです)。

• /IEEE_MODE 修飾子のデフォルト値は，/IEEE_MODE=DENORM_RESULTS です。

• ユーザは /FLOAT の値を 1 つと，/IEEE_MODE の値を 1 つ選択し，アプリケーション全体でその値を維持しなければなりません。

• F90 コンパイラだけがサポートされています。以前 /OLD_F77 修飾子で起動されていた F77 コンパイラは利用できません。 FDML や CDD のサポートなど， Alpha F77 コンパイラに含まれていて， Alpha F90 コンパイラでは利用できない一部の機能が， Integrity サーバ F90 コンパイラに実装されています。詳細は，Fortran V8.0 または V8.1 製品のリリース・ノートを参照してください。

• /ARCH 修飾子と /TUNE 修飾子での値 Alpha は，コンパイル・アンド・ゴーの互換性を保つために，コンパイラ起動コマンドで利用することができます。これらの値を無視したことを示す情報メッセージが表示されます。

インストール手順など，このリリースについての詳細は， Fortran V8.0 または V8.1 製品のリリース・ノートを参照してください。リリース・ノートを抽出するには， Fortran PCSI キットが置かれているディレクトリをデフォルトとして設定し，次のコマンドのいずれかを入力します。

$ PRODUCT EXTRACT RELEASE_NOTES FORTRAN ! For TXT file $ PRODUCT EXTRACT FILE FORTRAN/SELECT=FORTRAN_RELEASE_NOTES.PS ! For PS file

5.26 HP MACRO for OpenVMS

OpenVMS MACRO コンパイラは，OpenVMS VAX システム用に記述された Macro-32 ソース・コード (VAX MACRO アセンブラ) をコンパイルし， OpenVMS Alpha および OpenVMS Integrity システムで動作する機械語コードに変換します。ここでは，MACRO コンパイラに関する注意事項について説明します。

5.26.1 Macro-32 コンパイラの拡張

V8.4

Macro-32 コンパイラが拡張されており， OpenVMS Alpha および OpenVMS Integrity にインストラクション・レベルの新しいビルトインが含まれています。

表 5-1 に，追加された新しいビルトインを要約します。

表 5-1 Macro-32 の新しいビルトイン

ビルトイン	オペランド1	説明	サポート・プラットフォーム
EVAX_WH64	<AB>	Alpha 書き込みヒント 64 インストラクションを生成します。	Alpha
IA64_PADD1	<WQ,RQ,RQ>	最初の引数をデストネーションとし，次の 2 つの引数をソース・オペランドとして，シングルバイト形式で並列追加インストラクションを生成します。	Integrity
IA64_PADD1_SSS	<WQ,RQ,RQ>	最初の引数をデストネーションとし，次の 2 つの引数をソース・オペランドとして，シングルバイト形式で並列追加インストラクションを生成します。結果と両方のオペランドは signed として扱います。	Integrity
IA64_PADD1_UUS	<WQ,RQ,RQ>	最初の引数をデストネーションとし，次の 2 つの引数をソース・オペランドとして，シングルバイト形式で並列追加インストラクションを生成します。結果と最初のソース・オペランドは unsigned として扱います。 2 つめのソース・オペランドは signed として扱います。	Integrity
IA64_PADD1_UUU	<WQ,RQ,RQ>	最初の引数をデストネーションとし，次の 2 つの引数をソース・オペランドとして，シングルバイト形式で並列追加インストラクションを生成します。結果と両方のオペランドは unsigned として扱います。	Integrity
IA64_PADD2	<WQ,RQ,RQ>	最初の引数をデストネーションとし，次の 2 つの引数をソース・オペランドとして， 2 バイト形式で並列追加インストラクションを生成します。	Integrity
IA64_PADD2_SSS	<WQ,RQ,RQ>	最初の引数をデストネーションとし，次の 2 つの引数をソース・オペランドとして， 2 バイト形式で並列追加インストラクションを生成します。結果と両方のオペランドは signed として扱います。	Integrity
IA64_PADD2_UUS	<WQ,RQ,RQ>	最初の引数をデストネーションとし，次の 2 つの引数をソース・オペランドとして， 2 バイト形式で並列追加インストラクションを生成します。結果と最初のソース・オペランドは unsigned として扱い， 2 つめのソース・オペランドは signed として扱います。	Integrity
IA64_PADD2_UUU	<WQ,RQ,RQ>	最初の引数をデストネーションとし，次の 2 つの引数をソース・オペランドとして， 2 バイト形式で並列追加インストラクションを生成します。結果と両方のソース・オペランドは unsigned として扱います。	Integrity
IA64_PADD4	<WQ,RQ,RQ>	最初の引数をデストネーションとし，次の 2 つの引数をソース・オペランドとして， 4 バイト形式で並列追加インストラクションを生成します。	Integrity
IA64_MUX1	<WQ,RQ,RQ>	最初の引数をデストネーションとし，2 つのめ引数をソース・オペランドとして， 'mux1'インストラクションを生成します。 3 つめの引数は置換の実行を指定します。 2	Integrity
EVAX_S4ADDQ	<WQ,RQ,RQ>	Alpha 型クォドワード (すなわち 8 バイト) の追加インストラクションを生成します。	Alpha および Integrity
IA64_LFETCH_NT1, IA64_LFETCH_NT2, IA64_LFETCH_NTA, IA64_LFETCH_EXCL_NT1, IA64_LFETCH_EXCL_NT2, IA64_LFETCH_EXCL_NTA	<RQ,RQ>	これらの拡張されたプリフェッチ・ビルトインは，デフォルトでないキャッシュ位置ヒント (すなわち ".nt1"，".nt2"，および ".nta") を指定する手段を提供します。最初のオペランドはプリフェッチするアドレスで，2 つめのオペランドは reg-base-update-form か imm-baseupdate-form のどちらかのためのものです。オペランドが文字ゼロの場合，no-baseupdate- 形式が使用されます。	Integrity
IA64_LFETCH_FAULT_NT1, IA64_LFETCH_FAULT_NT2, IA64_LFETCH_FAULT_NTA, IA64_LFETCH_FAULT_EXCL_NT1, IA64_LFETCH_FAULT_EXCL_NT2, IA64_LFETCH_FAULT_EXCL_NTA		"FAULT" 付きの LFETCH インストラクションを生成します。	Integrity

---

¹ビルトインは，オペランド WQ - クォドワード書き込み， PQ - クォドワード読み取り，AB - バイトのアドレス，を必要とします。
² 置換を指定する文字は 3 つめの引数として使用される必要があります。文字に対する置換のマッピングは次のとおりです。

• BRCST 0

• MIX 8

• SHUF 9

• ALT 10

• REV 11

---

インストラクションの基本的な情報については，それぞれのハードウェア・アーキテクチャのマニュアルを参照してください。

5.26.2 OpenVMS Integrity 用 HP MACRO

V8.3

HP MACRO for OpenVMS Integrity コンパイラには，以下の注意事項があります。

• OpenVMS Version 8.3 よりも前のバージョンでは，コンパイラは HALT 命令に対して誤ったコードを生成していました。 Integrity プラットフォームでは， HALT 命令は Itanium の break命令と，予約リテラル値 BREAK$C_SYS_HALTを使用して実装されます。コンパイラの構築環境のバグにより， Macro-32 コンパイラが誤ったリテラル値を使用していました。この問題はバージョン 8.3 で修正されました。 HALT 命令を使用しているすべてのコードを，バージョン 8.3 のコンパイラで再コンパイルする必要があります。バージョン 8.3 よりも前のシステムでは，次のようにして正しい動作を実現することができます。

  $BREAKDEF IA64_HALT #BREAK$C_SYS_HALT ; Issue break instruction with correct literal HALT ; Use HALT builtin to inform compiler that this ends the flow of control

• コンパイラは， HALT， BPT，および EVAX_BUGCHKの前の命令を最適化によって除去する可能性があります。オプティマイザは，これらの命令が，ダンプ・ファイルを書き出したり，デバッグ環境に制御を渡すことで，すべてのレジスタを暗黙に読み込む特殊な命令になっていることを認識しません。使用されていないように見える命令は，誤って削除されます。これらの命令の特殊な動作についてコンパイラに通知する必要があります。任意の命令を最終的なオブジェクト・ファイルに残すように指示する構文はありませんが， IA64_LD8_A ビルトインを回避策として使用できます。このビルトインについては，次の Macro-32 の段落を参照してください。また， /NOOPTIMIZEを指定すると，使用されていないように見える命令も残りますが，コードの実行速度が遅くなり，またコードのサイズが大きくなります。

• コンパイラは，使用されていないように見えるメモリのロードを最適化によって除去することがあります。コンパイラのオプティマイザは，メモリのロード結果が使用されるかどうかを認識することができます。結果が使用されていないと判断されると，オプティマイザはメモリ・ロードを削除します。しかし，コードによっては，たとえば IPL を上げる前にページをメモリにページ・インさせるためにメモリのロードを使用している場合があります。そのような場合は，命令が除去されるとページがメモリにページ・インされなくなり，高い IPL での以降のコードで，高い IPL 例外での回復不可能なページ・フォルトが発生します。任意の命令を最終的なオブジェクト・ファイルに残すように指示する構文はありませんが， IA64_LD8_A ビルトインを回避策として使用できます。バージョン 8.3 で新たに追加された IA64_LD8_A ビルトインは，特別な形式の Itanium "ld8" 命令を生成し，フェッチされたアドレスを ALAT (Advanced Load Address Table) に格納します。コンパイラはこの特別な形式の "ld8" を，副作用を持ち，結果が使用されていないように見える場合でも最終的なオブジェクト・ファイルから削除できないものとして認識します。 ALAT にアドレスを挿入しても，問題が発生したり，他の変更が必要になることはありません。最終的なオブジェクト・ファイルに残す必要がある，使用されないメモリのロードについては，次のように変更します。

  MOVL (Rn),Rn

  
  から

  IA64_LD8_A Rn,(Rn),#0

  
  将来のリリースでは，最終的なオブジェクト・ファイルに残す必要がある命令を指定するための新しい構文がコンパイラに追加される予定です。
  バージョン 8.3 よりも前のシステムでは， IA64_LD8_A ビルトインはありません。唯一の回避策は， /NOOPTIMIZEを使用することです。

5.26.3 OpenVMS Alpha システム用の HP MACRO

V8.3

コンパイラは，使用されていないように見えるメモリのロードを最適化によって除去することがあります。コンパイラの新しいオプティマイザは，メモリのロード結果が使用されるかどうかを認識することができます。結果が使用されていないと判断されると，オプティマイザはメモリ・ロードを削除します。しかし，コードによっては，たとえば IPL を上げる前にページをメモリにページ・インさせるためにメモリのロードを使用している場合があります。そのような場合は，命令が除去されるとページがメモリにページ・インされなくなり，高い IPL での以降のコードで，高い IPL 例外での回復不可能なページ・フォルトが発生します。唯一の回避策は， /NOOPTIMIZEを使用するか，最適化機能を備えていない以前の Macro-32 コンパイラに戻ることです。

新しい Macro-32 コンパイラの名前は SYS$SYSTEM:MACRO.EXEであり， DCL MACROコマンドではこのイメージがデフォルトで起動されます。古いコンパイラは SYS$SYSTEM:ALPHA_MACRO.EXEにあります。 DCL コマンド MACRO で古いコンパイラを使用するには，論理名 MACRO を次のように定義します。

$ DEFINE MACRO SYS$SYSTEM:ALPHA_MACRO.EXE

5.26.4 /OPTIMIZE=VAXREGS 修飾子は Integrity サーバではサポートされない

V8.2

Alpha システムでサポートされていた /OPTIMIZE=VAXREGS 修飾子は， Integrity システムではサポートされません。残念ながら，関連するコードすべてがコマンド行処理から削除されてはいません。 Integrity システムで /OPTIMIZE=ALL を指定すると，サポートされていない VAXREGS 最適化を誤って起動することになります。今後のリリースで，コマンド行プロセスを修正して VAXREGS 最適化を起動しないようにする予定です。

5.26.5 浮動小数点数のゼロ除算エラーが検出されない (Integrity のみ)

V8.2

Macro-32 浮動小数点数サポート・ルーチンは，浮動小数点数のゼロ除算を検出しません。サポート・ルーチンでは，VAX 浮動小数点数を IEEE 浮動小数点数に変換して除算を実行します。チェック処理無しで，除算で IEEE の NaN 値 (非数値) が生成されます。サポート・ルーチンは，次に NaN 値を VAX 浮動小数点数に戻そうとします。この操作で，不正浮動小数点数のエラーになります。今後のリリースで，サポート・ルーチンが修正され，正しく浮動小数点数のゼロ除算エラーを検出するようになります。

5.27 Hypersort ユーティリティ

ここでは，OpenVMS Alpha および OpenVMS Integrity Version 8.2 用の Hypersort V08-006 に関する注意事項について説明します。

Hypersort で修正されていない問題を回避する場合，または Hypersort に実装されていない機能を使用する場合には，従来どおり SORT32 を使用してください。 SORT32 に関する注意事項は 第 5.39 節 を参照してください。

5.27.1 弊社への問題の報告

恒久的な条件

SORT や MERGE で問題を発見した場合は，問題を報告する前に，次のコマンドを実行してください。

$ WRITE SYS$OUTPUT "WSEXTENT =''F$GETJPI("","WSEXTENT")'" $ WRITE SYS$OUTPUT "PGFLQUOTA=''F$GETJPI("","PGFLQUOTA")'" $ SHOW LOGICAL SORTSHR $ SORT/STATISTICS (or MERGE/STATISTICS)

問題を再現する入力ファイルとともに，この出力を問題の報告に含めてください。

5.27.2 ラージ・ファイルの制限事項

V8.2

Hypersort V08-010 は，メモリ割り当てのアルゴリズムが改良されましたが，大規模な入力ファイルが使用されると，ハングアップしたり， ACCVIO が発生することがあります。ハングアップや ACCVIO が発生する可能性を低くするには， 第 5.27.8 項 に記載されているとおりにページ・ファイル・クォータとワーキング・セット・エクステントを設定します。 Hypersort でハングアップしたり ACCVIO が発生する場合は，代わりに SORT32 を使用してください。

5.27.3 Hypersort と VFC ファイルの制限事項

V7.3-2

Hypersort で VFC ファイルを使用するには，/FORMAT=RECORD_SIZE:n が必要です。

5.27.4 /FORMAT=RECORD_SIZE の制限事項

恒久的な制限事項

Hypersort では， SORT と MERGE の両方で使用する /FORMAT=RECORD_SIZE:n がサポートされます。ただし，次の 2 つの制限事項があります。

• すべての場合において，コマンドで指定した RECORD_SIZE の値が入力ファイル内の任意のレコードの最大レコード長 (LRL) よりも小さい場合，長すぎるレコードは，ソートされた出力ファイルで RECORD_SIZE のサイズまで切り捨てられ，診断メッセージ %SORT-E-BAD_LRL が発行されます。この場合は，出力ファイルを破棄し，ソートを再実行する必要があります。 SORT コマンドの RECORD_SIZE パラメータの値を，DIR/FULL コマンドを実行して表示される入力ファイルの最大レコードのサイズに合わせて修正してください。

• SORT や MERGE によって，入力索引順編成ファイルから出力順編成ファイルが作成されます。この場合，%SORT-E-BAD_LRL 診断メッセージも発行される場合があります。

5.27.5 Hypersort と検索リスト，および論理名の使用

恒久的な制限事項

Hypersort では，検索リスト，および入力ファイルと作業ファイルで使用される論理名のサポートが十分でありません。この問題を検出した場合は，SORT32 を使用してください。

5.27.6 作業ファイルの空き領域不足

恒久的な制限事項

すべてのソート作業ファイルで空き領域が無くなると，Hypersort が正しく終了しません。この問題を防ぐには，次のいずれかの処理を実行してください。

• ソートの作業ファイル用に使用するデバイスに，十分な空き領域を割り当てる。

• SORT32 を使用して，作業ファイルの領域を使い果たしたことを検出する。

5.27.7 入力アスタリスク (*) の制限事項

恒久的な制限事項

Hypersort では，入力ファイル指定にアスタリスク (*) を使用できません。

5.27.8 最適化されたワーキング・セット・エクステントとページ・ファイル・クォータの設定

恒久的な制限事項

SORT32 と Hypersort は，異なるソート・アルゴリズムと作業ファイル・アルゴリズムを使用します。これらのユーティリティの相対的な速度は，入力ファイルと，メモリ，ディスク，および CPU の構成によって異なります。ワーキング・セット・エクステントが，ページ・ファイル・クォータの 3 分の 1 を超えないようにしてください。 SORT32 と Hypersort はいずれも，個々の入力ファイルに合ったワーキング・セット・エクステントを使用することで，最高の性能を発揮します。

5.28 Intel® アセンブラ (Integrity のみ)

恒久的な制限事項

Intel アセンブラ言語で記述されたすべてのモジュールには，-Xunwind フラグによる自動生成を行うか，ソース・モジュールに明示的に unwind ディレクティブを記述する方法で，適切な unwind ディレクティブが含まれていなければなりません。正確な unwind 情報なしでは，オペレーティング・システムの条件処理と例外ディスパッチが動作せず，予期しない状態でプログラムが失敗することがあります。正確な unwind 情報を持たないプログラムは， OpenVMS ではサポートされていません。この前提条件は，恒久的な要件となります。

5.29 Librarian ユーティリティ

ここでは，Librarian ユーティリティと Library Service ルーチンに関する注意事項について説明します。

5.29.1 data-reduced ELF オブジェクト・ライブラリとのリンクは推奨できない (Integrity のみ)

V8.2

DCX data-reduced ELF オブジェクト・ライブラリは，ライブラリ内の連続領域には格納されません。その結果，最初にデータの展開を行う必要があるため，モジュールをプロセスの P2 空間に直接マッピングすることはできません。 LBR$MAP_MODULE ライブラリ・サービスが，モジュールを展開しプロセスの P2 空間にコピーします。この動作により，結果としてできた P2 空間内のページが，プロセス・クォータとしてカウントされます。

LBR$UNMAP_MODULE ライブラリ・サービスは，これらのページを回復しますが，これらのページはヒープ領域解放リストに残り，プロセス・クォータとしてカウントされ続けます。そのため，Linker 操作の前に，あらかじめ DCX data-reduced ELF オブジェクト・ライブラリを展開することをお勧めします。

5.29.2 Integrity サーバ・ライブラリへの .STB ファイルの挿入または置き換えの失敗 (Integrity のみ)

V8.2

OpenVMS VAX および Alpha では， .STB ファイルをオブジェクト・ライブラリに格納することができます。 OpenVMS Integrity では，Librarian はこの動作を行いません。例を次に示します。

$ LIBR/CREATE OBJ$:SOME_LIBRARY OBJ$:SOME_FILE.STB Librarian T01-23 %LIBRAR-E-NOTELFFILE, TPSSWRKD$:[TPSS.TRACE.IA64.LPIOBJ]TRACEMSG.STB;1 is not an ELF object or image file

.STB ファイルはオブジェクトでもイメージでもないため，現在 Librarian は，このファイルを Integrity システムの .OLB ファイルには格納しません。

ただし，Alpha と VAX では， .STB ファイルはオブジェクト・ファイルと同様の形式になっています。 VAX では，.STB ファイルを Linker への入力として使用することもできます。 Alpha では，.STB ファイルの形式は，.OBJ ファイルの形式と同じです (つまり，ファイル拡張子が .STB であること以外は，これらのファイルに違いはありません)。そのため，Alpha の Librarian はこのファイルを受け付けますが， Linker の入力として使用することはできません。

Integrity サーバでは， .STB ファイルにファイル・タイプ (ET_VMS_LINK_STB) が埋め込まれます。これにより，Librarian と Linker が， .STB ファイルを処理できないことを判断できます。これは恒久的な状態です。

5.29.3 プロセス・クォータが低すぎると Librarian がエラーを通知しない問題

恒久的な制限事項

OpenVMS Alpha および Integrity の Librarian は圧縮，データ・リダクション，データ拡張操作でエラーを通知しないことがあります。この問題が発生するのは，Librarian が動作しているアカウントまたはプロセスの PGFLQUOTA プロセス・クォータが低い場合です。 $PUTMSG システム・サービスは，エラーが発生した場合でも必ず SS$_NORMAL というステータスを返すので，操作エラーがただちに明らかになりません。しかし，エラーが発生した場合には， Librarian は Success 以外のステータスを返します。

この問題を回避するには，PGFLQUOTA を増加させてから圧縮，データ・リダクション，データ拡張操作を実行します。さらに，コマンド・プロシージャで LIBRARY コマンドからの戻りステータスを確認するようにしてください。

5.30 OpenVMS Alpha 用 Linker ユーティリティ

ここでは，すべての OpenVMS プラットフォーム上での Alpha Linker ユーティリティに関する注意事項について説明します。 Integrity Linker に関する注意事項は 第 5.31 節 を参照してください。

5.30.1 SYMBOL_VECTOR リンカ・オプションの制限事項

恒久的な制限事項

SYMBOL_VECTOR リンカ・オプションを使用して汎用宣言したい共有イメージのシンボル名あるいはプログラム・セクション名は， TPA$_SYMBOL シンボル・タイプに属する文字で構成されていなければなりません。 TPA$_SYMBOL シンボル・タイプは下記の文字で構成されます。
A から Z の英字 (大文字および小文字)，ドル記号($)，アンダースコア(_)，コード 192 よりも大きな DEC 多国語文字。

次の例では，TPA$_SYMBOL シンボル・タイプに属さない文字 '~' がプロシージャ名に含まれています。このため，SYMBOL_VECTOR リンカ・オプションが次のようなエラー・メッセージを表示しています。

$ LINK/SHARE SOME_LIBRARY, SYS$INPUT/OPT SYMBOL_VECTOR=(WRONG~NAME=PROCEDURE) %ILINK-F-OPTSYNERR, syntax error in options file SYS$INPUT:.; -ILINK-E-OPTLIN, options line in error SYMBOL_VECTOR=(WRONG'~'NAME=PROCEDURE)

5.30.2 多数のファイルを指定した場合に Linker がハングアップしたように見える

V8.3

RMS_RELATED_CONTEXT リンカ・オプションがオン (デフォルトは RMS_RELATED_CONTEXT=YES) で，存在しないファイルが LINK コマンドのファイル・リストに指定されていた場合，リンカによる LIB$FIND_FILE の呼び出しは完了するまでに長時間かかり，リンカがハングアップしたように見えることがあります。リンクしているファイルの数と，ファイル指定での論理名の使用状況に応じて，リンカの処理が完了するまでに数時間かかることもあります。これは LIB$FIND_FILE が，不明ファイルについてプレフィックスの組み合わせをすべて探してから， "file not found" メッセージを表示するためです。リンカが LIB$FIND_FILE を呼び出した後は， Ctrl/Y を押してもリンカを終了させることはできません。

どのファイルが不明かを調べるには，『Linker Manual』の第 4 部「LINK Command Reference」の RMS_RELATED_CONTEXT= オプションの説明に記載されている手順を使用します。

5.30.3 ライブラリ・チェックにおける Linker のデフォルト動作の変更

V7.3-1

これまでの Linker では，ライブラリと共有イメージ間の一致条件が厳密に検証されていましたが ( 正確な日時を照合し，該当するものがない場合は， LINK-I-DATMISMCH シグナル通知を発行)，このリリースでは，イメージ・アクティベータと同じ検証 (GSMATCH 条件を使用して互換性を検証) だけが実行されます。

以前の動作 (日時の照合) を実行する場合は， LINK$SHR_DATE_CHECK 論理名を設定してください。

詳細は，『Linker Manual』の第 4 部「LINK Command Reference」の /LIBRARY 修飾子を参照してください

共用可能イメージ・ライブラリには，イメージのコピーは格納されていません。格納されているのは，イメージの名前，イメージの識別情報，イメージのユニバーサル・シンボルが格納されたテーブルです。識別情報は，共用可能イメージをリンクする際に GSMATCH=オプションで指定します。詳細は，『Linker Manual』の第 4 部「LINK Command Reference」の GSMATCH=オプションを参照してください。

共用可能イメージを再リンクしても，ライブラリが更新されない場合があります。このような場合に対処するために，リンカは互換性を確認します。リンカは，イメージ・アクティベータが行うのと同じように， GSMATCH条件を使用して互換性を確認します。

VAX では，リンカは日付と時刻も比較し，違っている場合には LINK-I-DATMISMCHを生成します。

Alpha では，リンカの最初の動作は VAX のリンカと同じでした。しかし，このチェックは厳し過ぎると判断され，デフォルトでは GSMATCH 条件だけを使用するように変更されました。論理名 LINK$SHR_DATE_CHECKを定義すると， VAX と同じ以前の動作になります。

5.30.4 スタックのエレメント数は最大 25 に制限

恒久的な制限事項

オブジェクト・ファイルを作成する開発者は，Linker の内部スタックのエレメント数が最大 25 に制限されていることに注意しなければなりません。どのような計算も，この制限の範囲内で実行しなければなりません。

5.31 OpenVMS Integrity 用 Linker ユーティリティ

ここでは，Integrityサーバ用 Linker ユーティリティに関する注意事項について説明します。

Alpha Linker に関する注意事項は， 第 5.30 節 を参照してください。

5.31.1 SYMBOL_VECTOR リンカ・オプションの制限事項

恒久的な制限事項

SYMBOL_VECTOR リンカ・オプションの制限事項については 第 5.30.1 項 を参照してください。

5.31.2 正しくないイメージ間デバッグ・フィックスアップをリンカがデバッグ・シンボル・ファイルに書き込む

V8.3-1H1

状況によっては，リンカは OpenVMS デバッガ用のイメージ間フィックスアップを作成します。イメージ間デバッグ・フィックスアップは，リンカが解決できない，コンパイラが生成したデバッグ再配置の結果です。つまり，共用可能イメージに格納されている値を実行時に調べるために，デバッガはこれらのフィックスアップを必要とします。デバッガ用にイメージ間フィックスアップをリンカに作成させることが必要となる頻度は，コンパイラによって異なります。 C コンパイラはイメージ間デバッグ・フィックスアップをめったに使用しませんが， C++ コンパイラは頻繁に使用します。このようなイメージを /DEBUG 修飾子付きでリンクすると，リンカはデバッグ情報の後にイメージ間デバッグ・フィックスアップを書き込みます。 /NODSF 修飾子 (デフォルト) を使用すると，情報はイメージ・ファイルに正しく書き込まれますが，/DSF を指定すると，誤ってDSF ファイルに書き込まれることがあります。

たとえば，次の例の DEBUG 情報と DEBUG エラーは，リンカが誤ってDSF ファイルへ書き込んだために表示されます。

$ RUN/DEBUG MINIREF %DEBUG-I-INFODWARF, error reading Dwarf info: Section 0a extends outside file %DEBUG-I-INFODWARF, error reading Dwarf info: Section 0c extends outside file %DEBUG-I-INFODWARF, error reading Dwarf info: SHT_VMS_FIXUP section 10 size 17eb e0 not multiple of 18 %DEBUG-I-INFODWARF, error reading Dwarf info: SHT_VMS_FIXUP section 12 size 17ec 30 not multiple of 18 OpenVMS I64 Debug64 Version V8.3-003 %DEBUG-F-ACCVIO, access violation, reason mask=00, virtual address=000000000014A 000, PC=000000007BD73100, PS=0000001B %DEBUG-I-INITIAL, Language: C, Module: MINIREF DBG> The image file is not affected; it can be executed with the RUN command without any problem: $ RUN MINIREF

この誤りは OpenVMS V8.3-1H1 のLinkerで修正されました。

5.31.3 /SELECTIVE_SEARCH がトランスファー・アドレスを誤って無視することがある

V8.3-1H1

トランスファー・アドレスが含まれている Integrity サーバ・オブジェクト・モジュールがあり， /SELECTIVE_SEARCH 修飾子を指定したリンク操作にそのモジュールを含めると，リンカはそのトランスファー・アドレスを検出しませんでした。

次の例では，オブジェクト・モジュール (MAIN.OBJ) にトランスファー・アドレスが含まれていますが，/SELECTIVE_SEARCH によって無視されます。

$ LINK MAIN/SELECTIVE_SEARCH %ILINK-W-USRTFR, image USER:[JOE]MAIN.EXE;1 has no user transfer address

この状態になるのは，プログラムのトランスファー・アドレスを提供することを意図した Integrity サーバ・オブジェクト・モジュールが，SELECTIVE_SEARCH 属性を使用したリンク操作に含まれている場合だけです。次の例のように，LINK コマンドまたは LIBRARY コマンドでオブジェクト・モジュールに /SELECTIVE_SEARCH修飾子を指定すると， SELECTIVE_SEARCH 属性がオブジェクト・モジュールに与えられます。

$ LINK MAIN/SELECTIVE_SEARCH

または

$ LIBRARY/INSERT LIB.OLB MAIN.OBJ/SELECTIVE_SEARCH

このライブラリに含まれているモジュールを，リンク操作で参照を解決するために使用します。暗黙的に使用する例を次に示します。

$ LINK/EXECUTABLE=MAIN SUBROUTINES.OBJ, LIB.OLB/LIBRARY

明示的に使用する例を次に示します。

$ LINK/EXECUTABLE=MAIN SUBROUTINES.OBJ, LIB.OLB/INCLUDE=MAIN

この問題は，以下のどちらかの形で現れます。

• リンカが警告メッセージを表示する場合。この状態になるのは，リンク操作の他のオブジェクト・モジュールが (weak かどうかにかかわらず) トランスファー・アドレスを提供しない場合です。

• リンカがメッセージを表示しない場合。この状態になるのは，リンク操作の他のオブジェクト・モジュールが (weak かどうかにかかわらず) トランスファー・アドレスを提供する場合です。選択的に検索されたオブジェクト・モジュールからトランスファー・アドレスを見つけることができないと，リンカは他のオブジェクト・モジュールのトランスファー・アドレスを選択します。そのトランスファー・アドレスは，意図せずにそのイメージのメイン・エントリ・ポイントとなります。マップ・ファイルには，リンカが正しくない遷移モジュールとトランスファー・アドレスを割り当てたことが出力されますが，実際にアプリケーションを実行するまで問題に気づかない可能性があります。
  この誤りは OpenVMS V8.3-1H1 のリンカで修正されました。

5.31.4 最大セクション数

V8.3-1H1

65280 を超えるセクションに対しては，ELF 形式は拡張された番号付け方式を使用します。これは，OpenVMS Integrity V8.3 の Linker では実装されていませんでした。そのため，単一の入力オブジェクト・モジュールまたは共用可能イメージが持つことのできるセクションの数が制限されていました。通常リンカは複数のセクションを持つ共用可能イメージを作成するため，この制限は共用可能イメージを作成する際にも適用されます。ここで，ELF セクションは，C++ テンプレートや共用セクションをエクスポートするために使用されます。つまり，共用可能イメージ中のそのようなインタフェースの数は 65280 未満でなければなりませんでした。

OpenVMSV8.3-1H1 I64 Linker では，この制限はなくなりました。入力ファイル，オブジェクト・モジュール，あるいは共用イメージは， 65280 を超えるセクションを持つことができます。

5.31.5 マップ・ファイル中の共用可能イメージの作成日が正しくない

V8.3-1H1

OpenVMS Integrity プラットフォームでは，リンカ・マップ中の共用可能イメージの作成日が正しくない場合がありました。誤った日付は，通常 3686 と表示されます。この状態になるのは，リンカが共用可能イメージを入力ファイルとして処理し，日付フィールドを抽出してマップに出力した場合です。 ANALYZE/IMAGE で表示されるイメージ自体の日付は正しい内容になっています。

この誤りは OpenVMS V8.3-1H1 で修正されました。

5.31.6 demangler 情報を検索するとアクセス違反になる

V8.3-1H1

状況によっては，共用可能イメージ内に demangler 情報がないにもかかわらず，リンカでその情報の検索を試みると，リンカがアクセス違反で異常終了することがありました。

この問題は OpenVMS V8.3-1H1 で修正されました。

5.31.7 NOGLOSYM エラー・メッセージに対する誤った二次メッセージ

V8.3-1H1

NOGLOSYM エラー・メッセージに対して，OpenVMS Integrity V8.3 の Linker は誤った再配置タイプを表示し，一部の情報を 2 度表示していました。

この問題は OpenVMS V8.3-1H1 で修正されました。

5.31.8 未定義シンボルについての誤った情報

V8.3-1H1

未定義シンボルに対する USEUNDEF 操作によって，同一の参照についての情報が誤って 2 回表示されることがありました。この問題は，コンパイラが未定義シンボルへの参照について，再配置ペア (LTOFF22X/LDXMOV) を生成した場合に発生します。

この問題は OpenVMS V8.3-1H1 で修正されました。

5.31.9 誤った UNMAPFIL エラー

V8.3-1H1

ELF でない入力ファイルがあると，リンカは INVLDHDR エラー・メッセージを表示していました。そして INVLDHDR エラーの後には，誤った UNMAPFIL エラー・メッセージを表示していました。

この問題は OpenVMS V8.3-1H1 で修正されました。

5.31.10 共用可能イメージ・マップ内の識別子の最大長の変更

V8.3-1H1

リンカ・マップでは，リンカはオブジェクト・モジュールと共用可能イメージについて，最大で 14 文字の識別子をプリントしていました。本来は，オブジェクト・モジュールの識別子は無制限で，共用可能イメージの識別子は 15 文字です。

V8.3-1H1 Linker は，共用可能イメージの識別子として，最大で 15 文字プリントするようになりました。

5.31.11 共用可能イメージに対するリンケージ・タイプ・チェック

V8.3-1H1

これまで，リンカは共用可能イメージのシンボルに対して，タイプとリンケージのチェックを行っていませんでした。

OpenVMS V8.3-1H1 では，このチェックを行うようになりました。

5.31.12 プログラム・セクションの ABS 属性が無視される

V8.3-1H1

Integrity サーバでは，オフセットを定数に変換するためのラベルを持つプログラム・セクション (PSECT) には ABS 属性を設定できません。リンカにより次のようなエラー・メッセージが表示されます。

%ILINK-E-ILLABSPSC, absolute psect <psect-name> has non-zero length (not allowed)

OpenVMS 8.3-1H1 Linker は ABS プログラム・セクション属性を無視し，次のような情報メッセージを表示します。

%ILINK-I-PSCATTIGN, psect attribute ABS is not supported for OpenVMS ELF sections, attribute ignored

5.31.13 コマンド行に FP_MODE リテラルを指定していないとリンカはアクセス違反となる

V8.3-1H1

OpenVMS V8.3では，コマンド行に FP_MODE リテラルを指定していないと， Integrity サーバ Linker はアクセス違反になっていました。

この問題は OpenVMS V8.3-1H1 で修正されました。

5.31.14 OpenVMS Integrity のオブジェクト・モジュールとイメージ・ファイルの情報が現在利用できない

V8.3

Integrity サーバ上のオブジェクト・モジュールとイメージ・ファイルの形式である ELF (Executable and Linkable Format) に対する OpenVMS Integrity の拡張についての情報は，現時点では公開しておりません。将来のリリースで提供されます。

Alpha または VAX のオブジェクト言語形式についての詳細は，『OpenVMS Alpha/VAX Version 7.3 OpenVMS Linker Utility Manual』のそれぞれに対応した付録を参照してください。このこのマニュアルは，次の URL で入手できます。

http://h71000.www7.hp.com/doc/os732_index.html

5.31.15 Integrity リンカと Alpha リンカの違い

V8.3

OpenVMS Integrity Linker と OpenVMS Alpha Linker の違いに関する詳細な説明については，『HP OpenVMS V8.3 新機能説明書』を参照してください。『HP OpenVMS V8.3 新機能説明書』には，OpenVMS Integrity Linker の新機能についての説明もあります。

5.31.16 LINK_ORDER セクション・ヘッダ・フラグはサポートされていない

V8.2

Linker は， ELF セクション・ヘッダ・フラグ LINK_ORDER をサポートしていません。ただし，このフラグが設定されている unwind セクションは，正しい順序で配置されます。

このフラグは，セクションがイメージ・ファイル内の他のセクションと結合される場合，参照先のセクションが結合される順序と同じ順序で結合しなければならないことを示します。 unwind セクションは，特別なケースとして扱われ，正しい順序で現れます。

次の図に，この概念を図示します。

---

5.31.17 data-reduced ELF オブジェクト・ライブラリとのリンクは推奨できない

V8.2

DCX data-reduced ELF オブジェクト・ライブラリは，ライブラリ内の連続領域には格納されません。その結果，最初にデータの展開を行う必要があるため，モジュールをプロセスの P2 空間に直接マッピングすることはできません。 LBR$MAP_MODULE ライブラリ・サービスが，モジュールを展開しプロセスの P2 空間にコピーします。この動作により，結果としてできた P2 空間内のページが，プロセス・クォータとしてカウントされます。

LBR$UNMAP_MODULE ライブラリ・サービスは，これらのページを回復しますが，これらのページはヒープ領域解放リストに残り，プロセス・クォータとしてカウントされ続けます。そのため，Linker 操作の前に，あらかじめ DCX data-reduced ELF オブジェクト・ライブラリを展開することをお勧めします。これは恒久的な状態です。

5.31.18 初期化されたオーバレイ・プログラム・セクションの取り扱いについての誤りの修正

V8.3

以前のバージョンの Integrity 版 Linker では， 0 で初期化されたオーバレイ・プログラム・セクションは，誤って，互換性のある初期化と見なされていました。 OpenVMS Version 8.2 と Version 8.2-1 の Integrity Linker では 0 で初期化されたセクションは 0 以外の初期値を持つセクションと互換性があると見なされます。そのため，リンク操作時のモジュールの順番によっては，イメージに異なる初期値が設定されることがあります。

この問題は，Version 8.3 で修正されました。

5.31.19 リンカの修飾子 /EXPORT_SYMBOL_VECTOR と /PUBLISH_GLOBAL_SYMBOLS の削除

V8.3

すべてのグローバル・シンボルをエクスポートするだけで共用可能イメージを作成しても，それだけではうまくいきません。以前のバージョンの Integrity 版の Linker は， /EXPORT_SYMBOL_VECTOR 修飾子と /PUBLISH_GLOBAL_SYMBOLS 修飾子を提供しており，すべてのグローバル・シンボルのシンボル・ベクタ・オプションをモジュール単位に作成できました。ただし，これらの修飾子を使用すると，異なるイメージに格納されている同じユニバーサル・シンボルがエクスポートされます。異なるイメージに格納されている同じ C++ テンプレートがエクスポートされてしまうことを除外できないため，これは問題になります。

どちらの修飾子も Version 8.3 から削除されました。

この問題は，OpenVMS Integrity の将来のリリースの Integrity Linker で修正される予定です。

5.31.20 オプションでの長いシンボル名のサポート

V8.3

オプション用として，リンカの内部ライン・バッファが，2048 文字に拡大されました。これにより，最大サポート長が 1024 文字のシンボル名とともにオプションを指定できるようになりました。

5.31.21 リンカが作成したコード・スタブのメモリの使用方法の改善

V8.3

Integrity 版 Linker は， OpenVMS Debugger でのコードのステップ実行でも参照可能であるコード・スタブを生成します。コードはルーチン呼び出しに対して挿入され，そのサイズは異なることがあります。しかし，以前のリンカは，必要となりうる最大コード・サイズを使用して，固定サイズのコード・セクションとしてコードを追加していました。

バージョン 8.3 のリンカは，コード・スタブを実サイズで書き込みます。これにより，スタブ間の未使用スペースが無くなるため，未使用のメモリが解放される可能性があります。

5.31.22 コンパイラでのデマングル化されたシンボル名のサポート

V8.3

シンボル名を固有のものにするために，一部のプログラミング言語では名前のマングル化が使用されています。バージョン 8.3 からは，リンカはソース・コード名と呼ばれる，デマングル化された名前を表示しようとします。これらの名前は，リンカのメッセージに使用されます。また，要求によって，リンカ・マップに表示されるマングル化されたグローバル・シンボルの変換テーブルでも使用されます ( 『HP OpenVMS V8.3 新機能説明書』を参照)。この機能は，コンパイラでの名前のデマングル化のサポートに依存しています。

5.32 LTDRIVER: CANCEL SELECTIVE の制限事項

恒久的な制限事項

OpenVMS Version 6.1 より前のリリースでは，LTDRIVER は「拡張 DDT」ビットをセットしていませんでした。したがって，POSIX 関数 CANCEL SELECTIVE は LTDRIVER で動作しませんでした。この問題は解決されましたが，まだ制限事項が残っています。

この修正により，$QIO 読み込みと書き込みを選択的に取り消すことができるようになりましたが，ポート・ドライバに対して行った $QIO (つまり， LAT 接続 $QIO などのように IO$_TTY_PORT 関数修飾子を使用して行ったもの) は， CANCEL SELECTIVE によって取り消すことができません。

5.33 Mail ユーティリティ: 呼び出し可能メールのスレッドの制限事項

V7.1

OpenVMS 呼び出し可能メール・ルーチンはスレッド・セーフでは ありません。スレッド化されたアプリケーション内での非スレッド・セーフ・ルーチンの呼び出しの詳細については，『Guide to the POSIX Threads Library』を参照してください。

呼び出し可能メールのコンテキスト情報は，プロセス単位(スレッド単位ではない) で管理されるので，コンテキスト・ベースの処理を実行する複数のスレッドは相互に同期をとり，特定のタイプのメール・コンテキストが一度に 1 つ だけアクティブになるようにしなければなりません。この条件が満たされないと，1 つのスレッドが他のスレッドのメール操作を妨害する可能性があります。

OpenVMS Alpha システムでは，マルチスレッド環境でカーネル・スレッドが有効に設定されている場合，この他にも追加制限事項があります。この環境では，呼び出し可能メールは初期スレッドでのみ使用しなければなりません。

5.34 OpenVMS のシステム・ダンプ・アナライザ (SDA)

ここでは，システム・ダンプ・アナライザ (SDA) に関する注意事項について説明します。

5.34.1 CLUE コマンドは OpenVMS Integrity に移植されていない

V8.2

次の CLUE コマンドは，OpenVMS Integrity にはまだ移植されていないため，その旨のメッセージを返します。

CLUE CALL
CLUE ERRLOG
CLUE FRU
CLUE REGISTER

---

目次

索引