Re: File locks... sometimes...

[Jerry Adams <jerry@xxxxxxxxxxxxxxx>]

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