]有るプログラムで、何ヶ月かに一度、RPGで、エラーを起こすものがありました。それは、対話型のプログラムですが、RPGが暗黙の更新オープンをしているときに、xxODRMPというファイルの割り振りエラーなのです。そこでいろいろ調べているうちに、別のジョブで、全く同じ時間(まあ1秒くらいの差がありましたが)で、CPYFをしている事に気づきました。CPYFをしているプログラムでは、エラーになっていません。これが原因かなぁ、でも変です。*REPLACEなら、メンバーのRMVMをするはずなので、ロックするのは分かります。そこで調べてみました。アロック(割り振り)に関してのおさらいです。資源の割振りオブジェクトは、その使用目的(読取りまたは更新)、および共用(複数のジョブによる同時使用)が可能かどうかに基づいて割り振られます。割り振られ、ファイル・データはロック状態で指定されたロック・レベルで割り振られます。ロック状態とは、オブジェクトの用途、およびそのオブジェクトが共用されるかどうかを識別するものです。種類があります(パラメーター値をかっこに入れて示してあります)。オブジェクトは要求もとジョブの占有使用として確保され、他のジョブはこのオブジェクトを使用することができません。オブジェクトがすでに別のジョブに割り振られている場合には、他のジョブはそのオブジェクトを占有使用することはできません。実行している機能が完了するまで他のユーザーがオブジェクトにアクセスできないようにしたい場合には、このロック状態が必要です。オブジェクトはそれを要求したジョブに割り振られますが、他のジョブからもそのオブジェクトを読み取ることができます。他のユーザーがオブジェクトに対して読取り以外の操作を行うことができないようにしたい場合には、このロック状態が必要です。オブジェクトは、更新についても読取りについても、別のジョブとの共用が可能です。別のユーザーが、同じオブジェクトに対して読取り共用ロック状態または更新共用ロック状態のいずれかを要求することができます。オブジェクトを変更する処理で、他のユーザーによる同じオブジェクトの読取りまたは変更を可能にしたい場合には、このロック状態が適切です。ジョブが、更新不可共用ロック状態または読取り共用ロック状態を要求した場合には、そのオブジェクトを別のジョブと共用することができます。オブジェクトを変更する処理で、他のユーザーによるそのオブジェクトの変更をできないようにしたい場合には、このロック状態が必要です。ユーザーがオブジェクトの占有使用を要求していなければ、オブジェクトは別のジョブと共用することができます。共用、または更新不可共用の各ロック状態を要求することができます。ライブラリーの割振りは、そのライブラリー内のオブジェクトに対して実行できる操作を制限するものではありません。あるジョブによりライブラリーが読取り可占有ロック状態または更新共用ロック状態になった場合には、他のジョブはそのライブラリーにオブジェクトを入れたり、そのライブラリーからオブジェクトを除去したりすることはできません。この場合でも他のジョブはライブラリー内のオブジェクトを更新することができます。次の表は、オブジェクトに対する有効なロック状態の組合せを示しています。*SHRRD基本的に、OS400の上で何か作業をすれば、原則的に、参照されたオブジェクトは何かしらロックされると思った方がいいですね。これが一番弱いロックです。最強のロックは*EXCLです。*SHRRDは、*EXCL以外すべてで使えます。*SHRUPD同士、*SHRNUP同士はエラーになりません。*SHRNUPを有るジョブが取ると、*SHRUPD出来ないので、更新できない仕組みです。ま、早いもの勝ちです。これらのロック状態は、お互いにお互いの立場をわきまえるために存在しているだけです。すべてOKな*SHRRDなんて要らないじゃないか、と思うかもしれませんが、*EXCLがそれをはじき、*EXCLRDは、それを受け入れるので、*SHRRDの存在が必要なのですね。次に、RPGが、更新オープンしたファイルのロックはどうなるのか調べました。読取り共用)にすることができます。ジョブ内のプログラムは、ファイルのロック状態によって影響は受けません。ファイルのロック状態は、別のジョブ内のプログラムでファイルを同時に使おうとした場合にのみ適用されます。(オブジェクト割振り)によって、割り振ることができます。システムでは、データベース・ファイルのオープン時に、以下のロック状態が設定されます。読取り可占有のロック状態でファイルをオープンすることはできますが、ファイルを占有して使用するように指定することはできません。更新共用のロック状態の場合には、他のユーザーは読取り共用または更新共用のロック状態でこのファイルをオープンすることができます。プログラムでは装置ファイルに対して、読取り可占有のロック状態が設定されます。他のユーザーはこのファイルを読取り共用のロック状態でオープンすることができます。プログラムによって設定されたロック状態は、オブジェクト割振りコマンドを使用して変更することができます。これで、更新の時に、エラーが起きるとすれば、相手は、*EXCLか、*EXCLRDか、*SHRNUPとなりますよね。CPYFに関して調べてみました。ロック状態が割り振られます。メンバーにこの割振りがなされるのは、それがコピー中だけに限られます。ロック状態が割り振られます。ロック状態が割り振られます。ロック状態が割り振られ、コピー先になるファイルの中のレコードは削除されます。読取り共用ロック状態では、他のユーザーにコピー中のファイルの読取りおよび更新をさせます。物理ファイルから別の物理ファイルにコピーするときは、次のようにより強力なロックをメンバーに施して、内部システム機能でコピーを実行することができるようにすることもあります。ロック状態を割り振ることができます。ロック状態を割り振ることができます。指定されている場合は、より強力なロックが必要とされます。指定して、コピー操作を実行することもできます。あるメンバーに、別のジョブにより強力すぎるロック状態が割り振られた場合、またはファイルを含むライブラリーがコピー操作中に名前変更された場合は、エラー・メッセージが出されてコピー操作は打ち切られることになります。ロックと同様のロック)ことがあります。指定したオブジェクトを使用しなければならない機能を使用しようとすると、そのコピー・コマンドの実行が完了するまで、そのワークステーションのロックアップが起こります。以下に示すのは、コピー・コマンドによるコピーが進行中のコピー先ファイルに対して使用してはならない機能の例です。指定することによりコピー・コマンドにブロック・レコード単位の操作を強制的に使用させるようにしなければなりません。コマンドを使用して、ファイルおよびメンバーを事前割振りすることができます。)コピー・コマンドによるコピーが進行中のコピー先ファイルに対して使用してはならない機能の例、なんて皆さんご存知でしたか?コピー中はいつもWRKOBJLCKしてはいけないのだろうか?まあ、今回の調査目的は、コピー側のエラーではなくて、コピー先のファイルが、RPGの更新オープンでエラーになったわけで、関係ないですけど。....多分、上と同じ事を言ってますね。way)、MBROPT(*UPDADD)って使ったこと無かった。自分は正しいことをしていると思うのです。RPGの更新オープン=*SHRUPDで、CPYFの*ADDならば、同じく*SHRUPDです。この場合、エラーは起きないはずなのですが...2番目に出ていた、物理ファイルから別の物理ファイルにコピーするときは、次のようにより強力なロックをメンバーに施して、内部システム機能でコピーを実行することができるようにすることもあります。いう場合なのでしょう?論理ファイルなら良かったのでしょうか?結局、よく分からないまま、このページは終わりです。