日本-日本語
≫日本HPホーム ≫製品 & サービス ≫OpenVMS製品情報
≫  お問い合わせ


OpenVMS マニュアル
≫ 

OpenVMSマニュアル
ライブラリ

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

HP OpenVMS
V8.4 リリース・ノート【翻訳版】
目次 索引


V8.2

PL/I ライブラリ (ネイティブ・ライブラリと変換されたライブラリ) は， OpenVMS Alpha には含まれていましたが OpenVMS Integrity には含まれていません。 PL/I コア・イメージのうち OpenVMS Integrity にないものは以下のとおりです。

[SYSLIB]DPLI$RTLSHR.EXE
[SYSMSG]PLI$MSG.EXE
[SYSLIB]PLIRTL.IIF
[SYSLIB]PLIRTL_D56_TV.EXE

PL/I ライブラリを参照するアプリケーションや共有イメージは， Integrity サーバ用の OpenVMS Integrity では動作しません。 (一般的に，PL/I で記述したコードを含むアプリケーションや共有イメージがそうです。) この制約は，ネイティブ・コードにも，変換された VAX および Alpha イメージにも，適用されます。

第 2.12 節 の，関連する注意事項を参照してください。

5.36 POSIX スレッド・ライブラリ

ここでは，POSIX スレッド・ライブラリ (旧名称は，DECthreads) に関する注意事項について説明します。

5.36.1 プロセス共有オブジェクトのサポート

V8.2

OpenVMS Alpha および OpenVMS Integrity 上の POSIX スレッド・ライブラリは，プロセス共有のミューテックスと条件変数をサポートします。

  注意
ミューテックスと条件変数に対するプロセス共有の読み書きロックは Tru64 システムでのみサポートされます。

OpenVMS でサポートされる pthread ルーチンは以下のものです。

  • pthread_condattr_getpshared

  • pthread_condattr_setpshared

  • pthread_mutexattr_getpshared

  • pthread_mutexattr_setpshared



5.36.2 pthread_mutex_lock の新しい戻り状態値

V8.2

POSIX スレッド・ライブラリ pthread_mutex_lock をプロセス共有ミューテックスと使用すると新しいエラー状態 EABANDONED を返します。この状態は，ミューテックスを所有しながらプロセスが終了した場合のみ返されます。

5.36.3 新しい API pthread_mutex_tryforcedlock_np のサポート

V8.2

POSIX スレッド・ライブラリは，新しい API pthread_mutex_tryforcedlock_np をサポートします。 pthread_mutex_tryforcedlock_np API は，解放されたプロセス共有ミューテックスの所有権を待ちます。

構文 

pthread_mutex_tryforcedlock_np(mutex);

引数 データ型 アクセス
mutex opaque pthread_mutex_t read

C バインディング 

#include <pthread.h> 
int 
pthread_mutex_tryforcedlock_np ( 
          pthread_mutex_t *mutex);

引数 

mutex 
Mutex to be locked.

説明

プロセス共有オブジェクトにより，ミューテックスや条件変数などのオブジェクトを複数のプロセス間で共有することができます。ミューテックスを所有しながらプロセスが終了した場合，そのミューテックスは，終了したプロセスが所有したままの状態になります。このため，他のスレッドあるいはプロセスがそのミューテックスを所有することはできません。

しかし，オプションのシステム・サービスとして sys$pshared_registerが用意されています。このシステム・サービスを使用すると，終了したプロセスが所有しているミューテックスを解放することができます。

この場合，pthread_mutex_lock の呼び出しで EABANDONED が返され，アプリケーションは pthread_mutex_tryforcedlock_n を呼び出して解放されたミューテックスの所有権を取得することができます。

戻り値

エラー状態が発生すると，このルーチンはエラーのタイプを示す整数値を戻します。次のような戻り値があります。

戻り値 説明
0 正常終了
[EPERM] そのミューテックスは解放されておらず，他のスレッドが所有している。
[EINVAL] そのミューテックスはプロセス共有ミューテックスではない。
[ENOSYS] 不正なシステム・サービスがコールされた。



5.36.4 例外処理中のスタック・オーバフロー (Integrity のみ)

V8.2

Integrity サーバでの例外処理には， Alpha システムの場合よりもかなり大きなスタック領域が必要です。 OpenVMS からアプリケーションを移植するときに，例外処理を使用するスレッドに未使用スタック領域が十分にないと， Integrity サーバでの例外処理中に，このスレッドでスタック・オーバフローが発生することがあります。通常は，次の操作のいずれかに関連する ACCVIO の処理が不適切であったように見えます。

  • RAISE

  • pthread_cancel

  • pthread_exit

  • スレッドにアクティブな TRY または pthread_cleanup_push ブロックがあり， OpenVMS の状態がシグナル通知された (たとえば，ハードウェア例外や， LIB$SIGNAL または LIB$STOP の使用など)。

このような問題が発生した場合は，スレッドに割り当てられるスタックのサイズを数ページずつ増やしてみてください。最初は，スタックのサイズを 24 KB 大きくすることをお勧めします。

デフォルトのスタック・サイズは， Integrity サーバでのスタック使用量が多いことに対応するため， 24 KB 大きくされました。アプリケーションが多数のスレッドをデフォルトのスタック・サイズで作成している場合，アプリケーションのメモリ・リソースが不足することがあります。このような状況になった場合は，プロセス・クォータを大きくするか，アプリケーションを変更して同時に存在するスレッドの数を減らしてください。

5.36.5 Integrity サーバでの THREADCP コマンドの動作

V8.2

OpenVMS Integrity システム上の DCL コマンド THREADCP は，スレッド関連の 2 つのメイン・イメージ・ヘッダ・フラグ， UPCALLS と MULTIPLE_KERNEL_THREADS の問い合わせや変更には使用できません。代わりに， Integrityサーバでのスレッド・ヘッダ・フラグの設定や参照を行うための DCL コマンド SET IMAGE および SHOW IMAGE を使用する必要があります。

Alpha システムのユーザは，引き続き THREADCP コマンドを使用してください。

5.36.6 浮動小数点のコンパイルと例外 (Integrity のみ)

V8.2

次の 2 つの古い cma スレッド・ライブラリ・ルーチンのいずれかを呼び出すソース・モジュールは， OpenVMS Integrity 上で使用するために /FLOAT=G_FLOAT コンパイラ修飾子 (または，言語固有の同等の修飾子) を指定してコンパイルしなければなりません。 

cma_delay() 
 
cma_time_get_expiration()

これらのルーチンは， VAX 形式の浮動小数点数だけを引数として受け入れます。通常，OpenVMS Integrity コンパイラは，デフォルトで VAX 形式を使用する OpenVMS Alpha コンパイラとは異なり，デフォルトで IEEE 形式の浮動小数点数を使用します。この 2 つの cma スレッド・ルーチンは，Alpha と Integrity のどちらでも， VAX 形式の浮動小数点引数だけを受け入れます。これらのルーチンの呼び出しを適切にコンパイルしないと， IEEE 形式の浮動小数点数が実行時に誤って渡され，予期しない例外が発生することがあります。

5.36.7 C 言語コンパイル・ヘッダ・ファイルの変更

V7.3-2

OpenVMS Version 7.3-2 では，次の変更が行われました。

  • INTS.H
    OpenVMS の以前の一部のリリースでは，POSIX スレッドの C 言語ヘッダ・ファイル PTHREAD_EXCEPTION.H に， C ヘッダ・ファイル INTS.H の #include が誤って含まれていました。この問題は，OpenVMS Version 7.3-2 で修正されました。 PTHREAD_EXCEPTION.H を使用しても，コンパイルで INTS.H がインクルードされなくなりました。アプリケーションによっては，コンパイル時に INTS.H が必要で， PTHREAD_EXCEPTION.H でインクルードされることを誤って前提としているものがあるかもしれません。
    このようなアプリケーション・ソース・モジュールを OpenVMS Version 7.3-2 システムで再コンパイルすると， C コンパイラから診断メッセージが出力されます。これらのメッセージは，INTS.H で定義されるシンボルやデータ型 (たとえば int32) が未定義であることを示します。このようなアプリケーション・ソース・モジュールを修正するには，該当するシンボルや型を最初に使用している位置より前で，直接 <ints.h>を #include します。

  • timespec_ttypedef
    以前のリリースの OpenVMS では， POSIX スレッドの C 言語ヘッダ・ファイル PTHREAD.H に， timespec_tという名前の typedef 定義が入っていました。このシンボルは，PTHREAD.H に属さない，非標準のシンボルです。 (この typedef は，TIME.H や TIMERS.H などの C RTL ヘッダ・ファイルの内容との関連で残されていました。) OpenVMS Version 7.3-2 では，C RTL とスレッド・ヘッダ・ファイルの標準への準拠性が改善されました。この結果，PTHREAD.H から timespec_tの typedef が削除されました。
    アプリケーションによっては， timespec_tの typedef がコンパイル時に必要で， PTHREAD.H で直接的または間接的 (たとえば，TIS.H の使用による) に定義されることを誤って前提としているものがあるかもしれません。このようなアプリケーション・ソース・モジュールを OpenVMS Version 7.3-2 システムで再コンパイルすると， C コンパイラから， timespec_tを未定義のシンボルまたは型としてリストする診断メッセージが出力されます。このようなアプリケーション・ソース・モジュールを修正するには， timespec_tを使用している部分を timespec構造体に置き換えるか， timespec_tシンボルを最初に使用している位置より前で， C RTL ヘッダ・ファイル TIMERS.H をインクルードします。
    アプリケーションの構築環境で古い C RTL やスレッド・ヘッダ・ファイルのプライベート・コピーを使用していたり， timespec構造体や timespec_ttypedef を含む抜粋を使用している場合 (どちらの方法もお勧めできません) は，もっと多くのコンパイル・エラーが表示されることがあります。コンパイラは， timespec構造体が再定義されている (2 回定義されている) ことを示すメッセージを表示することがあります。このような場合，システムが提供している C RTL およびスレッド・ヘッダ・ファイルを使用するように戻したり， timespec構造体に関連して個別に抜粋した個所を，システムが提供している TIME.H ヘッダ・ファイルのインクルードに変更します。



5.36.8 新しい優先順位調整アルゴリズム

V7.3-2

OpenVMS Version 7.3-2 では，『Guide to the POSIX Threads Library』で説明されている適応型スレッド・スケジューリング動作が，新しい優先順位調整アルゴリズムとともに実装されました。場合によっては，新しいアルゴリズムでは，優先順位が異なる，スループット方針のスレッドが同期オブジェクトを共用することによる問題を回避できます。優先順位の調整により，アプリケーションのスループットや，システム全体の使用状況も改善できます。スループット・スケジューリング方針のスレッドの優先順位調整は，自動で，透過的に行われます。

5.36.9 プロセス・ダンプ

V7.3

POSIX スレッド・ライブラリで実行時に修正不能な重大エラー (アプリケーション内のデータ破損によって損傷したデータ構造など) が検出されると，ライブラリにより実行中のイメージが終了されることがあります。終了中に，ライブラリによりプロセス・ダンプ・ファイルの作成がトリガーされます (このファイルは， ANALYZE/PROCESS_DUMP によりエラー診断に使用されます)。このようなプロセス・ダンプ・ファイルのサイズは，エラー時のプロセスのアドレス空間に依存するため，非常に大きくなることがあります。

5.36.10 動的 CPU 構成の変更

V7.3

OpenVMS Version 7.3 以降，POSIX スレッド・ライブラリは，マルチプロセッサ Alpha システムを実行する CPU の数の動的変化に対応するようになりました。 1 つのイメージに対して，複数のカーネル・スレッドが使用できるように指定 (LINK/THREADS_ENABLE 修飾子または THREADCP コマンド動詞により) すると， POSIX スレッド・ライブラリが，アプリケーションの明白な並列処理を監視して，利用可能な CPU の数を最大とする数のカーネル・スレッドを作成します。それぞれのカーネルスレッドは，OpenVMS エグゼクティブによってスケジューリングされて別々の CPU で実行されるので，同時に実行することができます。

アプリケーションの実行中，オペレータは CPU を個別に停止または開始することができます。このような動的変化を反映して，これ以降にイメージがアクティブ化されたときに作成できるカーネル・スレッドの数が変化します。また，現在実行中のイメージにも反映されるようになりました。

CPU を追加または除去すると，スレッド・ライブラリは，追加，除去後のアクティブな CPU の数を照会し，プロセスが現在使用しているカーネル・スレッドの数と比較します。現在 CPU がカーネル・スレッドよりも多い場合，ライブラリは既存の POSIX スレッドを CPU まで延長します (必要に応じて，すぐに，または後に新しいカーネル・スレッドを作成します)。逆に CPU がカーネル・スレッドよりも少ない場合，ライブラリは余分のカーネル・スレッドを強制的にハイバネートさせ，残りのカーネル・スレッド上で POSIX スレッドを再度スケジューリングします。これにより，プロセスに関する限り，利用可能な数以上のカーネル・スレッドが， CPU リソースを奪い合うということがなくなります。

5.36.11 デバッガ計測機能は動作しない

V7.0

POSIX スレッド・デバッガの計測機能は動作しません。

『Guide to the POSIX Threads Library』の C.1.1 に記載されている，動作中のプログラムをデバッグする手順を使用すると，プロセスが ACCVIO メッセージで失敗する可能性があります。

5.37 RTL ライブラリ (LIB$)

ここでは，LIB$ ランタイム・ライブラリに関する注意事項について説明します。

5.37.1 RTL ライブラリ (LIB$) のヘルプ

V8.2

OpenVMS Version 8.2 の LIB$ ランタイム・ライブラリのヘルプ・ファイルには， LIB$LOCK_IMAGE ルーチンのヘルプがありません。この問題は，今後のリリースで修正される予定です。当面は，このルーチンの詳細な説明は『OpenVMS RTL Library (LIB$) Manual』を参照してください。

5.37.2 RTL Library (LIB$): 呼び出し標準ルーチン (Integrity のみ)

V8.2

この注意事項では，ローテートするレジスタが，以下の呼び出し標準ルーチンでどのように取り扱われるかを明確化します。

LIB$I64_GET_FR
LIB$I64_SET_FR
LIB$I64_GET_GR
LIB$I64_SET_GR
LIB$I64_PUT_INVO_REGISTERS

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

現在は，補足的なアクセス・ルーチン LIB$I64_GET_FR, LIB$I64_SET_FR, LIB$I64_GET_GR および LIB$I64_SET_GRが，レジスタ・リネーム・ベース・レジスタとローテート・サイズ・レジスタの効果を調整しないで，不適切に，そのレジスタ番号パラメータを解釈しています。これは，誤りであり今後のリリースで修正される予定です。

それまでは，ICB またはメカニズム・ベクタ内の汎用レジスタ，浮動小数点レジスタ，およびプレディケート・レジスタを調べるプログラムや，実行時に見えるレジスタを探して内容を解釈するプログラムでは，保存された CFM レジスタを調べて，自身で適切に調整する必要があります。

5.38 Screen Management (SMG$) のドキュメント

『OpenVMS RTL Screen Management (SMG$) Manual』の最後にある参照情報のトピックに，次の情報を追加します。

V7.2

  • ルーチン SMG$DELETE_VIRTUAL_DISPLAY の「Condition Values Returned (返される条件値)」に，次の説明を追加してください。
    "Any condition value returned by the $ DELPRC system service"
    ($DELPRC システム・サービスから返された条件値)

  • ルーチン SMG$GET_TERM_DATA の説明の「Arguments (引数)」の部分で， capability-data 引数の説明が誤っています。正しい説明は次のとおりです。

    アクセス: write-only
    受け渡し方: by reference, array reference

  • ルーチン SMG$SET_OUT_OF_BAND_ASTS の説明の「引数 (AST-argument)」の部分で，AST-argument 引数の説明に誤りがあります。構造体の図のシンボル名が誤っています。この図の下にある段落に示されているシンボル名は正しい名前です。正しいシンボル名と誤ったシンボル名は次のとおりです。

    誤っているシンボル名 正しいシンボル名
    SMG$L_PASTEBOARD_ID SMG$L_PBD_ID
    SMG$L_ARG SMG$L_USER_ARG
    SMG$B_CHARACTER SMG$B_CHAR

V7.1

  • SMG$READ_COMPOSED_LINE ルーチンの説明で，flags 引数の説明に次の文を追加してください。
    "The terminal characteristic /LINE_EDITING should be set for your terminal for these flags to work as expected. /LINE_EDITING is the default."
    (「これらのフラグが正しく機能するには，端末に対して端末属性 /LINE_EDITING を設定しなければなりません。/LINE_EDITING は省略時の設定です。」)

  • ルーチン SMG$SET_KEYPAD_MODE の説明に，次の注意を追加してください。

      注意
    キーパッド・モードを変更すると，物理端末の設定も変更されます。これは， keyboard-id 引数によって指定される仮想キーボードだけでなく，すべての仮想キーボードに対するグローバルな変更です。



5.39 SORT32 ユーティリティ

ここでは，OpenVMS Alpha および OpenVMS Integrity Version 8.2 用の， SORT32 V08-010 に関する注意事項について説明します。詳細は， 第 5.27.8 項 と 第 5.27.1 項 を参照してください。

Hypersort で修正されていない問題を回避する場合，または Hypersort に実装されていない機能を使用する場合に SORT32 を使用することをお勧めします。 Hypersort の注意事項については， 第 5.27 節 を参照してください。

5.39.1 DFS サービス・ディスクでの CONVERT の問題

V8.2

SORT，MERGE，および CONVERT 操作は， UNIX がサービスする DFS マウント・ディスクが出力先になっている場合， %SORT-E-BAD_LRL エラーを返します。

この制約事項を回避するには，次のいずれかを実行します。

  • 出力ファイルを OpenVMS ディスクに書き込んでから，その出力ファイルを UNIX がサービスする DFS マウントディスクにコピーする。

  • CONVERT/FDL コマンドを使用する。このとき，FDL には，出力ファイルに必要な LRL (最大レコード長) を指定する。



5.39.2 一時作業ファイルが削除されないことがある

V7.3-2

SORT32 は，一時作業ファイルを削除しないことがあります。 SYS$SCRATCH や， SORT32 の作業ファイルを置いている場所を定期的にチェックし，削除されていない作業ファイルを削除してディスク・スペースを空けることができないかを調べてください。

5.39.3 複合条件のある SORT/SPECIFICATION: 要件

V7.3-1

SORT32 では，キー指定ファイルの複合条件が括弧で囲まれていない場合，複合条件に対する診断メッセージを出力しません。例を次に示します。

誤り: 

/CONDITION=(NAME=TEST1, TEST=(Field2 EQ "X") AND (Field3 EQ "A"))

正しい: 

/CONDITION=(NAME=TEST1, TEST=((Field2 EQ "X") AND (Field3 EQ "A")))



5.39.4 可変長レコードでの性能の問題

V7.3-1

SORT32 では，入力ファイル内の最大レコード長 (LRL) 情報に基づいて，ソート作業ファイルの固定長のスロットが割り当てられます。性能を向上させるには，実際の最大レコード長に最も近い LRL 情報を入力ファイルに設定します。初期性能が低い場合は，C プログラムによって作成されたファイルをソートしており， LRL が必要以上に大きく (32767 まで) 設定されていることが原因と考えられます。

5.39.5 作業ファイル・ディレクトリの制約事項

V7.3

SORT32 の作業ファイルは，必要な数の作業ファイルを複数のファイル・バージョンにわたって格納できるディレクトリに作成する必要があります。

5.40 タイマ・キュー・エントリ (TQE)

恒久的な制限事項

OpenVMS Alpha Version 7.3-1 では，タイマ・キュー・エントリの管理方法が変更され，多くの TQE を使用するシステムの性能が大きく向上しました。この変更は，非特権アプリケーションにとっては無関係です。

また，特権コードで TQE を直接操作することはできません。特に TQE キュー・ヘッダ (TQE$L_TQFL/TQE$L_TQBL) 内のポインタに直接アクセスすると，通常はアクセス違反になります。ただし，特権コードで内部ルーチン exe_std$instimq/exe$instimq と exe_std$rmvtimq/exe$rmvtimq を使用して，タイマ・キュー・エントリを入力または削除することは可能です。

5.41 Watchpoint ユーティリティ (Integrity のみ)

V8.2

Watchpoint ユーティリティは，OpenVMS Integrity に移植されていません。弊社では，このユーティリティを今後のリリースで移植する予定です。

5.42 プログラム全体の浮動小数点モード (Integrity のみ)

V8.3

OpenVMS Alpha では，浮動小数点丸め動作，例外動作，および精度制御は，コンパイル時に定義されます。各モジュールは，それぞれの浮動小数点動作の設定で，個別にコンパイルされます。たとえば，計算のオーバフローでオーバフロー例外がシグナル通知されるディレクティブで 1 つのモジュールをコンパイルし，別のモジュールを，計算のオーバフローで例外をシグナル通知するのではなく，値を InfinityT とするディレクティブでコンパイルすることができます。これらの 2 つのモジュールがコンパイルされ実行された場合，モジュールのコードは，コンパイル時に指定されたオーバフロー動作をします。

OpenVMS Integrity では，浮動小数点丸め動作，例外動作，および精度制御は実行時に定義され，プログラム全体の浮動小数点モードの概念で制御されます。プログラム全体の浮動小数点モードでは，プログラムのメイン・エントリ・ポイント (リンカが決定したもの) を含むモジュールが，デフォルトの浮動小数点丸め動作，例外動作，および精度制御を定義するモジュールです。

大半のプログラムには，この相違点の影響はありません。要点は，ホワイト・ペーパー『Intel® Itanium® アーキテクチャにおける OpenVMS 浮動小数点演算について』を参照してください。このドキュメントは，次の Web サイトで参照できます。

http://h71000.www7.hp.com/openvms/integrity/resources.html

目次 索引

© 2012 Hewlett-Packard Development Company, L.P.