|
Locking occurs on several different levels. -- Object (File) Level -- Member Level -- Record Level Whenever a program opens a file, it issues both an object lock and a member lock to prevent someone from deleting the file, or removing the member while your program is running. (This also protects against many other things, but you get the idea...) The CHAIN(N) refers to a "record lock". When you lock a record, it prevents other programs from locking that same record. Since you must lock it to update it, the record lock protects you against other programs updating the record while your program is trying to change it. Its important to make the distiction between a "record lock" and a "file lock". The fact that you're using CHAIN(N) and therefore not locking the record has nothing whatsoever to do with whether another program is able to "open" the file. It would only prevent another program from reading the record that you've locked. An "Open" problem would be a file or member level lock. Perhaps you're using the CL command "ALCOBJ" to get exclusive use of the file? Or doing something else that prevents other programs from opening the file? In any case, a trigger program should "never" need to open the file that its being triggered on! Never! The buffer containing the before and after record images are passed as parameters, and your trigger can read & write data directly to those images! Assuming that the trigger is a *BEFORE trigger, and that you used ALWREPCHG(*YES) on the ADDPFTRG command, the changes you make to the "after" buffer will be placed into the file without you needing to issue an UPDATE or WRITE. (This seems to be a very popular topic on this list this week!) Hope that helps... (and hope I made sense...) On Tue, 21 Mar 2000, a b wrote: > I'm attempting to call a program from a trigger, but > I'm getting an error indicating that the application > is unable to open the file. I've notice that it locks > the files eventhough I' added the CHAIN(N). I don't > quite understand why it would lock all of the files. > Is there a way to avoid this? Is there a CL command > that "UNLOCKS" all of the file that are being used. > For example, I call a CL that calls the RPG, then > returns to the CL who in turn "UNLOCKS" all of the > files used... or is there a better way? Any help > would greatly be appreciated. > +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.