RE: A question about record locks

["Wilt, Charles" <CWilt@xxxxxxxxxxxx>]

> -----Original Message-----
> From: midrange-l-bounces+cwilt=meaa.mea.com@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces+cwilt=meaa.mea.com@xxxxxxxxxxxx] 
> On Behalf Of Pete Helgren
> Sent: Monday, October 23, 2006 11:49 PM
> To: Midrange Systems Technical Discussion
> Subject: A question about record locks
>
> I have a couple of applications that are experiencing conflicts on 
> record locking and I am not sure what to look for.
>
> App 1 is a maintenance application on the file.  The CLLE 
> program that 
> calls the app has the following OVRBDF statement in it:
>
> OVRDBF     FILE(MYFILE1) MBR(&MBR) RCDFMTLCK((FMTFILE1 +
>              *SHRUPD)) OVRSCOPE(*JOB)         
>
> When I run the program and use the WRKOBJLCK command I see 
> the following:
>
> Job          User         Lock      Status          Scope
> QPADEV0005   PETE         *SHRRD     HELD           *JOB
>
> Details show:
>
>                       
> Object                                                        Member
> Object           Library     Type           Lock           
> Status    Locks
> MYFILE1     MYLIB  *FILE-PHY  *SHRRD    HELD    YES
>
> The member locks show the following detail:
>
> Member       Lock Type   Lock      Status   Share   Scope
> MYMBR       MBR        *SHRRD     HELD            *JOB
>                       DATA       *SHRRD     HELD            *JOB
>                       DATA       *SHRUPD    HELD            *JOB
>
> Records are retrieved in the RPG program with a CHAIN(N)

If CHAIN(N) is the only thing being used, then
1) You wouldn't be able to update the record.
2) You wouldn't get the lock error you are describing.

I'd imagine that you've missed a normal CHAIN somewhere in the program.

It seems kind of funny to have a program that does a CHAIN(N) followed
by a CHAIN without an immediate UPDATE, thus holding the lock on the
record longer than need be.

In other words, as both Simon and Chris mentioned, the use of CHAIN(N)
is usually part of the solution to this problem.

Normally, in this situation you'd see the following:

CHAIN
 //screen I/O & validation
UPDATE

Which would be corrected by changing it like so
CHAIN(N)
 //save original data
 //screen I/O & validation
CHAIN
 //check that no one else has changed the record (or fields you have)
UPDATE


HTH,

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121