Question: Hi everyone.

We have a problem with several users trying to access the same reco rd, at the same time. The timeout parm on the logical is set to 60 sec. and may not be changed, because of another problem, but that another story :-) Is there anyway to tell there is a lock on a record without having to wait until the request times out ?? I use rpg/400. Please help.. ------------------------------------------------------------------------------Answer(s): 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 th e answers. :-) ------------------------------------------------------------------------------Great. OSITim has mentioned OVRDBF in the first answer to the question. If you p rolong 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 syndrome. This is the worst case scenario, as the application program is most likely in a dangerous situation, from the point of view of the d ata. --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 p ay attention to this point, especially when they have an OS that enables them to!) Batch prog rams do not change the locked-fields, except they change the same fields that the user is en abled to change. But this should be avoided by means of mutexes or a self-written mechanism. If t his is not possible, the batch-program has to exclude soft-locked records. (10 of 11 record

s processed - 1 not processed. Does this sound familiar?) Applications are not allowed to crash, they have to monitor everything (as menti oned above). Otherwise the soft-locker-fields still soft-lock the record, although the applic ation 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 in to a "soft-lock", it might check whether the other job is still running. So, put as many thought-p ieces together as you want and build a solution. OS/400 offers enough power to do it. ------------------------------------------------------------------------------You can overwrite the record wait time in a CL pgm before calling the RPG pgm or in a QCMDEXC call before opening the file in the RPG pgm 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... User B can be batch just as easily as interactive. In one applic ation, 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 year s. No batch was involved, so take care on taking the ris -------------------------------------------------------------------------------Another scenario: 1. User A reads record 1 (no lock) and sits on it. 2. Another (batch) process changes information in the record that is not on User A's screen. 3. User A wants to update the record, but is informed that the record has change d. 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 complain t 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 scr een 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. User A reads record 1 (no lock) and sits on it. 2. User B reads record 1 (no lock) also. 3. User B quickly re-reads the record (with lock) and updates it. 4. User A finally re-reads the record (with lock) and updates it also. If the program doesn't verify that the record contents have changed between step s 1 and 4. User A will overwrite User B's changes. -------------------------------------------------------------------------------You might try using the error indicator on the CHAIN or READ operation you are u sing. I believe it's the LO column, but not sure. On the other hand, why is everyone l ocking 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 no lock on the input operation and then re-inputting (ie. CHAIN, READ) when actual update occur s? Then again, you could use a data q 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 wou ld look into using the no lock option on your input operation until right before you do the u pdate 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 ex plore 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.