Re: File locks... sometimes... -- RPG400-L

Hi!

I do believe that in my case, the problem is related (indirectly) to the
conversion. I will try to explain it with my poor english:

At the beginning of the _AP file, there was a dummy record filled with
blanks. After the conversion, all the numeric fields has been filled with
zeros with a "one shot" program I made to correct invalid decimal values...

At the beginning of the program, the old programmer made a dummy chain to
unlock the file so when the returns to the first screen, the program is
supposed to unlock the last record that has been used...

The key fields of the files are all numerics and the programmer made a
"dummy" chain with all zeros... But now that the file is converted, the
dummy record at the beginning of the file is filled by zeros... so the
program finds a corresponding record and locks it... Then if another user
tries to launch this program, there is a record lock on the first
(converted) record...

So the solution is (I believe) to delete the first record of the file. The
program won't find any corresponding record with its dummy chain and
everybody will be happy...

Charles


"Jerry Adams" <jerry@xxxxxxxxxxxxxxx> a écrit dans
le message de news:45646A7C.7030705@xxxxxxxxxxxxxxxxxx
The System/36 Environment manual (SC41-4731-00).  There might be others
available at the IBM site.  Haven't seen a Redbook on 36E.  Also, the
RPG II Reference Manual (SC09-1818-00) might be of some help, especially
if RPG II is not one of your fluent tongues.


Better would be some old S/36 manuals.  There were tons of those, all
printed (before the 'Net).  But your organization is probably like ours:
Trashed them all once the /400 hit the door ("What will ever need these
things for again?").


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

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.