Re: File locks... sometimes...

Hi!

Where can I find documentation about file locks, disp-shr and all these
things?

Charles


"Jerry Adams" <jerry@xxxxxxxxxxxxxxx> a écrit dans
le message de news:456454F8.2090704@xxxxxxxxxxxxxxxxxx

Charles,


I'm in the same boat here: Our primary application is still RPG36 with
OCL drivers.  Whenever I've hit a file during some kind of maintenance,
I've also converted them to externally described files.


The conversion to a native file will have absolutely no effect on
whether the file is locked or not.  I suspect that the culprit in your
case, as it was in many of ours when I first came here, is the
DISP-SHR.  This is equivalent to DISP-SHRMM: "I want to lock the record
for maintenance and, by the way, it's OK if somebody else locks it if
they get there first."  Even if the program is a simple inquiry, the
record will be locked!  This was the rule on the /36; it's still the rule.


The statement // FILE NAME-SCEKAK,LABEL-SC_?L'1,2'?_AK,DISP-SHR should
actually use the DISP-SHRRM: "I'm only going to read the record for
input so if someone else wants to modify it, that's fine by me."  The
other file should, probably, have a DISP-SHRMR - if you want to totally
lock the file down for maintenance or DISP-SHRMM if you want to allow
others to also make changes.  That's a design question.


The lock applies to records, not the entire file.  I.e., User-1 can lock
record #1 for update while User-2 can lock record #2 for update without
a problem.  (If the I/O was buffered - multiple records read at one time
- this would not be the case; all records in the input buffer would be
locked.)


The next thing that I would do (have done here) is to not lock the
record even for maintenance.  In RPG36 this is done by:

    KEY   CHAIN   FILE         64
                EXCPTRELEASE

    FILE   E               RELEASE
    (no fields defined)

This means that you have to
    a)   save the state of the record that you retrieved on the CHAIN
    b)  re-CHAIN when you're ready to actually update
    c)  see if someone else has been quicker and updated the record
ahead of you (in which case you send a message to the maintenance panel
and re-populate the panel's fields - back to the original CHAIN).


This would only apply to interactive maintenance to alleviate the
problem of someone bringing the record up for maintenance and then going
to lunch (figuratively and literally!).  For a batch program whirling
through the file there shouldn't be a concern - as long as the
interactive programs don't blindly lock records.


* Jerry C. Adams
*IBM System i5/iSeries Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx

<mailto:jerry@xxxxxxxxxxxxxxx>

Charles St-Laurent wrote:

Hi!

Since I converted some S/36 files to native files, some old applications
began to fail starting, with file locks but the file locks doesn't not
occurs all the times with concurrent usage of the same program on the

same

files.

The program that uses the files is a RPG/36 program called by an OCL. I
didn't change anything in the OCL syntax and I didn't change anything in

the

way the RPG/36 uses the file that is sometimes locked.

Before the conversion, no file lock...

There's some code samples...

// LOAD SSSS03
// FILE NAME-SCEKAP,LABEL-SC_?L'1,2'?_AP,DISP-SHR
// FILE NAME-SCEKAK,LABEL-SC_?L'1,2'?_AK,DISP-SHR
// RUN

and the F specs in the RPG/36 program:

FSCEKAP  UC  F 384 384R15AI     2 DISK
FSCEKAK  IF  F 384 384L19AI  EXTK DISK

Why does the program fail sometimes with a record lock now? The only
difference: SC_?L'1,2'?_AP is now a native DDS file...

Charles

-- 
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.