Here 's the conclusion of an article on the 'system' call:
The stored procedure system calls are made as the login user who initiates
the session. The SHELL for the system call is user login shell, and the
environment (including SHELL) is obtained from the oninit. A number of
variables, like CLIENT_LOCALE, are in this environment even if they are not
in the users login environment. Sgidsh is not used by online. The errors
reported in addition to the 668 error do not reflect the OS, ISAM, or SQL error.
How does a user or support engineer resolve these issues? The short answer
is that it can be very difficult. Here is the long answer:
(1) Run the failed command at the command line as the login user and from
the informix initialization shell,
(2) Try running the procedure as other users.
(3) Get environments from unix command line "env" calls and from system
calls to env.
(4) Look at directory permissions and ownership and all the other
obvious issues that can prevent execution (see Things to Check
in the APPENDIX).
(5) Have the user and other users create and run a simple procedure.
(6) Re-install the engine.
(7) Attach a debugger to the ADMVP UNIX process and examine the output.
Pay close attention for the appearance of these errors:
vp_exit( 0x81 ); /* file descriptor points to wrong file
vp_exit( 0x82 ); /* setgid fails
vp_exit( 0x83 ); /* setgroups fails
vp_exit( 0x84 ); /* setuid fails
vp_exit( 0x85 ); /* chdir fails
vp_exit( 0x86 ); /* execve fails
vp_exit( 0x87 ); /* fork process failed
If they are observed, take a close look from where they are called and
the user that calls them. A problem here could just reflect an issue with
the permissions on the oninit. Expected file permissions and ownership
are
found in a file named *files (e.g. IIFfiles) in INFORMIXDIR/etc
If you want the whole article, I can send it too.