SYSPROCPLAN locked using Stored Procedures

We are using 16 bit PowerBuilder 5.02 connecting through its native driver using I-Net 5.01.WJ2 executing a stored procedure on Informix Online 5.06.UC2. Occassionally (we can not reproduce at will or with any consistency yet) the SYSPROCPLAN table becomes locked and gives a second user an SQL -211 error. We have studied the tbstat -u, tbstat -k and can see that for some unknown reason an initial PowerBuilder user's connection is HOLDING the lock on SYSPROCPLAN table even after that initial PowerBuilder user has finished executing the stored procedure. We have a call into Informix (case 676733) and are in the process of escalating it. Was hoping to see if other users have had similar experiences. The held lock on SYSPROCPLAN does not release until the PowerBuilder user releases their connection. We are NOT altering tables that the stored procedure calls, nor are we doing inserts or deletes to tables from the stored procedures. We have tried what informix has previously suggested including: tbcheck -cI admin:sysprocplan (does not work until person releases lock, so silly) tbcheck -cD admin:sysprocplan (ditto) Set Isolation Level to Dirty Read (Did this but still gets -211 error when locked) Set Lock Mode to Wait (Since the Lock is held until the connection is released = no good)Informix theorized that if someone was in dbaccess did a 'modify table' and then 'discarded changes' it would 'touch' the table so the next time the stored procedure executed it would remake the pcode (which would cause a lock on sysprocplan.) However, in our testing we could not reproduce this 'occassional' lock according to this 'light touching' theory Informix gave us. We also notice that the created column from sysprocplan changes to today's date when this occassional lock does occur on some of our stored procedures. We are just about ready to give up on using stored procedures altogether if we do not find a solution to this problem. Therefore any input from similar situations would be much appreciated. Here are some of the details of how the engine looks when this happens: In dbaccess did a 'select * from systables where tabname = 'sysprocplan' tabname sysprocplan owner informix partnum 67108883 tabid 18 rowsize 277 ncols 7 nindexes 1 nrows 33 created 08/11/1993 version 67452 tabtype T locklevel B npused 5 fextsize 16 nextsize 16 flags 0 Used Calculator to translate Decimal value 67108883 into hexidecimal tblsnum 4000013 fms /usr/informix$ tbstat -k|grep 4000013 (Only one user was on at this point) Locks address wtlist owner lklist type tblsnum rowid size c0999d6c 0 c07d57d4 c09b4ae4 HDR+X 4000013 bdba1f1b 1 c099b260 0 c07d57d4 c09a21c0 HDR+X 4000013 bdb87f1a 1 c09a21c0 0 c07d57d4 c09a327c HDR+IX 4000013 200 0 c09a2688 0 c07d57d4 c0999d6c HDR+X 4000013 303 0 c09a327c 0 c07d57d4 c09aec88 HDR+X 4000013 bdb87e4f 1 c09a7c98 0 c07d57d4 c09a2688 HDR+X 4000013 be3a1f1c 1 c09aa734 0 c07d57d4 c09b30bc HDR+X 4000013 302 0 c09b30bc 0 c07d57d4 c09d1ec0 HDR+IX 4000013 300 0 c09b4ae4 0 c07d57d4 c09aa734 HDR+IX 4000013 100 1 c09d1ec0 0 c07d57d4 c09b2510 HDR+IX 4000013 0 0 fms /usr/informix$ tbstat -u|grep c07d57d4 (I added the headings to the below lines) Users address flags pid user tty wait tout locks nreads nwrites c07d57d4 --B---- 5356 jdonovan - 0 0 12 17 4 Transactions address flags user locks log begin isolation retrys coordinator c081eb94 A-B-- c07d57d4 12 3743 DIRTY 0 fms /usr/informix$ tbstat -k|grep c07d57d4 Locks address wtlist owner lklist type tblsnum rowid size c0999d6c 0 c07d57d4 c09b4ae4 HDR+X 4000013 bdba1f1b 1 c099b260 0 c07d57d4 c09a21c0 HDR+X 4000013 bdb87f1a 1 c09a21c0 0 c07d57d4 c09a327c HDR+IX 4000013 200 0 c09a2688 0 c07d57d4 c0999d6c HDR+X 4000013 303 0 c09a327c 0 c07d57d4 c09aec88 HDR+X 4000013 bdb87e4f 1 c09a7c98 0 c07d57d4 c09a2688 HDR+X 4000013 be3a1f1c 1 c09aa734 0 c07d57d4 c09b30bc HDR+X 4000013 302 0 c09aec88 0 c07d57d4 c09a7c98 HDR+X 4000013 304 0 c09b2510 0 c07d57d4 0 S 1000002 201 0 c09b30bc 0 c07d57d4 c09d1ec0 HDR+IX 4000013 300 0 c09b4ae4 0 c07d57d4 c09aa734 HDR+IX 4000013 100 1 c09d1ec0 0 c07d57d4 c09b2510 HDR+IX 4000013 0 0 Danny Santee City of Aurora Aurora, Co dsantee@ci.aurora.co.us