STRDBGの活用方法
今回は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を起動する事で不要なミスが防げます。
TrackBack URL :
Comments (0)