|
ここでご紹介するのは、AS/400のOSの移行時（またはMES）の計画の作り方です。いままで、たくさんの移行に携わりましたが、失敗あり、成功ありと、教訓めいたものがたくさんあります。まあ、後で自分もこのページのお世話になるかもしれません。（忘れがち）。また、追加や変更も有るかもしれません。※あくまで、一人で行う場合を想定しています。
無ければ、移行は危険が伴うことを覚悟しましょう。本当に、すぐさま、移行すべきか、よく考えましょう。
さあ、バックアップと思ったら、空きテープが無かったことがありました。それから、予め、初期化しておくこと。結構、ロード、アンロードに、時間がかかる媒体もあります。
RTVCFGSRCで、全装置記述をソースに落とし、印刷して、さらにバックアップしておくこと。
これは重要です。とにかく、今動いている構成が、後で復元できる手段は、思いつく限り、たくさん用意すること。また、印刷環境が出来なければ、「後で印刷」は出来ないかもしれません。印刷しておきましょう。
夜中に開始して、一度帰り、朝に続けるとか。このとき、時期により、作業時間に差が出るはずです。たとえば1月と12月では、12月の方がトランザクションが多いのは当たり前です。また、SAVSYSは移行日直前でなくても、ゆとりのある日に取っておくといいでしょう。NONSYSは、出来れば、アクセスパスも同時に取りましょう。フロム・スクラッチもあり得ますので。ライブラリーの全リストを（含まれるオブジェクトを含めるのは紙の無駄。）出しておくと、今どの辺りの作業中か分かるかもしれませんね。
失敗の確率の高い移行では、必ず、2セットのフルバックアップを取ります。
媒体エラーの対策です。「失敗の高い」とは、MESなどのハードの初期不良によるトラブル（事故）などです。
 追記 1998/6/27
保管は、CLPを作成して、
- INZTAP
- SAVSYS
- INZTAP（SAVSYSとテープを分ける場合）
- SAVLIB *NONSYS ACCPTH(*YES) or (*NO)
- CPYIGCTBL（外字がある場合）
- SAVDLO（フォルダーの内容）
- SAV（ディレクトリーの保管）
などをまとめます。（保管に関するマニュアルを必ず、事前に読むこと）
また、時間的に余裕があるならば、RCLSTGも入れておくといいかもしれません。但し、構成によっては、十数時間かかる場合もあるので、連休などに事前に単独で実施してみましょう。これを、途中で強制終了するくらい、ばかげたことはありませんからね。
参考
AS/400
アドバンスト・シリーズ 基本バックアップおよび回復の手引き バージョン
3 資料番号 SC88-5460-00
| ライセンス内部コード |
SAVSYS |
SAVSYS |
| QSYS の OS/400 オブジェクト |
| ユーザー・プロファイル |
SAVSECDTA |
| 使用認可 |
| 構成オブジェクト |
SAVCFG |
| OS/400 光ライブラリー、QHLPSYS
QUSRTOOL |
SAVLIB *IBM |
SAVLIB *NONSYS |
| ライセンス・プログラムライブラリーQRPG
QCBL Qxxxxx |
| ユーザー・データ QGPL QUSRSYS QS36F
#LIBRARYがあるIBMライブラリー |
SAVLIB *ALLUSR |
| ユーザー・ライブラリーLIBA LIBB
LIBC LIBxxx |
| 文書およびフォルダー |
SAVDLO |
| 配布オブジェクト |
| ディレクトリー内のオブジェクト
追記：掲示板のゲストブックにコメントがありました。KAISERさんありがとう。
「SAV DEV('QSYS.LIB/TAPxx.DEVD') OBJ(('*') (QSYS.LIB *OMIT) (QDLS *OMIT)) を取って置いて ください。これをとり忘れてクライアントアクセスが動かなくなったことがあります。」 |
SAV |
訪問者の方から、外字の保管を忘れて、すべて消失し、全部作成したことがあるとの、悲しい情報を頂きました。CPYIGCTBLをしていなかったのだそうです。
注意：ただし、SAVSYSをしていれば、フォントテーブルは保管されています。
AS/400
アドバンスト・シリーズ データ管理 バージョン 3 資料番号
SC88-5494-00
システム保管 (SAVSYS) コマンドを使用すると DBCS
フォント・テーブルも保管されるので、通常のシステム・バックアップを行う場合には
CPYIGCTBL コマンドを使用する必要はありません。 |
必ず、バックアップの時間をノートに書き留めること。
ジョブログなどで、掛け替えメッセージの時間も分かります。SAVSYSの時間とか、SAVLIB *NONSYSとか、SAVとか、CPYIGCTBLやSAVDLOなどの、時間も書き留めます。絶対に、後で役立つときが来ます。単に、現在の時刻を書き留めるだけです。テープの掛け替えのメッセージが来た時刻なども書きます。次回のバックアップで、スケジュールを立てるのに、必ず役立ちます。
事前に、下記の書類を良く読み、必要事項はマーカーをつける。また、必要のないところは、無視できるようにする。
付箋をつけるなどしておきましょう。ページを破り捨ててはいけません。途中で、インストール方法を変えるて、読むべき場所が変わることも有ります。
- 移行のマニュアル
- 移行時の注意事項などのレター
- PTFの適用上の注意（前提PTFの有無や、適用方法に指示があるか）
- そのほか、念のため、ぺらぺらの一枚の紙も読んでおく。案外重要なことが出てるかも。
はっきり言えば、指さし確認をするのです。必ず、事前にしましょう。配布ミスも有るのです。さあ、移行だ、というときに気づいても、手遅れです。言語コードも問題ないかよく見ましょう。
予め、当日の作業内容を、簡潔に、大きな文字で、箇条書きにまとめる。
1つのステップから1つのステップへの間隔が長いので、まのびして、次にするべき事を忘れてしまうのです。自分へのメッセージです。
AS/400一台ならば＋１日、2台ならば＋2日くらいです。従って、連休などが狙い目です。予備日は必ず持つべきです。不意のトラブルへの対応に追われることも十分有るのです。
社内への、事前（一ヶ月くらい前から騒ぐこと。）の回覧。
これを、遅らせると「もう決まった仕事がその日にあるのです」と、ごり押しされて、すべての作業の見直しする可能性もあります。また、作業中、他の社員が休出して、「えー！使えないの？！」という絶叫を聞きたくなければ、必ず出すことです。必要ならば、よく休出する人に電話で直に伝え、また、実施の一週間まえに、リマインダーを出すこと（一度出しているから、「あ、そうかぁ」と、あきらめてくれるのが、人間の心理です）。
移行後、遠隔地での作業があるのなら、テスト内容を考えて、依頼する。
制御装置のバージョンに不安があって、サインオンとか、印刷のテストをしたい場合など。端末の電源をつけたままでもかまわない。System38からAS/400への移行の時は、大阪や名古屋の営業所の人に、頼みました。何日の何時かをしっかり伝えないと、相手も困りますよ。
結局うまく行かなかったら、どうするのかを決めておく。
これは、本当に念のためです。上司または、それ以上の人にも、この事は、言っておくべきです。
移行完了後に、どんな内容の確認をするのか、決める。
事前に、よく問題のあるOSの機能をIBM SEから聞き出し、該当するものが有るのならば、テスト方法を考える。移行作業終了後は、気がゆるみ、疲れがどっと出ます。そこでテスト内容を考えるより、予め決めておきましょう。時に、通信環境は気をつけてください。
もし、CE作業があるのなら、作業時間の見積もりと、こちらでの必要な準備作業を聞き出す。
たいてい、SAVSYSや、WRKHDWPRDなどの印刷を要求されます。
外部業者が入る場合は、担当者（監督）、連絡先、作業日程、関連する他の業者や、協力すべき作業内容を聞き出す。
ケーブル施設、電源工事、室内レイアウトなど。
移行一ヶ月前から、移行日までの中期スケジュールと、関連部署、業者の洗い出し。
時間軸と、作業担当の軸があると役立つ表が出来ます。変更による修正は、適宜行うこと。OS移行作業中は、予測時間を書いておくといいでしょう。回数を重ねてくると、その予測は結構当たります。最初は、やや長めにして、「おお、前倒し」と、自分に都合よく行きましょう。この時間配分の最中に、全体的な計画のミスに気づくこともあります。
暇つぶしの雑誌や、夜間の静けさを紛らわすラジオやCDなどの準備。また、ホテルの予約も必要ならばする。
「心の平静を保つ努力」って、ところですか。直前にホテルに電話したら、予約で一杯だったこともありました。惨めな気持ちになります。
作業中は、必ず、チェック欄に現在時間を書き留めること。
これも後で、別のMESやリリースアップなどで役立つ、大事な資料となります。ほかにすること無いしね。
広いスペースを確保して、「不可侵の領域」にしましょう。不思議と、気持ちにゆとりが出ます。
作業終了したら、必ず、動作確認と、バックアップです。
移行しても、動かなければ、非難ごうごうです。これに、一日かけてもいいでしょう。
どうしようもないのならば、リリースダウンなどの対策を考えます。
この決断は今までしたこと有りませんが、いつも計画上は必ず入れています。
最後に
結局は、「忍耐」と「集中力」と「緊張」と「緩和」を、どのように自分なりにコントロールするかです。どんな場合でも、「もし、このステップが失敗したら、どうすべきか」を、しぶとく考えておくのが、コツです。これが、先見の明のある計画です。途中で、少しでも変わると、そこからずーっと、アドリブでは、「計画」ではありません。ただの「理想」です。もし、失敗したら、必ず、それをメモすること。次には、同じミスをしないようにするのです。いろいろ場合を想定しましょう。電気は？まさか電気の法定点検日ではないだろうな、とか、社内のクーラーは何時に切れるのかなど、総務に確認したりもしました。これだけやっても、うまくいかないのなら、もう、笑って「やられたー」と叫んで、すっきりしましょう（？）
1998/6/11 | 
