Re: File locking / field locking

["Charles Wilt" <charles.wilt@xxxxxxxxx>]

No.

You'd need to write/except the logical.

But a idea is simply to use the UNLOCK op-code.

Charles

On Fri, Oct 17, 2008 at 10:58 AM, Doug Palme <DPalme@xxxxxxxxxxx> wrote:
>   Would any except cause that lock to be released?
>
>   From:                     "sjl" <sjl_abc@xxxxxxxxxxx>
>   To:                       rpg400-l@xxxxxxxxxxxx
>   Date:                     10/17/2008 09:27 AM
>   Subject:                  Re: File locking / field locking
>
>     ----------------------------------------------------------------------
>
>   Doug wrote:
>   > I have two files SourcePF is my physical file and SourceLF is a logical
>   > built over that PF.  Both are included in the program as update files
>   with
>   > add.
>
>   > In a subroutine the program sets a HIVAL on the logical and then does a
>   > readp in order to get the highest shipping number.  At this point I
>   > believe this field is locked and no other process can access read that
>   > record.
>
>   The SourcePF/SourceLF /record/ is locked, not the field, and no other
>   program that has either file defined as Update can access /this/ record,
>   but
>   programs that have it defined as Input can...
>
>   > it then increrments the count and writes it to a variable.  The
>   > other variables are setup and then the program finally writes a new
>   record
>   > to the Physical file, which at that point the lock is released correct?
>
>   NO, the logical file record is locked until you do:
>   1) A dummy except to release it
>   2) Any file operation that will read another record or reposition the file
>   pointer, such as a SETLL, Read, Readp, or Chain
>
>   > I am just checking every possible place for this thing to create
>   duplicate
>   > records (I did not write the code, just plugging the hole).....and
>   making
>   > sure that neither program can dup up the same number.
>
>   I would suggest that you instead have a 'next number' file to assign these
>   key numbers rather than using the current technique.  Your program would
>   call a program/procedure that retrieves the 'next number' record, adds 1
>   to
>   it, check to see if that key exists in the SourceLF (just to double-check
>   in
>   the case that the 'next number' isn't out of synch with the file), looping
>   until the key is NOT found in SourcePF, then write a record to either
>   SourcePF or SourceLF.
>
>   - sjl
>
>   --
>   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 transmission may contain information that is privileged, confidential
>   and/or exempt from disclosure under applicable law. If you are not the
>   intended recipient, you are hereby notified that any disclosure, copying,
>   distribution, or use of the information contained herein (including any
>   reliance thereon) is STRICTLY PROHIBITED. If you received this
>   transmission in error, please immediately contact the sender and destroy
>   the material in its entirety, whether in electronic or hard copy format.
>   Thank you.
> --
> 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.