日本-日本語
日本HPホーム 製品 & サービス サポート & ドライバー ソリューション ご購入方法
≫  お問い合わせ

製品とサービス >  ソフトウェアとOS >  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-1

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

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

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

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

5.8 OpenVMS Alpha 用の HP COBOL 実行時ライブラリ (RTL)

V7.3-2

HP COBOL RTL (DEC$COBRTL) は, OpenVMS Alpha Version 7.3-2 用の V2.8-670 に更新されました。

5.8.1 COBOL RTL と UNSTRING

V7.3-2

COBOL RTL は, DELIMITED BY 文字列にオーバラップがある場合の UNSTRING OR を正しく扱うようになりました。

5.8.2 COBOL RTL が CLOSE 時のデバイス・フルを検出する

V7.3-2

COBOL RTL は,CLOSE 操作時にデバイス・フルの状態を検出するようになりました。

5.8.3 COBOL RTL とレコード・ロックの制限事項

V7.3-1

COBOL プログラムの START 文または WRITE 文で自動レコード・ロックで複数のレコード・ロックが発生することがあります。この場合,UNLOCK ALL RECORDS を実行するか,CLOSE の後に OPEN して,レコード・ロックをクリアしてください。

5.9 Hypersort ユーティリティ

V7.3-2

ここでは,Hypersort ユーティリティに関する注意事項をまとめます。 OpenVMS Alpha Version 7.3-2 では, Hypersort が更新されています。新しいバージョンの Hypersort は V04-004 です。

従来どおり,Hypersort で修正されていない問題を解決する場合,または Hypersort に実装されていない機能を使用する場合には, SORT32 を使用してください。

5.9.1 ラージ・ファイルでの CONVERT の性能

V7.3-2

Hypersort は,ラージ・ファイルでの CONVERT を正しく扱うようになりました。以前は,ワーキング・セット・エクステント内に小規模な変更があっても, Hypersort の性能が低下することがありました。

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

V7.3-2

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

5.9.3 SORT と MERGE が大規模入力ファイルでハングアップすることがある

V7.3-2

Hypersort が大規模入力ファイル (一般に,4 GB よりも大きいファイル) を扱っているときに,Hypersort がハングアップするか ACCVIO で終了することがあります。 Hypersort で ACCVIO やハングアップが発生する場合は, SORT32 を使用して回避してください。

5.9.4 /FORMAT=RECORD_SIZE の制限事項

V7.3-1

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.9.5 Hypersort と検索リスト,および論理名の使用

V7.3-1

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

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

V7.3-1

すべてのソート作業ファイルで空き領域が不足していると,Hypersort が正しく終了しません。この問題を防ぐには,ソート作業ファイルに使用するデバイスに十分な空き領域を割り当ててください。または,SORT32 を使用して,作業ファイルの領域が不足しているかどうかを確認してください。

5.9.7 Hypersort と SORT32 の性能: ワーキング・セットとページ・ファイル・クォータ

V7.3-1

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

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

V7.3-1

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

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

V7.3

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

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

V7.3

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

5.10 Librarian ユーティリティ: PGFLQUOTA は 23000 以上必要

V1.5

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

この問題を回避するには, PGFLQUOTA プロセス・クォータが 23000 より大きい値に設定されたアカウントで,圧縮,データ・リダクション,データ拡張操作を実行します。さらに,コマンド・プロシージャで LIBRARY コマンドからの戻りステータスを確認するようにしてください。

5.11 Lightweight Directory Access Protocol (LDAP) API

ここでは,LDAP API に関する注意事項をまとめます。

5.11.1 ld が NULL の場合の ldap_get_option ルーチンからのエラー戻り値 (-1)

V7.3

ldap_get_options()の呼び出しで ldパラメータに NULL 値を使用すると,グローバル・デフォルト・データ・セットではなく,エラー戻り値 -1 が返されます。

5.11.2 ber_flatten() ルーチンが中括弧の不一致を検出しない

V7.3

ber_flatten()ルーチンでは,BerElement 内の '{' および '}' 形式修飾子が一致しない場合が正しく検出されません。

5.12 Linker ユーティリティ

ここでは,Linker ユーティリティに関する注意事項をまとめます。

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

V7.3-2

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

回避方法

LINK コマンドに SYS$INPUT:/OPTION を指定します。 Return を押すと,リンカはユーザがオプション・ファイルに情報を入力するのを待ちます。入力が終了したら,Ctrl/Z を押します。このリリース・ノートで説明した問題を回避するには,オプション・ファイルに次の項目を入れます。

  • 1 行目に,次のオプションを指定します。


    RMS_RELATED_CONTEXT=NO 
    


    RMS_RELATED_CONTEXT オプションに NO を設定した場合,このオプション・ファイルにリストされている不明ファイルに対しては,すぐに "file not found" メッセージが生成されます。

  • 以降の行では,リンクするファイルすべてを,完全ファイル指定 (disk:[dir]filename.ext の形式) で指定します。 RMS_RELATED_CONTEXT=NO を指定するとファイル名の省略指定ができず,完全ファイル指定が必要になります。

たとえば,次の LINK コマンドがあるとします。


$ LINK DSK:[TEST]A.OBJ, B.OBJ 

このコマンドを RMS_RELATED_CONTEXT=NO とともに指定したい場合は, /OPTION を指定してから,リンクするファイルの完全ファイル指定を,次のように入力します。


$  LINK SYS$INPUT:/OPTION
RMS_RELATED_CONTEXT=NO
DSK:[TEST]A.OBJ, DSK:[TEST]B.OBJ [Ctrl/Z]
$ 

RMS_RELATED_CONTEXT オプションについての詳細は,『OpenVMS Linker Utility Manual』を参照してください。


次の例では,リストに DOES_NOT_EXIST.OBJ ファイルが含まれていて, RMS_RELATED_CONTEXT オプションが指定されていない (デフォルトで YES が使用されます) 場合に,リンカがハングアップしたように見える様子を示しています。


$  DEFINE DSKD$ WORK4:[TEST.LINKER.OBJ.]
$  DEFINE RESD$ ROOT$, ROOT2$, ROOT3$, ROOT4$, ROOT5$, DISK_READ$:[SYS.] (1)
$  DEFINE ROOT$ WORK4:[TEST.PUBLIC.TEST]
$  DEFINE ROOT2$ WORK4:[TEST.LINKER.]
$  DEFINE ROOT3$ WORK4:[TEST.UTIL32.]
$  DEFINE ROOT4$ WORK4:[TEST.PUBLIC.]
$  DEFINE ROOT5$ WORK4:[TEST.PUBLIC.TMP]
$  LINK/MAP/FULL/CROSS/EXE=ALPHA.EXE  RESD$:[TMPOBJ] A.OBJ,-
_$  RESD$:[SRC]B.OBJ,C,DSKD$:[OBJ]D.OBJ,E,RESD$:[TMPSRC]F.OBJ,-
_$  RESD$:[TEST]G.OBJ,RESD$:[SRC.OBJ]H,RESD$:[COM]DOES_NOT_EXIST.OBJ
[Ctrl/T] NODE6::_FTA183: 15:49:46 LINK CPU=00:02:30.04 PF=5154 IO=254510 MEM=134 (2)
[Ctrl/T] NODE6::_FTA183: 15:49:46 LINK CPU=00:02:30.05 PF=5154 IO=254513 MEM=134
[Ctrl/T] NODE6::_FTA183: 15:50:02 LINK CPU=00:02:38.27 PF=5154 IO=268246 MEM=134
[Ctrl/T] NODE6::_FTA183: 15:50:02 LINK CPU=00:02:38.28 PF=5154 IO=268253 MEM=134
[Ctrl/T] NODE6::_FTA183: 15:50:14 LINK CPU=00:02:44.70 PF=5154 IO=278883 MEM=134

  1. このコマンドは,論理名と,それに対応する文字列を定義しています。

  2. Ctrl/T を押すたびに,CPU 値と IO 値が大きくなります。ただし,MEM 値と PF 値は大きくなりません。これは,LIB$FIND_FILE が呼び出されていることを示しています。

次の例のように,オプション・ファイルを使用して RMS_RELATED_CONTEXT に NO を設定すると,不明ファイルを見つけたときにリンク操作がすぐに終了します。


$  DEFINE DSKD$ WORK4:[TEST.LINKER.OBJ.]
$  DEFINE RESD$ ROOT$, ROOT2$, ROOT3$, ROOT4$, ROOT5$, DISK_READ$:[SYS.]
$  DEFINE ROOT$ WORK4:[TEST.PUBLIC.TEST.]
$  DEFINE ROOT2$ WORK4:[TEST.LINKER.]
$  DEFINE ROOT3$ WORK4:[TEST.UTIL32.]
$  DEFINE ROOT4$ WORK4:[TEST.PUBLIC.]
$  DEFINE ROOT5$ WORK4:[TEST.PUBLIC.TMP.]
$  LINK/MAP/FULL/ CROSS /EXE=ALPHA.EXE SYS$INPUT:/OPTION
RMS_RELATED_CONTEXT=NO
RESD$:[TMPOBJ]A.OBJ,RESD$:[SRC]B.OBJ,RESD$:[SRC]C,DSKD$:[OBJ]D.OBJ
DSKD$:[OBJ]E,RESD$:[TMPSRC]F.OBJ,RESD$:[TEST]G.OBJ
RESD$:[SRC.OBJ]H,RESD$:[COM]DOES_NOT_EXIST.OBJ [Ctrl/Z]
 
%LINK-F-OPENIN, error opening DISK_READ$:[SYS.][COM]DOES_NOT_EXIST.OBJ; as input
-RMS-E-FNF, file not found
$



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

V7.3-1

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

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

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

永続的な制限事項

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

5.13 LTDRIVER: CANCEL SELECTIVE の制限事項

永続的な制限事項

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

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

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

V7.1

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

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

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

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

ここでは,POSIX スレッド・ライブラリ (旧名称は,DECthreads) に関する注意事項をまとめます。

付録 A.3 節 の関連する注意事項も参照してください。

5.15.1 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 ヘッダ・ファイルのインクルードに変更します。


目次 索引

印刷用画面へ
プライバシー 本サイト利用時の合意事項 ウェブマスターに連絡