ISAM error -113 in IDS 7.31

We are getting the error -243, ISAM -113 from time to time, in IDS 7.31.UC2 on Solaris_x86 5.7. The funny thing is, that it says -113 ISAM error: the file is locked. Another user request has opened the file (table) that was requested in exclusive mode. In systems that use files for locking, a tablename.lok file exists. Possibly such a file was left behind when another program terminated abnormally. If you are sure that is the case, you can release the lock by emptying that file. Lock files are not used in many systems, and they are never used with Informix Dynamic Server or INFORMIX-OnLine Dynamic Server. so this error should never occur in IDS. Sometimes we also get error -243, ISAM -143 (deadlock) in this stored procedure, which is more plausible, but still there is nothing obvious there that could cause a deadlock. Does anyone have a clue what is going on? --Micha

Micha Meier wrote: > > We are getting the error -243, ISAM -113 from time to time, in IDS 7.31.UC2 > on Solaris_x86 5.7. The funny thing is, that it says > > -113 ISAM error: the file is locked. > > Another user request has opened the file (table) that was requested in > exclusive mode. In systems that use files for locking, a tablename.lok > file exists. Possibly such a file was left behind when another program > terminated abnormally. If you are sure that is the case, you can > release the lock by emptying that file. Lock files are not used in many > systems, and they are never used with Informix Dynamic Server or > INFORMIX-OnLine Dynamic Server. > > so this error should never occur in IDS. Sometimes we also get error -243, No. It does not say the error will not occur in IDS just that lock files are never used so don't look for old ones to be laying around, as they might in SE servers. > ISAM -143 (deadlock) in this stored procedure, which is more plausible, > but still there is nothing obvious there that could cause a deadlock. Does > anyone have a clue what is going on? All of this are bsic concurrency problems caused by applications holding row and page locks too long. The immediate cure is to add: SET LOCK MODE TO WAIT <nseconds>; to your applications so that they wait for short lived locks and do not error out. The bigger problem, and the one causing the -143 error occassionally is that you probably need to redesign at least some of your applications to hold fewer locks for less time and to ALWAYS follow the same sequence when updating related tables. Deadlocks are usually caused by two apps each needing the same two, or more, resources locked. One locks row A first then tries to acquire a lock on row B, meanwhile the other app locks row B first then tries to acquire a lock on row B. Bam a deadlock. Neither can get a lock on the second resource it needs because the other has that lock and will not release the lock until it gets access to the other resource. You must control access so that ALL apps always acquire A first then B so there cannot be any deadlocks. Art S. Kagel