| 前へ | 次へ | 目次 | 索引 |
この章では，システムの保守と管理，性能の管理，ネットワーキングに関連する情報をまとめます。
このバージョンで提供される新機能の詳細については，『OpenVMS V7.3 新機能説明書』を参照してください。
5.1 IPC-E-BCKTRNSFAIL エラー・メッセージ
V7.3
ここでは，ACMS ユーザ，場合によっては Rdb ユーザ，および DECdtm を呼び出して，次の特徴を持つリモート・システムとの分散トランザクションに参加するユーザ作成アプリケーションを実行しているユーザに関する注意事項を説明します。
DECnet によって返される，次のようなエラーが発生することがあります。
IPC-E-BCKTRNSFAIL, failure on the back translate address request |
このエラーは，リモート・ノード名が DECnet-Plus によって変換されない場合に，論理接続障害によって表示されます。リモート・システムの DECnet-Plus ノード名がローカルな DECnet-Plus データベースに定義されておらず，リモート・ノードの TCP/IP ネーム・サーバで ALIAS としてのみ定義される場合に，このエラーが発生することがあります。たとえば，ノード XXYZZY は，次のように定義することができます。
20.43.136.54 XXYZZY.ABC.DEF.COM, XXYZZY |
この状況を回避するには，ノード名をローカルな DECnet-Plus データベースに定義するか，または論理名 SYS$DECDTM_NODE_NAME を次のいずれかと等しくなるように定義します。
他の必要条件や制限事項については，『Compaq OpenVMS システム管理者マニュアル』の DECdtm Services の管理についての説明を参照してください。
5.2 V7.3 で使用可能な ECP Data Collector および ECP Performance Analyzer V5.4
V7.3
OpenVMS バージョン 7.3 以降，出荷時に Enterprise Capacity and Performance (ECP) Data Collector Version 5.4 for OpenVMS および Enterprise Capacity and Performance (ECP) Analyzer Version 5.4 for OpenVMS が有効なオペレーティング・システム・ライセンスとともに無償で提供されます。 Data Collector および Performance Analyzer は，V6.2 以降の OpenVMS オペレーティング・システム (OpenVMS Alpha および OpenVMS VAX プラットフォーム) に対して下位互換性があります(無償)。
Enterprise Capacity and Performance Data Collector にはデータ収集機能があり， Version 5.4 Enterprise Capacity and Performance (ECP) Analyzer for OpenVMS に入力できます。Data Collector のメトリクスには， CPU，ディスク I/O，メモリ，プロセス，ネットワーク，ロック，クラスタ，ディスクセットの構成情報が含まれます。ECP Analyzer では，コレクタにより処理されたデータのグラフィック (MOTIF ベース) レポートと表形式のレポート (CPU，ディスク I/O，メモリ，ページング，プロセス，ロック，SCS，および TCP/IP のメトリクスを含む) が表示されます。
Data Collector と Performance Analyzer は，Compaq OpenVMS System Management の Web ページからダウンロードできます。
http://www.openvms.compaq.com/openvms/system_management.html
ECP Data Collector と ECP Performance Analyzer の新機能については，『OpenVMS V7.3 新機能説明書』を参照してください。
これらの製品のソフトウェア・サポート・サービスは，個別に販売されるため，追加購入が可能です。詳細については，弊社のサービス担当者にご連絡ください。
5.3 Extended File Specifications
ここでは，Extended File Specifications に関するリリース・ノートをまとめます。 Extended File Specifications の詳細については，『Compaq OpenVMS Extended File Specifications の手引き』を参照してください。
5.3.1 UNIX 形式と OpenVMS 形式の複合ファイル名はサポートされない
ODS-5 ボリューム構造では，長いファイル名がサポートされ，ファイル名にこれまでより広範囲にわたる文字を使用することができ，ファイル名の大文字と小文字の区別が保存されます。
しかし，OpenVMS Alpha バージョン 7.3 に付属している C RTL では， ODS-5 装置の拡張ファイル名が完全にサポートされません。このように完全なサポートが提供されないため，ODS-5 装置で Netscape FastTrack Server や Apache Web Server for OpenVMS Alpha を実行するユーザ，あるいは Java アプリケーションを使用するユーザに特定の制限が発生します。
一般に，OpenVMS で Netscape FastTrack Server や Apache Web Server for OpenVMS Alpha を実行するユーザ，あるいは Java アプリケーションを使用するユーザは，UNIX 形式のファイル名または VMS 形式のファイル名のいずれかを入力できます(FastTrack サーバおよび Apache サーバでは通常，UNIX 形式のファイル名が出力されます)。どちらの製品でも，多くの場合，ファイル名は FastTrack サーバ，Apache サーバまたはJava Virtual Machine で作成されます。
UNIX 形式と VMS 形式の複合拡張ファイル名は Compaq C RTL でサポートされていないため，たとえばディレクトリやファイル名を追加するルートを変更する場合など，Java アプリケーションまたは FastTrack サーバや Apache サーバとやり取りする場合は，UNIX 形式の構文を使用しなければならない場合があります。たとえば，ディレクトリやファイル名を追加するルートを変更する必要があるかもしれません。
次の例に，UNIX 形式と VMS 形式の複合ファイル名を示しますが，このようなファイル名は OpenVMS Alpha バージョン 7.3 ではサポートされません。
doc/foo.bar.bar ./tmp/foo.bar.b^_ar ~foo^.bar |
しかし，最後の例を変更すれば，1 文字目としてティルダ (~) が指定された OpenVMS 拡張ファイル名として動作するようになります。最初のティルダ (~) の前に Extended File Specifications のエスケープ文字 (^) を指定します。次の例を参照してください。
^~foo^.bar |
OpenVMS 拡張ファイル名でのティルダ (~) の使用の詳細については，『Compaq OpenVMS Extended File Specifications の手引き』を参照してください。
さらに，次の条件のうちいずれかに該当する場合，ファイル名を返す C RTL 関数は正常に動作しません。
これらの条件のうちいずれかがあてはまると，次の C RTL ルーチンは失敗します。
getname()
fgetname()
getcwd()
decc$from_vms()
decc$translate_vms()
上記の条件のいずれかがあてはまるファイルについては，次の C RTL ルーチンはスキップします。
ftw()
readdir()
このような UNIX 形式と VMS 形式の複合ファイル名は， Compaq C RTL for OpenVMS の将来のリリースでサポートされる予定です
5.4 外部認証
ここでは，外部認証に関するリリース・ノートをまとめます。外部認証は OpenVMS バージョン 7.1 で導入されたオプションの機能であり，この機能を利用すると，OpenVMS システムは外部のユーザ ID とパスワードを使用して，指定されたユーザを認証できます。
OpenVMS バージョン 7.2 以降，DECwindows を稼動しているときに DECwindows ユーザを外部認証する場合は，DECwindows Version 1.2-4 以降および Advanced Server for OpenVMS を実行しなければならず，『Advanced Server for OpenVMS Server Installation and Configuration Guide』に示した必要条件を満たさなければなりません。外部認証の使用の詳細については，このマニュアルと『OpenVMS Guide to System Security』を参照してください。
5.4.1 FTP サーバは外部認証を使用
V7.2
Compaq TCP/IP Services for OpenVMS Version 5.0 のリリースにともない，File Transfer Protocol (FTP) サーバは外部認証を使用して OpenVMS システム上の接続を認証するようになりました。
5.4.2 外部認証を制御するための DCL コマンド・インタフェース
V7.2
『OpenVMS Guide to System Security』の第 7 章では，外部認証に対して現在使用している論理名 SYS$SINGLE_SIGNON と SYS$ACME_MODULE について説明しています。将来のリリースでは，外部認証を有効化および制御するための現在のインタフェースを DCL コマンド・インタフェースに変更する予定です。
5.4.3 POP サーバでの接続が失敗する
V7.2
Post Office Protocol (POP) サーバは，外部認証を使用して OpenVMS システムでの接続を認証しません。このため，次のいずれかの状況では，接続の試みは失敗します。
5.4.4 DECterm 端末セッションでの SET PASSWORD の動作
V7.2
DECterm 端末セッションでは，ログインで使用する外部ユーザ名にアクセスすることができず，SET PASSWORD 操作で外部ユーザ名を入力しなければなりません。外部ユーザ名のデフォルトは，プロセスのOpenVMS ユーザ名です。デフォルトが適切でない場合 (つまり，外部ユーザ名とマッピングされた OpenVMS ユーザ名が異なる場合)，正しい外部ユーザ名を入力しなければなりません。
次の例に，外部ユーザ名が JOHN_DOE であるユーザが開始したSET PASSWORD 操作を示します。マッピングされた OpenVMS ユーザ名は JOHNDOE であり，これは SET PASSWORD 操作で使用されるデフォルトです。この場合，デフォルトは正しくないので，実際の外部ユーザ名がユーザによって指定されています。
$ set password External user name not known; Specify one (Y/N)[Y]? Y External user name [JOHNDOE]: JOHN_DOE Old password: New password: Verification: %SET-I-SNDEXTAUTH, Sending password request to external authenticator %SET-I-TRYPWDSYNCH, Attempting password synchronization $ |
5.4.5 Compaq DECnet-Plus の必要条件
V7.2-1
SYSUAF アカウント・レコードで EXTAUTH ビットがセットされているユーザは，外部認証パスワードがすべて大文字の場合を除き，Compaq DECnet-Plus を実行しているシステムで明示的なアクセス制御文字列を使用できません。
たとえば，次のコマンドを入力した場合について考えてみましょう。
$ DIRECTORY nodename"username password":: |
nodename は DECnet-Plus を実行しているシステム， username は EXTAUTH アカウントです。DECnet-Plus は， password という文字列が外部認証エージェント (PATHWORKS または NT ドメイン・コントローラ) に渡される前に，これを大文字に変換します。
この問題には，次の 2 つの回避方法があります。
5.4.6 SYSUAF パスワードを使用する DECwindows の休止スクリーン
V7.1
DECwindows の休止スクリーンのアンロック機構では，パスワード確認に外部認証サービスが使用されません。システムで外部認証を有効化した場合でも SYSUAF ファイルのパスワードが使用されます。
デフォルトでは，パスワードの同期が有効化されています。パスワードの同期を無効化した場合は， LAN Manager と SYSUAF のパスワードを手動で同期させる必要があります。
5.4.7 DECnet-Plus と NET_CALLOUTS パラメータ
V7.3
外部認証を有効化して DECnet-Plus for OpenVMS を実行するには，NET_CALLOUTS システム・パラメータを 255 に設定します。この設定によりユーザ確認とプロキシ検索が DECnet ではなく LOGINOUT で実行されます。
5.4.8 レイヤード・プロダクトとアプリケーションに与える影響
V7.1
従来の SYSUAF ベースのユーザ名とパスワードをもとにした認証機能を使用する特定のレイヤード・プロダクトとアプリケーション (たとえば，$HASH_PASSWORD や $GETUAI/$SETUAI を呼び出して，OpenVMS パスワードの変更，フェッチ，確認を行うソフトウェア) では，次の場合に問題が発生します。
このような場合には，レイヤード・プロダクトまたはアプリケーションでユーザを認証できないという問題が発生します。
外部認証を受けるユーザの場合，通常のシステム登録データベース (SYSUAF.DAT) を使用して，OpenVMS プロセス・プロファイル (UIC ，特権，クォータなど) を作成したり，特定のログイン制限を適用します。ところが，外部認証を受けるユーザと通常の OpenVMS ユーザの間には， 2 つの重大な相違点があります。外部認証を受けるユーザの場合は，次のようになります。
OpenVMS では，これらの問題点をできるだけ少なくするために，ユーザの SYSUAF と外部ユーザ・パスワードの同期がとられます。ユーザの外部パスワードの最新のコピーは SYSUAF に保存されますが，たとえば外部パスワードに OpenVMS で使用できない文字が含まれている場合や，システム管理者が SYSUAF パスワードの同期化を無効にした場合は，パスワードの同期はとられません (デフォルトでは，パスワードの同期は有効に設定されています)。
外部認証を有効にする場合は，従来の SYSUAF ベースの認証を使用するレイヤード・プロダクトやアプリケーションとの互換性の問題をできるだけ避けるために，次の点に注意してください。
$GETUAI および$SETUAI システム・サービスでは，外部パスワードがサポートされません。これらのサービスは SYSUAF に格納されているパスワードに対してだけ動作し，更新情報は外部認証サービスに送信されません。これらのサービスを呼び出すソフトウェアを使用して，パスワードを確認したり，更新したりしているサイトでは，外部認証は有効にしないでください。将来のリリースでは，外部パスワードをサポートするための新しいプログラミング・インタフェースが提供される予定です。
5.4.9 複合バージョン OpenVMS Cluster システム
V7.1
すべてのシステムが OpenVMS バージョン 7.1 以上を実行している場合に限って，OpenVMS Cluster システムで外部認証を使用するようにしてください。
以前のバージョンのシステムで LOGINOUT を使用すると，外部認証を受けたユーザも含め，すべてのユーザに対して通常の OpenVMS パスワード・ポリシー ( パスワードの有効期限，パスワードの履歴など ) が適用されます。
5.4.10 LGI コールアウト・サービスは外部認証を無効にする
V7.1
バージョン 7.1 以降，LOGINOUT (LGI) コールアウトがあると，外部認証は無効になります。
5.4.11 ワークステーションではパスワードの有効期限切れは通知されない
V7.1
LAN Manager ドメインでは，パスワードの有効期限が切れた後，ログインすることはできません。
パーソナル・コンピュータ (PC) のユーザには，外部ユーザ・パスワードの有効期限が間もなく切れることが通知されるので，有効期限が切れる前にパスワードを変更できます。ところが，外部認証を使用して OpenVMS ワークステーションからログインする場合，ログイン・プロセスは外部パスワードの有効期限が間もなく切れるかどうか判断できません。したがって，パスワードの有効期限が設定されていて，ユーザの大半が PC を使用していないサイトでは，ワークステーション・ユーザに対して外部認証を使用しない方が賢明です。
5.5 FDL ユーティリティ---ディスク・クラスタ・サイズが大きい場合の EDIT/FDL 推奨バケット・サイズの変更
V7.3
OpenVMS V7.3 より前のバージョンでは，EDIT/FDL の実行時に，計算されたバケット・サイズ (最大バケット・サイズは 63) が常に最も近いディスク・クラスタのバウンダリに切り上げられていました。そのため，ディスク・クラスタ・サイズが大きい場合に，ファイルの元々のバケット・サイズは小さいが，バケット・サイズが必要以上に大きく切り上げられているという問題が発生することがありました。バケット・サイズが大きくなるほど，レコードとバケット・ロックの争奪が増加し，パフォーマンスに大きく影響します。
OpenVMS V7.3 では，推奨バケット・サイズを計算するためのアルゴリズムが変更され，ディスク・クラスタが大きい場合に，より厳密なサイズが提供されます。
5.6 OpenVMS Galaxy バージョン 7.3
ここでは，OpenVMS バージョン 7.3 向けの OpenVMS Galaxy のリリース・ノートおよびこのリリース・ノートに適用される OpenVMS バージョン 7.2-1H1，7.2-1，および 7.2 の注意事項についてまとめます。
5.6.1 OpenVMS Galaxy 構成でのFibre Channelの使用
OpenVMS Galaxy 構成におけるFiber Channel サポートは， OpenVMS Alpha バージョン 7.3 および OpenVMS Alpha バージョン 7.2-1H1 に組み込まれています。 OpenVMS Alpha バージョン 7.2-1 の場合，OpenVMS Galaxy 構成サポートは Fibre Channel 修正キット (V721_FIBRECHAN-V0200 以降) に含まれています。OpenVMS Fibre Channel 構成の詳細については，次の Web ページを参照してください。
新しい Compaq AlphaServer GS シリーズのシステムをサポートする Compaq Analyze サービス・ツールのリリースには，CPU にハード・アフィニティを設定する Director プロセスが含まれます。プロセスをハード・アフィニティ設定した CPU は，一つの Galaxy のインスタンスから別の Galaxy のインスタントへと再割り当てすることができません。
この制限は，一時的なものです。
Compaq Analyze とその操作方法の詳細については，弊社のサポート担当にご連絡ください。
5.6.3 Galaxy コンピュータ環境における Galaxy 以外のクラスタ・メンバの互換性
OpenVMS バージョン 7.2 では，OpenVMS Galaxy コンピュータ環境で使用される新しいセキュリティ・クラスが導入されました。新しいセキュリティ・クラスは， Galaxy システム以外では無効です。 OpenVMS Galaxy を既存の OpenVMS Cluster で構成する場合，クラスタ内のすべてのノードで新しいセキュリティ・クラスが認識されることを確認する必要があります。
該当するのは，次の条件がすべて満たされた場合です。
OpenVMS バージョン 6.2 またはバージョン 7.1 を実行中の OpenVMS VAX および Alpha システムの場合，VMS$OBJECTS.DAT ファイルで不明なセキュリティ・クラスが検出されるとクラッシュします。
同じ OpenVMS Cluster 環境内で，OpenVMS の旧バージョンを実行中の VAX および Alpha システムがバージョン 7.2 Galaxy インスタンスに対応できるように，各バージョンに対して SECURITY.EXE イメージが用意されています。これらのシステムで使用するすべてのシステム・ディスクに次のリストの修正キットをインストールする必要があります。 (これらの修正キットの新バージョンが使用されることがあります。)
| Alpha V7.1 および V7.1-1xx | ALPSYS20_071 |
| Alpha V6.2 および V6.2-1xx | ALPSYSB03_062 |
| VAX V7.1 | VAXSYSB02_071 |
| VAX V6.2 | VAXSYSB03_062 |
Galaxywide グローバル・セクションを作成する前に，更新されたシステム・ディスクの 1 つを共有するすべてのクラスタ・メンバをリブートする必要があります。
5.6.4 AlphaServer GS60/GS60E/GS140 の複数 I/O ポート・モジュール構成の制限事項
I/O ポート・モジュール (KFTHA-AA または KFTIA-AA) が複数存在する AlphaServer GS60/GS60E/GS140 構成では，システム・クラッシュが発生することがあります。
複数の I/O ポート・モジュールを含む OpenVMS Galaxy と Galaxy 以外が混在する AlphaServer 8200/8400 構成を GS60/GS60E/GS140 システムにアップグレードする場合， Compaq Action Blitz # TD 2632 の説明に従って，少なくともリビジョン B02 KN7CG-AB EV6 CPU (E2063-DA/DB rev D01) モジュール 1 つをインストールする必要があります。
この制限事項と解決方法については，Compaq Action Blitz # TD 2632 を参照してください。
5.6.5 MOP ブートの制限事項
OpenVMS Galaxy コンピューティング環境で MOP (Maintenance Operations Protocol) ブートがサポートされるのは，インスタンス 0 だけです。この制限事項は今後のリリースで排除される予定です。
5.6.6 Galaxy 構成での KFMSB および CIXCD アダプタの制限事項
永続的な制限事項
ドライバとアダプタ間の制御データ構造にファームウェアのアドレス制限があるため， KFMSB および CIXCD アダプタを適用できるのは，物理アドレス (PA) = 0 を基にするハードウェア・パーティションだけです。 OpenVMS Galaxy 構成では，これらのアダプタはインスタンス 0 でしか使用できません。
5.7 LAN ATM (Alpha のみ)
ここでは，ローカル・エリア・ネットワーク (LAN) 非同期転送モード (ATM) ソフトウェアのリリース・ノートについてまとめます。
5.7.1 LAN Emulation over ATM用 DAPBA/DAPCA アダプタの使用に関する条件または制限事項 (Alpha のみ)
DAPBA (155 Mb/s) および DAPCA (622 Mb/s) は，SYS$HWDRIVER4.EXEでサポートされる PCI バス・システムの ATM アダプタです。
どちらのアダプタも膨大なページング・プールが必要なため，構成時に注意が必要です。各 DAPBA については，SYSGEN パラメータ NPAGEVIR を 3000000 ごとに増加させることをお勧めします。各 DAPCA については，NPAGEVIR パラメータを 6000000 ごとに増加させることをお勧めします。そのためには，ADD_NPAGEVIR パラメータを MODPARAMS.DAT に追加し，AUTOGEN を実行します。たとえば，DAPBA 2 つと DAPCA 1 つを含むシステムの MODPARAMS.DAT には，次のコマンドを追加します。
ADD_NPAGEVIR = 12000000
|
DAPBA および DAPCA アダプタには，次の制限が適用されます。
ここでは，ロック・マネージャのリリース・ノートをまとめます。
5.8.1 ロック・マネージャ・システム・パラメータの名前変更 (Alpha のみ)
V7.3
『OpenVMS Performance Management』の専用 CPU ロック・マネージャの説明では， LOCKMGR_CPU システム・パラメータに関する記述が誤っています。 LOCKMGR_CPU システム・パラメータは，LCKMGR_CPUID に変更されています。
5.8.2 専用 CPU ロック・マネージャ機能の設定 (Alpha のみ)
V7.3
OpenVMS バージョン 7.3 では，CPU をロック・マネージャ専用に設定できる代替ロック・モードが導入されました。ロックする負荷が大きい場合には，専用 CPU ロック・マネージャは，従来のロック・マネージャよりも優れた性能を発揮します。このように性能が向上するのは，SMP の競合が低減され，ロック・マネージャ専用に設定された CPU での CPU キャッシュの利用率が改善されたためです。
専用 CPU ロック・マネージャを使用して効果があるのは，数多くの CPU を持ち，ロック・マネージャが原因で SMP 競合が激しいシステムに限られます。デフォルトでは，CPU はロック・マネージャ専用に設定されません。専用 CPU ロック・マネージャを有効にする方法の詳細については，『OpenVMS V7.3 新機能説明書』を参照してください。
5.8.3 高速ロック再マスタリングと PE1 (Alpha のみ)
V7.3
OpenVMS 分散ロック・マネージャには，ロック再マスタリングという機能があります。ロック再マスタリングとは，リソース・ツリーのロック・マスタの権利をクラスタ内にある別のノードに移動することです。ロック・ツリーのマスタになるノードは，クラスタ内の別のノードとのやり取りが不要なため，ローカルなロック要求をより高速で処理することができます。ほとんどのロック処理を実行するノードにロック・ツリーがあると，システム全体の性能が向上します。
OpenVMS バージョン 7.3 より前のバージョンで，ロック再マスタリングを実行すると，1 つのローカル・ロックにつき 1 つのメッセージがすべてのノードから新しいマスタに送信されていました。このため，非常に大規模なロック・ツリーの場合には，ロック再マスタリング処理を実行するために膨大な時間が必要でした。しかも，この処理中には，ロック・ツリーに対するすべてのアプリケーションのロックが停止されました。
OpenVMS バージョン 7.3 以降は，ロック・データの新しいマスタへの送信は，非常に大規模な転送で実行されます。これはより効率的な処理であり， 1 つのロック・ツリーを 3〜20 倍速く移動することができるようになります。
ロック再マスタリングの大規模転送を使用することができるのは， OpenVMS バージョン 7.3 またはそれ以降のバージョンを実行しているノードだけです。OpenVMS バージョン 7.3 ノードとそれより前のバージョンを実行しているノードとの間の再マスタリングでは，引き続き 1 つのロックにつき 1 つのメッセージを送信する必要があります。
PE1 システム・パラメータを使用して，再マスタリングの対象となりうるロック・ツリーのサイズを制限している場合には，その値を増やして大規模なロック・ツリーを移動できるようにするか，その値をゼロ (0) に設定してどのようなサイズのロック・ツリーでも移動できるようにします。
5.8.4 ロック・マネージャと非ページング・プール (Alpha のみ)
V7.2
OpenVMS Alpha システムでのアプリケーションのスケーラビリティを向上するために，ロック・マネージャ構造体の大部分が非ページング・プールから S2 空間に移動されました。多くのシステムで，ロック・マネージャ構造体は非ページング・プールの多くの部分を使用していました。
非ページング・プールに対してこのような変更が行われたため，次の操作を実行する必要があります。
ロック・マネージャが変更されたので，これらのパラメータは以前より小さい値に設定，または削除できる。
ロック・マネージャに関連するメモリについては，『Compaq OpenVMS DCL ディクショナリ: N--Z』のSHOW MEMORY の説明を参照してください。
5.9 OPCOM
ここでは，Operator Communication Manager (OPCOM) に関するリリース・ノートをまとめます。
5.9.1 変更された OPCOM メッセージ (Alpha のみ)
V7.2
OpenVMS Alpha バージョン 7.2 以降では，ジョブ・コントローラとキュー・マネージャからの OPCOM メッセージはユーザ・プロセスとして SYSTEM を表示します。
例:
%%%%%%%%%%% OPCOM 16-NOV-2000 15:07:49.33 %%%%%%%%%%% Message from user SYSTEM on NODEX %JBC-E-FAILCREPRC, job controller could not create a process %%%%%%%%%%% OPCOM 16-NOV-2000 15:07:49.34 %%%%%%%%%%% (from node BENN at 16-NOV-2000 15:07:49.34) Message from user SYSTEM on NODEX -QMAN-I-QUEAUTOOFF, queue NODEX$BATCH is now autostart inactive |
『Compaq OpenVMS システム管理者マニュアル』の例には，この変更が反映されていません。
5.9.2 誤ったオペレータ・クラスの処理
V7.3
以前は，OPC$OPA0_CLASSES 論理名または OPC$LOGFILE_CLASSES 論理名に誤ったクラスが含まれていると，OPCOM がエラーを表示し，処理が停止しました。
この問題は，OpenVMS バージョン 7.3 で修正されました。
OPCOM に次の 2 つのメッセージが追加されました。
%%%%%%%%%%% OPCOM 18-MAY-2000 13:28:33.12 %%%%%%%%%%% "BADCLASS" is not a valid class name in OPC$LOGFILE_CLASSES %%%%%%%%%%% OPCOM 18-MAY-2000 13:28:33.12 %%%%%%%%%%% "BADCLASS" is not a valid class name in OPC$OPA0_CLASSES |
誤ったクラス名がどちらかの論理名に指定されると，そのことを示すエラー・メッセージが表示されます。これらのメッセージはシステム・スタートアップ時にコンソールに表示され，OPERATOR.LOG に記録されます。
すべてのオペレータ・クラスのリストは，次のとおりです。
CARDS
CENTRAL
CLUSTER
DEVICES
DISKS
LICENSE
NETWORK
OPER1〜OPER12
PRINTER
SECURITY
TAPES
誤ったクラスを指定すると，すべてのクラスが有効化されます。この変更により，リストされたエラー・メッセージは可能な限り多くのオペレータの目に触れるようになります。
5.9.3 OPC$ALLOW_INBOUND と OPC$ALLOW_OUTBOUND の処理
V7.3
以前，OPC$ALLOW_INBOUND と OPC$ALLOW_OUTBOUND が FALSE に設定されたときに OPCOM が使用していたアルゴリズムは，あまりにも制限が多すぎるということがわかりました。これらの論理名では，メッセージが OPCOM の内側に入ることも，外側に出ることもできないためです。
これらの論理名を同時に OpenVMS Cluster で使用すると，クラスタ内の異なるシステムで OPCOM プロセスが通信を停止する可能性がありました。その結果，OPERATOR.LOG ファイルが次のようなメッセージでいっぱいになっていしまう恐れがありました。
%%%%%%%%%%% OPCOM 29-APR-2000 11:33:31.73 %%%%%%%%%%% OPCOM on AAAAA is trying again to talk to BBBBB, csid 00010001, system 00001 |
この問題を修正するために，OpenVMS Cluster 内の複数の OPCOM プロセスの間で相互に通信メッセージをやりとりできるように，アルゴリズムの制限が緩やかにされました。
それでも引き続き，これらの論理名を使用する場合には注意が必要です。これらの論理名を使用するのは，OPCOM メッセージが 1 方向または両方向で無効化された場合にシステム全体が受ける影響を本当に理解しているユーザだけにしてください。
5.9.4 OpenVMS Cluster 内のワークステーション
V7.3
OPCOM のデフォルトの動作は，OpenVMS Cluster 内のワークステーションでは OPA0: を有効化しないことです。さらに OPCOM は，これらのシステムにあるログファイル OPERATOR.LOG についても，有効化しません。唯一の例外は，システムがクラスタに追加される最初のシステムである場合です。
OPCOM は，あるシステムがワークステーションであるかどうかを，そのシステムにグラフィック・デバイスがあるかどうかによって判断します。このテストは，通常次のように実行します。
F$DEVICE ("*", "WORKSTATION", "DECW_OUTPUT")
|
OPCOM は，グラフィック・デバイスがあるシステムを，ワークステーションとして扱います。そのため，OPA0: と OPERATOR.LOG は，デフォルトでは有効化されません。
このデフォルトの動作を変更するには，SYS$MANAGER:SYLOGICALS.COM の中の次の論理名を TRUE に定義します。
ここでは，OpenVMS Cluster システムに関するリリース・ノートをまとめます。
5.10.1 パケット損失に関する新エラー・メッセージ
OpenVMS バージョン 7.3 より前のバージョンでは，LANのパスが使えなくなると，まず SCS 仮想サーキット閉塞が最初に発生します。 OpenVMS バージョン 7.3 では，最後に使用可能な LAN パスで超過レートによりパケットを損失すると，PEDRIVER により次のコンソール・メッセージが表示されます。
%PEA0, Excessive packet losses on LAN Path from local-device-name - _ to device-name on REMOTE NODE node-name |
このメッセージは，PEDRIVER により LAN パス (ローカル・デバイス，中継ネットワーク，およびリモート・ノードのデバイスで構成される) で過度のレートでパケットの再転送が行われた直後に表示されます。このメッセージは，LAN パスの品質低下や，リモート・ノードと通信の信頼性が失われそうな場合，または失われている場合に表示されます。損失が継続すると，リモート・ノードへの仮想サーキットが閉じる可能性があります。さらに，LAN パケットの損失が継続すると，パケット損失検知のタイムアウトとパケットの再送信により通信が遅延するため，パフォーマンスに重大な影響が出ます。
次の修復手順を実行してください。
$ SHOW DEVICE local-device-name $ MC SCACP SCACP> SHOW LAN device-name $ MC LANCP LANCP> SHOW DEVICE device-name/COUNT |
必要な場合，弊社のサポート担当者に連絡の上，LAN パスの問題を診断するためのサポートを受けてください。
PEDRIVER のトラブルシューティング情報については，『Compaq OpenVMS Cluster システム』の付録 F を参照してください。
5.10.2 複合バージョン・クラスタのClass Scheduler
V7.3
OpenVMS Alpha バージョン 7.2x を実行するノードが含まれる複合バージョン・クラスタ環境で新しい固定 Class Scheduler を使用する場合，これらのノードに対して SYSMAN CLASS_SCHEDULE サブコマンドを実行すると，これらのノードの SMISERVER プロセスが中断します。
この場合，次のコマンドを実行すると，これらのノードの SMISERVER プロセスを再起動できます。
@SYS$SYSTEM:STARTUP SMISERVER |
この問題を解決するための修正キットは，次の Web サイトからダウンロードできます。
この問題は，OpenVMS Alpha バージョン 7.2x を実行する Alpha プラットフォームだけに発生します。
5.10.3 複合バージョン OpenVMS Cluster システムで使用している Extended File Cache (XFC) に必要な修正キット
V7.3
OpenVMS Alpha オペレーティング・システムのこのバージョンで導入された Extended File Cache (XFC) により，入出力性能が向上し，ユーザはキャッシュおよびキャッシュ・パラメータの選択に関する決定権を持つようになります。
以前のバージョンの OpenVMS Alpha または OpenVMS VAX が含まれている OpenVMS Cluster システムで，OpenVMS バージョン 7.3 の XFC を使用するには，修正キットを以前のバージョンの OpenVMS を実行しているシステムにインストールしなければなりません。修正キットの情報については， 第 5.10.5 項 を参照してください。
これらの修正キットは，キャッシュのロック・プロトコルのエラーを修正し，以前のバージョンのキャッシュが新しい XFC で安全に動作できるようにします。修正キットの機能を使用しないと，システムまたはプロセスがハングする恐れがあります。 |
OpenVMS は，DEC-AXPVMS-VMS721_FIBRECHAN-V0300-4.PCSI キットを使用している場合を除いて，SANworks の Data Replication Manager (DRM) をサポートします。DRM とこのキットの間には互換性のない部分もあり，そのためにハード・ハングが発生します。この問題については，2 つの新しい修正キット，OpenVMS Alpha バージョン 7.2-1 および OpenVMS Alpha バージョン 7.2-1H1 で対応しています。キットの名前については， 第 5.10.5 項 を参照してください。
キット名の形式が変わったことに注意してください。 SCSI と Fibre Channel の修正キットは 1 つのキットに統合されました。新しい名前の形式には，この統合が反映されています。
対応する修正キットがオペレーティング・システムに含まれているため，この修正キットは，V7.3 では必要ありません。
5.10.5 クラスタの互換に必要な修正キット
OpenVMS バージョン 7.3 システムを既存の OpenVMS Cluster システムに導入する前に，特定の修正キットを，以前のバージョンの OpenVMS を実行しているシステムに適用しなければなりません。Fibre Channel，XFC または Volume Shadowing を使用する場合には，追加修正キットが必要です。これらのキットは，バージョンに固有です。
表 5-1 に，修正キットが必要な機能と，修正キット・ファイルのファイル名を示します。
修正キットは，次の Web サイトからダウンロードするか，弊社のサポート担当者に要求してください。
修正キットは，必要に応じて定期的にアップデートされます。キットの ReadMe ファイルに示されているように，機能に対応した最新の修正キットを使用してください。それぞれのキットの最新バージョンは， WWW サイトに記載されています。 |
| 機能 | ファイル名 |
|---|---|
| OpenVMS Alpha バージョン 7.2-1H1 | |
| 次のキット名以外のすべての機能 | DEC-AXPVMS-VMS721H1_UPDATE-V0100--4.PCSI |
| Fibre Channel | DEC-AXPVMS-VMS721H1_UPDATE-FIBRE_SCSI-V0100--4.PCSI |
| Volume Shadowing | DEC-AXPVMS-VMS721H1_SHADOWING-V0100--4.PCSI
このキットでは Fibre Channel ディザスタ・トレラント機能が提供されます。 |
| VCC | DEC-AXPVMS-VMS721H1_SYS-V0100--4.PCSI |
| OpenVMS Alpha バージョン 7.2-1 | |
| 次のキット名以外のすべての機能 | DEC-AXPVMS-VMS721_UPDATE-V100-4.PCSI |
| Fibre Channel | DEC-AXPVMS-VMS721_UPDATE-FIBRE_SCSI-V0100--4.PCSI |
| Volume Shadowing | DEC-AXPVMS-VMS721_SHADOWING-V0300--4.PCSI
このキットでは Fibre Channel ディザスタ・トレラント機能が提供されます。 |
| VCC | DEC-AXPVMS-VMS721_SYS-V0800--4.PCSI |
| OpenVMS バージョン 7.1 および 7.1-2 | |
| OpenVMS Cluster | DEC-AXPVMS-VMS712_PORTS-V0100--4.PCSI (Alpha 7.1-2) |
| Fibre Channel | ALPDRIV11_071 (Alpha 7.1)
DEC-AXPVMS-VMS712_DRIVER-V0200--4.PCSI (Alpha 7.1-2) VAXDRIV05_071 (VAX 7.1) |
| Monitor | ALPMONT02_071 (Alpha 7.1)
VAXMONT02_071 (VAX 7.1) |
| Mount | ALPMOUN07_071 (Alpha 7.1)
VAXMOUN05_071 (VAX 7.1) DEC-AXPVMS-VMS712_MOUNT96-V0100--4.PCSI (Alpha 7.1-2) |
| Volume Shadowing | ALPSHAD07_071 (Alpha 7.1)
VAXSHAD06_071 (VAX 7.1) |
| VCC | DEC-AXPVMS-VMS712_SYS-V0100--4.PCSI (Alpha 7.1-2) |
5.10.6 Fibre Channel の OpenVMS バージョン 7.2-1 でのインストールに関する制限事項
V7.2-1
OpenVMS Alpha バージョン 7.2-1 CD-ROM は，KGPSA-BC や KGPSA-CA をサポートしていないことに注意してください。このオペレーティング・システムは， KGPSA-BC や KGPSA-CA を介してアクセスされないディスクにインストールし，最新の FIBRECHAN キットを適用し，リブートしてから KGPSA-BC や KGPSA-CA を使用しなければなりません。
この制限事項は，OpenVMS Alpha バージョン 7.2-1 のみに適用されるだけで， OpenVMS Alpha バージョン 7.2-1H1 や OpenVMS Alpha バージョン 7.3 には適用されません。また，DEC-AXPVMS-VMS721_FIBRECHAN-V0300-4.PCSI より前のバージョンを使用しても HSG60 でディスクを設定することはできますが，これらのデバイスを使用するとエラーが発生する恐れがあります。このようなエラーは INVALID INQUIRYエラーとして記録され， HSG60 への冗長パスは設定できません。
HSG60 を使用する前に，次の手順を実行してください。
5.10.7 HSG ホスト接続テーブルがフルの場合にはデバイスは設定されない
V7.3
Fibre Channel ホスト・バス・アダプタが HSG コントローラに (Fibre Channel スイッチを介して) 接続されている場合には，HSG は HSG 接続テーブルのエントリを作成します。それぞれのホスト・バス・アダプタと，そのアダプタが接続されるそれぞれの HGS ポートには個別の接続が存在します (HSG CLI コマンド SHOW CONNECTIONS を参照してください)。
接続が確立されれば，『HSG Array Controller ACS Configuration and CLI Reference Guide』で説明するコマンドを使用して，パラメータを変更することができます。接続は変更することができるため，ホスト・バス・アダプタの接続が切断されても，HSG は接続情報をテーブルから削除しません。代わりに，接続して処理が完了した後，ユーザが CLI コマンドを使用して，接続を明示的に削除しなければなりません。
HSG は，一定の数の接続をサポートします。ACS V8.5 では最大で 64 の接続が可能であり，ACS V8.4 では最大で 32 の接続が可能です。この接続の上限は，シングル冗長コントローラでも，デュアル冗長コントローラでも同じです。最大接続数に達すると，新しい接続ができなくなります。このようになると， OpenVMS が HSG 上で，ディスク・デバイスまたはディスク・デバイスへの特定のパスを設定しなくなります。
この問題を解決するには，不要になった以前の接続を削除します。ただし，Fibre Channel ファブリックが大きく，アクティブな接続の数が HSG の上限を上回る場合には，このファブリックを再設定するか， FC スイッチ・ゾーンを使用して一部のアダプタを一部の HSG ポートから "隠し"，接続の数を減らさなければなりません。
OpenVMS の将来のバージョンでは，OpenVMS が HSG 接続テーブルがフルになっていることを検出すると，メッセージが表示されるようになります。
5.10.8 Console V5.6 以上での KGPSA NVRAM エラー
V7.2-1
V5.6 以上のバージョンのコンソールを使用すると， KGPSA ドライバが起動したときに， kgpsaa0.0.0.2.4 - Nvram read failedというエラー・メッセージが表示されます。このエラーは，KGPSA の NVRAM がフォーマットされていないか，正常に動作していないことを示します。まず考えられる原因は， NVRAM がフォーマットされていないことです。 V5.6 より前，NVRAM は，常にフォーマットされていませんでした。 V5.6 以降，KGPSA アダプタの NVRAM の一部が，ファブリック (スイッチ) トポロジとループ・トポロジのどちらに対応するようアダプタを初期化するべきかを示すために使用されています。デフォルトでは，コンソールは KGPSA をファブリック・トポロジに対応するよう初期化します。
次の例のように，トポロジを設定すると，NVRAM は自動的にフォーマットされます。
P00>>>set mode diag P00>>>wwidmgr -show adapter item adapter WWN Cur. Topo Next Topo kgpsaa0.0.0.8.1 - Nvram read failed. [ 0] kgpsaa0.0.0.8.1 1000-0000-c920-05ab FABRIC UNAVAIL kgpsab0.0.0.10.1 - Nvram read failed. [ 1] kgpsab0.0.0.10.1 1000-0000-c921-0ce0 FABRIC UNAVAIL [9999] All of the above. P00>>>wwidmgr -set adapter -item 9999 -topo fabric kgpsaa0.0.0.8.1 - Nvram read failed. Reformatting nvram kgpsab0.0.0.10.1 - Nvram read failed. Reformatting nvram P00>>>wwidmgr -show adapter item adapter WWN Cur. Topo Next Topo [ 0] kgpsaa0.0.0.8.1 1000-0000-c920-05ab FABRIC FABRIC [ 1] kgpsab0.0.0.10.1 1000-0000-c921-0ce0 FABRIC FABRIC [9999] All of the above. P00>>>init |
KGPSA の NVRAM をフォーマット中に， wwidmgr -set adapterコマンドを実行すると，次のエラーが発生します。
*** MBX not ready ***
次の例のように，このコマンドは再実行すれば成功します。
P00>>>wwidmgr -set adapter -item 9999 -topo fab pga0.0.0.6.1 - Nvram read failed. Reformatting nvram *** MBX not ready *** pgb0.0.0.1.2 - Nvram read failed. Reformatting nvram P00>>>wwidmgr -show adapter item adapter WWN Cur. Topo Next Topo *** MBX not ready *** pga0.0.0.6.1 - Nvram format incorrect. [ 0] pga0.0.0.6.1 1000-0000-c920-a763 FABRIC UNAVAIL [ 1] pgb0.0.0.1.2 1000-0000-c920-c9fe FABRIC FABRIC [9999] All of the above. P00>>>wwidmgr -set adapter -item 9999 -topo fab P00>>>wwidmgr -show adapter item adapter WWN Cur. Topo Next Topo [ 0] pga0.0.0.6.1 1000-0000-c920-a763 FABRIC FABRIC [ 1] pgb0.0.0.1.2 1000-0000-c920-c9fe FABRIC FABRIC [9999] All of the above. |
wwidmgr -set adapterコマンドの詳細については， Alpha Systems Firmware Update CD-ROM の [.DOC] ディレクトリにある『WWIDMGR User's Manual』を参照してください。
5.10.9 選択型自動構成は Fibre Channel 構成と SCSI 構成の一部ではサポートされない
V7.2-1
OpenVMS Alpha では，システム管理者がどのデバイスを自動構成するかを指定できる， SYSMAN コマンドが提供されています。デバイスの自動構成は，それぞれのシステムのブート時，または手動による自動構成コマンドの実行中に恒久的に適用されるように，次の修飾子を使用して指定することができます。
SYSMAN> IO SET/EXCLUDE=(device_name) SYSMAN> IO AUTOCONFIGURE [/EXCLUDE=(device_name)] [/SELECT=(device_name)] |
/EXCLUDE 修飾子と /SELECT 修飾子を使用すると，Fibre Channel ポート・ドライバ・デバイス (PG と FG) および SCSI ポート・ドライバ・デバイス (PK) を除外したり，取り込んだりすることができます。
しかし，これらの修飾子を使用して，次のデバイス・タイプを除外したり，取り込んだりすることはできません。
この制限事項は，OpenVMS Alpha バージョン 7.1 システムにインストールされている SCSI デバイスのデバイス名に，ポート割り当てクラスが含まれている場合には，その SCSI についても適用されます。
5.10.10 SHOW コマンドの実行で Fibre Channel デバイスのデバイス・タイプが誤って表示される (VAX のみ)
V7.2
Fibre Channel デバイスは，OpenVMS VAX システムにサービスを提供することができます。OpenVMS VAX バージョン 7.2 (以上の) システムでは， SHOW DEVICE/FULL コマンドを Fibre Channelデバイス ($1$DGAxxxx) に対して実行すると，次の例のように，誤ったデバイス・タイプ Snapshot-capable virtual disk deviceが表示されます。
$ SHOW DEV/FULL $1$DGA1000 Disk $1$DGA1000: (CRNPOP), device type Snapshot-capable virtual disk device, is online, mounted, file-oriented device, shareable, available to cluster, error logging is enabled. |
この場合のデバイス・タイプは，DEC HSG80 のはずです。
5.10.11 MEMORY CHANNEL のローリング・アップグレードの制限事項 (Alpha のみ)
V7.3
OpenVMS バージョン 7.3 は， 第 1.2 節 で説明しているとおり，OpenVMS Cluster システムでのローリング・アップグレードをサポートしています。
ここでは，OpenVMS Alpha バージョン 7.1 (またはバージョン 7.1 相当) から次のいずれかへのローリング・アップグレードについて説明します。
OpenVMS をバージョン 7.2 (またはバージョン 7.2 相当)，またはバージョン 7.3 にアップグレードする前に MEMORY CHANNEL アダプタ (CCMAA-xx) がクラスタに追加されている場合には，2 番目以降のシステムのインストール中に AUTOGEN および SHUTDOWN を実行すると，最初のシステムで MC_FORCEDCRASH バグチェックが実行されます。この問題の原因は，システム・パラメータの競合です。
アップグレードの時にこの問題が発生するのを回避するには，次のいずれかの手順を実行します。
すべてのシステムがアップグレードされたら，MEMORY CHANNEL ハブの電源をオンにします。
すべてのシステムがアップグレードされたら， MEMORY CHANNEL ケーブルを接続します。
MEMORY CHANNEL ハードウェアの設定の詳細については，『MEMORY CHANNEL User's Guide (EK--PCIMC--UG.A01)』を参照してください。このマニュアルは，OpenVMS Version 7.3 CD-ROM から，次のファイル名を使用してコピーすることができます。
[DOCUMENTATION]HW_MEMORY_CHANNEL2_UG.PS |
5.10.12 HSZ 割り当てクラスを使用するマルチパス・デバイスに対するブート・サポート
AlphaServer 2x00(A) を除く，KZPBA-CB をサポートするすべての AlphaServer システムは，HSZ 割り当てクラスを使用するデバイスからのブートをサポートしています (割り当てクラスのサポートは， OpenVMS での SCSI マルチパス・フェールオーバをサポートするために，これらのコントローラに追加されました)。
OpenVMS V7.3 に必要な Alpha コンソール・ファームウェアは，Version 5.9 以上です。
5.10.13 ローカル・パスと MSCP がサービスを提供するパスの間でのフェールオーバ
V7.2
ローカル・パス (SCSI または Fibre Channel デバイスへ) から MSCP がサービスを提供するパスへ，さらに同一のデバイスへのフェールオーバは，現在，使用できません。このタイプのフェールオーバは，OpenVMS バージョン 7.3 のリリース後の配布での実現が検討されています。
MSCP パスへのフェールオーバはまだ使用できませんが，マルチパス・デバイスは， OpenVMS Cluster システムの他のシステムに対して MSCP によりサービスを提供することができます。 MSCP がサービスされるシステム間のフェイルオーバーは，すべてのデバイスに対して機能します。
5.10.14 マルチパス SCSI シャドウ・セットと Fibre Channel シャドウ・セット: システム・パラメータの調整
V7.2
特定のシステム・パラメータのデフォルト設定を使用したために，そのマルチパス・サポートに対応して設定されているシャドウ・セット・メンバ (Compaq Volume Shadowing for OpenVMS を使用しているシステム) が削除されることがあります。
このため，Volume Shadowing for OpenVMS を使用しているマルチパス・シャドウ・セットを設定する場合には， 表 5-2 の推奨値で，これらのシステム・パラメータを設定してください。
| システム・パラメータ | 推奨設定 |
|---|---|
| MSCP_CMD_TMO | 最小値として 60。
60 は，ほとんどの構成では適切な値である。一部の構成では，より大きい値が必要な場合もある。 |
| SHADOW_MBR_TMO | 3 x MSCP_CMD_TMO |
| SHADOW_SYS_TMO | 3 x MSCP_CMD_TMO |
| MVTIMEOUT | 2 x SHADOW_MBR_TMO (最小値) |
次の例に，推奨設定の使用方法を示します。
MSCP_CMD_TMO 60 SHADOW_MBR_TMO 180 SHADOW_SYS_TMO 180 MVTIMEOUT 1200 |
5.10.15 マルチパス・デバイス: マウント処理中のボリュームのリビルド
V7.2-1
Fibre Channel デバイスまたは SCSI デバイスをマウントすると，特別なエラーも発生せずにボリュームがすでにディスマウントされているにもかかわらず，次の例のようにボリュームのリビルドが実行されることがあります。
$ DISMOUNT $1$DGA32762: $ $ MOUNT/CLUSTER $1$DGA32762: MYVOL %MOUNT-I-MOUNTED, DGA1016 mounted on _$1$DGA32762: (FIBRE2) %MOUNT-I-REBUILD, volume was improperly dismounted; rebuild in progress |
回避方法
特権を持つユーザは，次の例のように，ディスマウントする直前に，このデバイスに対する入出力を実行することによって，この問題を回避できます。
$ CREATE $1$DGA32762:[0,0]A.TMP $ DELETE $1$DGA32762:[0,0]A.TMP;0 |
5.10.16 マルチパス・デバイス: ボリューム・シャドウイングでのディスマウントの問題
V7.3
シャドウ・セットのマルチパス・メンバが，ディスマウントされる前にパスを切り替え，DISMOUNT コマンドが実行される直前に何の入出力も実行されなかった場合には，ディスマウントは失敗し，次のエラー・メッセージが表示されます。
%DISM-W-CANNOTDMT |
このエラーは，次の状況では発生しません。
回避方法
特権を持つユーザは，次の例のように，ディスマウントする直前に，このデバイスに対する入出力を実行することによって，この問題を回避できます。
$ CREATE $1$DGA32762:[0,0]A.TMP $ DELETE $1$DGA32762:[0,0]A.TMP;0 |
5.10.17 マルチパス・フェールオーバが HSZ70/HSZ80 コントローラでまれに失敗する
負荷が大きい場合に，1 つのコントローラから別のコントローラへ，ホストから手動または自動でパスを切り替えると，HSZ70 または HSZ80 コントローラで失敗することがあります。テストにより，このエラーはまれにしか発生しないことがわかっています。
この問題は，HSZ70 については，ファームウェア・リビジョン HSOF V7.7 (およびそれ以上のバージョン) ですでに修正されています。HSZ80 については，将来のリリースで修正されることになっています。この問題は， HSG80 コントローラでは発生しません。 |
V7.2
システムと SCSI デバイス間に存在する複数のパス間でのフェールオーバをサポートする SCSI マルチパス機能は，OpenVMS Alpha バージョン 7.2 で導入されました。
このSCSI マルチパス機能は，サード・パーティのディスク・キャッシング，ディスク・シャドウイング，または類似の機能を持つ製品との互換性がないことがあります。この機能がソフトウェアの製造元でサポートされるようになるまでは，そのようなソフトウェアを，マルチパス・フェールオーバを実行するために設定した SCSI デバイス (マルチバス・モードの HSZ70 コントローラや HSZ80 コントローラに接続される SCSI デバイスなど) では使用しないようにしてください。
OpenVMS Alpha SCSI ディスク・クラス・ドライバ (SYS$DKDRIVER.EXE) の Driver Dispatch Table (DDT) の変更に依存しているサード・パーティ製品で SCSI マルチパス機能が正常に動作するようにするには，製品を変更する必要があります。該当する製品の製造元の詳細については， Compaq の担当部門 vms_drivers@zko.dec.comまたは，サポート担当者までお問い合わせください。
OpenVMS Alpha SCSI マルチパス機能の詳細については，『Compaq OpenVMS Cluster 構成ガイド』を参照してください。
5.10.19 OpenVMS Cluster システムでの Gigabit Ethernet スイッチの制限事項
V7.3
Gigabit Ethernet スイッチを介して Gigabit Ethernet ノードを OpenVMS Cluster システムに追加しようとすると，スイッチが自動ネゴシエーションをサポートしていない場合には，失敗することがあります。DEGPA はデフォルトで自動ネゴシエーションを有効化しますが，すべての Gigabit Ethernet スイッチが自動ネゴシエーションをサポートしているとは限りません。たとえば，Cabletron が製造している現在の Gigabit Ethernet スイッチは，自動ネゴシエーションをサポートしていません。
さらに，表示されるメッセージが誤解を招く場合もあります。たとえば， CLUSTER_CONFIG.COM を使用してノードを追加し，ローカル・ページをインストールするオプションとスワップ・ディスクを選択していると，ディスク・サービスの問題であるかのように見えます。CLUSTER_CONFIG.COM を実行しているノードは "waiting for node-name to boot" というメッセージを表示する一方で，ブート・ノードは "waiting to tune system" というメッセージを表示するためです。使用可能なディスクのリストはまったく表示されません。ネットワーク・パスが失われているのは，DEGPA とスイッチの間の自動ネゴシエーションのミスマッチが原因であることが伝わりません。
この問題を回避するには，新しいノードの DEGPA での自動ネゴシエーションを，次のように無効にします。
5.10.20 DQDRIVER ネームスペースの競合の回避方法
V7.3
クラスタ内の複数のシステムは，それぞれ IDE，ATA，または ATAPI といったデバイスを持ち，それぞれ DQA0，DQA1，DQB0，および DQB1 といった名前を共有している可能性があります。
このようにデバイス名を共有すると，混乱やエラーが起きることがあります。 OpenVMS バージョン 7.2-1 以降は，デバイスに固有の名前を付けて作成することにより，この問題を回避できます。
クラスタで固有に命名されたデバイスのリストを作成するには，次の手順を実行します。
このファイルを編集して情報を手動で追加することも，次のコマンドをブートストラップ時に実行して，このファイルを自動的に更新することもできます。
SYSBOOT> SET /CLASS DQA 0 SYSBOOT> SET /CLASS DQB 0 |
次の例に，SYS$SYSTEM:SYS$DEVICES.DAT ファイルの例を示します (ノード名は ACORN::)。
[Port ACORN$DQA] Allocation Class = 0 [Port ACORN$DQB] Allocation Class = 0 |
この手順を実行すると，すべての DQ デバイスは，クラスタ全体で固有のデバイス名を使用できる，次の形式に従って命名されます。
node-name$DQxn:
node-name はシステム名
x は A または B
n は 0 または 1
ポート割り当てクラスについては，『Compaq OpenVMS Cluster システム』マニュアルを参照してください。このマニュアルでは，ここで説明した方法についても詳しく説明しています。
SYS$DEVICES.DAT ファイルでは，0 以外のポート割り当てクラスを使用することもできます。しかし，0 以外のポート割り当てクラスを使用する場合には，『Compaq OpenVMS Cluster システム』マニュアルで概要を説明している規則に必ず従ってください。
制限事項:
DCL コマンド $INITIALIZE を使用して，マス・ストレージ・コントロール・プロトコル (MSCP) サーバを使用しているリモート・システムにある IDC ハード・ドライブを初期化しようとすると，ボリュームに不良ブロック検出ファイルがないことを示す警告メッセージが表示されることがあります。この警告メッセージは，無視しても構いません。
さらに，特定の製造元の製品では，未使用ドライブには，ヘッド・アラインメント・テスト・ディスクで使用されるデータ・パターンをまねて，工場出荷時に書き込まれたデータが含まれていることがあります。このような場合には，OpenVMS ソフトウェアはこのディスクをリモートで初期化しません。この問題を回避するには，ディスクをローカル・システムから初期化します。この回避方法を使用すれば，不良ブロック検出ファイルがないという警告メッセージも回避することができます。
5.10.21 廃止された Fibre Channel マルチスイッチ・ファブリックに関するシャドウイングの制限事項
V7.3
OpenVMS では，マルチスイッチ Fibre Channel ファブリックがサポートされます (DEC-AXPVMS-VMS721_FIBRECHAN-V0200 修正キット以降)。ただし，マルチスイッチ・ファブリックを含む構成で Volume Shadowing for OpenVMS を使用する場合は，重要な制限事項が適用されます。シャドウ・セットをマウントしたすべての Fibre Channel ホストは，同じスイッチに接続する必要がありました。つまり，すべての Fibre Channel シャドウ・セット・メンバを同じスイッチに接続する必要がありました。Fibre Channel ホストまたはシャドウ・セット・メンバが複数のファブリックに接続されている場合，各ファブリックでこの規則に従う必要があります。
OpenVMS バージョン 7.3 では Volume Shadowing for OpenVMS が変更され，これらの制限事項が解除されています。現在のバージョンに固有の Volume Shadowing 修正キットにより OpenVMS バージョン 7.2-1 および 7.2-1H1 で同じ変更が可能です。
5.10.22 Fibre Channel のインストールに NPAGEVIR が必要になる問題
V7.3
この問題は，OpenVMS Alpha バージョン 7.2-1H1 および OpenVMS Alpha バージョン 7.3 で新しいシステム・パラメータ NPAGECALC を導入することによって修正されました。このパラメータは，システムの物理メモリの量に基づいて，NPAGEVIR および NPAGEDYN の値を自動的に計算します。
5.10.23 システム・ブート後に Fibre Channel アダプタがオフラインになる問題
V7.3
Fibre Channel アダプタがシステム・ブート後にオフラインになっている問題は，次のバージョンで修正されています。
5.10.24 大規模な Fibre Channel 構成では SHOW DEVICE が失敗する問題
V7.2-1
大規模な Fibre Channel 構成で SHOW DEVICE が失敗する問題は，以下のバージョンで修正されています。
修正前は，2400 を超えるユニット・コントロール・ブロック (UCB) のあるシステムでは，SHOW DEVICE が virtual address space fullエラーで失敗する可能性がありました。マルチパス SCSI および FC 構成では，ホストからそれぞれのストレージ・デバイスに対して 1 つの UCB が存在しました。
SHOW DEVICE を呼び出す，CLUSTER_CONFIG のようなプロシージャを実行した場合にも，この問題が発生する可能性があることに注意してください。
5.10.25 ループバック・コネクタがインストールされているシステムに KGPSA があるとブートが失敗する問題
V7.2-1
KGPSA ループバック・コネクタのブート障害の問題は，以下のバージョンで修正されています。
修正前は，ループバック・コネクタがインストールされているシステムに KGPSA があると，システムはブートに失敗しました。ループバック・コネクタとは，KGPSA の GLM/光ファイバ・ポートを覆っている，黒いプラスチック製の保護カバーです。
できるだけ，システムに KGPSA をインストールする前に， OpenVMS Alpha バージョン 7.2-1 および FIBRE_SCSI update kit for OpenVMS Alpha Version 7.2-1 キットをインストールしてください。
KGPSA がすでにインストールされ，現在の FIBRE_SCSI update kit for OpenVMS Alpha Version 7.2-1 がインストールされていない場合には，KGPSA を Fibre Channel ストレージ・サブシステムに接続してから， OpenVMS をブートすることができます。
KGPSA を Fibre Channel ストレージ・サブシステムに接続する準備ができていない場合には，次のうちいずれかを実行します。
ループバック・コネクタが装着され，KGPSA がインストールされたままの状態で OpenVMS をブートしようとすると，システムはブート・プロセスの初期に Fibre Channel アダプタを設定するところでハングします。
5.10.26 Fibre Channel パス名の構文での引用符の使用の問題
V7.2
OpenVMS Alpha バージョン 7.3 から，Fibre Channel パス名を引用符で囲むことができるようになりました。
OpenVMS バージョン 7.3 より前のバージョンでは，ドキュメントやヘルプテキストで，パス名を次の例のように引用符で囲むことができると説明していました。
$ SET DEVICE $1$dga166:/PATH="PGA0.5000-1FE1-0000-1501"/SWITCH |
OpenVMS バージョン 7.3 より前のバージョンのシステムでは，このコマンドを実行すると，次のエラーが発生していました。
%SET-E-NOSUCHPATH, path "PGA0.5000-1FE1-0000-1501" does not exist for device $1$DGA166: |
以前のバージョンの OpenVMS を実行しているシステムでこの問題を回避するには，次のように，パス識別文字列を囲んでいる引用符を削除してください。
$ SET DEVICE $1$dga166:/PATH=PGA0.5000-1FE1-0000-1501/SWITCH |
5.10.27 再設定した Fibre Channel ディスクがオンラインにならない問題
V7.2
この問題は，OpenVMS Alpha バージョン 7.2-1H1 および OpenVMS Alpha バージョン 7.3 では修正されています。
それぞれの Fibre Channel デバイスは，HSG80 に 2 つの識別子を持っています。最初の識別子は論理ユニット番号 (LUN) です。この値は，コマンド ADD UNIT Dnnn を HSG80 で実行すると設定され， nnn が LUN 値になります。この LUN 値は，HSG80 でパケットを正しい宛先に配布するために使用されます。LUN 値は，HSG80 サブシステム上で固有に識別できるものでなければなりません。2 番目の識別子は，デバイス識別子です。この値は，次のコマンドを実行すると設定され， nnnnn がデバイス識別子になります。
$ SET Dmmm IDENTIFIER=nnnnn |
デバイス識別子は OpenVMS のデバイス名で使用され，クラスタ内で固有に識別できるものでなければなりません。
5.10.28 HSG80 CCL でのデバイス識別子の必要条件
V7.2
OpenVMS Alpha バージョン 7.2-1H1 および OpenVMS Alpha バージョン 7.3 では，デバイス識別子を HSG CCL に割り当てる手順はオプションです。この割り当てを実行しない場合には，OpenVMS は $1$GGA デバイスを設定しませんが，HSG サブシステムの他のデバイスについては設定します。
5.10.29 好ましくない自動パス切り替えの問題
この問題は，OpenVMS Alpha バージョン 7.3 では，現在のパスに優先順位を与えることで，一時的なエラーの後でパスの切り替えを回避できるように修正されています。
マウント・チェックを起動する入出力エラーが発生するつど，マルチパス・フェールオーバ・コードは現在のパスを検索します。以前のバージョンの OpenVMS では，マルチパス・アルゴリズムは 1 次パス (OpenVMS によって設定される最初のパス) から開始され，検索を実行し，オンラインになっているデバイスのある HSx コントローラへの直接パスに優先順位を与えていました。修正前は，このアルゴリズムは現在のパスを最初にテストせず，エラー状態がクリアになっていても，そのパスを続けて検索することはありませんでした。
5.11 OpenVMS レジストリ
ここでは，OpenVMS レジストリのリリース・ノートについてまとめます。
5.11.1 OpenVMS V7.3またはV7.2-1 の複合クラスタでのレジストリ・サービス
V7.3
OpenVMS NT レジストリでのデータ転送サイズの制限事項を解除するために，レジストリで使用する通信プロトコルが変更されました。この変更では，OpenVMS V7.3 のレジストリ ($REGISTRY システム・サービスとレジストリ・サーバ) のコンポーネントが OpenVMS V7.2-1 の対応するコンポーネントと互換性を持ちません。
複合バージョンの OpenVMS のクラスタを実行する場合，$REGISTRY サービスまたは$REGISTRY サービスを使用する製品 (Advanced Server，COM for OpenVMS など) を実行するときに，これらのサービスを OpenVMS V7.3 ノードのみ，または V7.2-1 ノードのみに限定する必要があります。両方のノードでは同時に使用できません。
V7.3 と V7.2-1 の両方を含むクラスタ内でレジストリ・サービスを実行する場合は，弊社のサービス担当者にご連絡ください。
5.11.2 OpenVMS NT レジストリ・データベースのバックアップと復元
V7.3
OpenVMS NT レジストリ・データベースのバックアップと復元については，『OpenVMS コネクティビティ開発者ガイド』を参照してください。定期的なバックアップをお勧めします。データベースが破損することはめったにありませんが，旧バージョンの OpenVMS では 2MB を超えるデータベースで破損する場合があることがテストで発見されました。ただし，初期のデータ・サイズは 8 KB なので，このサイズのデータベースはほとんどありません。さらに，クラスタ全体をリブートするときだけに発生する可能性があります。
レジストリ・サーバでは，データベースの自動バックアップが可能です。デフォルトでは，1 日 1 回レジストリ・サーバによりデータベースのスナップショットが作成されます。ただし，この操作は，基本的にはファイルのコピー操作であり，デフォルトでは，コピーを最新の 5 つに制限します。データベースの特定の領域が破損している可能性があっても，アプリケーションが破損部分にアクセスしないかぎりレジストリ操作は継続されます。そのため，日次のバックアップでは，すでに破損したファイルのコピーが作成されることがあります。
これを防ぐには，次の手順を実行することをお勧めします。
また，OpenVMS の旧バージョンでは，一定の条件下で EXPORT コマンドによる操作が失敗することがありました。この場合の回復操作は，REG$CP イメージを再起動し，成功するまで操作を繰り返します。
さらに，旧バージョンの OpenVMS の場合，IMPORT コマンドがクラス名またはリンクを持つキーを正しくインポートできませんでした。この状態から回復するには，キーを修正してクラス名またはリンクに追加するか，問題のキーを再作成します。
5.12 性能---アプリケーション性能データの比較
V7.3
OpenVMS の仮想入出力キャッシュ (VIOC) および拡張ファイル・キャッシュ (XFC) は，入出力のボトルネックを解消し，性能を向上させる，ファイル指向のディスク・キャッシュです (XFC は，バージョン 7.3 から Alpha システムに導入されていることに注意してください)。キャッシュ操作は，アプリケーション・ソフトウェアに対して透過的です。使用頻度の高いファイル・データはメモリにキャッシュされ，ディスクからではなく，メモリから直接，入出力要求に応答できるようになっています。
バージョン 7.0 より前は，データがキャッシュから戻されるために入出力が回避されると，プロセスの直接入出力カウント (DIO) は増加しませんでした。実際には，プロセスはデバイスへの入出力操作を実行していなかったためです。バージョン 7.0 以降は，すべての入出力要求について，データがキャッシュから戻されるため，実際には回避される入出力であっても，直接入出力としてカウントされるように変わりました。
この変更が，バージョンが異なる OpenVMS でアプリケーション性能を比較する際の混乱の原因です。アプリケーションは，バージョン 7.0 以降で実行した場合には，それ以前のバージョンで実行した場合と比較すると，ディスクに対する実際の入出力量は等しいにもかかわらず，より多くの入出力を実行しているように見えるのです。
5.13 ポイント・ツー・ポイント・ユーティリティのドキュメンテーション
ポイント・ツー・ポイント・ユーティリティ (PPPD) では，OpenVMS Alpha ホスト・システムでポイント・ツー・ポイント・プロトコル (PPP) ネットワーク接続とリンク・パラメータを管理し，実行します。
PPP 接続をサポートする PPPD コマンドとそのパラメータおよび修飾子については，『Compaq OpenVMS システム管理ユーティリティ・リファレンス・マニュアル (下巻) 』の章を参照してください。
5.14 Queue Manager---ブート時間が長い
V7.3
キュー・ジャーナル・ファイル (SYS$QUEUE_MANAGER.QMAN$JOURNAL) は，非常に大規模なボリュームのキュー処理が発生すると，特に (500,000 ブロックを超える) 大規模なサイズになる場合があります。このため，ブート時間が長くなったり，エラー・メッセージ QMAN-E-NODISKSPACEが OPERATOR.LOG に表示されたりすることがあります。ブート時間が長くなるのは，Queue Manager がキュー・ジャーナル・ファイルを処理するための大量の領域を必要とするためです。
次の例に，operator.log に表示されるエラー・メッセージを示します。
%%%%%%%%%%% OPCOM 2-MAR-2000 23:05:31.24 %%%%%%%%%%%
Message from user QUEUE_MANAGE on PNSFAB
%QMAN-E-OPENERR, error opening $1$DUA0:[SYS3.SYSCOMMON.][SYSEXE]
SYS$QUEUE_MANAGER.QMAN$JOURNAL;1
%%%%%%%%%%% OPCOM 2-MAR-2000 23:05:32.42 %%%%%%%%%%%
Message from user QUEUE_MANAGE on PNSFAB
-RMS-F-FUL, device full (insufficient space for allocation)
%%%%%%%%%%% OPCOM 2-MAR-2000 23:05:32.87 %%%%%%%%%%%
Message from user QUEUE_MANAGE on PNSFAB
-SYSTEM-W-DEVICEFULL, device full - allocation failure
%%%%%%%%%%% OPCOM 2-MAR-2000 23:05:32.95 %%%%%%%%%%%
Message from user QUEUE_MANAGE on PNSFAB
%QMAN-E-NODISKSPACE, disk space not available for queue manager to continue
%%%%%%%%%%% OPCOM 2-MAR-2000 23:05:33.07 %%%%%%%%%%%
Message from user QUEUE_MANAGE on PNSFAB
-QMAN-I-FREEDISK, free up 191040 blocks on disk _$1$DUA0
|
特権を持つユーザが次の DCL コマンドを実行すれば，ジャーナル・ファイルのサイズを縮小することができます。
$ MCR JBC$COMMAND DIAG 7 |
この DCL コマンドを実行すると，キュー・ジャーナル・ファイルがチェックポイントされ，キューのシステム操作に必要な最小サイズに縮小されます。
この問題が解決されるまで，ジャーナル・ファイルのサイズを縮小するこの回避方法を使用してください。
5.15 RMS Journaling
ここでは，RMS Journaling for OpenVMS のリリース・ノートをまとめます。
5.15.1 変更されたジャーナル・ファイルの作成
バージョン 7.2 より前には，リカバリ・ユニット(RU) ジャーナルは，ジャーナリングされたファイルと同じボリュームの [SYSJNL] ディレクトリに一時的に作成されていました。リカバリ・ユニット・ジャーナルのファイル名は RMS$process_id (process_id はプロセス ID の 16 進表現) という形式であり，ファイル・タイプは RMS$JOURNAL でした。
OpenVMS バージョン 7.2 では，RU ジャーナル・ファイルの作成に関して，次の点が変更されました。
これらの変更により，ジャーナル・ファイルの作成と削除で発生するディレクトリのオーバーヘッドが削減されます。
次の例に，以前のバージョンと現在のバージョンの両方のジャーナル・ファイルの作成を示します。
以前のバージョン: [SYSJNL]RMS$214003BC.RMS$JOURNAL;1
現在のバージョン: [SYSJNL.NODE1]CB300412.;1
RMS が [SYSJNL] ディレクトリまたはノード固有のディレクトリを見つけることができない場合は，RMS は自動的にそのディレクトリを作成します。
5.15.2 カーネル・スレッドと互換性のないリカバリ・ユニット・ジャーナリング (Alpha のみ)
V7.3
DECdtm Services は複数カーネル・スレッド環境でサポートされず， RMS リカバリ・ユニット・ジャーナリングは DECdtm Services に依存しているため，RMS リカバリ・ユニット・ジャーナリングは，複数カーネル・スレッドが有効になっているプロセスではサポートされません。
5.15.3 順方向 (AI) ジャーナリング
V6.0
順方向 (AI) ジャーナリングを使用すれば，使用不能またはアクセス不能になったデータ・ファイルを回復することができます。AI リカバリでは，AI ジャーナル・ファイルを使用して，データ・ファイルのバックアップ・コピーをロール・フォワードすることで，障害が発生した時点でのデータ・ファイルの新しいコピーが作成されます。
プロセスが削除されたりシステムがクラッシュしたりした場合には，更新情報を AI ジャーナル・ファイルに書き込むことができますが，データ・ファイルに書き込むことはできません。 AI ジャーナリングだけが使用されている場合は，データ・ファイルとジャーナルの一貫性は自動的には維持されません。データ・ファイルに対して追加更新を行い，AI ジャーナルに記録すると，その後のロール・フォワード操作で一貫性のないデータ・ファイルが作成されることがあります。
リカバリ・ユニット (RU) ジャーナリングを AI ジャーナリングと組み合わせて使用した場合には，自動的なトランザクション・リカバリにより，AI ジャーナルとデータ・ファイルの間の一貫性が復元されます。
特定の状況では，AI ジャーナリングだけを使用するアプリケーションは，プロセスの削除やシステム・クラッシュの後，データの不整合が発生しないように，予防措置をとることができます。たとえば，AI ジャーナリングされているファイルの手動ロール・フォワードを行うと，非共有 AI アプリケーション (シングル・アクセッサ) やスタンドアロン・システムで実行中の共有AI アプリケーションなどが関連するシステム・クラッシュの後で，ファイルの一貫性を維持できます。
しかし，共有 AI アプリケーションでは，クラスタ内でプロセスの削除やシステム・クラッシュが発生した後で，AI ジャーナル・ファイルと同期のとれていないデータ・ファイルに対してこれ以上の操作が実行されないようにするための措置はとられません。このような状況では，データ・ファイルと AI ジャーナル・ファイルの間の一貫性は，AI ジャーナリングと RU ジャーナリングを組み合わせて使用することで維持できます。
5.15.4 OSI 環境でのリカバリ・ユニット・ジャーナリングされたファイルへのリモート・アクセス
V6.1
ネットワーク内の他のノードからリモート・アクセスされるリカバリ・ユニット・ジャーナリング・ファイルのホストである OSI ノードでは，SYS$NODE をフェーズ IV 形式のノード名として定義しなければなりません。 SYS$NODE によって指定されるノード名は，ホスト・ノードのリカバリ・ユニット・ジャーナリング・ファイルにアクセスしようとするすべてのリモート・ノードから認識されなければなりません。また，リモート・ノードがこのノード名を使用して，ホスト・ノードとの間で DECnet 接続を確立できるように，ノード名は固有の名前でなければなりません。この制限は，OSI または複合 OSI 環境と非 OSI 環境でネットワークを介してアクセスされる，リカバリ・ユニット・ジャーナリング・ファイルにだけ適用されます。
5.15.5 VFC 形式の順編成ファイル
逆方向ジャーナリングやリカバリ・ユニット・ジャーナリングを使用している場合，固定長制御部付可変長 (VFC) 順編成ファイルを更新することはできません。VFC 順編成ファイル形式は，FAB のFAB$B_RFM フィールドのシンボリック値 FAB$C_VFC によって示されます。
5.16 セキュリティ---DIRECTORY コマンドによる抑制された PATHWORKS ACE の要約表示
V7.1
OpenVMS バージョン 7.1 およびそれ以降では，PATHWORKS アクセス制御エントリ (ACE) を含むファイルに対して DCL コマンド DIRECTORY/SECURITY または DIRECTORY/FULL を実行すると，PATHWORKS ACE それぞれの 16 進表現は表示されなくなりました。その代わりに，各ファイルに対して検出された PATHWORKS ACE の総数が "Suppressed
n PATHWORKS ACE" というメッセージに要約されます。抑制されている PATHWORKS ACE を表示するには，DUMP/HEADER コマンドを使用します。
5.17 システム・パラメータ
ここでは，OpenVMS システム・パラメータのリリース・ノートをまとめます。
5.17.1 有効な MAXBOBMEM システム・パラメータ
V7.3
AUTOGEN ユーティリティを使用する場合，AGEN$PARAMS.REPORT に次の警告が表示されることがあります。
** WARNING - Parameter MAXBOBMEM is Obsolete . |
MAXBOBMEM システム・パラメータは，廃止されていません。
5.17.2 VCC_MAXSIZE システム・パラメータの定義の変更
V7.3
VCC_MAXSIZE システム・パラメータに関するオンライン・ヘルプおよび『Compaq OpenVMS システム管理ユーティリティ・リファレンス・マニュアル (下巻) 』の説明は，誤っています。
"この特殊なパラメータはコンパックが使用するものであり，予告なく変更される可能性があります。コンパックからの依頼がある場合を除いて，このパラメータは変更しないでください。"
引用符で囲まれた段落は無視してください。VCC_MAXSIZE は特殊なパラメータではないので，変更できます。また，現在，最大値は 3700000 に正しく設定されています。
XFC サイズを調整するには，VCC_MAX_CACHE システム・パラメータを使用します。
5.17.3 NISCS_MAX_PKTSZ システム・パラメータの定義の変更
V7.3
PEDRIVER は，NISCS_MAX_PKTSZ を使用して，LAN パケットで転送するデータの最大量を計算します。
LAN packet size <= LAN header (padded Ethernet format)
+ NISCS_MAX_PKTSZ
+ NISCS checksum (only if data checking is enabled)
+ LAN CRC or FCS
|
次の表は，特定の LAN タイプでサポートされる最大パケット・サイズの使用に必要な NISCS_MAX_PKTSZ の最小値をまとめたものです。これらの値は，オンライン・ヘルプと『Compaq OpenVMS システム管理ユーティリティ・リファレンス・マニュアル (下巻) 』のシステム・パラメータに関する付録で示されている値を訂正したものです。
| LAN のタイプ | NISCS_MAX_PKTSZ の最小値 |
|---|---|
| Ethernet | 1498 |
| FDDI | 4468 |
| Gigabit Ethernet | 7532 |
| ATM | 7606 |
V7.3
前回のリリース以降，次のシステム・パラメータの記述が変更，修正されています。
これらのシステム・パラメータの新しい記述の詳細については，次のコマンドを実行して，オンライン・ヘルプを参照してください。
$ HELP SYS_PARAMETERS FAST_PATH |
V7.3
OpenVMS バージョン 7.3 から，次のパラメータが廃止されます。
当初，パラメータ MAXBOBS0S1 および MAXBOBS2 は，ユーザがサイズの大きいバッファ・オブジェクトを作成することによってシステムに悪影響を与えないためのものでした。しかし，ユーザがバッファ・オブジェクトをより幅広く使用し始めると，これらのパラメータの組み合わせの管理は複雑すぎます。
ユーザがバッファ・オブジェクトを作成するには， VMS$BUFFER_OBJECT_USER 識別子を保持するか，エグゼクティブ・モードまたはカーネル・モードで実行しなければなりません。したがって，これらのユーザは特権を持つアプリケーションであるとみなされるため，これらのパラメータが提供する追加の予防措置は不要です。
システム・メモリ・リソースの現在の使用状況を判断するには，次のコマンドを入力します。
$ SHOW MEMORY/BUFFER_OBJECT
|
5.18 Terminal Fallback Facility (TFF) (Alpha のみ)
OpenVMS Alpha システムの Terminal Fallback Facility (TFF) には，フォールバック・ドライバ (SYS$FBDRIVER.EXE)，共有可能イメージ(TFFSHR.EXE)， Terminal Fallback ユーティリティ (TFU.EXE)，フォールバック・テーブル・ライブラリ (TFF$MASTER.DAT) が含まれます。
TFFSHR は，ドキュメントに説明されているユーザ呼び出し可能インタフェースではないので，IMAGELIB から削除されています。ただし，イメージは現在でも SYS$LIBRARY: ディレクトリにあります。 |
TFF を起動するには，次のように SYS$MANAGER にある TFF スタートアップ・コマンド・プロシージャを起動します。
$ @SYS$MANAGER:TFF$SYSTARTUP.COM |
フォールバックを有効にしたり，フォールバック属性を変更するには，次のように Terminal Fallback ユーティリティ (TFU) を起動します。
$ RUN SYS$SYSTEM:TFU TFU> |
端末に対するデフォルトのフォールバックを有効にするには，次の DCL コマンドを入力します。
$ SET TERMINAL/FALLBACK |
Compaq OpenVMS TFF は，次の点で OpenVMS VAX TFF と異なります。
| テーブル名 | ベース | 説明 |
|---|---|---|
| BIG5_HANYU | BIG5 | CNS 11643 (SICGCC) 端末/プリンタの場合は BIG5 |
| HANYU_BIG5 | CNS | BIG5 端末/プリンタの場合は CNS 11643 (SICGCC) |
| HANYU_TELEX | CNS | MITAC TELEX-CODE 端末の場合は CNS 11643 |
| HANGUL_DS | KS | DOOSAN 200 端末の場合は KS |
これらのテーブルは主にアジア地域で使用されます。また，このテーブルの形式は，16 ビット文字フォールバックのサポートのために変更されています。
Terminal Fallback Facility の詳細については，『OpenVMS Terminal Fallback Utility Manual』を参照してください。このマニュアルの注文番号は AA--PS6BA--TE です。このマニュアルは， OpenVMS Documentation CD-ROM (の中のアーカイブ・マニュアルのディレクトリ) からオンラインで利用することもできます。
5.19 Volume Shadowing for OpenVMS
ここでは，Volume Shadowing for OpenVMS のリリース・ノートをまとめます。
5.19.1 すべてのクラスタ・ノードに必要なミニコピー・バージョン
V7.3
OpenVMS Alpha バージョン 7.3 では，Compaq Volume Shadowing for OpenVMS のミニコピー機能がサポートされます。
OpenVMS Cluster システムでボリューム・シャドウイングの新機能を使用するには，このサポートを含む OpenVMS バージョン 7.3 または OpenVMS バージョン 7.2--xx へのアップグレードをすべてのノードに行う必要があります。この制限事項は，OpenVMS を使用してディスクにサービスする HS121 などのすべてのストレージ・コントローラに関係します。
ミニコピー・サポートを含む OpenVMS バージョン 7.2--xx へのアップグレードは，OpenVMS バージョン 7.3 のリリース直後に提供される予定です。
5.19.2 マルチパス HSG/HSZ ディスク・パーティションとボリューム・シャドウイングの制限事項
V7.3
HSG80，HSG60，HSZ80，またはHSZ70 コントローラのマルチパス・ディスクのパーティションは，ディスクをそのパーティション専用に使用する場合だけに ホスト・ベースのボリューム・シャドウ・セット (HBVS) のメンバとして使用できます。具体的には，パーティション化されたディスクの残りの領域を，HBVS メンバのパーティションからも同時にアクセスできる他の論理ユニットに使用することはできません。
この制限を守らない場合，次の状態が発生します。
弊社では，今後この制限を排除する予定です。
5.19.3 /MINICOPY を使用したクライアントのディスマウント - 初回ディスマウントのエラーの可能性
V7.3
OpenVMS Cluster 構成では，シャドウ・セットのメンバをクライアントでディスマウントをミニコピー修飾子を指定して行うと，最初の DISMOUNT コマンドが失敗することがあります。
最初の DISMOUNT コマンドが失敗した場合，次の例のようにコマンドを繰り返します。
$SHOW DEVICE DSA5555 Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt DSA5555: Mounted 0 $80$DKA107: 7994646 1 18 $80$DKA107: (WILD3) ShadowSetMember 0 (member of DSA5555:) $80$DKA302: (WILD3) ShadowSetMember 0 (member of DSA5555:) $80$DKA303: (WILD3) ShadowSetMember 0 (member of DSA5555:) $ $ $DISMOUNT/POLICY=MINICOPY $80$DKA302: %DISM-W-CANNOTDMT, $80$DKA302: cannot be dismounted %DISM-F-SRCMEM, only source member of shadow set cannot be dismounted $ $ $DISMOUNT/POLICY=MINICOPY $80$DKA302: $ |
この問題は，今後のリリースで修正される予定です。
5.19.4 SHADOW_MAX_UNIT の設定
V7.3
OpenVMS Alpha バージョン 7.3 では，Volume Shadowing for OpenVMS でのミニコピーのサポートが導入されました。
ミニコピー機能の一部として，新しいボリューム・シャドウイングのシステム・パラメータ SHADOW_MAX_UNIT が提供され，ノードで可能なシャドウ・セットの最大数が指定できます。OpenVMS Alpha システムでのデフォルト値は 500 です。 OpenVMS VAX システムでのデフォルト値は 100 です。このシステム・パラメータは動的ではありません。変更を有効にするには，リブートが必要です。
現在の構成の SHADOW_MAX_UNIT のデフォルト設定を注意して確認してください。ディスマウントされたシャドウ・セット，未使用のシャドウ・セット，Write Bitmap が割り当てられていないシャドウ・セットが，この合計には含まれています。デフォルト設定は，システムで予定しているシャドウ・セットの数 以上でなければなりません。SHADOW_MAX_UNIT で指定された最大数を超えて作成しようとする MOUNT コマンドは，失敗します。 |
このパラメータは，シャドウ・セットの命名に影響を与えることはありません。たとえば，デフォルト値が 100 の場合でも，DSA999 のようなデバイス名が有効です。
5.19.5 複合アーキテクチャ・クラスタでのミニコピー向けの SHADOW_MAX_COPY VAX 設定
V7.3
OpenVMS バージョン 7.3 では，スタンドアロンの Alpha システム，Alpha システムだけで構成される OpenVMS Cluster システム，および Alpha システムと VAX システムで構成される複合アーキテクチャの OpenVMS Cluster システムの場合にミニコピーがサポートされます。VAX システムでメンバ追加タスクをシャドウ・セットへ割り当てることが複合アーキテクチャ・クラスタでも可能です (このような場合はほとんどありません)。VAX システムではミニコピーを実行できないため，完全コピーが実行されます。
この発生を防ぐには，この新しいミニコピー機能を使用する場合，クラスタ内の各 VAX システムで SHADOW_MAX_COPY システム・パラメータを 0 に設定することをお勧めします。
5.19.6 HSD10 仮想ディスク
V7.1
HSD10 コントローラは，物理ディスクのパーティションを実行することによって，仮想ディスク機能をサポートします。データの破損を防ぐために， OpenVMS Volume Shadowing を使用して，HSD10 仮想ディスクを使用するシャドウ・セットを作成しないでください。
| 前へ | 次へ | 目次 | 索引 |