The issue is, that you are running out of sort space. Most informix setups will have a dedicated area (a temp dbspace) that is used when informix is working to create indexes, do sorts and joins on SQL queries, etc. If several people are running 'big' queries doing sorts and joins at the same time you'll probably get the error pretty quickly and on several sessions. You may always get a failure on 1 type of query if it has to sort lots of data (for example) and the space available is never going to be enough (because of data volumes) even when no other user is on the system. The frequency depends on data size, how many concurrent users and the types of SQL their sessions execute relative to the temp space available for infomrix to work in.
I guess what has happened is that your data has now grown to the size where you now will get this problem more frequently. You may never have had it before even, but now that the data has reached that critical size, where temp tables for executing SQL statements exceed the size of available space to work in.
Simple solution is to extend the space or create a temp dbspace (you'd need to update your config file for that and restart informix).
Alternatively, you could reduce the size of your database by archiving (then delete) data (if that's appropriate).
An easy way to see what is happening in the dbspaces is get someone to execute the query when you are logged in as informix user.
As informix, keep running the onstat -d command.
This shows the status of the dbspaces.
If the temp dbspace is being used, then you see it filling up with data and then releasing the space when the query is finished.
If you see the space is not being used, then there is something wrong with your config file because it should be used for your query.
If you see it fill up and get the errors, then there is not enought temp dbspace for your query to complete.
OPTCOMPIND is one of the PDQ parameters. Setting it to 2 hints the query optimiser to use various join methods to improve performance when making typically big table joins and sorting output for OLAP-type environments. Setting it to 0 is used when you are tuning for OLTP type installation.
In a mixed environment I guess it's a toss-up and you just have to play with the setting. I never thought of it I must admit, because 2 is the default value (OLTP queries will not really be slowed down much anyway when you set it to 2, because they are small/quick by nature anyway - so selecting 2 is a good default. Never heard of anyone changing that value ;-) ).