日本-日本語

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

OpenVMS マニュアル


≫ 

OpenVMS V7.3-2
ライブラリ

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

OpenVMS Alpha
V7.3-2 リリース・ノート【翻訳版】


目次 索引



V7.3-2

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

5.15.3 プロセス・ダンプ

V7.3

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

5.15.4 動的 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.15.5 スレッド・プログラムの高度デバッグ

V7.3

POSIX スレッド・ライブラリは,監視ツールとデバッグ・ツールをサポートするための,高度なデータ収集機能を備えています。これらの機能は, OpenVMS Alpha システム上のスレッド・プログラムのための新しいデバッグ,分析ツールであるビジュアル・スレッドをサポートします。ビジュアル・スレッドは,OpenVMS Version 7.3 でライセンスされており,監視機能,自動デバッグ機能,およびマルチスレッド・アプリケーションの性能評価機能を備えています。

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

V7.0

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

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

5.16 特権付きインタフェースとデータ構造体

ここでは,特権付きコードとデータ構造体の注意事項をまとめます。

5.16.1 スレッド単位のセキュリティは特権付きコードとデバイス・ドライバに影響する

V7.3-1

Version 7.2 では,セキュリティ・プロファイルを I/O Request Packet (IRP) に添付するために使用される方法が変更されました。

OpenVMS の Version 7.2 より前のバージョンでは,要求者のプロセス単位の Access Rights Block (ARB) セキュリティ構造のアドレスは IRP 構造に含まれていました。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 以降で動作するように,ドライバを再コンパイルおよび再リンクしなければなりません。

5.16.2 OpenVMS フォーク・スレッド作成のための IPL 要件の強制

V7.3-1

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.17 RTL ライブラリ (LIB$)

ここでは,LIB$FIND_IMAGE_SYMBOL の注意事項をまとめます。

5.17.1 LIB$FIND_IMAGE_SYMBOL: 『OpenVMS RTL Library (LIB$) Manual』の正誤情報

V7.3-1

『OpenVMS RTL Library (LIB$) Manual』の, LIB$FIND_IMAGE_SYMBOL に対する flags 引数の説明には誤りがあります。 flags は,参照渡しとして説明されていますが,この記述は誤りで,戻り値としてエラー・メッセージ LIB-F-INVARG が返されます。 flags を値で渡すと,LIB$FIND_IMAGE_SYMBOL は問題なく機能します。

この誤りは,『OpenVMS RTL Library (LIB$) Manual』の次の改訂版で修正される予定です。

5.17.2 LIB$FIND_IMAGE_SYMBOL シグナル通知による警告

V7.1

LIB$FIND_IMAGE_SYMBOL は,起動されているイメージにコンパイル警告が発生したモジュールが含まれていることを示すために,警告 (LIB$_ EOMWARN) を通知することがあります。LIB$FIND_IMAGE_SYMBOL で使用される条件ハンドラは,この状況を特殊な場合として取り扱わなければなりません。

LIB$_EOMWARN が通知された後,LIB$FIND_IMAGE_SYMBOL が実行を続行するには,条件ハンドラが SS$_CONTINUE で終了しなければなりません。この理由から, LIB$FIND_IMAGE_SYMBOL の条件ハンドラとして LIB$SIG_TO_RET を使用することは適切ではありません。

5.18 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.19 SORT32 ユーティリティ

ここでは,SORT32 ユーティリティの注意事項をまとめます。 Hypersort で修正されていない問題に対応する場合,または Hypersort に実装されていない機能を使用する場合に SORT32 を使用することをお勧めします。

SORT32 は,OpenVMS Alpha Version 7.3-2 向けに更新されています。 SORT32 の新しいバージョンは V07-006 です。

5.19.1 VFC ファイルが正しく書き込まれるようになった

V7.3-2

OpenVMS Alpha Version 7.3 および 7.3-1 と一緒に出荷されたバージョンの SORT32 は,指定ファイルが使用された場合, VFC 情報を VFC 出力ファイルに正しく書き込みませんでした。この問題は,修正されました。

5.19.2 SORT32 が一時作業ファイルを削除しないことがある

V7.3-2

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

5.19.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.19.4 SORT32 と Hypersort の性能: ワーキング・セットとページ・ファイル・クォータ

V7.3-1

SORT32 と Hypersort では,それぞれのソート・アルゴリズムと作業ファイル・アルゴリズムが異なります。それぞれのソート・ユーティリティの処理速度は入力ファイルとメモリ/ディスク/CPUの構成に依存します。 SORT32 と Hypersort のどちらでも,ワーキング・セット・エクステントが,最大でもページ・ファイル・クォータの 3 分の 1 になるようにしてください。

5.19.5 可変長レコードでの SORT32 と Hypersort の性能

V7.3-1

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

5.19.6 SORT32 作業ファイル・ディレクトリの制限事項

V7.3

SORT32 の作業ファイルは,要求した作業ファイル数を処理できる複数のファイル・バージョンを格納できるディレクトリにリダイレクトする必要があります。この制限は,Hypersort にも適用されます。

5.20 システム・サービス: SYS$ACM(W) の変更

V7.3-2

ここで説明する SYS$ACM[W] の機能変更は, OpenVMS Version 7.3-2 で盛り込まれました。ここで,非特権プロセスは, SECURITY 特権のないユーザ・モードで実行されるプロセスを指します。

  • タイムアウト処理
    非特権プロセスに対して,タイムアウト処理が強制されるようになりました。他のプロセスでは,ACME$M_TIMEOUT 関数修飾子を指定することで,タイムアウト処理を要求できます。

  • ダイアログ・モード繰り返し回数の制限
    非特権プロセスでは,呼び出しのダイアログ・シーケンスで実行できる繰り返し要求の数が制限されるようになりました。

  • ログオン・タイプの制限
    次の CME$_LOGON_TYPE 項目コード値は,LOGINOUT 用に予約されています。
    ACME$K_BATCH
    ゼロ (0)

    また,ACME$_LOGON_TYPE 項目コードの指定には, IMPERSONATE 特権は不要になりました。

詳細は,『OpenVMS System Services Reference Manual』の SYS$ACM[W] システム・サービスの説明を参照してください。

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

V7.3-1

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 を使用して,タイマ・キュー・エントリを入力または削除することは可能です。


目次 索引

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