高橋CTOのSystemiテクニカル講座

業務によっては、Queryを多用しているシステムもあります。
しかし、ファイルの変更等があった場合は少々不便です。
DSPPGMREFではQueryで使用しているファイル情報を取得できません。
WRKQRY(STRQRY)で照会や印刷機能を使用すれば可能ですが、少々手間がかかってしまいますね。

手早く、Queryの情報を取得するには、RTVQMQRYコマンドを活用しましょう。
RTVQMQRYコマンドはQueryオブジェクトより、Queryの内容(SQL文)をソースファイルに出力してくれます
ソースファイルに落としてしまえば、STRPDMの検索機能を使用すれば、検索も簡単にすみますね。

以下のソースはオブジェクトライブラリーからQueryオブジェクトを抽出してファイルに格納し
ファイルを読みながら、RTVQMQRYコマンドを実行するCLです。
これなら、簡単にQuery情報を取得できます。

PGM                                                     

DCLF       FILE(QTEMP/OBJDFILE)

DSPOBJD    OBJ(OBJLIB/*ALL) OBJTYPE(*QRYDFN) +
OUTPUT(*OUTFILE) OUTFILE(QTEMP/OBJDFILE)

LOOP:

RCVF
MONMSG     CPF0864   EXEC(GOTO END)

RTVQMQRY   QMQRY(OBJLIB/&ODOBNM) +
SRCFILE(SRCLIB/QQMQRYSRC) ALWQRYDFN(*YES)

GOTO       LOOP
END:
ENDPGM

今回はSTRDBGの活用方法です。

本番環境のあるマシンで開発作業は、
本番環境のデータ更新してしまうというリスクが発生します。
そこで、本番環境のファイルを間違って更新してしまわない為に。。。。

本番環境のあるマシンでの開発で特に注意しないといけない事は、
誤って本番環境のファイルを更新してしまわない事です。
本番環境でテスト環境を作成する方法は大きく分けて２通りあると思います。

１・本番環境を丸々複製したテストライブラリーを作成する。
大々的な開発プロジェクト向きだと思います。
DIKS容量の問題や、本番環境からのマスターデータの反映等の問題があります

２・開発に必要なファイルだけをテストライブラリーに作成する。
小さなプロジェクト開発や、ＰＧ単体での修正には向いていると思います。
テストライブラリーに、テストしているＰＧ全ての更新系の
ファイルが含まれているか注意が必要です

何れの場合もライブラリーリストには気をつけなければいけません。
CLの中でCHGLIBLを行う様な仕様になっていると、
いつの間にかライブラリーリストが変更されてしまって知らないうちに
本番データが更新なんて事態が発生してしまいます。

１の場合は、しっかりした環境作りがされているでしょうから
さほど気にはならないのですが、
２の場合のＰＧ単体での修正時は特に注意が必要です。
修正するPGの修正ファイルを把握したつもりでも、
そのPGから別PGがCALLされていた為に
CALL先のPGで本番ファイルが更新されてしまったって事も十分に考えられます。

上記のようなミスにより本番環境のファイルを更新させない方法があります。

それは、デバッグの活用です。

みなさんは、デバックをかける時 STRDBG XXXXXX UPDPROD(*YES)
と無意識に 実行ファイルの更新のUPDPROD(*YES)としていませんか？。

このUPDPRODが重要なのです。
まず、テストライブラリーを作成する時にライブラリーの
タイプを*TESTで作成します。
すでに作成してあるライブラリーはCHGLIBで変更可能です。
PGをCALLする前に STRDBGと打ち実行キー。
UPDPRODは省略値の(*NO)です。プログラム名は省略です。
入力しても構いません。

UPDPROD(*NO)とした事により、
これから先はライブラリーのタイプが*TESTとなっている中のファイルは更新できますが、
タイプが*PROD(CTRLIBのデフォルト値）の中のファイルは更新不可となった訳です。
実際にRPGをCALLした場合はファイルのOPEN時にエラーとなる為、
プログラムを実行する事ができません。
また、これはPGだけでなくコマンドラインからの
CLRPFM,STRDFU等にも有効ですので、誤って消したりする事もありません。
(注:UPDPROD(*NO)のままSEUでソースの修正を行うと、
メンバー保管時にエラーとなりますのでその場合は慌てず編集画面に戻り,
F21のコマンドラインを呼び出し ENDDBGを実行して下さい。）

また、STRDBG時にPGM名を指定しても
そのPGMだけSTRDBGが有効になる訳ではないのでご安心下さい。

付け加えますと、QTEMPというライブラリーは*TESTになっています。
ですのでQTEMPに作成したファイルは、UPDPROD(*NO)でも更新可能です。
言い換えれば、ちょっとしたテスト環境はQTEMPにファイルを
作成すればいい訳です。

従って、テストライブラリーを作成する場合はタイプを*TESTで作成し、
実行前にSTRDBGを起動する事で不要なミスが防げます。

PCOMMで作業中に、PCの再起動が必要になった経験はありませんか？
再起動をするにはサインオフをして、PCOMMを終了させないとイケません。
しかし、QTEMPに作業途中のファイルが残っている場合等、どうにか
このJOBを維持したいものです。
そんな時に活躍するのがDSCJOBコマンドです。
端末装置名がQPADEVXXXXではなく、任意の名前で作成されていれば
DSCJOBコマンドを実行すれば、サイン・オン画面へと戻ります。
もう一度、サインオンしていたユーザープロファイルで再サイン・オンすれば、DSCJOBを実行した直前に戻ります。

DSCJOBを行った場合のJOBはWRKACTJOBで確認すると、
一見表示されていませんが、F14キーを押下で状況がDSCのJOBとして表示されます。

昨今はセキュリティーや省エネの関連で昼休みはパソコンの電源をOFFにする事も
あるでしょう。そんな時はDSCJOBを利用してみてはいかがでしょう？