ここでは前節の問い合わせ処理ファンクションを改訂して、レコードの保守(データの修正)もできるようにします。

処理対象ファイル

物理ファイル「CUSMST」(顧客マスター)

RDMLプログラム

     GROUP_BY   NAME(#CUSTOMER) FIELDS((#CUSTNO *NOCHG) 
                #NAME #ADDL1 #ADDL2 #ADDL3)
 
     BEGIN_LOOP
 
     REQUEST    FIELD(#CUSTNO)
     FETCH      FIELDS(#CUSTOMER) FROM_FILE(CUSMST) 
                WITH_KEY(#CUSTNO)
 
         IF_STATUS  IS(*OKAY)
         SET_MODE   TO(*DISPLAY)
         DISPLAY    FIELDS(#CUSTOMER) CHANGE_KEY(*YES)
 
             IF_MODE IS(*CHANGE)
             UPDATE  FIELDS(#CUSTOMER) IN_FILE(CUSMST) 
                     VAL_ERROR(*LASTDIS)
             ENDIF
 
         ELSE
         MESSAGE    MSGTXT('No customer exists with this number')
         ENDIF
 
     END_LOOP

着目点：

  • 顧客情報の問い合わせのほか、修正もできるよう改訂しました。

  • BEGIN_LOOP～END_LOOPのブロック内で、ファンクション・キーEXITまたはMENUが押されるまでの間、検索/修正処理を繰り返します。

  • ファンクション・キーEXITとMENUは、デフォルトでREQUEST/DISPLAY/POPUP画面に表示されます。いずれかのキーを押すとファンクションは終了します。

  • さらにDISPLAY画面では、ファンクション・キーCHANGEも使えるようになっています。このキーを押すと、モードが*CHANGEに変わり、画面が再描画されて、#CUSTNO以外のフィールドがすべて入力を受け付けるようになります。#CUSTNOが入力を受け付けないのは、GROUP_BYコマンドで#CUSTNOに*NOCHG属性が設定されているからです。

  • DISPLAYコマンドが完了した後、モードのテストが行われます。*CHANGEモードであれば、画面上で顧客データが修正され、ファンクション・キーCHANGEが押された、ということになります。したがって、UPDATEコマンドを使って、顧客マスター・ファイルを更新します。UPDATEコマンドの実行中に(ファイル単位またはフィールド単位の)妥当性規則違反を検出した場合、画面にエラーの詳細が表示されます。これはVAL_ERROR(*LASTDIS)というパラメータの働きによるものです。

  • UPDATEコマンドには、更新対象レコードを表すWITH_KEYパラメータが指定されていません。これは、ファイルから読み込んだ最新のレコード、すなわち、直前にFETCHコマンドで読み込んだレコードを更新することを表します。

  • LOCK(*YES) パラメータの指定がないので、FETCH コマンドから UPDATE コマンドまでの間、レコードはロックされません。

したがって、他のユーザーが、この間に同じレコードを更新してしまうこともありえます。作業中に昼休みになった場合など、ロックされない状態で30分以上放置されることもあるので、問題が起こりそうに見えます。

しかしCUSMSTの作成や保守にLANSAを使っている場合、問題が起こることはありません。UPDATEコマンドは自動的に、読み込みから更新までの間にレコードが更新されていないか確認するようになっているからです。この間に他のユーザーが同じレコードを更新していた場合、UPDATEコマンドを実行しようとするとエラーとなり、更新が拒絶されたことを示すメッセージが自動的に表示されます。DISPLAY画面が再び表示され、エラー・メッセージが示されます。

  • No labels