a.5. 2000年問題 其の伍

また、2000年問題の解決準備に関して,

使われていないプログラムについて

• 未使用のプログラムオブジェクトを消すだけで、ソースメンバーは、先頭に＠をつけて、リネームする。
  作業が完了してから、PDMで＠＊として出てくるソースメンバーは、後で一括して、バックアップ・アンド・リムーブする。
  
• 但し、一時使用などで、野谷に埋もれさすも惜しいし、2000年対象にするほどでもないプログラムは、別のソースファイルに移し（このソースは消さない）、プログラムは削除する。

ところで、プログラムだけ調べて、未使用プログラムを削除すると、最後に、一切参照されない、ファイルや画面ファイルが残るはずですよね。
たとえば、中間ファイルを作成して、そこからレポートを出すとき、中間ファイルを作成するプログラムやレポーターを消すと、その中間ファイルのみ残ってしまいます。

そこで、後で、DSPPGMREFで調べます。孤児の捜索です。これをしないと、ファイルや画面ファイルだけ残って、2000年作業の工数見積もりが狂います。

それから、たまに中間ファイルを作成するプログラムがQRYのこともあります。（自分が作ったんじゃ無い！）。これは困った。QRYで作成されたファイルの中に、記述として「MADE BY QRY」なんてフラグがあると、助かるのにな。多分無いと思う。も少し考えなくては。

使われていないプログラムの洗い出しの方法

担当者に聞く

そりゃそうだが、自分が担当者になることが多い。そこで、

具体的には、DSPOBJD、DSPPGMREF,自作の汎用メニューのメニュー参照機能、を使います。

抽出条件を、昨年10月以前に作成されたプログラムで、０から1O回しか参照されていないものとして、QRYでレポート作成しました。作成ユーザー別に改ページさせて、配れるようにしました。これで、担当者は使われていないプログラムに気づくはずです。ああ、簡単だな、くわははは、「楽勝！」

の、はずだったんです...

ところが、出てきたプログラムが、思ったより多くて（300個くらい）、さらに8割くらい作成ユーザーが自分になっています。

ナンデスト...？

そして、去年の一月に取引先マスター変更により、レイアウト変更の一斉リコンパイルをした事実に、遅まきながら気づきました。（というより、思い出しました。） くっそ！。

仕方なく、自分のものだけ調べながら、うなる。唸る。ウナル。うーーーーん。これは俺んじゃない。えええ、これ使ってないの？うそ！みたいなこと始めました。悲しい。

何かの役に立つかもしれないので、上のやり方で、出てくる、「おお、そうか」と思ったプログラムの内訳を掲げます。

そもそも具体的に、何から始めるのか

すべての、準備が終わったら、実際問題として何から始めるんでしょう。やっぱ、取りあえずファイルを一斉に変更するんでしょうかね。