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

今回は画面のカーソルを入力項目のみに移動さる方法をお伝えします

DDSソースのキーワードにCSRINPONLYを指定するだけで完了です。

これにより、画面上のカーソルの移動できる場所を入力項目のみに限定でき
、矢印キーで次の項目へ移動する事が可能となります
エンドユーザーが端末に不慣れな場合に入力項目にのみカーソルが移動するので、入力するべき項目がはっきりするので意外と使えます。

今回は前回の標識の話にちなんだ内容にします。
前回は標識を使用しない方法をお伝えしましたが、今回は標識を節約する方法です。
画面のファンクションの標識、何も指定しないと*INKC や *INKLなど♪ABCDEFG････と口ずさみながらじゃないと？わかりづらいですよね。
そこで,CF01(01),CF02(02)とファンクションと標識を関連づけると、標識が最大で24個も使われてしまいますね。
そこで、今回は標識も使用せず尚且つソースも見やすくなる方法をお伝えします。

RPG側のコーディングです。
I仕様書にてファンクションキーの定義を行います。
F01,F02...は好きな名前で定義して結構です。

F仕様書で定義しているINFDSにファンクションを定義します
369 369バイト目に任意の名前で定義します
今回はW#FUNKとして定義します

実際のファンクションの判定です。

画面系のPRGプログラムを組んでいると、項目の多いＰＧになると標識が足らなくなって困った経験はありませんか！？
そこで今回は、標識を使用せずに画面項目の制御する方法をお伝えしようと思います

まず、画面DDS側でのコーディング方法を説明します

DSPATRにはBL等のキーワードではなく&の後に任意の名前を入力します。
次に&の後につけた名前と同じフィールドを追加します。ここでフィールドのタイプはPタイプ（プログラム-システム間）を指定します。

プログラム－システム間フィールドはプログラムとシステム間でデータの受け渡しに使用されます。 次にＲＰＧ側のコーディングです。

Ｉ仕様書にて、項目の表示属性を16進数で定義します。
上記の例で説明すると
X'2A'は下線表示の入力項目
X'A0'は下線なしの非入力項目
X'2A'は明滅の高輝度表示の入力項目 となります

通常、標識のON、OFFで項目の表示属性を制御している所は、次の様に行います

16進数で定義した値を、画面ＤＤＳで定義したプログラム-システム間フィールドにセットします。

今回の例では
P#CLRをセットすれば、画面は下線付きの入力項目(DSPATR ULと同じ)になり
P#PROをセットすれば、画面は下線なしの保護項目(DSPATR PRと同じ）になり
P#ERRをセットすれば、画面は高輝度の明滅項目(DSPATR BL HIと同じ）になります。

但し、DSPATR(PC)と同等の動きをさせる事は不可能なので、カーソル制御は別途する必要があります。

みなさん、5250画面でESCキーは使用していますか？
デフォルトのままだと、「AS/400 操作援助機能 (TM) メニュー」ってなものが表示されると思います。
でも、これってイマイチ使い道がないですよね？
そこで、ESCキーを押したときにQCMDが起動されたら便利だと思いませんか？
例えば、画面PGMをCALL時にESCキーを押してQCMDが呼び出されれば、
QTEMPのファイルの中身をタイムリーに確認する事もできます。

方法はユーザープロフィールの「アテンション・プログラム」にQCMDを指定すればＯＫです。
もちろん、QCMD以外のＰＧＭを指定する事も可能です。
エンドユーザー用のアテンション・プログラムを印刷スプールの制御が行える
独自画面を設定した例もあります。

でも、うちはユーザープロフィールを共用で使用しているから、
勝手に変えられないとお困りの場合も大丈夫です。
サイン・オン後のコマンド画面にて SETATNPGM PGM(QCMD) を実行すれば、
それ以降はESCキーがQCMDとなるのでご安心を！

ちょいとした小技ですが、是非お試し下さい。

今回は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を起動する事で不要なミスが防げます。