せこい話しですが...
当社のAS/400のハードディスクは、かなり小さく、2年分のデータを持つと、もう70％を越えます。System38のころ、ディスクの使用率が70%を越えると、がくっと、性能が落ちたのですが、その先入観があるせいか、AS/400も同じような気がします。（eモデルもそうなのかなぁ？）
また、当社ではAS/400の担当者が少なく、毎日、毎月のバックアップを無人化するために、日締め後に、ライブラリー単位の保管ファイル（SAVF)を作っています。その為、特に夜間にディスク使用量がピークになります。SAVFに保管された後であれば、どんな業務も、開始出来ることが「ねらい」です。直接、テープに保管した場合、もし、掛け替えメッセージ待ちになったり、テープ違いなどで保管できなかったりすると、翌日、朝方保管作業をするために、業務（特に出荷部門）がすぐに開始できません。これをさけたいのです。SAVFに保管が完了すると、次に磁気テープにSAVSAVFDTAをします。このとき、保管内容をOUTFILEに曜日別に保管すると、後で復元するときに、順序番号などもわかり便利です。保管が完了すると、その都度、CLRSAVFをしていきますので、全ての保管が完了すると、ディスク使用率は下がっています。もし、テープのボリューム名を曜日で設定しているので、テープを間違えてマウントした場合、エラーでストップして、次の朝まで、夜間の使用率が続くことになりますので、夜間のピーク時の使用率の把握はとても大事です。
たとえば...
さて、使用率の把握は、私の場合、GO DISKTASKSのディスク管理機能を利用しています。これは、大きく分けて、「収集」と「印刷」の機能に分かれます。収集をしなくては、印刷もできません。収集は早い話、ディスクに、そのディスクの情報を保管することです。従って、もうすでに、90%を越えてから、原因を知ろうと、収集を開始するのは、危険な行為となり得ますので、気をつけてください。このレポートは便利なので、試す価値はあります。
さて、もしディスクが90%を越えた場合、どのように減らしていくのでしょうか。今までの経験から述べてみたいと思います。
ファイル
上で述べた、ディスク情報の収集結果からすると、ディスクをもっとも多く占有するオブジェクトは、データファイルです。プログラムやコマンドさらに、画面ファイルは、割合小さいオブジェクトです。また、データの移行時に、10数個の論理ファイルを消したら、一気にディスク使用率が10%から20%くらい下がったことがあります。もちろん、大量のレコードを持つ物理ファイルも大きいのは当然なのですが、大きな物理ファイルにぶら下がる、論理ファイルもその分ディスクを占有します。これを減らすためには、このファイルを参照するプログラムを調べていって、もし別の論理ファイルで実行が可能であれば、プログラム修正をして、論理ファイルを減らしたりします。これは、システムへ、機能の追加を繰り返す（無限のシステム拡張）果てに、起こりうることです。無駄な論理ファイルは、排除しましょう。
さて、物理ファイルのオブジェクトサイズが異様に大きい場合、削除レコードの欠番の相対レコード番号が多い可能性があります。これを避ける場合、
REUSEDLTの指定
定期的なRGZPFMの実施
CPYFでCMPRESS(*YES)を指定する
などがあります。削除されたレコード件数は、DSPFDで確認できます。
また、削除されていない（通常の）レコードの、件数が多い場合、以下のことを検査しましょう。
追加する一方で、整理していないログファイルではありませんか？
無駄なフィールドが多いファイルの、レコード件数が、多くありませんか？
開発時の一時ファイル（QRYなどのOUTFILE）が、残っていませんか？
ソースファイルに、無駄なメンバーがありませんか？
スプール
System38のあるリリースでは、ライブラリーQSPLの中の、巨大なファイルをみることができました。（本当は見てはだめ。DSPOBJDやDSPFDなど、いったんスプールしたものを、DSPSPLFで表示する方式のコマンドが多いため、QSPLの中のスプールデータファイルを、それらのコマンドを使って表示すると、おかしくなる場合があったらしい。それに、スプール一個がメンバー一個に対応していたので、そのメンバーを誤ってRMVすると、やばそうである。）ところが、いつの頃からか、QSPLの中のファイルはみれなくなりました。あれが使えると、直接スプールのコピーが出来ただろうに、残念なことです。
さて、SAVE(*YES)やHOLD(*YES)で、印刷されずに残っているスプールは結構多いようです。ユーザーの要望によるものや、こちらの都合でHOLDしているものもあります。場合によっては、長時間かかるので注意して欲しのですが、試しに、WRKOUTQ ＊ＡｌｌやWRKSPLF *ALLをしてみましょう。いやに、無駄な（一年前のスプールとか）スプールの嵐になっていないでしょうか。印刷すると紙がもったいないので、HOLDしてしまうユーザーもいます。印刷しても、後で確認出来るからと、書き出し後保管のまま、データ検索用に残しているユーザーもいます。ページも1000ページを越えるとかなりディスクを圧迫しています。
どのように、スプールを整理していくのでしょうか。スプールの種類によって考えてみると、
QPJOBLOG、QPPGMDMP,QPSRVDMPは、GO ASSISTのなかのクリーンアップの設定で自動的に削除できます。
SAVE(*YES)やHOLD(*YES）、プリンターに接続されないOUTQへの指定変更、こういったロジックを持つプログラムを探しだし、本当にこれが必要か、また、その理由を聞き出します。理由がなければ、印刷後消します。（ディスクの上に残さない）。
スプールの作成日から、そのスプールの「年齢」を割り出し、お年寄りの場合は、削除する。APIを利用して、「ユーザー名」「スプール名」「有効最古日付」を渡すと、条件から不要と考えられるものを、削除するツールや、実行日から-180日を割り出し、それ以前にオープンされたスプールを固定的に「OLDSPLOUTQ」に移したりするツール、を持っています。特に、OUTQを別のものに移しておき、回覧の後、CLROUTQをするのは、なかなか良いアイデアと思っています。
問題は、「これは消さないで」というスプールの扱いなのだが、自分は、スプールをディスクに保管するツールを持っています。これを利用して、オンラインで保管の後、オフライン（磁気テープ）で保管する。これで、スプールを消してしまっても、復元が可能となる。但し、このツールは、ディスクを大きく占有するので、オフラインバックアップをしたら、消してしまった方がいいと思います。
また、スプールに関して、コマンドRCLSPLSTGがあるので、各自調べてください。自分は、WRKJOBSCDEに入れて、定期的に実行しています。（初めてする場合は、注意して欲しい。時間がかかることがある。）
その他の考慮事項
如何に、クリーンアップの一部の機能をマニュアルから引用します。良く読んで下さい。この機能はとても便利です。しかしながら、何をしているのかよく分かっていない人もいます。（恥ずかしながら、この機能でPTFの一時ファイルが消えることは知りませんでした。）ここでは、クリーンアップ機能の中核となる「SYSLOG」の解説の引用です。
AS/400 CL(制御言語)解説書 バージョン3 3.1.111 CHGCLNUP(終結処置変更)コマンド
SYSLOG
システム・ジャーナル・レシーバー、活動記録ログ・ファイル、問題記録簿ファイルと問題記録簿項目、警報データベース項目、およびプログラム一時修正の終結処置を行うことを指定します。
ジャーナル・レシーバー:
次のシステム・ジャーナルの1つで使用されていて、このパラメーターに指定した日数を越えているジャーナル・レシーバーの終結処置を行うことを指定します。
QAOSDIAJRN |
DIAファイルのジャーナル |
QDSNX |
DSNXログのジャーナル |
QSNADS |
SNADSファイルのジャーナル |
QSXJRN |
問題データベースのジャーナル |
QPFRADJ |
パフォーマンス調整データのジャーナル |
QACGJRN |
ジョブ会計データ用のジャーナル |
QX400 |
OSIメッセージ・サービスOS/400用 |
QCQJMJRN |
分散管理OS/400用のジャーナル |
QO1JRN |
適用業務可動プログラムOFCファイルのジャーナル |
ADJRNL0 |
適用業務プログラム・ドライバー・ファイルのジャーナル |
QSNMP |
SNMPのジャーナル |
QLYJRN |
適用業務開発管理プログラム・トランザクションのジャーナル |
QLYPRJLOG |
プロジェクト・ログのジャーナル |
QMAJRN |
作業順序要求のジャーナル |
注: ジョブ会計のジャーナル・レシーバー (QACGJRN)
は、操作援助機能によって該当のジャーナルを作成した場合にのみ終結処置が行われます。
活動記録ファイル:
次の両方の条件を満たす活動記録ファイルが削除されます。
1.
このパラメーターに指定した日数を越えている活動記録ファイル
2. QSYS/QHST*という名前のファイル
問題ログ・ファイルおよび問題ログ項目:
このパラメーターに指定した日数を越えているすべての問題ログ項目が削除されます。問題ログ項目を削除するために問題削除(DLTPRB)コマンドが実行されます。DLTPRBコマンドの実行時に、このパラメーターに指定した日数が、
DLTPRB コマンドの DAYSパラメーターで使用されます。省略時値は、DLTPRBコマンドの他のすべてのパラメーターで使用されます。このコマンドの実行方法の詳細については、DLTPRBコマンドの説明を参照してください。
注: このパラメーターに指定した日数が、システム値QPRBHLDITV(問題ログ保留間隔)に指定した日数に満たない場合は、問題ログの終結処置に、
QPRBHLDITVの値が代りに使用されます。
削除する問題ログ項目に加えて、次の問題ログ・ファイルが再編成されます。
注: これらのファイルはすべてライブラリーQUSRSYSに入っています。
QASXCALL QASXFRU QASXNOTE
QASXPROB QASXPTF QASXYMP
QASXEVT
警報データベース項目:
このパラメーターに指定した日数を越えているすべての警報データベース項目が削除されます。警報データベース項目を削除するために、警報削除(DLTALR)コマンドが実行されます。DLTALRコマンドの実行時に、このパラメーターに指定した日数が、DLTALRコマンドのDAYSパラメーターで使用されます。省略時値は、DLTALRコマンドの他のすべてのパラメーターで使用されます。このコマンドの実行方法の詳細については、DLTALRコマンドの説明を参照してください。
削除する警報データベース項目に加えて、ファイルQUSRSYS/QAALERTが再編成されます。
プログラム一時修正:
次のPTFが削除されます。
以下に挙げる名前の一時オブジェクト:
- QPZA000000からQPZA999999
- QPZR000000からQPZR999999
- QPZI000000からQPZI999999
- QSCA000000からQSCA999999
- QSCR000000からQSCR999999
PTFと同時に提供されている出口プログラム
QUSRSYSの中の物理ファイル
QAPZPTF
QAPZREQ
QAPZSYM
ライブラリーQSMUがシステム上に存在している場合は、現行リリースのPTFだけが終結処置の対象となります。QSMUライブラリーがシステム上に存在していない場合は、現行のリリースおよび以前のすべてのリリースのPTFが終結処置の対象となります。
1999/1/30 | 
