Maybe you can create another logical file with the same key, using the same DDS but giving the object a different name. That way you don't have to use OVRDBF if at creation time you set the waiting time to just a few seconds. In the other hand you have to determine if that is a good option; maybe you have already a lot of LF's and adding a new one would slow down you system's performance. I hope you find what you need between all the answers. :-)

---

Great. OSITim has mentioned OVRDBF in the first answer to the question. If you prolong the time, the user doesn't know why she/he cannot proceed. Most users will think that the AS/400-program is looping or crashed, just like their PC-programs do from time to time. Or they think that the AS/400 is extremely slow and they ask whether to buy a Pentium-processor for the AS/400. They might even use Attn-2 to cancel or turn off the terminal (don't laugh! This shit happens!) to get rid of the Input Inhibited syndrom. This is the worst case scenario, as the application program is most likely in a dangerous situation, from the point of view of the data. --- So if the techniques described so far aren't good enough, combine them with the old-fashioned way: some fields in the database that say "This record is locked by interactive jobnbr/user/job since timestamp". The applications are not allowed to lock records when they wait for user's input. They fill the fields mentioned above instead. They have to use error indicators on every update/write, however. If something goes wrong, the program should do what the MIS personnel would do. (An AS/400 is said to be operator-less. Programmers should pay attention to this point, especially when they have an OS that enables them to!) Batch programs do not change the locked-fields, except they change the same fields that the user is enabled to change. But this should be avoided by means of mutexes or a self-written mechanism. If this is not possible, the batch-program has to exclude soft-locked records. (10 of 11 records processed - 1 not processed. Does this sound familiar?) Applications are not allowed to crash, they have to monitor everything (as mentioned above). Otherwise the soft-locker-fields still soft-lock the record, although the application isn't active any more. (Extremely uncomfortable with TCP/IP and changing device names!) That's why i suppose to store the job number, user and job name. If the application runs into a "soft-lock", it might check whether the other job is still running. So, put as many thought-pieces together as you want and build a solution. OS/400 offers enough power to do it.

---

You can overwrite the recordwait time in a CLpgm before calling the RPG pgm or in a QCMDEXC call before opening the file in the RPGpgm itself

---

i have this problem and the solution i came up with is: 1. use the error indicator on your chain command 2. immediately after your chain check the error indicator 3. at this point you can send the user a message telling them that the record is in use or as i did call a cl to send the operator/mis person a message to the effect that ???? has a record lock. 4. they can then find the person who probably went on break with the record left on their screen and have them get out of it. 5. you can then let the user enter a "r" to retry and have the program loop back to the chain command or have the mis person handle the retry and the program automatically loop back to the chain.

---

That's right... UserB can be batch just as easily as interactive. In one application, with five users updating a database of 25,000 applicants and 40,000 certificate records, the record-lock condition happened around twice a year over a period of six years. No batch was involved, so take care on taking the ris

---

Another scenario: 1. UserA reads record 1 (nolock) and sits on it. 2. Another (batch) process changes information in the record that is not on UserA's screen. 3. UserA wants to update the record, but is informed that the record has changed. How annoying! We generally take the risk that 2 users might interfere and don't worry about it. In the more than 10 years that my company is in business we never had a complaint from any of our about 200 customers (which doesn't mean that it did not happen, of course). We once developed a program template where only the fields that were modified on the screen were output to the file, but it was a lot of coding, so we dropped it.

---

Since the original poster is new to the technique, it should be pointed out that the record contents should be rechecked before the update occurs. 1. UserA reads record 1 (nolock) and sits on it. 2. UserB reads record 1 (nolock) also. 3. UserB quickly re-reads the record (with lock) and updates it. 4. UserA finally re-reads the record (with lock) and updates it also. If the program doesn't verify that the record contents have changed between steps 1 and 4. UserA will overwrite UserB's changes.

---

You might try using the error indicator on the CHAIN or READ operation you are using. I believe it's the LO column, but not sure. On the other hand, why is everyone locking a record for such a long time? Is this a file update program that someone likes to sit on for a while, and not realize the problem they are causing? Or, could it be solved by using a nolock on the input operation and then reinputting (ie. CHAIN, READ) when actual update occurs? Then again, you could use a dataq attached to the display file to kick someone off if they sit on the same record for more than say 45 seconds or so. This could be a design problem. I would look into using the nolock option on your input operation until right before you do the update as a first solution.

---

How is a SETLL and a READ different from a CHAIN on an input only file? This is was you're saying, right?

---

If you are not doing updates, then use SETLL then READ to retrieve the record. If you are using CHAIN, then use the 'N' to not lock the record. Hope this helps.

---

When you chain to the file, also use a low indicator. If it comes on, the record is unavailable-so give your user a message to try later. Also, you might want to explore techniques that limit record locking.

---

If you can't *change* the WAITRCD parameter, then why don't you try using the OVRDBF with WAITRCD(0) in those programs that you don't want to have wait.

---