[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ] [ DOC Home ]

4 システム管理に関するリリース・ノート

この章では，システムの保守と管理，性能の管理，ネットワーキングに関連する情報をまとめます。

このバージョンで提供される新機能の詳細については，『OpenVMS V 7.2新機能説明書』を参照してください。

4.1 Alpha System Dump Analyzer (SDA)

ここでは，Alpha System Dump Analyzer (SDA)のリリース・ノートをまとめます。

4.1.1 変更点と強化された機能

ここでは，SDAユーティリティの変更点について説明します。

4.1.1.1 非ページング・プール・ルックアサイド・ リストの数の増加

V7.2

8192バイトの最大パケット・サイズに対応できるように，バージョン7.2 で48個の非ページング・プール・ルックアサイド・リストが追加されました。 各リストのパケットの数を確認するには，SDAユーティリティからCLUE MEMORY /LOOKASIDE コマンドを入力します。

4.2 Backupユーティリティ

ここでは，Backupユーティリティ(BACKUP)のリリース・ノートをまとめます。

4.2.1 変更点と強化された機能

ここでは，性能の向上に関するヒントをまとめます。

4.2.1.1 Files-11マウント・ディスクへのセーブ・ セットの書き込み

V7.2

OpenVMSバージョン7.2以降，ハイウォータ・マークを付けてセーブ・セットをFiles-11 マウント・ディスクに書き込むと，性能が向上します。このように性能が向上したのは， セーブ・セットをディスクに書き込むときに， ハイウォータ・マークを消去するためのIOを回避したからです。

4.2.2 問題点と制限事項

ここではBackupユーティリティの問題点と制限事項について説明します。

4.2.2.1 /MEDIA_FORMAT=COMPACTION修飾子はTA90装置に対して無効

V7.2

OpenVMSバージョン7.2で複数のテープ密度が導入された結果，標準のDCL 修飾子/MEDIA_FORMAT=COMPACTIONをINITIALIZEコマンド，BACKUPコマンド，MOUNT コマンドで使用しても，TA90テープ・ドライブはコンパクション・ モードになりません。コマンドと修飾子はDCLレベルで受け付けられますが， 装置のモードは変化しません。

この問題を回避するには，新しい修飾子/MEDIA_FORMAT=(DENSITY=3480,COMPACTION) を使用して，装置をコンパクション・モードに設定します。

4.2.2.2 /OWNER修飾子と/BY_OWNER修飾子では数値識別子が必要

V7.2

次のような一連のコマンドを実行すると，BACKUPでエラーが発生し，エラー・ メッセージが出力されます。 

     $ CREATE X.X
     $ BACKUP X.X X.SAV/SAVE
     $ BACKUP X.SAV/SAVE *.*/OWNER=SYS$NODE_'F$GETSYI("NODENAME")
     %BACKUP-F-BADOPTVAL, invalid callable interface option value,
     argument position 7, option type = 59, option value = 2147549196

/BY_OWNER修飾子を使用した場合もエラーになり，前の例と同じようなメッセージが出力されます。

どちらの修飾子の場合も，数値識別子ではなく，一般的な識別子を入力すると， エラーが発生します。たとえば，BACKUPは次のようなコマンドを受け付けます。 

     $ BACKUP [.EXE]S.SAV/SAV *.*/OWNER=[100,100]/LOG
     %BACKUP-S-CREATED, created $4$DUA155:[BTE.VMSTEST.BACKUP_REG]X.X;2
     %BACKUP-S-CREATED, created $4$DUA155:[BTE.VMSTEST.BACKUP_REG]X.X;1
     $

この問題を回避するには，数値識別子を入力します。

4.3 Compaq Galaxy Software Architecture on OpenVMS Alpha

V7.2

OpenVMS Alphaバージョン7.2で，Galaxy Software Architecture on OpenVMS Alphaが導入されました。OpenVMS Galaxyコンピューティング環境は，OpenVMS の複数のインスタンスを1台のコンピュータで実行することで， 非常に柔軟なコンピューティング機能を提供します。このコンピューティング環境は， 変化するアプリケーション・ニーズや作業負荷に動的に対応できます。

Compaq Galaxy Software Architecture on OpenVMS Alphaは，個別にライセンスが供与されるSystem Integrated Product (SIP) として提供されます。

AlphaServer 8400，8200，4100システムをOpenVMS Galaxyコンピューティング環境に変換する方法と，OpenVMS バージョン7.2で提供されるOpenVMS Galaxy機能を使用する方法については，『OpenVMS Alpha Galaxyガイド』を参照してください。 このマニュアルには，Galaxy Software Architecture on OpenVMS に関するリリース・ ノートもまとめられています。

4.4 DECamds

ここでは，DECamdsのリリース・ノートをまとめます。

4.4.1 変更点と強化された機能

ここでは，OpenVMSバージョン7.2以降のDECamdsの重要な変更点について説明します。

4.4.1.1 インストール・プロシージャの変更

V7.2

DECamdsはクライアント・ソフトウェアとサーバ・ソフトウェアで構成されます。

OpenVMSの以前のバージョンでは，最新のDECamdsキットからクライアント・ ソフトウェアとサーバ・ソフトウェアの両方をシステムにインストールしなければなりませんでした。

サーバ・ソフトウェア:インストールは不要

OpenVMSバージョン7.2以降，Data CollectorはOpenVMSの一部として出荷されます。 つまり，OpenVMSバージョン7.2をインストールまたはアップグレードすると，Data Collector もシステムにインストールされます。

Data Collectorを使用するには，次のいずれかの操作を実行します。

クライアント・ソフトウェア:インストールが必要

OpenVMSバージョン7.2では，クライアント，つまりグラフィカル・ユーザ・ インタフェースを実行するシステムにDECamdsクライアント・ソフトウェアを再インストールしなければなりません。 このため，DECamdsバージョン7.2 の新しいライブラリを入手する必要があります。

OpenVMSのRMDRIVERの部分を作成するには，次のファイルを移動しなければなりません。

ファイル 新しいディレクトリの場所
AMDS$DRIVER_ACCESS.DAT SYS$MANAGER
AMDS$RMCP.EXE SYS$SYSTEM
AMDS$LOGICALS.COM SYS$MANAGER

これらの新しいディレクトリの場所を使用しても，AMDS$SYSTEMディレクトリに格納されているAMDS$DRIVER_ACCESS.DAT の以前のコピーには影響ありません。 これは，AMDS$SYSTEMという論理名がSYS$COMMON:[AMDS]とSYS$COMMON:[SYSMGR] の検索リストだからです。DECamdsの以前のバージョンにある上記のファイルのコピーは現在も有効です。 しかし，ファイルの新しいコピーは新しい場所に格納されます。

4.4.1.2 イベント・ログ・ファイルとロック・ログ・ ファイルの強化

V7.2

バージョン7.2より以前には，イベント・ログ・ファイルとロック・ログ・ ファイルは1ブロックの省略時の作成サイズおよび1ブロックのデフォルトの拡張サイズで作成されていました。 この結果，DECamdsが長時間にわたって実行可能な場合は， 非常に細分化されたログ・ファイル(およびディスク) が作成されることがありました。

AMDS$LOGICALS.COMファイルに2つの新しい論理名が登録されたため，ユーザはログ・ ファイルの追加サイズを定義できるようになりました。これらの論理名と省略時の値は次の表に示すとおりです。

論理名 説明 デフォルト値
AMDS$EVTLOG_ALLOC_SIZE ログ・ファイルの初期サイズを設定する。 100ブロック
AMDS$EVTLOG_EXTNT_SIZE 拡張が必要な場合のファイルの拡張サイズを設定する。 0ブロック

AMDS$EVTLOG_EXTNT_SIZEのデフォルト値を使用すると，DECamdsはエクステント・ サイズに対してシステムの省略時の値を使用します。

4.4.1.3 不明なアダプタ・タイプの取り扱いの向上

V7.2

バージョン7.2より以前には，DECamdsはRPORTの値が不明として報告されたアダプタに"UNKNOWN" というラベルを付けていましたが，SCA Summary Windowに他の情報は提供されていませんでした。バージョン7.2以降， DECamdsは"UNKNOWN"というラベルの他に，リモート・システムがRPORTに対して返した値も表示します。

4.4.1.4 類似したグループの正しいソート

V7.2

バージョン7.2より以前には，グループ名の最初の3文字が類似している場合，DECamds はグループ名を正しくソートしないことがありました。 OpenVMSバージョン7.2ではソート・アルゴリズムが修正され，DECamdsはグループ名を正しくソートするようになりました。

4.4.2 問題点と制限事項

ここでは，DECamdsの制限事項について説明します。

4.4.2.1 カーネル・スレッドはサポートされない(Alpha のみ)

V7.2

DECamdsによるカーネル・スレッドのサポートは，OpenVMS Alphaシステムに実装されていません。 スレッドされたプロセスを使用すると，DECamds は一番上のスレッドだけを表示します。

4.5 DECdtmサービス

ここでは，DECdtmサービスのリリース・ノートをまとめます。

4.5.1 問題点と制限事項

ここでは，DECdtmサービスを使用する場合の問題点と制限事項について説明します。

4.5.1.1 カーネル・スレッドの制限事項(Alphaのみ)

V7.1

OpenVMS Alphaシステムでは，DECdtmサービスをマルチスレッド環境で使用すると， 予測できない結果が発生することがあります。DECdtmが実行する作業の多くは呼び出しプロセスのコンテキストを使用するので， 初期スレッド以外のカーネル・ スレッドでDECdtmサービスを呼び出さないでください。

4.6 DECevent Fault Managementのサポート

ここでは，DECeventイベントの最新のバージョンの変更点について説明します。DECevent のインストールの詳細については，第1.2.1.4 項を参照してください。

4.6.1 変更点と強化された機能

ここでは，OpenVMSバージョン7.2でDECeventバージョン2.9を使用するのに必要な条件について説明します。

4.6.1.1 エラーを分析するにはDECeventバージョン2.9 以上が必要

V7.2

OpenVMSバージョン7.1-2以降，エラー・ログ・ファイルを分析するには， DECeventバージョン2.9以上が必要です。

バイナリ・エラー・ログ・ファイルの形式が変更されたので，DECeventの以前のバージョンは動作しません。 さらに，一部の装置固有のエラー・ログ・ エントリも変更されています。

DECeventバージョン2.9のDECeventキットには，Binary Error Log Translationユーティリティという個別のユーティリティが添付されています。Binary Error Log Translation ユーティリティは，新しいCommon Event Header (CEH) バイナリ・エラー・ログ・ファイルを別のバイナリ・ エラー・ログ・ファイルに変換します。変換後のファイルのヘッダの形式と構造は，DECevent の以前のバージョンや，以前のユーティリティであるError Reporting Formatter (ERF) で読み取ることができます。Binary Error Log Translation ユーティリティの詳細については， DECeventキットに付属しているドキュメントを参照してください。

ERFを起動するDCLコマンドANALYZE/ERROR_LOGは，MEMORY CHANNELや他の新しい装置をサポートしません。 このコマンドを使用すると，不適切な形式のエラー・ ログ・エントリが作成されます。

OpenVMSのCD-ROMに格納されているDECeventキットをインストールしてください。 その後，次のコマンドを使用して，DECeventを起動し，ダンプ・ ファイルを分析します。

DIAGNOSEコマンドの詳細については，HELP DIAGNOSEコマンドを使用して確認してください。 追加情報については，『OpenVMS DCLディクショナリ』を参照してください。DECevent の詳細については，『OpenVMSシステム管理者マニュアル』，『OpenVMSシステム管理ユーティリティ・ リファレンス・マニュアル』，DECeventキットに付属しているDECevent のドキュメントを参照してください。

4.7 Extended File Specifications

ここでは，Extended File Specificationsのリリース・ノートをまとめます。Extended File Specifications の詳細については，『OpenVMS Extended File Specificationsの手引き』を参照してください。

4.7.1 問題点と制限事項

ここでは，拡張ファイル名の制限事項について説明します。

4.7.1.1 UNIX形式とVMS形式の複合ファイル名はサポートされない(Alpha のみ)

V7.2

OpenVMS Alphaバージョン7.2で導入されたODS-5ボリューム構造では，長いファイル名がサポートされ， ファイル名の内部でこれまでより広範囲にわたる文字を使用することができ， ファイル名の内部の大文字と小文字の区別が保存されるようになりました。

しかし，OpenVMS Alphaバージョン7.2に付属しているDEC C RTLでは， ODS-5装置で拡張ファイル名が完全にサポートされません。このように完全なサポートが提供されないため，ODS-5 装置でNetscape FastTrack Serverを実行するユーザやJavaアプリケーションを使用するユーザに特定の制限が発生します。

一般に，OpenVMSでNetscape FastTrackを実行したり，Javaアプリケーションを使用するユーザは，UNIX 形式のファイル名またはVMS形式のファイル名を入力できます(FastTrack では通常，UNIX形式のファイル名が出力されます) 。どちらの製品でも，多くの場合，ファイル名はFastTrackまたはJava Virtual Machine で作成されます。

UNIX形式とVMS形式の複合拡張ファイル名はDEC C RTLでサポートされていないので， たとえばディレクトリやファイル名を追加するルートを変更する場合など，Java アプリケーションやFastTrackとやり取りする場合は， UNIX形式の構文を使用しなければなりません。

次の例では，UNIX形式とVMS形式の複合ファイル名を示していますが，このようなファイル名はOpenVMS Alpha バージョン7.2でサポートされません。 

     doc/foo.bar.bar
     ./tmp/foo.bar.b^_ar
     ~foo^.bar

しかし，最後の例を変更すれば，1文字目としてティルダ(~)が指定されたOpenVMS 拡張ファイル名として動作するようになります。最初のティルダ(~) の前にExtended File Specificationsのエスケープ文字(^)を指定します。 次の例を参照してください。 

     ^~foo^.bar

OpenVMS拡張ファイル名でのティルダ(~)の使用の詳細については，『OpenVMS Extended File Specifications の手引き』を参照してください。UNIX 形式とVMS形式の複合ファイル名は， DEC C RTL for OpenVMS Alphaバージョン7.2の将来のリリースでサポートされるようになる予定です。

4.8 外部認証

ここでは，外部認証に関するリリース・ノートをまとめます。外部認証はOpenVMS バージョン7.1で導入されたオプションの機能であり，この機能を利用すると，OpenVMS システムは外部のユーザIDとパスワードを使用して， 指定されたユーザを認証できます。

OpenVMSバージョン7.2以降，DECwindowsを稼動しているときに， DECwindowsユーザを外部認証する場合は，DECwindowsバージョン1.2- 4以上を実行しなければならず，Advanced Server for OpenVMS Server Installation and Configuration Guideに示した必要条件を満たさなければなりません。 外部認証の使用の詳細については，このマニュアルと『OpenVMS Guide to System Security』を参照してください。

4.8.1 変更点と強化された機能

ここでは，外部認証のサポートの変更点について説明します。

4.8.1.1 FTPサーバは外部認証を使用

V7.2

DIGITAL TCP/IP Services for OpenVMSバージョン5.0のリリースにともない，File Transfer Protocol (FTP) サーバはOpenVMSシステムで接続を認証するために外部認証を使用するようになりました。

4.8.1.2 外部認証を制御するためのDCLコマンド・ インタフェース

V7.2

『OpenVMS Guide to System Security』の第7章では，外部認証に対して現在使用されている論理名SYS$SINGLE_SIGNON とSYS$ACME_MODULEについて説明しています。将来のリリースでは， 外部認証を有効化および制御するための現在のインタフェースは，DCL コマンド・インタフェースに変更される予定です。

4.8.2 問題点と制限事項

ここでは，外部認証の問題点と制限事項について説明します。

4.8.2.1 POPサーバでの失敗した接続の試み

V7.2

Post Office Protocol (POP)サーバは，OpenVMSシステムで接続の試みを認証するために， 外部認証を使用しません。このため，次のいずれかの状況では， 接続の試みが失敗します。

4.8.2.2 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
     $

4.8.2.3 DECnetフェーズIVの必要条件

V7.2

SYSUAFアカウント・レコードでEXTAUTHビットがセットされているユーザは， 外部認証パスワードがすべて大文字の場合を除き，DECnetフェーズIV を稼動しているシステムで明示的なアクセス制御文字列を使用できません。

たとえば，次のコマンドを入力した場合について考えてみましょう。 

     $ DIRECTORY nodename"username password"::

"nodename"はDECnetフェーズIVを実行しており，"username"はEXTAUTHアカウントです。DECnet は，"password"という文字列を外部認証エージェント(PATHWORKS またはNTドメイン・コントローラ)に渡す前に，大文字に変換します。

ノードがOpenVMSバージョン7.2上でDECnetフェーズVを実行しており， システムのシステム・パラメータNET_CALLOUTSが255に設定されている場合は， この問題は発生しません(第4.8.2.8 項を参照)。

この問題には，次の2つの回避方法があります。

4.8.2.4 レイヤード・プロダクトとアプリケーションに与える影響

V7.1

従来のSYSUAFベースのユーザ名とパスワードをもとにした認証機能を使用する特定のレイヤード・ プロダクトとアプリケーション(たとえば，$HASH_PASSWORD や$GETUAI/$SETUAIを呼び出して，OpenVMSパスワードの変更， フェッチ，確認を行うソフトウェア)では，次の場合に問題が発生します。

このような場合には，レイヤード・プロダクトまたはアプリケーションからユーザを認証できないという問題が発生します。

外部認証を受けるユーザの場合，通常のシステム登録データベース(SYSUAF.DAT) を使用して，OpenVMSプロセス・プロファイル(UIC，特権， クォータなど)を作成したり，特定のログイン制限が適用されます。 しかし，外部認証を受けるユーザと通常のOpenVMSユーザの間には，2つの大きな相違点があります。 外部認証を受けるユーザの場合は，次のようになります。

OpenVMSでは，これらの問題点をできるだけ少なくするために，ユーザのSYSUAF と外部ユーザ・パスワードの同期がとられます。ユーザの外部パスワードの最新のコピーはSYSUAF に保存されますが，たとえば外部パスワードにOpenVMS で使用できない文字が含まれている場合や，システム管理者がSYSUAF パスワードの同期化を無効にした場合は，パスワードの同期はとられません( デフォルトでは，パスワードの同期は有効に設定されています) 。

外部認証を有効にする場合は，従来のSYSUAFベースの認証を使用するレイヤード・ プロダクトやアプリケーションとの互換性の問題をできるだけ避けるために， 次の操作を実行してください。

$GETUAIおよび$SETUAIシステム・サービスでは，外部パスワードがサポートされません。 これらのサービスはSYSUAFに格納されているパスワードに対してだけ動作し， 更新情報は外部認証サービスに送信されません。パスワードの確認や更新のために， これらのサービスを呼び出すソフトウェアを使用しているサイトでは， 外部認証は有効にしないでください。将来のリリースでは， この目的で新しいプログラミング・インタフェースが提供される予定です。

4.8.2.5 複合バージョンOpenVMSクラスタ・システム

V7.1

OpenVMS Clusterシステムで外部認証を使用する場合は，すべてのシステムがOpenVMS バージョン7.1以上を稼動している場合に限ってください。

以前のバージョンのシステムでLOGINOUTを使用すると，外部認証を受けたユーザも含めて， すべてのユーザに対して通常のOpenVMSパスワード・ポリシー( パスワードの有効期限，パスワードの履歴など)が適用されます。

4.8.2.6 LGIコールアウト・サービスは外部認証を無効に設定する

V7.1

バージョン7.1以降，LOGINOUT (LGI)コールアウトが存在すると，外部認証は無効になります。 この制限事項は将来のリリースで解決される予定です。

4.8.2.7 DECwindows休止スクリーンはSYSUAFパスワードを使用する

V7.1

DECwindows休止スクリーンのアンロック機能は，パスワードの確認のために外部認証サービスを使用しません。 システムで外部認証が有効に設定されている場合でも，SYSUAF ファイルのパスワードが使用されます。

デフォルトでは，パスワードの同期化は有効に設定されます。パスワードの同期化を無効に設定した場合は，LAN Manager とSYSUAFのパスワードの同期を手動でとらなければなりません。

4.8.2.8 DECnet-PlusとNET_CALLOUTSパラメータ

V7.1

外部認証を有効に設定した状態でDECnet-Plus for OpenVMSを実行するには， システム・パラメータNET_CALLOUTSを255に設定します。このように設定すると， ネットワーク・ログインのためにLAN ManagerのユーザIDマッピングと認証機能が有効になります。

4.8.2.9 ワークステーションではパスワードの有効期限切れは通知されない

V7.1

LAN Managerドメインでは，パスワードの有効期限が切れた後，ログインすることはできません。

パーソナル・コンピュータ(PC)のユーザには，外部ユーザ・パスワードの有効期限が間もなく切れることが通知されるので， 有効期限が切れる前にパスワードを変更できます。 しかし，外部認証を使用してOpenVMSワークステーションからログインする場合， ログイン・プロセスは外部パスワードの有効期限が間もなく切れるかどうか判断できません。 したがって，パスワードの有効期限が設定されていて， ユーザの大半がPCを使用していないサイトでは， ワークステーション・ユーザに対して外部認証を使用しない方が賢明です。

この問題は将来のリリースで解決される予定です。

4.9 Fast Path (Alphaのみ)

ここでは，Fast Pathのリリース・ノートをまとめます。Fast Pathとは， I/O性能を向上するために設計された高性能機能です。Fast Pathの詳細については， 『OpenVMS I/O User's Reference Manual』を参照してください。

4.9.1 変更点と強化された機能

ここでは，Fast Pathのサポートに関する最近の変更点をまとめます。

4.9.1.1 SYSGENパラメータの変更

V7.2

Fast Pathはデフォルトで有効に設定されるようになりました。Fast Path を無効にするには，FAST_PATH SYSGENパラメータを0に設定します。

また，IO_PREFER_CPUSパラメータは動的SYSGENパラメータになりました。 IO_PREFER_CPUSを変更すると，使用可能なCPUセットの間でFast Pathポートのバランスが取り直されます。

4.9.1.2 DCLのサポート

V7.2

次のDCLコマンドはFast Pathをサポートするようになりました。


SHOW DEVICE/FULL
SHOW CPU/FULL
SET DEVICE/PREFERRED_CPU

これらのコマンドの詳細については，『OpenVMS DCLディクショナリ』を参照してください。

4.9.1.3 STOP/CPUコマンドを使用可能

V7.2

バージョン7.2より以前には，DCLコマンドSTOP/CPUを使用してFast Path の優先CPUを停止することはできませんでした。この制限はなくなりました。

4.10 ロック・マネージャ

ここでは，ロック・マネージャのリリース・ノートをまとめます。

4.10.1 変更点と強化された機能

ここでは，ロック・マネージャ構造体の変更点について説明します。

4.10.1.1 ロック・マネージャと非ページング・ プール(Alphaのみ)

V7.2

OpenVMS Alphaシステムでアプリケーションのスケーラビリティを向上するために， ロック・マネージャ構造体の大部分が非ページング・プールからS2 空間に移動されました。多くのシステムで，ロック・マネージャ構造体は非ページング・ プールの多くの部分を使用していました。

非ページング・プールに対してこのような変更が行われたため，次の操作を実行する必要があります。

ロック・マネージャに関連するメモリについては，『OpenVMS DCLディクショナリ: N-Z』 のSHOW MEMORYの説明を参照してください。

4.11 Monitorユーティリティ

ここでは，Monitorユーティリティ(MONITOR)について説明します。

4.11.1 問題点と制限事項

ここでは，バージョン7.2のノードからバージョン7.2より以前のノードを監視するときに， バージョン間の互換性の問題に対処する方法について説明します。

4.11.1.1 バージョン7.2のノードからバージョン7.2以前のノードを監視する

V7.2

OpenVMSバージョン7.2でMonitorユーティリティが変更された結果， OpenVMSの以前のバージョンとの間に互換性の問題が発生しました。バージョン7.2 のノードからバージョン7.2より以前のノードを監視しようとすると， 次のようなバージョン間の互換性の問題に関するエラー・メッセージが表示されます。 

     MONITOR> MONITOR /NODE=ARTOS1 PROCESSES
     %MONITOR-I-ESTABCON, establishing connection to remote node(s)...
     %MONITOR-E-ERRSYSINFO, failed to collect system information on node ARTOS1
     -MONITOR-E-SRVMISMATCH, MONITOR server on remote node is an incompatible
     version
     %MONITOR-I-CONT, continuing....

バージョン7.2のシステムと通信するには，OpenVMSバージョン7.1およびバージョン6.2 システムに修正キットをインストールしなければなりません。 キット名は次のとおりです。

4.11.1.2 MONITORレコーディング・ファイルの変更

V7.2

MONITOR DISKクラス・レコードのMNR_DSK$B_ALLOCLSフィールドがバイト長フィールドからワード長フィールドに変更されました。 このように変更されたのは， ディスク・ポート割り当てクラス機能に対応するためです。 さらに，MONITOR DISKクラス・レコードのMNR_DSK$B_ALLOCLSの後のすべてのフィールドが1 バイトずつ前に移動されました。

このように変更されたため，File Header RecordのStructure Level Identificationフィールド(MNR_HDR$T_IDENT)が"MON30050"から"MON31050" に変更されました。

ここに示す変更点は，『OpenVMSシステム管理ユーティリティ・リファレンス・ マニュアル( 下巻)』の付録Aでは反映されていません。

4.11.2 ドキュメントの変更点と修正点

OpenVMSバージョン7.2 『OpenVMSシステム管理ユーティリティ・リファレンス・ マニュアル(下巻)』で反映されていない変更については，第4.11.1.2項を参照してください。

4.12 Mountユーティリティ

ここでは，ディスクのマウントに関するリリース・ノートをまとめます。

4.12.1 問題点と制限事項

ここでは，MOUNTユーティリティの複数の制限事項の回避方法について説明します。

4.12.1.1 /MEDIA_FORMAT=COMPACTION修飾子はTA90装置に対して無効

V7.2

OpenVMSバージョン7.2で複数のテープ密度がサポートされた結果，標準のDCL 修飾子/MEDIA_FORMAT=COMPACTIONをINITIALIZEコマンド，BACKUPコマンド，MOUNT コマンドで使用しても，TA90テープ・ドライブはコンパクション・ モードに設定されなくなりました。コマンドと修飾子はDCLレベルで受け付けられますが， 装置のモードは変化しません。

この問題を回避するには，新しい修飾子/MEDIA_FORMAT=(DENSITY=3480,COMPACTION) を使用して，装置を正しくコンパクション・ モードに設定します。

4.12.1.2 複合バージョン・クラスタでの書き込み禁止されたディスクのマウント

V7.1-2

OpenVMSバージョン7.1-2でMOUNTが修正された結果，MOUNTの以前のバージョンとの間に互換性に関する小さな問題が発生しました。 この互換性に関する問題が発生するのは，( ハードウェアまたはソフトウェアの書き込み禁止によって) 書き込み禁止されたディスクがOpenVMSの以前のバージョンにマウントされる場合です。 このような場合，MOUNTは次のエラーを返します。 

     %MOUNT-F-DIFVOLMNT, different volume already mounted on this device

このエラーを回避するには，次のMOUNTキット(またはそれに代わるキット) から適切なキットを適用します。


ALPMOUN04_062
ALPMOUN06_071
VAXMOUN03_062
VAXMOUN04_071

また，次の回避方法を使用して，書き込み可能なディスクを複合バージョン・ クラスタにマウントすることもできます。 

     $ DISMOUNT ddcu:       ! on any nodes that it can be mounted on
     $ MOUNT/WRITE ddcu: label   ! on the V7.1-2 node
     $ DISMOUNT ddcu:     ! on the V7.1-2 node
     $ MOUNT/CLUSTER/NOWRITE ddcu: label

MOUNT/WRITE操作を実行すると，装置の記憶制御ブロック(SCB)が更新され， 変更されたMOUNTと互換性を維持するようになります。SCBに新しい情報が格納された後，MOUNT のどのバージョンでも装置を正しく使用できるようになります。

4.13 OPCOM

ここでは，Operator Communication Manager (OPCOM)のリリース・ノートをまとめます。

4.13.1 修正点

V7.2

OpenVMSバージョン7.2では，OPCOMの次の問題が修正されました。

4.14 OpenVMS Clusterシステム

ここでは，OpenVMS Clusterシステムのリリース・ノートをまとめます。

4.14.1 変更点と強化された機能

ここでは，OpenVMS Clusterシステムの変更点と強化された機能について説明します。

4.14.1.1 新しいHSZ割り当てクラス(Alphaのみ)

V7.2

OpenVMS Alphaバージョン7.2では，HSZ70およびHSZ80ストレージ・コントローラ上の装置に対して， 新しい装置名オプションとしてHSZ割り当てクラスが導入されました。HSZ 割り当てクラスについては，『Guidelines for OpenVMS Cluster Configurations』の新しい章「Configuring Multiple Paths to SCSI and Fibre Channel Storage」に説明されています。

HSZをマルチパス構成で使用する場合は，HSZ割り当てクラスが必要です。 また，HSZに直接にSCSI接続しているすべてのシステムがOpenVMSバージョン7.2 を稼動している場合は，非マルチパス構成でもHSZ割り当てクラスを使用できます。

HSZ割り当てクラスは他のどの装置命名方法より優先します。つまり，HSZ コントローラに有効なHSZ割り当てクラスが割り当てられている場合は， 装置名を作成するために常にHSZ割り当てクラスが使用されます。装置名の作成のためにポート割り当てクラス(PAC) ，ノード割り当てクラス，ポート名， ノード名は使用されません。

この結果，SCSIバス構成アルゴリズムが変更されました。HSZ割り当てクラスが使用される場合は， 共有SCSIバスに対するこれまでの制限事項の一部が適用されません。

OpenVMSバージョン7.2により以前には，すべてのノードが一致するPACまたは一致するポート名と一致するノード割り当てクラスを提供した場合にだけ，SCSI バス構成コードは共有SCSIバスで装置を構成することができました。 このように一致する値が必要だったのは，クラスタ内のすべてのノードで装置に一貫性のある名前を付けるためです。 構成コードを使用すると， このようなチェックに失敗した装置を構成できないだけでなく，システムの稼動時間が20 分未満の場合は，システムが停止していました。

OpenVMSバージョン7.2では，構成コードは次のように動作します。

HSZ割り当てクラスが含まれている名前を持つ装置も含めて，特定の装置は，SYSMAN ユーティリティを使用して選択的に自動構成することができません。 選択的な自動構成の詳細については，第6.3 節を参照してください。

4.14.1.2 バージョン6.2システム用のOpenVMSクラスタ互換性キット

V7.1-1H1

OpenVMSバージョン7.1に添付されていたOpenVMSクラスタ互換性キットは，Alpha システムでは修正キットALPCLUSIOnn_062，VAXシステムではVAXCLUSIO nn_062に変更されました。次のOpenVMSバージョンを稼動しているシステムを含むOpenVMS Cluster システムのメンバであるOpenVMS バージョン6.2システムでは，これらのキットが必要です。

ここに示したキットには，Volume Shadowing，Mount，ロック・マネージャなどに対して，OpenVMS バージョン6.2システム用にOpenVMSバージョン7.1 で強化された機能や他の品質向上機能が含まれており，OpenVMSバージョン7.1 のリリース・ノートでこれらのサブシステムに対して追加された拡張機能も含まれています。 また，ポート割り当てクラスを使用したSCSI 装置名の限定的なサポートも含まれています。

これらの修正キットはOpenVMSバージョン7.2のCD-ROMに格納されています。 また，Compaqのサポート担当者や次のWebサイトから入手することもできます。 

     http://www.service.digital.com/html/patch_public.html

4.14.1.3 Cluster Clientライセンスの変更

V7.1

OpenVMS Cluster Clientライセンスが変更されました。バージョン7.1より以前には，OpenVMS Cluster Client ライセンスにより，次の機能を除いて完全なOpenVMS Cluster 機能が提供されていました。

以前は投票に関する最初の例外は適用されていませんでした。バージョン7.1 以降，この例外も適用されるようになりました。

4.14.2 問題点と制限事項

ここでは，OpenVMS Clusterシステムの問題点と制限事項について説明します。SCSI クラスタに関する制限事項の大部分は，『Guidelines for OpenVMS Cluster Configurations』のSCSI OpenVMS Clusterに関する付録に説明されていますが， 一部の制限事項はこのリリース・ノートにしか示されていません。

4.14.2.1 複合バージョンの互換性の問題

V7.2

OpenVMS Clusterバージョン7.2ソフトウェアが変更された結果，OpenVMS バージョン7.2を稼動しているシステムは，1つ以上のノードが次のいずれかのソフトウェア・ バージョンを稼動しているクラスタに参加できなくなりました。

ここに示した以前のバージョンを稼動しているノードを含むクラスタで， バージョン7.2のノードをブートしようとすると，バージョン7.2のノードはクラスタに参加することができず，CLUSWVER バグチェックでクラッシュします。

同様に，1台以上のノードがバージョン7.2を稼動しているクラスタで，ここに示した以前のバージョンを稼動しているノードをブートしようとすると， 以前のバージョンのノードはクラスタに参加することができず，同じCLUSWVER バグチェックでクラッシュします。

複合バージョンおよび複合アーキテクチャ・クラスタでサポートされるソフトウェア・ バージョンの詳細については，『OpenVMS V 7.2新機能説明書』を参照してください。

4.14.2.2 DECnet-Plusサテライト・ブートの制限事項(Alpha のみ)

V7.2

DECnet-Plus MOPサテライト・ブート・サービスを使用して，SCSIポート割り当てクラス(PAC) またはHSZ70/80コントローラ割り当てクラスが正の値であるシステム・ ディスクから，OpenVMS Clusterサテライト・システムをブートすることはできません。

問題が発生したサテライトは，ブート時に次のメッセージを表示します。 

     %VMScluster-I-MSCPCONN, Connected to a MSCP server for the system disk,
                             node ALAN
     %VMScluster-E-NOT_SERVED, Configuration change, the system disk is no
                               longer served by node ALAN

サテライトは使用可能なブート・サーバを探そうとするので，おそらく異なるブート・ サーバ・ノード名でこれらのメッセージが無限に繰り返されます。

DECnet-Plusを実行しており，SCSI PACまたはHSZ70/80コントローラ割り当てクラスが割り当てられているサテライト・ システム・ディスクをサービスしているブート・ サーバで，LAN MOPサービスを使用すれば， この問題を回避することができます。LAN MOPサービスは，CLUSTER_ CONFIG.COMプロシージャまたはLANCPユーティリティを使用して有効に設定できます。LAN MOP ブートの詳細については，『OpenVMS Cluster Systems』を参照してください。

ブート・サーバがDECnet for OpenVMS (フェーズIV)を稼動している場合は， この制限事項は適用されません。

4.14.2.3 MSCP_SERVE_ALLと複合バージョン・ クラスタ

V7.2

MSCP_SERVE_ALLは，OpenVMS Clusterシステムでサービスされるディスクを制御するシステム・ パラメータです。OpenVMSバージョン7.2以降，特定の構成では， ノード割り当てクラスがシステムのノード割り当てクラスと異なるHS xコントローラに接続されたディスクをサービスすることができます。 しかし，そのためには，すべてのシステムがOpenVMSバージョン7.2 を稼動していなければなりません。

複合バージョンOpenVMS Clusterシステムでは，"使用可能なすべてのディスク" に対するサービスという表現は，バージョン7.2以前の意味に制限されます。 つまり，ローカルに接続されたディスクか，システムのノード割り当てクラスと一致するノード割り当てクラスが割り当てられたHS xおよびDSSIコントローラに接続されたディスクだけがサービスされます。 複合バージョン・クラスタで"使用可能なすべてのディスク"をサービスするには， 値として9を指定しなければなりません。

MSCP_SERVE_ALLシステム・パラメータの変更の詳細については，第4.21.1.6項を参照してください。

4.14.2.4 ポート割り当てクラスを使用する場合のSCSI 装置名の制限事項

V7.2

OpenVMS Alphaバージョン7.2で，ポート割り当てクラスが0より大きいSCSI 装置の内部装置名モデルが変更されました。この変更は，第4.14.3.2項で説明する問題解決の一部です。

新しいモデルでは，ポート割り当てクラスが割り当てられたSCSI装置を指定するために使用できる有効な装置名は，$3$DKA500 などのように，完全に指定された装置名だけです。 このような装置を指定するために，DKA500 やFUZZY$DKA500などの名前を使用することはできません。さらに，ポート割り当てクラスが0 より大きいSCSI装置の場合，ポート割り当てクラスも含めて完全に指定された装置名を返すように，$GETDVI システム・サービスが変更されています。

2番目の制限事項は，装置を選択的に自動構成するためのSYSMANユーティリティの使用に関係しています。 名前にポート割り当てクラスが含まれる装置も含めて， 特定の装置はSYSMANを使用して選択的に自動構成することができません。 詳細については，第6.3節を参照してください。

4.14.2.5 パラレルSCSIとFibre Channelに対するマルチパスのサポート(Alpha のみ)

V7.2

パラレルSCSIとFibre Channelに対するマルチパスのサポートについては， 『Guidelines for OpenVMS Cluster Configurations』の新しい章「Configuring Multiple Paths to SCSI and Fibre Channel Storage」に説明されています。OpenVMSバージョン7.2 の初期リリースには，次の3つの制限事項があります。

これらの制限事項は，上記のマニュアルの上記の章にも説明されています。OpenVMS バージョン7.2のリリースの後まもなく，これらの制限事項は更新キットによって削除されます。 このキットの入手については，Compaq の担当者にお問い合わせください。

4.14.2.6 Fibre Channelのサポート(Alphaのみ)

V7.2

Fibre ChannelのサポートはOpenVMS Alphaバージョン7.2に間に合いませんでした。Fibre Channel のサポートは，OpenVMS Alpha バージョン7.2のリリース後まもなく提供される予定です。

OpenVMS ClusterシステムでFibre Channelを使用される場合の計画に役立つように，Fibre Channel のサポートについて，『Guidelines for OpenVMS Cluster Configurations』の新しい2つの章「Configuring Fibre Channel as an OpenVMS Cluster Storage Interconnect」と「Configuring Multiple Paths to SCSI and Fibre Channel Storage」に説明されています。

OpenVMS Alphaバージョン7.2でFibre Channelのサポートがいつ提供されるようになるかについては，Compaq のサポート担当者にお問い合わせください。

4.14.2.7 SCSI共有インターコネクトでは同じノード割り当てクラスが必要(Alpha のみ)

V7.1-1H1

OpenVMSバージョン7.1でポート割り当てクラスが導入されるまでは，SCSI インターコネクトを共有するノードは，同じ0以外のノード割り当てクラスを使用しなければなりませんでした。 ポート割り当てクラスを使用しているかどうかとは無関係に， この要件は現在でも有効です。

ポート割り当てクラスがOpenVMSバージョン7.1で導入されたときに，この要件が『Guidelines for OpenVMS Cluster Configurations』の表A-1から削除されていましたが，これは誤りです。

4.14.2.8 SCSIクラスタでのAlphaServer 4000/4100システムに関する問題

V7.1

KZPSAアダプタを通じてシステム・ディスクにアクセスするAlphaServer 4000/4100システムは，SCSIバスの他のシステムが同時にブートまたはシャットダウンしているときに， ブートしたり，クラッシュ・ダンプ・ファイルを書き込むことができないことがあります。 その後のブートは成功します。

ファームウェアを更新するまで，この構成でこのような操作を同時に実行しないようにしてください。

4.14.2.9 CI-to-PCI (CIPCA)アダプタ(Alphaのみ)

ここでは，OpenVMS AlphaシステムでCIPCAモジュールを使用する場合の制限事項について説明します。 永久的な制限事項も含めて，CIPCAアダプタの詳細については， 『Guidelines for OpenVMS Cluster Configurations』の付録Cを参照してください。

4.14.2.9.1 4K CIパケットの使用に関するHSJ50 ファームウェア・バージョンの制限事項

V7.2

HSJ50ファームウェアのバージョンが5.J-3以上でない場合は，HSJ50コントローラによる4K CI パケットの使用を有効に設定しないでください。 HSJ50ファームウェアのバージョンが5.0J-3より以前のバージョンのときに，4K CI パケットを有効にすると，データが壊れる可能性があります。 HSJ50ファームウェアがこの要件を満たさない場合は，Compaqのサポート担当者にご連絡ください。

HSJ50コントローラによる4K CIパケットの使用の詳細については，『OpenVMS Cluster Systems 』を参照してください。

4.14.2.9.2 CIPCAを含むマルチプロセッサ・システム:CPUSPINWAIT バグチェックの回避

V7.1-1H1

マルチプロセッサ・システムでCIPCAアダプタを使用している場合は， SMP_SPINWAITパラメータの値をデフォルトの100000 (1秒)ではなく， 300000 (3秒)にリセットしなければなりません。

SMP_SPINWAITの値を変更しないと，CIPCAアダプタ・エラーによって，次のようなCPUSPINWAIT システム・バグチェックが発生することがあります。 

     **** OpenVMS (TM) Alpha Operating System V7.1-1H1 - BUGCHECK ****
     ** Code=0000078C: CPUSPINWAIT, CPU spinwait timer expired

この制限事項は，将来のOpenVMSリリースで解除される予定です。

注意
このリリース・ノートは，『OpenVMS Version 7.1 リリース・ノート[ 翻訳版]』で発行されたリリース・ノート(4.15.2.4.5項)の改訂です。 そのノートに示されているSYSTEM_CHECKパラメータに関する制限事項は誤りです。

4.14.2.10 MEMORY CHANNEL (Alphaのみ)

ここでは，MEMORY CHANNELのガイドラインと制限事項について説明します。MEMORY CHANNEL ハードウェアの設定の詳細については，MEMORY CHANNEL User's Guide (注文番号EK-PCIMC-UG.A01)を参照してください。 このマニュアルは，次のファイル名を使用して，OpenVMSバージョン7.2 のCD-ROMからコピーすることができます。 

     [DOCUMENTATION]HW_MEMORY_CHANNEL2_UG.PS

4.14.2.10.1 ローリング・アップグレード

V7.2

OpenVMSバージョン7.2では，OpenVMS Clusterシステムでバージョン6.2， バージョン6.2-1Hx，バージョン7.1，7.1-1Hxからバージョン7.2 へのローリング・アップグレードがサポートされます。ここでの説明は， バージョン6.2およびバージョン6.2-1Hxからバージョン7.2 へのローリング・アップグレードにだけ適用されます。

OpenVMSをバージョン7.2にアップグレードする前に，MEMORY CHANNELアダプタ(CCMAA-xx)をクラスタに追加した場合は，2番目以降のシステムがバージョン7.2 のインストールでAUTOGENおよびSHUTDOWN を実行したときに，最初のシステムでMC_FORCEDCRASHバグチェックが発生します。 この問題はシステム・パラメータの競合によって発生します。

アップグレード時にこの問題が発生するのを回避するには，次のいずれかの手順を実行します。

4.14.2.11 DECnet-Plusによるサテライトのブート

V7.1

すべてのMOPブートの要件に対して，LANCPユーティリティを使用するようにしてください。LANCP の代わりにDECnet-Plus MOPブートを使用する場合は， サテライトを追加するときに制限事項があります。CLUSTER_ CONFIG.COMは，NET$MOP_CIRCUIT_STARTUP.NCLファイルでMOPに対して構成されている最初のサーキットを使用します。

別のサーキットを使用するには，CLUSTER_CONFIG.COMを起動する前に， NET$MOP_CIRCUIT_STARTUP.NCLを編集しなければなりません。NET$MOP_ CIRCUIT_STARTUP.NCLファイルの先頭に適切なサーキットを指定した後， CLUSTER_CONFIG.COMを起動してください。

4.14.2.12 OpenVMS Cluster環境でのシステム・ スタートアップ(Alphaのみ)

V6.2

AlphaシステムのOpenVMS Cluster環境では，一部の状況でシステム・スタートアップ・ プロシージャがALPHAVMSSYS.PARファイルの新しいコピーを書き込むことができないことがあります。 この場合は，ブート・シーケンスからのコンソール出力に次のメッセージが報告されます。 

     %SYSGEN-E-CREPARFIL, unable to create parameter file
     -RMS-E-FLK, file currently locked by another user

このエラーが操作上の問題になるのは，会話型ブートを使用してシステム・ パラメータを変更する場合だけです。通常の非会話型ブートの場合は， パラメータ・ファイルが変更されないので，このエラー・メッセージは表面的なものに過ぎません。 会話型ブートを使用するときに，システム・ パラメータがブート時に変更される場合は，変更されたパラメータがシステムの現在のブートに対して正しく使用されます。 しかし，ブート・ プロシージャはパラメータ・ファイルの新しいコピーを正しく書き込んでいないので， 変更されたパラメータは今後のブートで使用されません。

会話型ブートで変更されたシステム・パラメータを永久に変更するには， システムがブートを完了した後，SYSGENを実行して，次のコマンドを入力します。 

     SYSGEN> USE ACTIVE
     SYSGEN> WRITE CURRENT

4.14.3 修正点

ここでは，OpenVMS Clusterシステムの修正点について説明します。

4.14.3.1 SCSI装置名とクォーラム・ディスクの問題の修正(Alpha のみ)

V7.2

OpenVMSバージョン7.2より以前には，次の条件がある場合，OpenVMSシステムをブートして， 新しいOpenVMS Clusterを作成することができませんでした。

このような状況では，システム・コンソール端末に次のメッセージが表示された後， ブート・システムはハングしていました。 

     %SYSINIT-I- waiting to form or join an OpenVMS Cluster

システム・ディスクをクォーラム・ディスクとして指定できる場合を除き， クォーラム・ディスクに依存しなければならない場合は，SCSIポート割り当てクラスを使用しないようにしなければなりませんでした。

この制限事項は解除されました。このような状況でシステムをブートした場合， 正しくブートされるようになりました。

4.14.3.2 PKA装置を使用する場合のSCSI装置名の問題の修正

V7.2

OpenVMSバージョン7.1で導入されたポート割り当てクラスは，OpenVMS Cluster内のAlphaシステムに接続されているSCSI装置の名前を付けるための新しい方法です。 値が0または正の整数に設定されている場合は，ポート割り当てクラスがポートで有効になります。

OpenVMSバージョン7.1がリリースされた後，OpenVMS装置名PKAを使用しているSCSI ポートで問題が発生する可能性があることがわかりました。PKA でポート割り当てクラスを有効に設定できないために，一部のI/O操作が誤ったSCSI 装置に対して実行された結果，データが破損したり，紛失することがありました。

この問題が検出された直後に，SCSI装置名に関する助言が発行されました。 共有SCSI装置に対してポート割り当てクラスを使用するお客様は， OpenVMS装置名がPKAであるSCSIポートに対して，ポート割り当てクラスを有効に設定するように要請されました。PKA が共有(マルチホスト)バスに接続されている場合も， プライベート・バスに接続されている場合も，これはすべての場合に必要でした。 また，OpenVMS Clusterシステムのメンバであるシステムに対してだけ， ポート割り当てクラスを使用するように要請されました。

OpenVMSバージョン7.1-2以降，この問題は解決されました。OpenVMS Clusterシステムのすべてのシステムがバージョン7.1-2以上を稼動している場合は，OpenVMS 装置名がPKAであるSCSIポートに対して，ポート割り当てクラスを使用する必要はありません。

オペレーティング・システム・バージョンが混在しているOpenVMS Clusterシステムでは，すべてのシステムがOpenVMSバージョン7.1-2 以上にアップグレードされるか，以前のバージョンのシステムでこの変更に対する互換性キットがインストールされるまで，OpenVMS バージョン7.1 のSCSI装置名に関する助言に従わなければなりません。これらの互換性キットはまだ提供されていません。

ポート割り当てクラスの詳細については，『OpenVMS Cluster Systems』を参照してください。

4.14.3.3 サテライト・ブートを妨害するSCSI 装置名の問題の解決

V7.2

OpenVMSバージョン7.2より以前には，直接接続されたSCSIポートに対してSCSI ポート割り当てクラスを使用するサテライト・システムは，次の状況でOpenVMS Cluster システムに正しくブートすることができませんでした。

たとえば，サテライト・システムが$100$DKB100という名前のMSCPでサービスされるシステム・ ディスクからブートしようとし，PKBポートのポート割り当てクラスが20 の場合は，この条件が満たされます。

これらの条件が満たされる場合，サテライト・システムはコンソールに次のメッセージを表示し， これ以降の操作を実行できません。 

     %VMScluster-I-RETRY, Attempting to reconnect to a system disk server

この問題はOpenVMSバージョン7.2で解決されました。

4.14.3.4 MSCP_CMD_TMOシステム・パラメータの修正

V7.2

OpenVMSバージョン7.1では，MSCP_CMD_TMOシステム・パラメータのデフォルト値が誤って600 に設定されていました。この問題は解決され，省略時の設定は0 になりました。

また，OpenVMSバージョン7.1でSYSGENコマンドSHOW MSCP_CMD_TMOを実行すると， パラメータの単位が秒ではなく，CNTLRTMO (コントローラ・タイムアウト) として表示されていました。これは誤りです。この問題も解決されました。

MSCP_CMD_TMOは，OpenVMS MSCPサーバがMSCPコマンドのタイムアウトを検出するために使用する秒単位の時間です。MSCP サーバは，約40秒の組み込み時間とMSCP_CMD_TMO パラメータの値を合計した時間内にコマンドを完了しなければなりません。 このパラメータの詳細については，『OpenVMSシステム管理ユーティリティ・ リファレンス・マニュアル(下巻)』を参照してください。

4.15 OpenVMSファイル・システム

ここではOpenVMSファイル・システムに関するリリース・ノートをまとめます。

4.15.1 変更点と強化された機能

OpenVMSバージョン7.2で，ファイル・システムがストレージ・ビットマップとインデックス・ ファイル・ビットマップを取り扱う方法が大きく変更されました。 これらのファイルはOpenVMSマスタ・ファイル・ディレクトリ(MFD) にあります。

ここでは，これらの変更について説明します。ストレージ・ビットマップとインデックス・ ファイル・ビットマップの上限を拡大する詳細については， 『OpenVMSシステム管理者マニュアル』を参照してください。

4.15.1.1 大きなビットマップの性能と構成の要件

V7.2

クラスタ係数が小さく，ストレージ・ビットマップが大きい場合には，小さなファイルを効率よく割り当てることができますが， 性能と構成に関して厳しい条件が要求されます。 空間を割り当てるために，ファイル・システムはストレージ・ ビットマップを連続的にスキャンします。非常に大きなストレージ・ ビットマップの場合は，ボリュームがほとんどいっぱいになると， ファイルの作成と拡張が非常に遅くなる可能性があり，その結果， ファイル・システムは空き空間を探すために，忙しく動作しなければなりません。

MOUNT，SET VOLUME/REBUILD，BACKUP，ANALYZE/DISK_STRUCTUREなどの特定のファイル・ ユーティリティでは，インデックス・ファイル・ビットマップとストレージ・ ビットマップのコピーを格納するために，仮想メモリが割り当てられます。 ビットマップが大きくなると，それに対応してこれらのユーティリティで必要となる仮想メモリのサイズも大きくなります。 大きなビットマップのボリュームに対して，これらのユーティリティを使用するには， ページ・ファイル・クォータを拡大しなければならない可能性があります。OpenVMS VAX システムでは，システム・パラメータVIRTUALPAGECNT を大きくしなければならない可能性があります。

次の表にビットマップにとって必要な仮想メモリを示しています。サイズはビットマップのブロック当たりのVAX ページ数(またはAlphaの512バイト・ ページレット)で示しています。インデックス・ファイル・ビットマップのサイズはブロック数であり， 最大ファイル数を4096で除算した値です。

ユーティリティ 必要な仮想メモリ
MOUNTおよび
SET VOLUME /REBUILD 		ボリューム・セットのすべてのインデックス・ ファイル・ビットマップとストレージ・ビットマップのサイズの合計。 この条件はボリュームを再構築する場合にだけ，MOUNTに適用される。
BACKUP ボリューム・ セットのすべてのインデックス・ファイル・ビットマップのサイズの合計( このメモリ・サイズは，BACKUPユーティリティのバッファ・ プールの他に必要である)。
ANALYZE /DISK_STRUCTURE ボリューム・セット全体で次の値の合計。

  • すべてのストレージ・ビットマップの3倍にボリューム・セットの最大のビットマップを加算した値

  • インデックス・ファイル・ビットマップの117倍

  • /USAGEが要求された場合は，インデックス・ファイル・ビットマップの96 倍を加算した値

  • 約600ページの追加の固定スクラッチ空間

4.15.1.2 ディスク・クラスタ係数の変更による互換性の問題

V7.2

OpenVMSバージョン7.2以降，ボリュームのストレージ・ビットマップのサイズの上限が255 から65535に拡大された結果，すべてのボリュームで小さなクラスタ係数を使用できるようになりました。 しかし，ストレージ・ビットマップが255 ブロックより大きいボリュームは，バージョン7.2より以前のバージョンを稼動しているOpenVMS システムにマウントできません。 このような操作を実行すると，次のエラーが発生します。 

     %MOUNT-F-FILESTRUCT, unsupported file structure level

ODS-2ディスクの場合，INITIALIZEコマンドのデフォルト動作により， ビットマップは255ブロックに制限されます。BACKUPコマンドのデフォルト動作では， 入力ボリュームのビットマップが255ブロック以下の場合，ODS-2 ビットマップは255ブロックに制限されます。INITIALIZE /CLUSTER_SIZE=nを使用してクラスタ係数を指定するか，BACKUP /NOINITIALIZEを指定した場合には，255ブロックより大きなビットマップのボリュームを作成することができます。

次の公式を使用すれば，255ブロックのビットマップを作成するクラスタ係数を計算できます。 

         クラスタ係数   =    ボリューム・サイズ/ 1044480

クラスタ係数は次の整数に切り上げてください。

ビットマップ・サイズの上限の拡大の詳細については，『OpenVMS V 7.2新機能説明書』のSystem Management に関する章を参照してください。また，INITIALIZEコマンドとBACKUP コマンドの詳細については，オンライン・ヘルプまたは『OpenVMS DCLディクショナリ』を参照してください。

4.15.1.3 ストレージ・ビットマップがボリュームで必要なサイズより小さくなる可能性がある

V7.2

INITIALIZEコマンドとBACKUP/IMAGE/INITIALIZEコマンドは，常にストレージ・ ビットマップのサイズを物理ボリューム全体に対応するように設定していました。 この動作はOpenVMSバージョン7.2でも変更されていません。 しかし，OpenVMSバージョン7.2以降，ファイル・システムは，要求されたサイズよりストレージ・ ビットマップが小さいボリュームを正しく取り扱うようになりました。 割り当てのために使用できるボリューム上の空間は， ビットマップが記述する空間です。この結果，ビットマップがボリュームで要求されるサイズより小さい場合は， ボリュームの一部をファイルの割り当てのために使用できなくなります。SHOW DEVICE /FULL コマンドは今後も実際の物理ボリューム・ サイズを表示しますが，表示される空きブロック数は割り当てのために実際に使用できるブロック数です。

ANALYZE/DISKユーティリティは，ビットマップが小さすぎることを次のメッセージによって報告します。 

     SHORTBITMAP,  storage bitmap on RVN 'n' does not cover the entire device

バージョン7.2システムでこのメッセージが表示されることはありません。 将来のファイル・システムの開発を予測して，ショート・ビットマップのサポートも含まれています。OpenVMS バージョン7.2ソフトウェアでは， ディスクのストレージ・ビットマップが不足することはありません。

OpenVMSバージョン7.2システムでは，ビットマップが小さいボリュームでも正しく機能します。 しかし，OpenVMSバージョン7.1以前のシステムにこのようなボリュームをマウントしないでください。OpenVMS の以前のバージョンでは， ショート・ビットマップを正しく取り扱うことができないので， このようなボリュームがマウントされ，そのボリュームにファイルを作成しようとすると， システムがクラッシュする可能性があります。ビットマップが小さいボリュームを作成するためのOpenVMS の将来の拡張機能は，Files-11 構造レベル5ボリュームに制限され，このようなボリュームをバージョン7.1 以前のシステムにマウントすることはできません。

4.16 POLYCENTER Software Installationユーティリティ

ここでは，POLYCENTER Software Installationユーティリティのリリース・ ノートをまとめます。このユーティリティに関して，プログラマに関連のある注意事項については， 第5.18節を参照してください。

4.16.1 変更点と強化された機能

ここでは，POLYCENTER Software Installationユーティリティと， PRODUCTコマンドのDCLインタフェースの変更点について説明します。

4.16.1.1 DECwindows Motifインタフェースのリタイア

V7.2

OpenVMSバージョン7.2以降，PRODUCT/INTERFACE=DECWINDOWSコマンドを使用して，POLYCENTER Software Installation ユーティリティ用のMotifインタフェースを起動することはできなくなりました。Motif インタフェースは今後使用できませんが，PRODUCT コマンドに対するデフォルトのキャラクタ・ セル・インタフェースは今後も完全に機能し，バージョン7.2用に強化されています。

4.16.2 問題点と制限事項

ここでは，POLYCENTER Software Installationユーティリティを使用して， ソフトウェア製品のインストール，削除，再構成を行う場合の問題点と制限事項について説明します。 プログラマにとって特に関心のある問題点と制限事項については， 第5.18.1項を参照してください。

4.16.2.1 PRODUCTコマンドで出力を制御するためのオプションが欠如

V6.2

PRODUCT FINDコマンドやPRODUCT SHOWコマンドなど，1画面より多くのテキストを表示する可能性のあるコマンドで， スクロールを制御するための/PAGE や，出力をファイルにリダイレクトするための/OUTPUTなどの修飾子を使用できません。 この結果，情報がスクリーンの外部にスクロールされて表示されなくなることがあります。 これらのコマンドは将来のリリースで強化される予定です。

4.16.2.2 製品の削除に関する制限事項

V6.1

POLYCENTER Software Installationユーティリティを使用して製品を削除すると， その製品に対して作成されたアカウントも削除されます。この問題は，SYSUAF.DAT ファイルが別のシステム・ディスクによって共有されているかどうかとは無関係に発生します。

ライト識別子やRIGHTSLIST.DATファイルに関しても，同じ問題が発生します。

4.17 RMS Journaling

ここでは，RMS Journaling for OpenVMSのリリース・ノートをまとめます。

4.17.1 変更点と強化された機能

ここでは，RMS Journaling for OpenVMSの変更点について説明します。

4.17.1.1 変更されたジャーナル・ ファイルの作成

V7.2

バージョン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 は自動的にそのディレクトリを作成します。

4.17.2 問題点と制限事項

ここでは，RMS Journaling for OpenVMSの制限事項について説明します。

4.17.2.1 順方向(AI)ジャーナリング

V7.2

順方向(AI)ジャーナリングを使用すれば，使用不能またはアクセス不能になったデータ・ ファイルを回復することができます。AIリカバリでは，AI ジャーナル・ファイルを使用して，データ・ファイルのバックアップ・コピーをロール・ フォワードすることで，障害が発生した時点でのデータ・ ファイルの新しいコピーが作成されます。

プロセスが削除されたりシステムがクラッシュした場合には，更新情報をAI ジャーナル・ファイルに書き込むことができますが，データ・ファイルに書き込むことはできません。AI ジャーナリングだけが使用されている場合は， 自動的にデータ・ファイルとジャーナルの統一がとられるわけではありません。 データ・ファイルに対して追加更新を行い，AIジャーナルに記録すると， その後のロール・フォワード操作で一貫性のないデータ・ファイルが作成されることがあります。

リカバリ・ユニット(RU)ジャーナリングをAIジャーナリングと組み合わせて使用した場合には， 自動的なトランザクション・リカバリにより，AIジャーナルとデータ・ ファイルの間の一貫性が復元されます。

特定の状況では，AIジャーナリングだけを使用するアプリケーションは， プロセスの削除やシステム・クラッシュの後，データの不統一が発生しないように， 予防措置をとることができます。たとえば，AIジャーナリングされているファイルの手動ロール・ フォワードを行うと，非共有AIアプリケーション( シングル・アクセッサ)やスタンドアロン・システムで実行中の共有AI アプリケーションなどに関係するシステム・クラッシュの後，ファイルの一貫性を維持することができます。

しかし，共有AIアプリケーションでは，クラスタ内でプロセスの削除やシステム・ クラッシュが発生した後，AIジャーナル・ファイルと同期のとれていないデータ・ ファイルに対して，これ以上の操作が実行されないようにするための措置はとられません。 このような状況では，データ・ファイルとAI ジャーナル・ファイルの間の一貫性は，AIジャーナリングとRUジャーナリングを組み合わせて使用することで維持できます。

4.17.2.2 OSI環境でのリカバリ・ユニット・ ジャーナリングされたファイルへのリモート・ アクセス

V6.1

ネットワーク内の他のノードからリモート・アクセスされるリカバリ・ ユニット・ジャーナリング・ファイルのホストであるOSIノードは， SYS$NODEをフェーズIV形式のノード名として定義しなければなりません。 SYS$NODEによって指定されるノード名は，ホスト・ノードのリカバリ・ユニット・ ジャーナリング・ファイルにアクセスしようとするすべてのリモート・ ノードから認識されなければなりません。また，リモート・ノードがこのノード名を使用して， ホスト・ノードとの間でDECnet接続を確立できるように， ノード名は一意の名前でなければなりません。この制限は， OSIまたは複合OSI環境と非OSI環境でネットワークを介してアクセスされるリカバリ・ ユニット・ジャーナリング・ファイルにだけ適用されます。

4.17.2.3 VFC形式の順編成ファイル

VAX V5.0，
Alpha V1.0

逆方向ジャーナリングやリカバリ・ユニット・ジャーナリングを使用している場合， 固定長制御部付可変長(VFC)順編成ファイルを更新することはできません。VFC 順編成ファイル形式は，FABのFAB$B_RFMフィールドのシンボリック値FAB$C_VFC によって示されます。

4.18 セキュリティ

ここでは，システム・セキュリティに関連するリリース・ノートをまとめます。

4.18.1 変更点と強化された機能

ここでは，システム・セキュリティの変更点と強化された機能について説明します。

4.18.1.1 DETACH特権はIMPERSONATEという名前に変更

V7.1

DETACH特権はIMPERSONATEという名前に変更されました。この特権の能力はこれまでより強化されており， この特権が与えられているユーザは，別のユーザの一般的な偽装(general impersonation) を実行できるようになりました。

IMPERSONATE特権は次の方法で使用できます。

4.18.1.2 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コマンドを使用します。

4.19 Show Clusterユーティリティ

ここでは，Show Cluster (SHOW CLUSTER)ユーティリティのリリース・ノートをまとめます。

4.19.1 ドキュメントの変更点と修正点

ここでは，SHOW CLUSTERのドキュメントの変更点について説明します。

4.19.1.1 『OpenVMSシステム管理ユーティリティ・ リファレンス・ マニュアル(下巻)』

V7.2

以前のリリースでは，ADD (Field)コマンドのMEMBERSクラスのEXPECTED_VOTES フィールドとQUORUMフィールドの説明が不完全でした。 このリリースではドキュメントが更新されました。これらのフィールドの完全な説明は次のとおりです。

フィールド名 説明
EXPECTED_VOTES 各ノードが検出できる最多投票数。 CL_EXPECTED_VOTESを計算するための初期見積もりとして使用される。クラスタ・ マネージャは，EXPECTED_VOTESシステム・パラメータを使用してこの値を設定する。REMOVE_NODE オプションを使用してクラスタ・メンバをシャットダウンした場合や， このノードが最後に再ブートされた後， SET CLUSTER/EXPECTED_VOTES DCLコマンドを使用した場合には，このフィールドに対してEXPECTED_VOTES システム・パラメータの設定より小さい値が表示されることがある。 クラスタ単位で使用されるEXPECTED_VOTES の動的な値はCL_EXPECTED_VOTESフィールドであり，これはADD (Field) のCLUSTERクラス・カテゴリで記述される。
QUORUM EXPECTED_VOTESから導かれ，接続マネージャによって計算される。 このノードが機能するために必要な最少投票数の初期値を表す。 動的なQUORUMの値は，CL_QUORUMフィールドであり，これはADD (Field) のCLUSTERクラス・カテゴリで記述される。

4.20 SYS$EXAMPLES

ここでは，SYS$EXAMPLESのリリース・ノートをまとめます。

4.20.1 変更点と強化された機能

ここでは，SYS$EXAMPLESの変更点について説明します。

4.20.1.1 PREFER.MARとPREFER.CLDの代わりに使用されるSET PREFERRED_PATH コマンド

V7.2

PREFER.MARとPREFER.CLDはSYS$EXAMPLESから削除されました。これらのファイルはオペレーティング・ システムに添付されなくなりましたが，アップグレード時に既存のシステムから削除されるわけではありません。 これらのファイルは削除しても， 保存してもかまいません。

PREFER.MARとPREFER.CLDの機能は，新しいDCLコマンドSET PREFERRED_ PATHが提供するようになりました。SET PREFERRED_PATHコマンドの詳細については， オンライン・ヘルプまたは『OpenVMS DCLディクショナリ』を参照してください。

4.21 システム・パラメータ

ここでは，OpenVMSシステム・パラメータのリリース・ノートをまとめます。

4.21.1 変更点と強化された機能

ここでは，バージョン7.2のシステム・パラメータとシステム・ パラメータのヘルプの変更点について説明します。新しいシステム・ パラメータの詳細については，オンライン・ヘルプ，『OpenVMS V 7.2新機能説明書』， 『OpenVMSシステム管理ユーティリティ・ リファレンス・マニュアル』のいずれかを参照してください。

4.21.1.1 システム・パラメータのヘルプ

V7.2

システム・パラメータのヘルプは，これまでより簡単にアクセスできるようになりました。 次の新しい場所からシステム・パラメータのヘルプを検索してください。

バージョン7.2以降，特殊パラメータは他のシステム・パラメータとアルファベット順にマージされ， これまでより簡単に検索できるようになりました。 この新しい構造は『OpenVMSシステム管理ユーティリティ・リファレンス・ マニュアル』でも使用されています。

4.21.1.2 CRD_CONTROL

V7.2

CRD_CONTROLシステム・パラメータはVAXシステムだけでなく，Alphaシステムでも実装されています。VAX システムでは，CRD_CONTROLは以前のリリースでCRDENABLE が実行していた機能を実行します。Alphaシステムでは， CRD_CONTROLを使用して，CRDENABLEで定義されていた機能を拡張することができます。

CRD_CONTROLは，修正された読み込みデータ(CRD)ソフト・エラー制御フラグのビット・ マスクです。これらのフラグはCRDERRORルーチンの使用を制御します。OpenVMS バージョン7.2では，Alphaシステム用に拡張機能をサポートするために， いくつかの新しいビットが定義されています。

デフォルト値は，VAX場合とAlphaの場合で異なります。VAXシステムでは，CRD_CONTROL のデフォルト設定は7から6に変更されており，CRD処理， スクラブ，ページ置換が有効になります。Alphaシステムでは，CRD_ CONTROLのデフォルト設定は22であり，CRD処理，スクラブ，ページ置換， CRDの取り扱いの拡張が有効になります。

VAXシステムとAlphaシステムのビットの詳細については，オンライン・ ヘルプのトピックSys_Parametersを参照するか，『OpenVMSシステム管理ユーティリティ・ リファレンス・マニュアル(下巻)』の「システム・パラメータ」という付録を参照してください。

4.21.1.3 MAXBOBMEM (Alphaのみ)

V7.2

Alphaシステムでは，MAXBOBMEMシステム・パラメータは，バッファ・オブジェクトに割り当てることができる物理メモリの最大サイズをページレット単位で定義します。 バッファ・オブジェクトに割り当てられるページは， それが同時に複数のバッファ・オブジェクトに割り当てられる場合でも， このパラメータに対して1回だけカウントされます。

OpenVMSバージョン7.2以降，メモリ常駐ページはこのパラメータに対してカウントされなくなりました( ただし，$LCKPAGシステム・サービスによってメモリ内でロックされているページはカウントされます) 。

MAXBOBMEMはDYNAMICパラメータです。

4.21.1.4 MMG_CTLFLAGS (Alphaのみ)

V7.2

OpenVMSバージョン7.2以降，メモリをいつテストするかを制御できます。 この機能は，システムの電源をオンにしてから，AlphaServer 4100コンピュータにログインするまでの時間を短縮するのに役立ちます。

MMG_CTLFLAGSパラメータのビット2は遅延メモリ・テストを制御します。

4.21.1.5 MSCP_CMD_TMO

V7.2

MSCP_CMD_TMOシステム・パラメータは，OpenVMS MSCPサーバがMSCPコマンド・ タイムアウトを検出するために使用する秒数を指定します。MSCPサーバは約40 秒の組み込み時間とMSCP_CMD_TMOパラメータの値を加算した時間内にコマンドを完了しなければなりません。

このパラメータの省略時の値は0であり，通常はこの値が適切です。値が0 の場合は，MSCP_CMD_TMOシステム・パラメータがなかったOpenVMSの以前のリリースと同じ動作をします。0 以外の値に設定すると，MSCPコマンドがタイムアウトになるまでの時間が延長されます。

コマンド・タイムアウト・エラーがクライアント・ノードでログに記録された場合は，OpenVMS サーバでこのパラメータを0以外の値に設定すると， ログに記録されるエラーの数を削減できます。このパラメータの値を大きくすると， クライアントMSCPコマンドのタイムアウトの発生回数が少なくなり， 正常に動作していない装置を検出するのにかかる時間が長くなります。

コマンド・タイムアウト・エラーの数を削減しなければならない場合は， 初期値として60に設定してください。その後もタイムアウト・エラーがログに記録される場合は， この値を20秒刻みで大きくすることができます。

4.21.1.6 MSCP_SERVE_ALL

V7.2

割り当てクラスがシステム・ノードの割り当てクラスと異なるHS xコントローラに接続されたディスクをサービスすることができるように，MSCP_SERVE_ALL システム・パラメータが強化されました。 さらに，MSCP_SERVE_ALLのデフォルト設定は，特殊な状況で発生する可能性のある問題を防止するために，0 ( オフ)から4 (システム・ディスクだけをサービス) に変更されました。

OpenVMSバージョン7.2以降，サービス・タイプはビット・マスクとして実装されています。 各ビットで制御されるサービス・タイプの詳細については， 『OpenVMSシステム管理ユーティリティ・ リファレンス・マニュアル(下巻)』の「System Parameters」という付録を参照してください。

TMSCP_SERVE_ALLパラメータも同様に変更されています。第4.21.1.13項を参照してください。MSCP とTMSCPサービスの詳細については， 『OpenVMS Cluster Systems』を参照してください。

4.21.1.7 NOCLUSTER

V7.2

NOCLUSTERシステム・パラメータは，VAXシステムとAlphaシステムの両方でサポートされるようになりました。 このパラメータは，システムのブート時にページ読み込みクラスタが禁止されるかどうかを制御します。 デバッグの場合にだけ，NOCLUSTER パラメータを1 (ページ読み込みクラスタを禁止) に設定しなければなりません。

4.21.1.8 PASTDGBUF

V7.2

PASTDGBUFシステム・パラメータの定義が変更されました。

PASTDGBUF クラスタ・ポート・ドライバの構成ポーリングに対して，最初にキューに登録するためのデータグラム受信バッファの数。 初期値は，必要に応じてシステム操作時に拡張されます。

Memory Channel装置はこのパラメータを無視します。

PASTDGBUFはAUTOGENパラメータです。

4.21.1.9 PIOPAGES

V7.2

PIOPAGESシステム・パラメータのデフォルト値は575に拡大されました。 この新しい設定は，バージョン7.2でRMSファイル名の解析方法が変更された結果， 必要なプロセス・パーマネント・メモリの容量が拡大したことに対応するためのものです。

4.21.1.10 QDSKINTERVAL

V7.2

OpenVMSバージョン7.2以降，QDSKINTERVALのデフォルト値は10から3に変更されました。

4.21.1.11 SCSCONNCNTの廃止

V7.2

OpenVMSバージョン7.2以降，SCSCONNCNTシステム・パラメータは廃止されました。SCS 接続は必要な場合にだけ割り当てられ，最大65,000まで拡張されるようになりました。

4.21.1.12 STARTUP_P3

V7.2

OpenVMSバージョン7.2以降，STARTUP_P3がAGENに設定されている場合，システムはスタートアップ・ シーケンスの最後にAUTOGENを実行するようになりました。

4.21.1.13 TMSCP_SERVE_ALL

V7.2

割り当てクラスがシステムのノード割り当てクラスと異なるHSxコントローラに接続されているテープをサービスできるように，TMSCP_ SERVE_ALLシステム・パラメータが強化されました。

OpenVMSバージョン7.2以降，TMSCP_SERVE_ALLパラメータは，システム・ ブートでテープのサービスを制御するビット・マスクです。また，バージョン7.2 以降，ビット3の値が1である場合を除き，割り当てクラスとは無関係に， テープはサービスされます。

各ビットで制御されるサービス・タイプの詳細については，Sys_ Parametersヘルプ・トピックまたは『OpenVMSシステム管理ユーティリティ・ リファレンス・マニュアル( 下巻)』の「システム・パラメータ」という付録を参照してください。

MSCP_SERVE_ALLパラメータも同様に変更されています。第4.21.1.6項を参照してください。TMSCP サービスとMSCPサービスの詳細については，『OpenVMS Cluster Systems』を参照してください。

4.21.1.14 VBN_CACHE_S (VAXのみ)

V7.2

OpenVMS VAXバージョン7.2で，このシステム・パラメータのデフォルト値と動作が変更されました。 ここでは，新しいデフォルト値と動作について説明します。

VAXシステムで静的システム・パラメータVBN_CACHE_Sは，ファイル・システム・ データ・キャッシュを有効または無効にします。デフォルト値は1 であり，その場合はキャッシングが有効になり，仮想I/Oキャッシュがシステム・ スタートアップ時にロードされます。

ローカル・ノードおよびOpenVMS Cluster全体でファイル・システム・ データ・キャッシングを無効にするには，値を1に設定します。OpenVMS Clusterでは，このノードがクラスタから切り離されるか，VBN_CACHE_Sパラメータを1 に設定して再ブートされるまで，クラスタ内の他のノードはどれもファイル・ データをキャッシングすることができません。

4.21.1.15 VCC_MAXSIZE (Alphaのみ)

V7.2

このシステム・パラメータの説明は次のように変更されました。

Alphaシステムでは，静的システム・パラメータVCC_MAXSIZEは仮想I/Oキャッシュのサイズを制御します。 このパラメータはサイズをブロック数で指定します。 デフォルト値は6,400です。

Alphaシステムでは，仮想I/Oキャッシュを縮小または拡大することはできません。 サイズはシステム・スタートアップ時に固定されます。

VCC_MAXSIZEはAUTOGENパラメータです。

4.21.2 問題点と制限事項

ここでは，システム・パラメータの問題点と制限事項について説明します。

4.21.2.1 ARB_SUPPORT (Alphaのみ)

V7.2

新しいスレッド単位のセキュリティPersona Security Block (PSB)構造体でまだ更新されていない製品をサポートするために， 新しいAccess Rights Block (ARB)互換性オプション，ARB_SUPPORTシステム・パラメータが提供されるようになりました。

注意
すべてのOpenVMS Alphaバージョン7.2 システムで，ARB_SUPPORTパラメータを2または3 (省略時の値) に設定するようにしてください(バージョン7.2のオンライン・ヘルプには， デフォルト値が2と示されていますが，これは誤りです)。ARBおよび関連構造体に依存するすべての製品が新しい環境に対して変更されるまで，ARB_SUPPORT パラメータを他の値に変更しないでください。

ARB互換性オプションの詳細については，オンライン・ヘルプのSys_Parameters トピックからARB_SUPPORTを検索するか，または『OpenVMSシステム管理ユーティリティ・ リファレンス・マニュアル』のシステム・パラメータに関する付録を参照してください。

4.21.2.2 MSCP_SERVE_ALL

V7.2

OpenVMSノードがブート・サーバの場合，OpenVMS割り当てクラスはサテライト・ ブート装置の割り当てクラスに設定しなければなりません。この条件が満たされない場合， サテライト・ブートで障害が発生することがあります。

4.21.3 修正点

MSCP_CMD_TMOシステム・パラメータの修正の説明については，第4.14.3.4項を参照してください。

4.21.4 ドキュメントの変更点と修正点

ここでは，システム・パラメータのドキュメントの変更点について説明します。 システム・パラメータのヘルプの変更点については，第4.21.1.1項を参照してください。

4.21.4.1 ARB_SUPPORTのデフォルト値は3 (Alphaのみ)

V7.2

OpenVMSバージョン7.2システムのSys_Parametersヘルプ・トピックで， ARB_SUPPORTの省略時の値が表に誤って2であると示されています。実際の省略時の設定は3 であり，これはARB_SUPPORTのヘルプの最初の段落に示されています。

4.21.4.2 MPDEV_REMOTEはサポートされない

V7.2

オンライン・ヘルプと『OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』に説明されているMPDEV_REMOTE システム・パラメータは，OpenVMSバージョン7.2でサポートされません。OpenVMS VAX のオンライン・ヘルプには，省略時の値がON と示されていますが，これは誤りです。

4.22 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

OpenVMS Alpha TFFは，次の点でOpenVMS VAX TFFと異なります。

RT端末はTFFでサポートされません。

Terminal Fallback facilityの詳細については，『OpenVMS Terminal Fallback Utility Manual 』を参照してください。 [1]

[1] このマニュアルはアーカイブされていますが，OpenVMSドキュメンテーションCD-ROM にPostScript形式とDECW$BOOK (Bookreader)形式で格納されています。 印刷したマニュアルはDECdirect (800-344-4825)を通じて注文できます。 このマニュアルの注文番号はAA-PS6BA-TEです。

4.23 Volume Shadowing for OpenVMS

ここでは，Volume Shadowing for OpenVMSのリリース・ノートをまとめます。

4.23.1 変更点と強化された機能

ここでは，ボリューム・シャドウイング・ソフトウェアの変更点について説明します。

4.23.1.1 サポートされるシャドウ・セット・メンバ数が500 に拡大

V7.1

OpenVMSバージョン7.1で，サポートされるシャドウ・セット・メンバの数が390 から500に拡大されました。

4.23.2 問題点と制限事項

ここでは，Volume Shadowingの問題点とその他の留意事項について説明します。

4.23.2.1 HSD10仮想ディスク

V7.1

HSD10コントローラは物理ディスクをパーティション分割することで，仮想ディスク機能をサポートします。 データが破損しないようにするために，HSD10 仮想ディスクを使用してシャドウ・セットを作成するために， OpenVMS Volume Shadowingを使用しないでください。

4.23.2.2 システム・ディスクのミニマージ機能ではDUMPSTYLE パラメータが必要(Alphaのみ)

V7.1

システム・ディスクをダンプする場合，DUMPSTYLEパラメータを使用せずに， システム・ディスク・ミニマージを有効にしないでください。 このシステム・パラメータについては，『OpenVMSシステム管理ユーティリティ・ リファレンス・マニュアル』のシステム・ パラメータに関する付録を参照してください。 DUMPSTYLEパラメータをDOSD (システム・ディスクのダンプ・オフ)に設定しないで， システム・ディスクに対してミニマージを有効に設定すると， ミニマージが有効になり，クラッシュ・ダンプ分析が破損します。

OpenVMS Alphaバージョン7.1でSHADOW_SYS_DISKシステム・パラメータに新しい設定(4097) が追加され，DUMPSTYLEパラメータが使用されるようになったため，OpenVMS VAX システムだけでなく，OpenVMS Alphaシステムでも， シャドウイングされているシステム・ディスクに対してミニマージを有効に設定できるようになりました。DUMPSTYLE パラメータを使用すると， システムがダンプをシャドウイングされていない非システム・ディスクに書き込むことを指定できます。 この結果，性能をかなり向上することができます。

システム・ディスクのシャドウイングは，SHADOW_SYS_DISKシステム・ パラメータを設定して制御します。表 4-2 を参照してください。

表 4-2 SHADOW_SYS_DISKシステム・パラメータの設定

設定 説明
0 システム・ディスクをシャドウイングしない。
1 システム・ディスクをシャドウイングする。 システム・ディスクのミニマージを無効にする( 有効な場合)。
4097 システム・ディスクをシャドウイングする。システム・ディスクのミニマージを有効にする。

クラッシュ・ダンプが書き込まれるシステム・ディスクに対して，誤ってミニマージを有効にし， システム・ディスクのダンプ・オフを設定していない場合は， どのディスクに有効なダンプが格納されているかがわかっていれば， 回復することができます。そのメンバを削除し，再びマウントし， そのメンバからダンプを削除します。

4.23.2.3 ミニマージのバージョンの互換性に関する問題

V7.1

OpenVMSバージョン7.1でVolume Shadowingソフトウェアが変更され，品質が大幅に向上しました。 しかし，この結果，同じクラスタ内にバージョン7.1 以上のノードとバージョン6.2のノードがある場合，これらのノードの間でミニマージ機能の互換性に関する問題が発生しました。 このような構成では，Volume Shadowing ソフトウェアはバージョン7.1以上のシステムのインストール時にこの互換性の問題を検出し， クラスタ全体に対してミニマージ機能を無効にします。

この問題は，クラスタ互換性キット(第4.14.1.2 項を参照)をインストールすることで解決できます。このキットをインストールすると， バージョン6.2のミニマージ機能は，バージョン7.1 以上のソフトウェアを稼動しているノードのミニマージ機能と互換性を維持するようになります。

4.23.2.4 HSZ40およびトランスポータブルSCSI ディスク・シャドウ・セット・メンバ

V6.2

HSZ40 Raid-ArrayコントローラとOpenVMS Volume Shadowingを使用している場合には，HSZ40 非トランスポータブルSCSIディスクを使用してください。 これはトランスポータブル・ディスクに必要な機能が欠如しているためであり， この結果，データが破損する可能性があります。

HSZ40 Raid-Arrayコントローラでは，OpenVMSで初期化されたSCSIディスク( つまり，Files-11 ODS-2フォーマットのディスク)を，OpenVMSで制御されるSCSI バスとHSZ40で制御されるSCSIバスの間で移動することができ， その場合，ディスクの再初期化は不要であり，そのためにデータが紛失することもありません。 この機能を備えたディスクをトランスポータブル ・ディスクと呼びます。

HSZ40で初期化され，その後でOpenVMSで初期化されたSCSIディスクは 非トランスポータブル・ディスクと呼びます。データを失わずに， このディスクをOpenVMSで制御されるSCSIバスに移動することはできません。

トランスポータブルSCSIディスクは，OpenVMSで制御されるSCSIバスに接続されている間，READ_LONG/WRITE_LONG 機能をサポートしますが，HSZ40 Raid-Arrayコントローラで制御されるSCSIバスに移動されると，この機能は失われます。 しかし，OpenVMS Volume Shadowingでは，通常のボリューム・ シャドウイング操作で発生する特定のクラスのエラーを取り扱うために，SCSI ディスクがREAD_LONG/WRITE_LONG SCSIコマンドをサポートすることを要求しています。READ_LONG/WRITE_LONG SCSI コマンドがサポートされない結果， データが破損する可能性があります。

READ_LONG/WRITE_LONG機能の欠如は，次のエラーによって，シャドウ・セットのMOUNT 時に検出されます。 

     MOUN$_DEVNOFE, device does not support FORCED ERROR handling

この制限を承知の上でOpenVMS Volume Shadowingを使用する場合は(このような使い方は望ましくありません) ，シャドウ・セットのMOUNT時にMOUNT 修飾子/OVERRIDE=NO_FORCED_ERRORを指定できます。

このMOUNT修飾子を指定すると，修正できない特定のエラーが発生したときに， シャドウ・セット・メンバSCSIディスクがシャドウ・セットから削除されることがあります。

4.23.3 修正点

ここでは，以前のボリューム・シャドウイングの問題点に対する修正について説明します。

4.23.3.1 StorageWorks RAIDソフトウェアとの互換性の問題の修正

V7.2

StorageWorks RAIDソフトウェアと，OpenVMSバージョン7.1およびクラスタ互換性キットで提供される強化されたボリューム・ シャドウイングの間には， 互換性の問題がありました。この互換性の問題により，RAIDソフトウェアはシャドウ・ セット状態の変化を検出することができませんでした。

この問題はStorageWorks RAIDソフトウェア・バージョン2.4で解決されました。

注意
この互換性の問題は，RAID 0 (シャドウイングなし)アレイやRAID 5アレイには影響しませんでした。

4.23.3.2 Bad Block Repair (BBR)ロジックの問題点の修正

V7.2

OpenVMSバージョン7.1のVolume ShadowingドライバのBad Block Repair (BBR)ロジックは正しく動作しないことがありました。

この問題は，OpenVMSバージョン7.2およびOpenVMSバージョン6.2 システム用のクラスタ互換性キットで解決されています(第4.14.1.2項を参照)。

[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ] [ DOC Home ]