($title_img_alt)

こちらからの投稿は、先頭に表示されているコメントへの返信になります。
メンバー・ロックされてしまう現象について ゆうやん さん [ 12月8日(火) 15時57分 ]
お世話になります。項目をデータベースにしましたが、どういうジャンルにしていいのかわからないの
で仮に選択しました。

今回修正したPGMをテストするために、新しくライブラリを用意し、使用する全てのPF/LF及び下位のプ
ログラムをコピーして環境を用意しました。

対象のRPGプログラムを実行したところ、下位のプログラムで使用するDB（CHAIN/READのみ）がPGM終了
してもロックされた状態のままです。特定のDBではなく、下位PGMで使用する全てのDBがそのようになっ
ています。どのDBも特にメンバーの指定などはありません。

ファイル・ロックやレコード・ロックではなくメンバー・ロックという点も不思議ですが、更新対象で
もないのになぜだかわかりません。

ご回答のほどよろしくお願いします。
RE:メンバー・ロックされてしまう現象について ゆうやん さん [ 12月8日(火) 17時45分 ]
申し訳ありません、その後の調査で対象のDBにアクセスする下位の共通プログラムがLR標識を立ててい
なかったことが判明しました。これが原因なのでしょうか？
ただ、それならば上位のプログラム終了時に同時にクローズし解放されるのではないかとも思います。
RE:メンバー・ロックされてしまう現象について ASD さん [ 12月8日(火) 18時29分 ]
セッションが終了するまで、解放されません。
１.　終了呼び出しをする。パラメーターとかで。
２.　FREE　命令をだす。
　
RE:メンバー・ロックされてしまう現象について ゆうやん さん [ 12月9日(水) 10時35分 ]
ＡＳＤ様

早速のご回答ありがとうございました。
やはりそうですか…。
このＰＧＭはＪＯＢスケジュール起動の夜間バッチでしか動かないために、オンラインにて単体でテス
トするとこのような現象が出ることに今まで気付かなかったみたいです。
処理速度 ASD さん [ 12月9日(水) 15時13分 ]
処理速度を上げる為、普段は、LRをONに　しないのが、望ましい。

ただし、LR　ON　のタイミングを　プログラマーが明示的に　指示するのも　めんどい。　

ファイルを扱うものは、LR　ON　を　推奨します。
RE:処理速度 ゆうやん さん [ 2月1日(月) 20時38分 ]
>　処理速度を上げる為、普段は、LRをONに　しないのが、望ましい。
>　
>　ただし、LR　ON　のタイミングを　プログラマーが明示的に　指示するのも　めんどい。　
>　
>　ファイルを扱うものは、LR　ON　を　推奨します。


申し訳ありません！しばらくこちらを見ていなかったもので、ご回答いただいていたのを知りませんで
した。教えていただいてありがとうございました。
RE:メンバー・ロックされてしまう現象について ＩＫＤ さん [ 12月9日(水) 11時19分 ]
症状からすると呼び出される下位のプログラムが　LR終了していないのが
原因のようですね。

下位のプログラムで必ずしも更新が必要ないときは
CHAIN(N)　などにすればレコードは解放されます。

また上位のプログラムが　ILE　であるなら
DSPPGM　で上位のプログラムを調べてみてください。

活動化グループ属性が　万一、*CALLER　になっていれば
そのまた上位が終了しないとこの上位プログラムも解放されません。
活動化グループ属性が　QILE　になっていても同じです。
*NEW　が最も望ましいのですが　CRTBNDRPG　をそのまま
実行してしまうと　QILE　になってしまいます。
RE:メンバー・ロックされてしまう現象について ゆうやん さん [ 12月9日(水) 14時58分 ]
ＩＫＤ様

ご回答、ありがとうございます。

下位の共通プログラムは今回改変になっておらず、
残念ながらご指導いただいた対応が出来ません。
レコードロックはされていないので、この点は後回しにされそうです。

上位のPGMはRPG?で今のタイミングではコンバートもできないので、
教えていただいた方法で逃げることも出来なさそうです。

確認はしていないのですが、毎回SBMJOBで実行するしかないのか。。。と思い始めています。

ともあれ、色々教えていただいてありがとうございました。お礼申し上げます。

お名前

パスワード

メールアドレス

タイトル

ホームページ

アドレス

項目