|
皆さんは、画面のメニューをどうしてますか。よく教書ではCLP使ったり、や最近ではMenu画面がサポートされました。でも、どちらにしても、メニューの項目を増やすときRecompile(Delete
& Generate)をせねばならず、不便です。
自分はそれ専用のプログラムを作成しています。
メニューって、結局は、画面に出ている項目の横の数字を入力して、その数字で何を実行すべきかを判定して、それを実行するだけですよね。
そこで、以下のファイルを作成します
| メニュー見出しファイル |
メニューIDをキーにメニュー画面のタイトルとか、そのメニューにアクセスする前の実行IDや、そのメニューから抜けるときの実行IDのデータ。伝票で言えば、かがみにあたる部分。 |
| メニュー明細ファイル |
メニューIDの下に登録された、個別のメニュー項目（「XXXファイルの登録」など）と、明細単位に以下の実行IDの内容を実行できるように、その実行IDを登録する。伝票で言えば明細に当たる部分。 |
| 機能キーファイル |
メニューの下に出す、「F3=終了」といった内容を登録します。Fの何番かを登録して、それに関連するコマンドを登録しますが、予約語として、*ENDならメニュー終了、*PREVならネストしたメニューの一個のメニューに戻るとか、を指定できるようにします。もちろん予約語以外は、QCMDEXCで実行できるようにします。例えば、F5でWRKSPLFの実行など。 |
| 実行ID見出しファイル |
実行ID版の見出しファイルで、実行項目のテキスト登録が主なねらいです。これがないと、メニュー明細登録で、いちいち「XXXファイル登録」などと入力せねばなりません。ここで一回登録すれば、省略値のテキストにするので、メニュー登録が楽。また、実行IDは11桁がお勧めです。 |
| 実行ID明細ファイル |
実際に実行する項目を登録。たいてい「CALL XXXXXX」となる。QCMDEXCでOVRDBFやOVRPRTFもできるんですよ。 |
| 実行ログファイル |
これは、なくてもいいのですが、実行した内容をユーザー名や実行日時とともに記録。メニュー明細にTRACE=L(LOG0またはB(BOTH)とあるもののみ対象。全部のメニュー対象ではディスクがもったいない。また、CALLまでなので、CALLで出た画面で、いきなりF3で終了しても記録上、実行したことになるので、厳密には利用価値は少ない。でも、このプログラム誰も使ってないのでは？というとき、判定材料になります。（今は、OSが最終使用履歴を管理しているので価値は更に減ってしまった。S/38のときは便利だったんです。） |
| 現在実行ファイル |
現在実行中のデータを記録（実行しているユーザ＋ジョブ名＋ジョブ番号を含む）。実行でWRITE,終了でDELETEを繰り返す。今誰が「XXX入力してるのかな」というとき便利。メニュー明細にTRACE=M(モニター）またはB(BOTH)とあるもののみ対象。WRITEとDELETEの嵐なので、実行中メニューはすべて、メニュー項目はモニターしたいもののみという限定です。定期的にRGZPFMをします。 |
| ユーザープロファイルtoメニューIDファイル |
ユーザー名から実行すべきメニューIDを判定する。自社では全員にユーザープロファイルを割り当てています。 |
のファイルを作成して、
| メニュー保守プログラム（入力、印刷） |
メニューIDの登録と印刷。 |
| メニュー実行プログラム |
実行IDの登録と印刷。 |
| ログ照会プログラム |
実行ログファイルの検索。ユーザー名から検索やMENU IDから検索。実際はあまり活用していません。 |
| 現在実行内容紹介プログラム |
現在実行中IDの照会。ジョブのキャンセル(CNLJOB)などで、メニューが途中で突然終了して、実行開始のRECORDのままだと不正確なので、APIで記録上のユーザ＋ジョブ名＋ジョブ番号が、現在活動中か判定してから、表示します。このため、表示にやや時間がかかります。 |
を作成します。
図式化すると
 ユーザプロファイル
↓
メニューID
↓
オペレータが「実行項目」選択
↓
実行ID
↓
プログラムの実行
となります。
つまり、メニュー一塊をRPGで表示して、番号が指定されたら、それに関連付けられた実行内容（たいていCALL命令）をQCMDEXCで実行するわけです。もうかれこれ、10年くらい（SYSTEM38から）このやり方ですが、新しいプログラムを作った後で、つまらないメニュープログラムの修正や作成をしないでいいので、とっても楽です。メニューのDSPFの再作成はDLTFの時点で、ユーザーが使用中では実行できません。いちいち電話して「やめて」を訴えるか、皆帰るまで待つか。そのストレスから完全に開放されました。
最初作ったときは、簡単なものでしたがバージョンアップを重ねるうち、さらに便利になっています。
- メニューはネステイングできる。（この際、メニューIDのログを配列でPUSH
& POPしています。配列なので当然、ネストレベルは限定されますが、100個くらいで,今まで問題まったくなし。もちろん配列要素以上になったらメッセージを出して、それ以上進みません。
- メニュー実行テキストのみで、実行IDがないものは、そのテキストを高輝度表示する。メニューにコメントを入れると、それが注意書きになったり、グループ別のメニューのタイトルテキストを高輝度にできる。
考慮事項
- メニューの内容を実行する部分を、CLPにするか、RPGにするかで迷いましたが、結局RPGにしました。この方が楽に開発できたからです。CLPだと、メニュー部分は、サブファイルができないので、結局メニュー表示をRPGにせざるを得ません。
- ところで、実行IDは11文字にしたのはいいアイデアだったと思います。プログラム名+1あれば使い方が広がります。（12文字でもよかったかも）同じプログラムでも、パラメータで動きが違うとき、実行IDをかえて登録するのです。ちなみに、パラメータは文字列で固定情報で登録しています。
- バリアブルにパラメータを登録するのはしていません。（&DATEは今日の日付と置き換えるなど。こんなのプログラムの中ですればいいのです。）変数を考慮すると、結構プログラム作成のときルールをあらかじめ作らないとうまくいきません。自分は中途入社で今の会社に入りましたが、どうしても過去の遺産は存在して、基幹として働いていて、変更する気にならないのです。パラメータを数字にしてるプログラムまであるのです。（普通はキャラです！）。そして「痛くもない腹をさぐる」結果になるのです。これでバグったら、やですよ。
- メッセージサブフィルを有効利用しよう。SBMJOBしたら、何も出ないより、「ジョブXXXXXが投入された」と画面最下部に出た方がいいです。
登録するとき一つのメニューIDの中に、欲張って、たくさん実行IDをだすより、ネストをうまく利用しましょう。
- 一つ前に、何を実行したかを、画面に残すと、オペレータは喜びます。よろうと思えば、サインオンからサインオフまでの履歴を表示することもできます。(自分はしてませんけど）
- 「情報システム部からのお知らせ」をどっかに出せるといいですね。
- メニューやメニュー項目の保留を可能にすると便利です。保留コードで「作成中」「修正中」「テスト中」などが出てくると、プログラム完成前に、メニューを登録できますよね。（これはやっています）。
- ユーザー環境（ライブラリーリストやOUTQなど）をファイル登録していたのですが、JOBDとダブるので止めました。OSへの反抗と取られます（冗談）。
-
多分、こういったプログラムを考えたことは、皆さんおありでしょう。でも面倒だし、アプリの開発に追われる毎日では、やる気も起きないかもしれません。でも、あれば「絶対に」便利だし、最終的には、あなた自身を楽にするものです。作ってしまいましょう!!必ずうまくいきます。便利なアイデアと実行効率最優先です。きっとすごいアイデアがぼんぼん出てきますよ！
注意事項
- このメニュー表示したら、極端に遅くなったのでは改悪です。
- このメニューのためにオープンするファイルが多すぎても困ります。TFRCTLなども検討しましょう。ODPについて勉強してください。
PAGもなるべく減らしましょう。
- ローカル（構内）だけでなく、リモート（遠隔）先のレスポンスも考えましょう（PUTOVRとOVRDTA,OVRATRなど）。
- 初期起動のプログラムがファイル登録ですので、DSPPGMREFを工作して、一度も自分を参照しないプログラムが、ルートプログラムというわけ「ではない」ことに注意してください。市販のユーティリティで、そのように判定するものがあります。（Dr.xxxなど）。ルートプログラムは上記のファイルに指定されているのです。DSPPGMREFは検知しません。
- パッケージをこのメニューに取り込むのは止めた方がいいです。サポート対象外にされたり、パラメータを変数で渡せなかったりします。（CLPならうまくいったのだろうか？いやいや、サポート対象外に飛ばされるは、やっぱ、やだ。）そのパッケージのルートプログラムをメニュー登録してしまえばいいです。
| 
