第4章 OpenVMS オペレーティング・システムをアップグレードするための準備

この章では，アップグレードを開始する前の準備作業について説明します。また，4.1 項「アップグレード前の準備作業」に，この章で説明する作業の実施を確認するためのチェック・リストが示してあります。

4.1 アップグレード前の準備作業

システムのアップグレードを実施する前に，表 4-1 「アップグレード前のチェックリスト」のチェックリストを使用して，必要な作業をすべて確実に実施してください。

表 4-1 アップグレード前のチェックリスト

	作業	説明箇所
	関連ドキュメントに目を通す	4.2 項「参照ドキュメント」
	次の各項目に関する注意事項および制限事項を確認する V8.4 へのアップグレード・パスアップデート・ライセンスの要件インストールしないコンポーネントシステム・ディスクのディレクトリ構成を変更したことで発生するアップグレードの問題レイヤード・プロダクトのライセンスと再インストールの必要性	4.3 項「注意および制限事項」
	手作業で削除しなければならないソフトウェアをチェックする	4.4 項「手作業で削除しなければならないソフトウェア」
	必要なファイルがアップグレードで削除されないようにする	4.6 項「アップグレードによる削除からアーカイブ・ファイルを保護する」
	アップグレードに備えてシステム・ディスクを準備する	4.7 項「システム・ディスクの準備」
	最近の FEEDBACK.DAT ファイルを用意する	4.8 項「新しい FEEDBACK.DAT ファイルの用意」
	ボリューム・シャドウイング環境で行うアップグレードの前に，必要な作業を実施する	4.9 項「シャドウイング環境」
	現在のシステム・ディスクをバックアップする	4.10 項「システム・ディスクのバックアップ」
	システムをシャットダウンする	4.11 項「アップグレード前の作業の終了」

4.2 参照ドキュメント

この章で説明する内容に加え，必要に応じて以下のドキュメントを参照してください。

『日本語 HP OpenVMS Version 8.4 をご使用のお客様へ』
配布キットに含まれているソフトウェア仕様書
『HP OpenVMS Version 8.4 リリース・ノート』
『HP OpenVMS Version 8.4 新機能説明書』
『『HP OpenVMS Cluster システム』』
『HP OpenVMS Cluster 構成ガイド』
『OpenVMS システム管理者マニュアル (下巻)』
「システム・パラメータの管理」の章を中心に，AUTOGEN の使用方法，システム・パラメータ・ファイル (MODPARAMS.DAT) の変更方法，およびその関連操作に関する情報が記載されています。
『HP OpenVMS システム管理ユーティリティ・リファレンス・マニュアル』
SYSMAN や ANALYZE/DISK_STRUCTURE などのシステム管理ユーティリティの使用方法について説明しています。
『OpenVMS システム・セキュリティ・ガイド』
アップグレード後にセキュリティ環境を再構築する方法について説明しています。

4.3 注意および制限事項

この節には，アップグレードの成否に関係する重要な情報が記載してあります。アップグレードを開始する前に，ここに記載してある注意事項および制限事項に目を通してください。

4.3.1 アップグレード・パス

OpenVMS V8.4 へ移行するためのさまざまなアップグレード・パスを，以下に示します。

4.3.1.1 直接アップグレード・パス

OpenVMS Integrity V8.4 へ直接アップグレードできるのは，次の各バージョンだけです。

V8.3-1H1
V8.3
V8.2-1

OpenVMS Alpha V8.4 へ直接アップグレードできるのは，次の各バージョンだけです。

OpenVMS Alpha V8.3
OpenVMS Alpha V8.2
OpenVMS Alpha V7.3-2

4.3.1.2 間接アップグレード・パス

Version 7.3-2 より前のバージョンの OpenVMS Alpha を使用している場合は，Version 8.4 に直接アップグレードすることはできません。 Version 8.4 にアップグレードする前に，まず Version 7.3-2 にアップグレードしなければなりません (使用している OpenVMS のバージョンによっては，さらに中間のバージョンにアップグレードする必要があります)。何度かアップグレードを繰り返す場合は，アップグレード時に問題が発生した場合に対処できるよう，システム・ディスクのバックアップを実施しながら数日かけて行なうことをお勧めします。

たとえば，OpenVMS Alpha Version 7.1 を使用している場合は，まず Version 7.2，7.2-1，または 7.2-2 のいずれかにアップグレードしてから Version 7.3-2 にアップグレードし，その後 Version 8.4 にアップグレードする必要があります。




	注記: 中間バージョンへのアップグレードを行なう場合，アップグレード先のバージョンの OpenVMS ドキュメントを参照して，パッチなど，インストレーションに必要な要件がないか確認してください。

4.3.2 アップデート・ライセンスの要件




	重要: OpenVMS Integrity V8.4へアップグレードするときは，その前に，適切な OE ライセンスをシステムにロードしておく必要があります。同様に，OpenVMS Alpha システムをアップグレードするときは，その前に，適切な Alpha ライセンスをシステムにロードしておく必要があります。

弊社のソフトウェア・ライセンスを購入すると，その製品の現行バージョンまたは購入時点での過去のバージョンを使用する権利が与えられます。




	注意: OpenVMS のソフトウェアとライセンスを初めて購入した時に，弊社から，ライセンス管理機能 (LMF) によるライセンス登録とそれ以降の製品使用の検証・許可を可能にする PAK (Product Authorization Key) が提供されます。ただし，PAK を提供されたからといって，その PAK だけでライセンスや新バージョンの使用権が与えられるわけではありません。ライセンスと LMF についての詳細は，『HP OpenVMS License Management Utility Manual』を参照してください。

アップデート・ライセンスが必要な場合は，弊社の営業担当にお問い合わせください。

4.3.3 インストールしないコンポーネントの選択

アップグレード中に，オプションの OpenVMS ネットワーク・ソフトウェア (DECnet または TCP/IP) や DECwindows/Motif GUI をインストールしないように選択すると，それらの製品はアップグレード・プロシージャによって，システム・ディスクから削除されます。 OpenVMS を HP SIM のプロビジョニング機能でインストールすると，TCP/IP Services for OpenVMS は自動的にインストールされます。システムにインストールされている各種ソフトウェアのバージョンが適切かどうかをチェックする方法と，旧バージョンを手動で削除すべき製品があるかどうかを調べる方法については，4.4 項「手作業で削除しなければならないソフトウェア」を参照してください。




	注意: 特に理由がない限り，デフォルトの設定に従って，OpenVMS のオプションをすべてインストールするようお勧めします。OpenVMS とレイヤード・プロダクトは，これらオプションの多くにさまざまな形で依存しています。不要と思われるオプションでも，それがインストールされていないと OpenVMS やレイヤード・プロダクトの一部の機能が正しく機能しない可能性があります。 OpenVMS Integrity のインストールでは，購入した OE の種類によって一部のオプションが利用できない場合があるので，そのことにも注意してください。詳細は，『HP OpenVMS Alpha Version 8.4 / HP OpenVMS Version 8.4 for Integrity Servers ソフトウェア仕様書』(SPD 25.C4.`xx`) を参照してください。

4.3.4 ライセンスとレイヤード・プロダクト

アップグレード・プロシージャは，アップグレードした後にレイヤード・プロダクトを再インストールしなくても良いように設計されています。ただし，一部のレイヤード・プロダクトについては，専用のインストール・プロシージャを使用しているために，あらためて再インストールが必要になることがあります。

アップグレードを行っても，OpenVMS とレイヤード・プロダクトのライセンスはそのまま使用できます。アップグレードの後で，これらのライセンスをインストールし直す必要はありません。

4.4 手作業で削除しなければならないソフトウェア

DECram または TDC V2.0 を現在使用している場合は，アップグレードの前に，これらの製品を手作業で削除しなければなりません。削除しないと，アップグレードが失敗する場合があります。手作業で削除する必要のあるソフトウェアについてのその他の情報は，『HP OpenVMS Version 8.4 リリース・ノート』を参照してください。




	注意: OpenVMS Alpha のアップグレードでは SSL のバージョンがチェックされ，古いバージョンが見つかると自動的に削除されます。

4.4.1 古いバージョンの DECram for OpenVMS の削除 (Alpha のみ)

DECram for OpenVMS は，OpenVMS V8.2 から OpenVMS オペレーティング・システムに必須のコンポーネントとなりました。以前にインストールした古いバージョンの DECram for OpenVMS は，OpenVMS Alpha V8.4 へアップグレードする前に手動で削除する必要があります。アップグレード中に DECram for OpenVMS を自動削除することはできません。古いバージョンの DECram for OpenVMS がインストールされていると，アップグレードが途中で失敗することがあります。また，アップグレード自体は完了しても，DECram for OpenVMS がエラーを引き起こす原因になったり，正しく機能しなくなるおそれがあります。ここでは，オペレーティング・システムから古いバージョンの DECram for OpenVMS を削除する方法について説明します。

アップグレードのためにオペレーティング・システムをシャットダウンする前に，以下の手順で DECram for OpenVMS を削除してください (オペレーティング・システムがすでにシャットダウンされている場合は，リブートしてから以下の手順を実施してください)。




	重要: 以下の手順は，V8.2 より前の OpenVMS Alpha でのみ実行してください。

必要な特権を持つアカウントでログインした後，次のコマンドを実行して，PCSI (POLYCENTER Software Installation) ユーティリティでインストールした DECram for OpenVMS の有無をチェックします。
$ PRODUCT SHOW PRODUCT DECRAM
DECram がシステムにインストールされていない場合は手順 3 へ進み，見つかった場合は手順 2 へ進みます。
SHOW PRODUCT の結果，DECram for OpenVMS がインストールされていることを示す出力が表示された場合は，次のコマンドを実行して DECram for OpenVMS を削除します。
$ PRODUCT REMOVE DECRAM
このコマンドが正常に実行されれば，手順は完了です。以下の手順はスキップしてください。削除できなかった場合は，手順 3 へ進みます。

次のコマンドを実行して，VMSINSTAL ユーティリティでインストールした DECram for OpenVMS のファイルがシステムに存在するかどうかをチェックします。

$ DIRECTORY SYS$SYSDEVICE:[SYS*.SYS$LDR]SYS$MDDRIVER.EXE
$ DIRECTORY SYS$SYSDEVICE:[SYS*.SYSEXE]MDMANAGER.EXE
$ DIRECTORY SYS$SYSDEVICE:[SYS*.SYSMGR]MDRECOVER.EXE
$ DIRECTORY SYS$SYSDEVICE:[SYS*.SYSHLP]DECRAM$HELP.HLB;*
$ DIRECTORY SYS$SYSDEVICE:[SYS*.SYSTEST]DECRAM$IVP.COM;*

ファイルが見つかった場合は，手順 4 のコマンドを使用して削除します。ファイルが見つからなかった場合は，手順 5 へ進みます。

手順 3 で見つかったファイルを，適切な DELETE コマンドを実行して削除します (/NOCONFIRM/NOLOG 修飾子はオプションです)。

$ DELETE/NOCONFIRM/NOLOG SYS$SYSDEVICE:[SYS*.SYS$LDR]SYS$MDDRIVER.EXE*
$ DELETE/NOCONFIRM/NOLOG SYS$SYSDEVICE:[SYS*.SYSEXE]MDMANAGER.EXE;*
$ DELETE/NOCONFIRM/NOLOG SYS$SYSDEVICE:[SYS*.SYSMGR]MDRECOVER.EXE;*
$ DELETE/NOCONFIRM/NOLOG SYS$SYSDEVICE:[SYS*.SYSHLP]DECRAM$HELP.HLB;*
$ DELETE/NOCONFIRM/NOLOG SYS$SYSDEVICE:[SYS*.SYSTEST]DECRAM$IVP.COM;*

さらに次のコマンドを実行して，スタートアップ・データベースから DECram for OpenVMS のスタートアップ・ファイルを削除します。
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_LAYERED SYSMAN> STARTUP REMOVE FILE MDRECOVER.EXE
「-STARTUP-E-FILNOTFND, STARTUP file MDRECOVER.EXE not found」というエラーは無視してもかまいません。SYSMAN を終了するには，Ctrl/Z を押すか，EXIT と入力します。

4.4.2 TDC V2.0 の削除 (Alpha のみ)

TDC V2.0 は OpenVMS Alpha V7.3-2 システムで使用するためにリリースされた製品です。TDC V2.0 がインストールされている場合は，OpenVMS Alpha の最新リリースをインストールする前に，システムから削除してください。

アップグレードするオペレーティング・システムをシャットダウンする前に，以下の手順で TDC V2.0 を削除してください (オペレーティング・システムがシャットダウンされている場合は，リブートしてから以下の手順を実施してください)。

必要な特権を持つアカウントでログインした後，次のコマンドを実行して，PCSI (POLYCENTER Software Installation) ユーティリティでインストールした TDC V2.0 の有無をチェックします。
$ PRODUCT SHOW PRODUCT TDC
TDC がシステムにインストールされていない場合は，特に処理は必要ありません。TDC が見つかった場合は，手順 2 へ進みます。
SHOW PRODUCT の結果，TDC V2.0 がインストールされていることを示す出力が表示された場合は，次のコマンドを実行して TDC V2.0 を削除します。
$ PRODUCT REMOVE TDC

4.5 構成を外す必要があるソフトウェア (Integrity のみ)

WBEM Providers for OpenVMS を使用しているあるいは構成している場合は，アップグレードの前に次のコマンドを入力して手動で WBEM Providers の構成を解除する必要があります。

$ @SYS$COMMON:[WBEMPROVIDERS]WBEMPROVIDERS$DECO NFIGURE.COM

4.6 アップグレードによる削除からアーカイブ・ファイルを保護する

回避策をとらない限り，OpenVMS 修正キットによって filename.type_OLD の名前でアーカイブされたファイルは，アップグレード中に削除されてしまいます。これらのファイルが削除されるのを回避するには，アップグレードの前にファイル名を変更します。またこれ以外の方法として，6.4.4 項「アーカイブ・ファイルの保護」で説明してあるように，アップグレード中のプロンプトに順次応答することで，削除を回避することもできます。

4.7 システム・ディスクの準備

この節では，システム・ディスクをアップグレードするための準備について説明します。実施する作業は次のとおりです。

ディレクトリ構造のチェックとセキュリティ保護の確保
SYSCOMMON ディレクトリのチェック
システム・ディスクからの重複ファイルの削除
システム・ディスクの整合性チェック
システム・ディスクのサイズ・チェック
登録ファイルと AGEN$INCLUDE ファイルのシステム・ディスクへの移動
システム・パラメータの検証

4.7.1 ディレクトリ構造のチェックとセキュリティ保護の確保

システム・ディスクのディレクトリ構造が変更されていると，アップグレード・プロシージャは正しく動作しません。アップグレードを行う前に，システム・ディスクを標準のディレクトリ構造に戻してください。

OpenVMS のアップグレード・プロシージャは，[VMS$COMMON...] ディレクトリ内に新しいファイルとディレクトリを用意します。特殊な保護やアクセス制御リスト (ACL) がある場合，現在のセキュリティ環境を再確立するためには，その保護や ACL を再度適用する必要があります。セキュア環境の作成と維持についての詳細は，『OpenVMS システム・セキュリティ・ガイド』を参照してください。

4.7.2 SYSCOMMON ディレクトリのチェック

アップグレードを成功させる条件の 1 つは，すべてのシステム・ルートにある SYSCOMMON ディレクトリが VMS$COMMON ディレクトリの別名 (またはハード・リンク) になっている，ということです。この条件が満たされているかどうかをチェックするには，アップグレード対象となるシステム・ディスクからブートした後，次の 2 つのコマンドを実行してファイル識別子を表示し，それらがすべて同じであることを確認します。

$ DIRECTORY/FILE_ID/NOHEADING/NOTRAILING SYS$SYSDEVICE:[000000]VMS$COMMON.DIR
$ DIRECTORY/FILE_ID/NOHEADING/NOTRAILING SYS$SYSDEVICE:[SYS*]SYSCOMMON.DIR

アップグレードの対象となるシステム・ディスクからブートしなかった場合は，アップグレードの対象となるシステム・ディスクをマウントした後，上記のコマンドでそのデバイス名を指定します。たとえば，アップグレードの対象となるシステム・ディスクを DKA100 にマウントした場合は，次のようなコマンドを実行します。

$ DIRECTORY/FILE_ID/NOHEADING/NOTRAILING DKA100:[000000]VMS$COMMON.DIR
$ DIRECTORY/FILE_ID/NOHEADING/NOTRAILING DKA100:[SYS*]SYSCOMMON.DIR

最初のコマンドからは，1 つのファイルだけがリストに表示されます。2 番目のコマンドからは，そのディスク内にあるシステム・ルートごとに，対応するファイルが 1 つずつ表示されます。表示されたすべてのファイルについて ID が同じであるかどうかをチェックし，その結果に応じて次のように対処します。

ファイルの ID がすべて同じ場合は，次の項へ進んで作業を継続します。
ファイルの ID の中に一致しないものがある場合は，システム・ディスクのディレクトリ構造が OpenVMS の要件を満たしていないので，アップグレードは成功しません。この問題の解決方法については，ソフトウェア・サポート担当者にお問い合わせください。

4.7.3 システム・ディスクからの重複ファイルの削除

ディスク容量とファイル・ヘッダを解放するために，システム・ディスクで重複しているファイルを削除してください。以下のコマンドを実行することをお勧めします。

$ PURGE/LOG/BEFORE=TODAY SYS$SYSDEVICE:[000000...]*.LOG
$ PURGE/LOG SYS$SYSTEM:PAGEFILE*.SYS
$ PURGE/LOG SYS$SYSTEM:SWAPFILE*.SYS
$ PURGE/LOG SYS$SYSTEM:DUMPFILE*.SYS

次のコマンドを実行して，アプリケーションとシステムのダンプ・ファイルがないかシステム・ディスクを確認してください。

$ DIRECTORY/SIZE/DATE SYS$SYSDEVICE:[000000...]*.DMP

.DMP ファイルが見つかった場合は，適宜判断の上，それらを削除してください。

4.7.4 システム・ディスクの整合性チェック

ANALYZE/DISK_STRUCTURE コマンドを使用してシステム・ディスクの整合性をチェックし，問題があれば修正します (このコマンドについての詳細は，『HP OpenVMS システム管理ユーティリティ・リファレンス・マニュアル (上巻)』を参照してください)。手順は次のとおりです。

次のコマンドを実行して，システム・ディスクのファイル構造に矛盾やエラーがないかどうかをチェックします。
$ ANALYZE/DISK_STRUCTURE SYS$SYSDEVICE
次のメッセージは無視してください。
%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
システム・ディスクにこれ以外のエラーが見つかった場合は，次のコマンドを実行して，そのエラーを修正します。
$ ANALYZE/DISK_STRUCTURE/REPAIR SYS$SYSDEVICE
エラーが表示されなくなるまで (手順 1 に示したエラーを除く)，手順 1 と 2 を繰り返します。

4.7.5 システム・ディスクのサイズ・チェック

アップグレードにはディスク・スペースが必要ですが，そのブロック数を前もって予測することは簡単ではありません。必要となるブロックの数は，ターゲット・ディスクにある既存ファイルの数と，アップグレード中に選択するコンポーネントの数に左右されます。ここでは，その予測に役立つ情報を示します。

必要となるディスク容量は，最大で約 675,000 ブロックです。システムで実際に使用される値は，これよりもかなり小さくなる可能性があります。

アップグレードでインストールする各コンポーネントを選択すると，十分なディスク・スペースが存在するかどうかが計算されて，利用可能なブロック数とアップグレードに必要なブロック数が表示されます。この計算でアップグレードの実行に必要なディスク・スペースが足りないということがわかると，警告メッセージが表示されます。そのため，アップグレードをその時点で終了し，十分なディスク・スペースを確保した後で，再度アップグレードを試みることができます。




	注意: システム・ディスクにあるファイルが著しく断片化していると，数字上は十分なディスク・スペースが存在していても，アップグレードを完了できない可能性があります。したがって，アップグレードの前にシステム・ディスクをバックアップしリストアするようお勧めします。システム・ディスクをそのバックアップ・イメージからリストアすると，ファイルの断片化を解消することができます。システム・ディスクのバックアップとリストアについては，付録 F 「システム・ディスクのバックアップとリストア」を参照してください。

利用可能なスペースがシステム・ディスクにどれだけあるかを確認するには，次のコマンドを実行します。

$ SHOW DEVICE SYS$SYSDEVICE

4.7.6 登録ファイルと AGEN$INCLUDE ファイルのシステム・ディスクへの移動

登録ファイルと AGEN$INCLUDE ファイルがシステム・ディスク以外のディスクに置いてあると，アップグレード・プロシージャでは，それらのファイルを見つけることができません。その理由は，アップグレードでは他のディスクがマウントされないからです。また，それらのファイルを指すように設定されていた論理名も，アップグレードの間は，未定義の状態になってしまいます。この項では，登録ファイルと AGEN$INCLUDE ファイルをアップグレード・プロシージャで利用できるようにする方法を説明します。

4.7.6.1 登録ファイル

OpenVMS では，一部のシステム・ファイル (主に登録ファイルなど) をシステム・ディスク以外のディスクへ再配置することができます。そのような再配置を行う場合は，対象となるファイルを他のディスクへコピーするとともに，論理名を定義します (論理名の定義方法は，SYS$MANAGER:SYLOGICALS.TEMPLATE ファイルに記載されています)。論理名は SYS$STARTUP:SYLOGICALS.COM で定義します。

OpenVMS オペレーティング・システムのメディアからブートしたシステムでは，再配置されているファイルを指す論理名が定義されていないので，それらのファイルがあるディスクもマウントされません。そのため，それらのファイルへアクセスできなくなって，アップグレードの結果が正しくなかったり不完全になったりする可能性があります。また，アップグレードがエラーなしで完了しても，本来の場所に存在すべきファイルが存在しないということもありえます。

システムをアップグレードする前に，そのシステムで定義されている論理名をチェックしてください (再配置されていないファイルについては対応する論理名が定義されていない場合もありますが，問題はありません)。表 4-2 「論理名と，登録ファイルの場所および名前との関係」に，論理ファイル名と，それが指し示す場所およびファイル名との対応関係を示します。指し示す場所やファイル名がこの表と一致していない論理名が見つかった場合は，そのファイルをデフォルトの場所と名前に戻してください。システムがシステム・ディスク以外の場所にあるファイルを参照しないようにするには，関連付けられている論理名を削除するか (DCL の DEASSIGN/SYSTEM/EXEC コマンドを使用)，またはオペレーティング・システムをシャットダウンして，オペレーティング・システムのメディアからリブートします。アップグレードが完了した後でオペレーティング・システムをブートする前に OpenVMS オペレーティング・システムのメニューにある DCL オプション (8) を使用すれば，システム・ディスクへ移動したファイルを，システム・ディスク以外の元の場所に戻すことができます。




	注意: 表 4-2 「論理名と，登録ファイルの場所および名前との関係」に記載されている，SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATA や SYS$LIBRARY:VMS$PASSWORD_POLICY.EXE などの一部のファイルは，構成によってはシステムに存在しないことがあります。これらのファイルについては，『OpenVMS システム・セキュリティ・ガイド』を参照してください。

表 4-2 論理名と，登録ファイルの場所および名前との関係

論理名	場所とファイル名
LAN$NODE_DATABASE	SYS$SYSTEM:LAN$NODE_DATABASE.DAT
LMF$LICENSE	SYS$SYSTEM:LMF$LICENSE.LDB
NETNODE_REMOTE	SYS$SYSTEM:NETNODE_REMOTE.DAT
NETNODE_UPDATE	SYS$MANAGER:NETNODE_UPDATE.COM
NETOBJECT	SYS$SYSTEM:NETOBJECT.DAT
NETPROXY	SYS$SYSTEM:NETPROXY.DAT
NET$PROXY	SYS$SYSTEM:NET$PROXY.DAT
RIGHTSLIST	SYS$SYSTEM:RIGHTSLIST.DAT
SYSUAF	SYS$SYSTEM:SYSUAF.DAT
SYSUAFALT	SYS$SYSTEM:SYSUAFALT.DAT
SYSALF	SYS$SYSTEM:SYSALF.DAT
VMSMAIL_PROFILE	SYS$SYSTEM:VMSMAIL_PROFILE.DATA
VMS$AUDIT_SERVER	SYS$MANAGER:VMS$AUDIT_SERVER.DAT
VMS$OBJECTS	SYS$SYSTEM:VMS$OBJECTS.DAT
VMS$PASSWORD_DICTIONARY	SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA
VMS$PASSWORD_HISTORY	SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATA
VMS$PASSWORD_POLICY	SYS$LIBRARY:VMS$PASSWORD_POLICY.EXE

4.7.6.2 AGEN$INCLUDE ファイル

追加パラメータの設定が定義されているファイルを AGEN$INCLUDE 機能で SYS$SYSTEM:MODPARAMS.DAT にインクルードしている場合は，そのインクルード・ファイルがシステム・ディスクに存在しているかどうかをチェックし，存在していなければ，アップグレードの前に次の手順を実行します。

それらのファイルをシステム・ディスクへ移動します。
AGEN$INCLUDE のエントリを修正して，移動したファイルの新しい場所を反映させます。スタートアップ・プロシージャが正常に動作するようにするには，これらのエントリで，SYS$STARTUP:SYLOGICALS.COM (または，通常の起動プロシージャで使用するその他の場所) に定義してある論理名を使用しないでください。アップグレードを行うために OpenVMS オペレーティング・システムのメディアからブートしたシステムでは，通常の起動プロシージャが実行されません。そのため，これらの論理名を使用していると，アップグレードのときに実際のファイルを見つけることができません。また，アップグレードしたシステムを最初にブートする際も事情は同じです。この場合も，特殊なスタートアップ・プロシージャが使用されます。

移動したファイルは，アップグレードが完了した後で元の場所に戻すことができます。元の場所へ戻したら，必ず SYS$SYSTEM:MODPARAMS.DAT 内の AGEN$INCLUDE エントリを再設定してください。

4.7.7 システム・パラメータの検証

システム・パラメータを検証 (および必要に応じて変更) します。システム・パラメータの検証と変更については，『OpenVMS システム管理者マニュアル (下巻)』を参照してください。アップグレードが始まると，AUTOGEN はパラメータの最初の値をデフォルトに基づいて生成します。しかし GETDATA フェーズに入ると，AUTOGEN はそのパラメータの値を, SYS$SYSTEM:MODPARAMS.DAT に格納されているエントリに基づいて変更します。また，AUTOGEN は AGEN$FEEDBACK.DAT ファイルに格納されているフィードバック情報を分析して，そのデータが正しければ，関連するパラメータの値をそれに応じて調整します (AUTOGEN は，システムが起動されてから 24 時間以上経過していて，フィードバックの日からまだ 30 日経過していなければ，そのデータを正しいと見なします)。フィードバック・データが最新になるようにするには，4.8 項「新しい FEEDBACK.DAT ファイルの用意」の手順に従ってください。

重要: 変更しても SYS$SYSTEM:MODPARAMS.DAT ファイルに入れておかなかったシステム・パラメータは，アップグレードですべて失われてしまいます。システム・パラメータの変更を保持するには，変更したパラメータの名前とその変更後の値を，SYS$SYSTEM:MODPARAMS.DAT に入れておきます。アップグレードの後で AUTOGEN が実行されると，その SYS$SYSTEM:MODPARAMS.DAT 内の値が使用されます。

たとえば，GBLPAGES の現在の値 30000 をそれより 128 ページ大きい値に変更したときは，SYS$SYSTEM:MODPARAMS.DAT に次の行を追加します。

MIN_GBLPAGES=30128  !Increased by 128 by PLM for product z 12/12/04

AUTOGEN は，計算された GBLPAGES の値をこの MIN_ の値 (30128) と比較します。計算された値が指定された MIN_ の値より小さいと，AUTOGEN は GBLPAGES の値を MIN_ の値だけ増やします。 AUTOGEN では実行のたびに同様の比較を繰り返して GBLPAGES の値を調整します。しかし，その値が MIN_GBLPAGES で定義されている最小値より小さくなることはありません。

重要:

システム・パラメータの設定を変更する場合は，以下の点に注意してください。

特別な理由がない限り，システム・パラメータは，AUTOGEN に調整させてください。パラメータの値を明示的に設定することも可能ですが (例: GBLPAGES=value)，そのような設定は AUTOGEN より優先されるので，AUTOGEN で実際の使用状況に基づいた最適値を設定しても無効になる可能性があります。
MIN_parameter (MIN_GBLPAGES など) を可能な限り使用して，AUTOGEN によるパラメータ値の調整に下限を設定してください。AUTOGEN では，必要に応じて設定値を増やします。また，関連するパラメータが明示的に設定されていなければ，その値も調整します (そのようなパラメータについては，AGEN$PARAMS.REPORT ファイルにその情報が出力されます)。パラメータの上限値が分かっている場合は，MAX_parameter を使用してその値を設定します。
数値は，コンマなしの整数で入力してください。たとえば，10,000 ではなく 10000 と入力します。英字は，大文字または小文字のどちらで入力してもかまいません。

MODPARAMS.DAT ファイルには，値を変更したユーザ，変更日，および変更理由を示すコメントを含めることをお勧めします。感嘆符 (!) はコメントの開始を表します。感嘆符は，行内のどの位置でも使用できます。次に，これらの注意点を反映した設定変更の例を示します。

! the following changes made by K.Newcomb on 9/20/03
!
SWAPFILE=0                    ! don’t re-size the SWAPFILE on AUTOGEN runs
MIN_gblsections=750           ! required for DECwindows MOTIF
MIN_NPAGEDYN=2750000          ! set npagedyn to a min of 2.75 million

AUTOGEN を推奨内容に合わせて使用する方法についての詳細は，7.24 項「AUTOGEN によるシステムの調整」を参照してください。

アップグレードを以前実施したシステムには，そのときに新しく生成した SYS$SYSTEM:MODPARAMS.DAT ファイルが存在します。このファイルにはコメントが含まれています。また，アップグレード中に生成されたエントリが重複している可能性もあります。そのため，同じシステムを再度アップグレードすると，SYS$SYSTEM:MODPARAMS.DAT が必要以上に大きくなって，内容も分かりにくくなります。したがって，アップグレードを再実行する場合は，その前に SYS$SYSTEM:MODPARAMS.DAT を編集して，内容を整理するようお勧めします。




	注意: クラスタ・システム・ディスクでは，各ルートの SYS$SYSROOT:[SYSEXE] に MODPARAMS.DAT ファイルが存在します。したがって，MODPARAMS.DAT の編集は，ルートごとに行う必要があります。

4.8 新しい FEEDBACK.DAT ファイルの用意

システムをアップグレードする前に，新しい AGEN$FEEDBACK.DAT ファイルを用意するようお勧めします。このファイルは SYS$SPECIFIC:[SYSEXE] の中，つまり，[SYSx.SYSEXE] (x はルートを表す値で，たとえば SYS0，SYS1 など) にあります。OpenVMS Cluster システムでは，各ノードの SYS$SPECIFIC ディレクトリにこのファイルがあります。アップグレードした後にシステム (またはクラスタ内の各システム) をリブートすると，AUTOGEN が実行されます。AUTOGEN では，新しい AGEN$FEEDBACK.DAT ファイルが存在するとそれを使用し，そのファイル内のデータに基づいて，実際のアプリケーションやワークロードを反映した値をシステム・パラメータに設定します。




	注意: 新しい AGEN$FEEDBACK.DAT ファイルが存在しないと，システム・パラメータに設定する値が AUTOGEN で計算されます。しかし，AUTOGEN で計算した値は，システムのニーズに合っていない可能性があります。そのような場合は，レイヤード・プロダクトがすべて起動するまで，AUTOGEN の実行とリブートを繰り返さなければならないことがあります。また場合によっては，MODPARAMS.DAT へエントリを追加することが必要になることもあります。新しい AGEN$FEEDBACK.DAT ファイルが存在すれば，そのような事態を避けることができます。

システムに AGEN$FEEDBACK.DAT ファイルが存在しない場合は，システムが通常のワークロードで動作しているときにそのファイルを作成するようお勧めします。ただしデータの信頼性を高めるために，このファイルは 24 時間以上動作しているシステムで 30 日以内に作成してください。次のコマンドを実行します。

$ RUN SYS$SYSTEM:AGEN$FEEDBACK.EXE

このコマンドは処理が瞬時に行われるので，システムの性能に影響を与えることはありません。

なお，SYS$SYSTEM:SHUTDOWN.COM プロシージャを実行する際に SAVE_FEEDBACK オプションを指定することもできますが，取得したデータにシステムの通常のワークロードが十分に反映されている保証はありません。




	重要: 実行モード・パラメータ (FEEDBACK，NOFEEDBACK，または CHECK_FEEDBACK) を指定しないで AUTOGEN を実行した場合は，計算にフィードバック情報が使用されます。ただし，フィードバック情報がまだ 24 時間以上連続動作していないシステムから得られたものであったり，1 カ月以上前に得られたものであったりした場合は，AUTOGEN から，フィードバック・データに問題がある可能性を知らせる警告が AGEN$PARAMS.REPORT ファイルに出力されます。フィードバックの信頼性が十分でないと，AUTOGEN によって設定されたパラメータの精度が著しく低下するおそれがあります。 FEEDBACK を指定すると，AUTOGEN ではデータの信頼性に関係なく，常にフィードバック・データを使用します。また，NOFEEDBACK を指定すると，データの信頼性に関係なく，フィードバックをいっさい使用しません。最終フェーズとして SETPARAMS，SHUTDOWN，または REBOOT を指定すると，AUTOGEN では SETPARAMS フェーズまで進んで，システム・パラメータに計算した値を設定します。 CHECK_FEEDBACK を指定すると，AUTOGEN ではフィードバック・データの妥当性をチェックします。その結果，妥当性が低いと判定すると，AUTOGEN ではフィードバックを無視してパラメータの値を計算します。その場合，AUTOGEN の実行は TESTFILES フェーズで停止し，パラメータの値が変更されていないことを知らせる警告が表示されます。この警告が表示されたら，その内容に目を通し，計算された値が妥当かどうかを判断してください。そのまま使用する場合は AUTOGEN SETPARAMS を実行します。妥当でないと判断した場合は，適切なフィードバック・データを用意して AUTOGEN を再実行します。

4.9 シャドウイング環境

シャドウ・システム・ディスクにアップグレード対象のオペレーティング・システムがあると，そのままではアップグレードできません (アップグレードを試みても失敗します)。アップグレードするには，システム・ディスクのシャドウイングを前もって無効にするとともに，他の前処理も行う必要があります。

シャドウイングを無効にしたターゲット・ディスクは，いくつかの方法で作成できます。ここでは，マルチ・メンバ・シャドウ・セットから既存のシャドウ・システム・ディスクを 1 つ選び，そのディスクのシャドウイングを無効にして，アップグレードのターゲット・ディスクとして使用する方法を説明します。

比較的規模の大きな構成で，しかもそのディスクへ物理的にアクセスできるという環境では，シャドウ・システム・ディスクのコピーを作成して，それをターゲット・ディスクとして使用することもできます。シャドウイングのコマンドまたは BACKUP コマンドを使用してコピーを作成する方法と，ボリューム・シャドウイングを無効にする方法については，『Volume Shadowing for OpenVMS 説明書』を参照してください。

4.9.1 ブート・デバイスの設定

アップグレードを行う場合は，システムがアップグレード対象のディスクからデフォルトでブートするように設定しておく必要があります。 OpenVMS Alpha システムでこの設定を行うには，コンソール・コマンドの SHOW BOOTDEF_DEV と SET BOOTDEF_DEV を使用します (詳細は，付録 A 「OpenVMS Alpha システムのブートとシャットダウン」を参照してください)。

OpenVMS Integrity システムの場合は，OpenVMS Integrity Boot Manager ユーティリティ (SYS$MANAGER:BOOT_OPTIONS.COM) を使用して，マルチ・メンバ・シャドウ・セット内のシャドウ・システム・ディスクを EFI のブート・デバイス・リストとダンプ・デバイス・リストに追加しておくことをお勧めします。またその場合に必ずすべてのメンバを，両方のリストに追加してください。ブート・オプションの設定と，このユーティリティの使用方法についての詳細は，B.5.2 項「システム・ディスクのブート・オプションの設定」を参照してください。

4.9.2 シャドウイングを無効にしたターゲット・ディスクの作成

既存のシャドウ・システム・ディスクを 1 つ選んで，シャドウイングを無効にしたディスクにするには，以下の手順を実行します。




	重要: アップグレードするボリュームを MOUNT/OVERRIDE=SHADOW_MEMBERSHIP コマンドでマウントしても，それだけであると，ボリューム・シャドウイングによって，アップグレードしたディスクがアップグレード前のボリューム情報で上書きされる可能性があります。

シャドウ・システム・ディスクからブートしたすべてのシステムをシャットダウンします。
ターゲット・ディスクとして選択したシステム・ディスクで会話型ブートを実行します (OpenVMS Alpha システムの場合はA.1.4 項「会話型ブート」を参照してください。OpenVMS Integrity システムの場合は B.6.8 項「対話型ブートの実行」を参照してください)。 OpenVMS Alpha システムでは，たとえば次のコマンドを実行します。
>>> BOOT -FLAGS 0,1 DKA100
OpenVMS Integrity システムでは，EFI Shell のプロンプトに対して次のコマンドを実行します。fsn: には，システム・ディスクに関連付けられているデバイス (fs1: など) を指定します。
Shell> fsn:＼efi＼vms＼vms_loader.efi -flags 0,1
SYSBOOT> プロンプトに対して次のコマンドを実行し，システム・ディスクのボリューム・シャドウイングを無効にします。
SYSBOOT> SET SHADOW_SYS_DISK 0
CONTINUE コマンドを実行して，ブート・プロシージャを再開します。次に，その例を示します。
SYSBOOT> CONTINUE
ブートが完了したら，4.11 項「アップグレード前の作業の終了」へ進みます。

以上の手順が完了すれば，シャドウイングを無効にしたシステム・ディスクが作成されて，アップグレードに使用することができます。

4.10 システム・ディスクのバックアップ

システム・ディスクは必ずバックアップすることを強くお勧めします。また可能な限り，バックアップ・コピーもアップグレードしておくことをお勧めします。バックアップをとっておけば，問題が発生したときにそのバックアップをシステム・ディスクとして使用することで，運用を継続することができます。




	注意: OpenVMS のエンジニアリング・グループでは，アップグレードの前にシステム・ディスクのバックアップをとっておかなかったために，アップグレードに失敗したシステム・ディスクの回復が困難，高くつく，あるいは不可能になったケースを何度も経験しています。アップグレードの途中でハードウェアやソフトウェアのさまざまな障害または電源障害などが発生して，システム・ディスクが使用できなくなることがあります。そのような場合を想定した唯一の回復方法は，おそらくバックアップ・コピーだけです。バックアップを作成するためのわずかな手間が，コスト面では非常に大きな意味を持ちます。

システム・ディスクをバックアップするには，以下の手順を実行します。

システムをシャットダウンします (OpenVMS Alpha システムの場合はA.3.2 項「システムのシャットダウン」を，また OpenVMS Integrity システムの場合はB.7.2 項「システムのシャットダウン」を参照してください)。
オペレーティング・システムのメディアをブートします (OpenVMS Integrity の場合はB.6 項「ブート操作」の説明に，また OpenVMS Alpha の場合はA.1 項「ブート操作」の説明に従います)。
オペレーティング・システムのメニューでオプション 8 を選択し，DCL 環境に入ります。
システム・デバイスと，バックアップ・コピーの作成先となるターゲット・デバイスをマウントします (テープにバックアップする場合は，次の手順へ進んでください)。たとえば，システム・ディスクを DKA0: に，またターゲット・デバイスを DKA100: にそれぞれマウントする場合は，次のコマンドを使用します。この例では /OVERRIDE 修飾子を指定しています。そのため，ボリューム・ラベルを入力しなくてもシステム・ディスクをマウントできます。BACKUP /IMAGE コマンドを使用する場合は，/FOREIGN 修飾子を指定してターゲット・ディスクをマウントしておく必要があります。
$$$ MOUNT /OVERRIDE=IDENTIFICATION DKA0: $$$ MOUNT /FOREIGN DKA100:
システム・ディスクを磁気テープにバックアップする場合は，次のコマンドを実行します。MTA0: には磁気テープ・ドライブを，また label にはボリューム・ラベルをそれぞれ指定します。BACKUP コマンドを実行すると，テープが自動的にマウントされて，バックアップが開始されます。
$$$ INITIALIZE MTA0: label $$$ MOUNT /OVERRIDE=IDENTIFICATION DKA0: $$$ BACKUP /IMAGE /LOG DKA0: MTA0:label.BCK
磁気テープ・ドライブ以外のデバイスにバックアップする場合は，BACKUP コマンドを実行します。たとえば，システム・ディスクを DKA0: に，またターゲット・ディスクを DKA100: にそれぞれマウントしている場合は，次のコマンドを実行します (コロン記号は省略しないでください)。
$$$ BACKUP /IMAGE /LOG DKA0: DKA100:
この Backup ユーティリティには /IMAGE 修飾子が指定されているので，システム・ディスクのコピーと同様，ブート可能なディスクが作成されます。また /LOG 修飾子が指定されているので，バックアップの処理に合わせて各セーブ・セットの仕様が順次表示されます。バックアップ・ファイルとソース・ファイルを比較して検証させる場合は，/VERIFY 修飾子を指定します。検証で不一致が見つかると，Backup ユーティリティから相違を示すエラー・メッセージが表示されます。
DCL 環境からログアウトします。
メニューからオプション 9 を選択して，システムをシャットダウンします。

オペレーティング・システムのメディアを使用しない方法やバックアップ操作などに関する詳しい説明は，付録 F 「システム・ディスクのバックアップとリストア」を参照してください。Backup ユーティリティについての詳細は，『HP OpenVMS システム管理ユーティリティ・リファレンス・マニュアル (上巻)』を参照してください。

4.11 アップグレード前の作業の終了

アップグレード前の作業を次の表に従って続けます。この表は，スタンドアロン環境でアップグレードする場合と，OpenVMS Cluster 環境でアップグレードする場合に分けてその手順を記載してあります。

条件操作

スタンドアロン・システムをアップグレードする

この章の冒頭にあるチェックリストを使って，必要な作業がすべて完了したことを確認する。
SYSTEM アカウントでログインする。
次のコマンドを実行する。
$ @SYS$SYSTEM:SHUTDOWN
システムを自動的にリブートするかどうか尋ねるプロンプトが表示されたら，N (NO) と入力する。
第6章「OpenVMS オペレーティング・システムのアップグレード」へ進んで，アップグレードを開始する。

OpenVMS Cluster システムをアップグレードする

この章の冒頭にあるチェックリストを使って，必要な作業がすべて完了したことを確認する。
第5章「OpenVMS Cluster 環境でのアップグレードの準備」へ進む。