Re: Lost Invoices

} Why not take a look at your tunable kernel parameters? We discovered that } the default values on our system were entirely too small for our INFORMIX } applications. } } > BEGIN WORK } > LOCK CONTROL RECORD # To make sure only one sessions runs } > UPDATE ORDER DATA (1 row) } > UPDATE DETAIL DATA (several rows, usually < 5) } > UPDATE SHIP DATA (similiar to detail) } [ stuff deleted ] } > INSERT INTO INVOICE VALUES (INVOICE_REC.*) } > UPDATE SHIP DATA with new INVOICE DOCUMENT NUMBER. } } According to the 4GL ver 4.0 reference manual entry on the UPDATE statement, } note #9 (page 7-236) says (the same is true for the INSERT statement; see } note #13, page 7-156): } } "Each row affected by an UPDATE statement within a transaction } is locked for the duration of the transaction;..." } } It goes on to say that the rows that UPDATE locks inside a transaction } will be locked until the END/ROLLBACK WORK statement is encountered and } that if you have a large number of rows, you can exceed the value of the } maximum number of record locks (the FLCKREC kernel parameter). Try counting } the number of record locks in your code above: } Number of Locks } --------------- } > LOCK CONTROL RECORD 1 } > UPDATE ORDER DATA (1 row) 1 } > UPDATE DETAIL DATA (several rows, usually < 5) say 4 } > UPDATE SHIP DATA (similiar to detail) 4 } > INSERT INTO INVOICE VALUES (INVOICE_REC.*) 1 } > UPDATE SHIP DATA with new INVOICE DOCUMENT NUMBER. 1 } ------- } Total: 12 } Multiply 12 times the number of users, say 30, and you end up with 360. I } don't know what your default FLCKREC is, but if this were my application with } 30 users, I would increase it to 400 (on one of our machines it's set at 600). } You could also issue some LOCK TABLE statements, if you don't want to tune } your kernel. } The system is running SE and has maybe 8 users active...tops. The kernel parameters are already insane (been this route before). NFILE is at something like 1200 and FLCKREC is around 500. If one of the processes blocks, and runs away, the users aren't aware. It will stay blocked until somebody comes in and kills it. They usually kill it after they discover it. They usually discover it after the system starts complaining, which is about 30 invoice processes. At this point, I'm considering reducing kernel parameters so that the thing blows up with only 10ish extra processes runnin. From what I can tell in the errlog, the LOCK problem happens when there isn't a whole lot going on the system. I also question how I can run out of locks that I've already acquired. (If I've updated the rows once, does it lock them again..even though I've already got the lock? That almost makes a sick kind of sense.) } Will's problem brings up one big question: } } How do you code in 4GL to handle unexpected error messages from the kernel? } In SQL, of course, you can't (which is why we had so much trouble diagnosing } the problem). Do you use SQLCA.SQLCODE? Can anyone give some sample code? } --- } John } =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= } John Baker, USAISC - Lex, Lexington - Blue Grass Army Depot, Lexington, KY } (jbaker@lexington-emh2.army.mil) Phone: (606) 293-3644, 293-3743 DSN: 745- } =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Unfortunately, it's difficult to test for the truly evil things tat can happen. For example, test for a -408 (SQLEXEC is toast message) may not do you a whole lot of good, since most responses rely on the SQL engine. If you're talking things like signals, I'm not sure there is a way of do that in pure 4GL. Will (uunet!la4gen!villy)