On sysprocplan being locked

Guys, This had been question of discussion in the iiug forum in many occasions or for years. Correct me if I am wrong, I can recall one saying that altering and modifying objects in the database will cause IDS to force the reoptimization of stored procedures thereby at times causing sysprocplan to lock. Does the "altering and modifying objects" apply to temp tables where we create and drop indexes. In my situation, killing the sessions and update stats for the procedures resolve it. But I am only looking for a root cause now, trying to narrow down or isolate the problem to its underlying cause. For, besides creating tmp tables, add indexes and drop them, we are not altering and modifying real objects. Thanks! JP sending to informix-list

if the modified temp tables are used by stored procedures and they have been altered after the procedure was optimised then yes the procedure will need re optimised if the version number any table used by the stored procedure is different from when the procedure was last optimised then the procedure will decide it needs to be re optimised dropping and recreating a table will change the version number (and the tabid amongst other things) adding and droping indexes will change the version number of the table as will changing user permisions on the table this is not a comprehensive list