UNLOAD in 4gl and TMP dirs

I have been running across a problem in some 4gl code which is doing an UNLOAD of a relatively large table, dropping and re-creating the table then reloading it. The error being returned is -242 indicating that the drop of the table is failing. This should not happen, at least it definitely doesn't happen on our development environment (SCO 3.2.4, 4.1 SE, 4.1 4GL etc.) yet it occurrs under the production environment (SUN Solaris, SE 5.01, 4.11 4GL) What I am presuming is that SE is running out of TMP storage space to perform the drop. We have a 100MB paritition for informix temp usage pointed to with the DBTEMP environment variable. However I understand after scanning some other posts here that the /tmp area will also be used for certain functions. Q. Am I right in assuming that /tmp is being targeted for the DROP and has run out of room? The process which performs the upgrade of the database (which incorporates the above steps) is a staggered process which can be restarted at any of the major fix points. On exiting this process and then restarting the thing from the step that failed it all runs through cleanly without further hiccup. Thus I'm surmising that any temp files created in /tmp from the previous run have been cleaned up and sufficient room is made available for the remaining steps. Comments, pointers anyone? Q. Does informix SE have any problem with a DBTEMP dir of /inf_tmp is the underscore in the name okay, or could Informix be ignoring this temp dir spec because of it? (just another thought). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Ian Timms (DBA/Administrator) % Disclaimer: All opinions expressed % % itimms@vprp333q.prop.telecom.com.au % herein are mine and mine alone! % % Ph. 61+3+634-9144 % ==__( pretty piccy goes here )__== % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%