RE: Record locking 101

Pet,

In answer to your question, yes you shouldn't see anything with DSPRCDLCK when using chain(n).

The only time you should see anything is during the microsecond after you've read the record with a
lock while updating the fields before you issue the UPDAT op-code.

HTH,
Charles

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Helgren
Sent: Monday, September 10, 2007 5:14 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Record locking 101

Booth/Walden,

Yes. Whether I use READx/CHAIN I am using the (n) extender
not to lock the record. The only exception is when I
actually want either update or delete the record and then I
am exclusively using Chain (without the
extender) to retrieve the record. That is what trigger the
question.
If I update or delete, the record lock should be gone after
those op codes have executed, correct?

I am guessing somewhere there is another READx or CHAIN I
missed that is still locking record. But that is what brings
me to the second question. What would a lock look like after
a Chain(n) on the record?
Would there even be an entry showing a lock when I use the
DSPRCDLCK command?

Thanks,

pete


Booth Martin wrote:

Question: You are using the (n) extender on the get of the record
that fills the screen, right?

Pete Helgren wrote:

I had a program that was originally written in such a way that it
would read/chain and lock a record while the user was in the
maintenance screen. That would cause problems for a

posting program

that could also be run while records were being maintained. So I
needed to eliminate the lock in the maintenance program.

Thanks to

this list, I modified the program so that the record data is now
retrieved into a data structure temporarily (with

supposedly no lock

on the record) and then when the user presses enter the record is
retrieved again from the DB, the data updated and written without
delay so that the lock is very transitory.

Now comes time to test it. When this was originally reported as a
problem, I looked at the code and found the flawed design and set
about fixing it. I never looked at the job to see what

the locks on

the record actually looked like. So now I am viewing the record
locks on the file and I am not sure what I *should* see. This is
what I do see when I am in the record in the "view" mode

(shouldn't

be a lock on the
record)

Record Lock
Number Job User Number Status Type
494 QPADEV000R PETE 861530 HELD UPDATE

So I am guessing that I still have some more work to do, yes?

An UPDAT or DELET after a CHAIN would effectively release

the lock on

the record, correct?

What should the Lock Type be when you are just reading through the
records with no need to update?

Thanks,

Pete

--
This is the RPG programming on the AS400 / iSeries (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.