|
更新ファイルを、メンバーオープンして、レコードの読み取りをする場合、レコードロックがかかります。これがかからないと、同時更新をしていしまい、おかしな結果を招くことは、ご存知と思います。ＯＳがレコードロックをしてくれるから、安心して、プログラムを作れるんですよね。
更新レコードロックの解除条件
この更新レコードロックが外れる場合をきちんと知っていますか？
マニュアル「RPG/400使用者の手引き」より |
レコードが RPG/400
プログラムによりロックされている場合には、次の１つが発
生するまでそのロックは続きます。
- （ロック中の）レコードが更新される。
- （ロック中の）レコードが削除される。
- （ロック中の）ファイルから別のレコードが読み取られる（更新または照会のため）。
- （ロック中の）ファイルに対して SETLL または SETGT
命令が実行される。
- （ロック中の）ファイルに対して UNLCK 命令が実行される。
- （ロック中の）ファイルに対して、フィールド名がない出力仕様書によって定義されている出力操作が実行される。
注:
ファイルにレコードを加える出力操作では、レコード・ロックは解除さ
れません。 |
レコードを、更新ロックした状態で、そのファイルに書き出し命令をしても、ロックは外れません。それから、SETLL命令で、ロックは外れます。
飢餓状態
飢餓状態（Starvation)ってご存知ですか。一般には、「デッドロック」ともいわれますが、
2つのタスクまたはジョブが、お互いに、お互いの資源を求め合い、ロックがかかっているために、手に入れられない状態です。
更新レコードでも、同じことがおきます。
たとえば、プログラム１がファイルAを更新ロックして、その次にファイルBを更新ロックして、そして、プログラム２がファイルBを更新ロックして、その次にファイルAを更新ロックするとします。
この2つのプログラムを同時に実行すると、プログラム１はプログラム２がレコードを開放するのを待ち、逆に、プログラム２はプログラム１がレコードを開放するのを待ちます。この場合、ファイルAまたはBのWAITRCDの秒数が、*NOMAXだと、プログラム実行をキャンセルするまで、待ち続けます。これを、実験する場合は、両方のプログラムをデバッグして、更新ロックしたところで、ストップさせれば、実現できます。これをやれば分かりますが、起こる確率は低いでしょう。でも、起こることは間違いありません。
また、物理ファイルとその論理ファイルを、両方とも更新オープンした場合、メンバーロックが起こる場合があります。通常は一つのプログラムで、物理ファイルと、それに従属する論理ファイルは、同時に更新オープンしないほうがいいでしょう。また、このあたりは、プログラムミスではなく、スペックバグと言えるでしょう。
| 
