|
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:
midrange.com
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
