John,
What you have done looks fairly careful and thorough. My
last 2 observations, 1 something you might want to try, are:
1) One thing that I did notice and seems unusual is that neither Env Var
$USER or $LOGNAME is getting set in the Environment shown in
your printenv output. However, even so, that test by you worked.
I know that at least one of these 2 gets should be set and which one does
can depend upon the coding that forks the subshell for what SYSTEM
wants to run under the UserID that is connected to the db server.
On Linux, if that matters, I have an Application Server that runs
programs under the UserID of the person who authenticated to
the App Server to invoking the program. I had problems at first
with the programs connecting to the db server backend
with the username of the person who authenticated. Then I found
out that the programs wanted to get $LOGNAME, to use for the db
connection login, from the Environment that the App Server set for them.
This behavior of needing the value of $LOGNAME set to the username is
probably
unique to the application development software that I used to create
the programs run by this App Server. But I wanted to mention it. Lucky for
me, $USER was
being set with the username in the Env of the program launched by the App
Server, so
I was able to get its value into $LOGNAME. Of course, probably, but
not for sure, all of your users would be having a problem if $LOGNAME
(or $USER) not being set was the culprit.
I agree that if the user surry does have a home directory whose path and
name is the same as
that in what you authenticate against (/etc/passwd, PAM/Kerberos, NIS), and
if the
permissions and ownership on it are correct, then you probably do have a
different
sort of problem than I had. Sorry for anything misleading...
Also, I am on Linux SLES and not HPUX (but used that platform for years with
IDS 10 and never saw either yours or my problem causing -668 happen).
2) My only other suggestion is to change the shell that surry gets when
SYSTEM
executes to Bourne or Bash, if you have that.
From my reading of the man pages on these shells, there are some rules and
behavioral differences between them, especially regarding setting up Env
Vars
and executing dot files.
and
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of John
Adamski
Sent: Thursday, November 01, 2012 2:54 PM
To: ids@iiug.org
Subject: RE: I have a puzzling situation [28693]
Jim & David
I will combine my answers to the last 3 emails on this fun subject.
First between testing users I deleted any test.log file that was created, so
write permission to the file should not be a factor. Also made it so anyone
could run the script.
ll /tmp/test.csh
-rwxr-xr-x 1 adamski common 100 Nov 1 13:56 /tmp/test.csh
I plead overwork and poor attention to details as I should have removed the
parenthesis in the script. I have since done that.
adamski cars: cat /tmp/test.csh
#!/bin/csh -f
##
printenv | sort > /tmp/test.log
id -r >> /tmp/test.log
id -u >>/tmp/test.log
SQL: New Run Modify Use-editor Output Choose Save Info Drop Exit
Run the current SQL statements.
----------------------- cars@carsitcp ---------- Press CTRL-W for Help
--------
(expression)
succeded
1 row(s) retrieved.
ury cars: cat /tmp/test.log
CLIENT_LOCALE=en_US.8859-1
DBCENTURY=C
DBPATH=:OBJ:/opt/carsi/schema/common:/opt/carsi/install/frm/common:.:
DBTEMP=/tmp
DB_LOCALE=en_US.819
INFORMIXDIR=/opt/informix
INFORMIXSERVER=newt
LC_COLLATE=en_US.iso88591
LC_CTYPE=en_US.iso88591
LC_MONETARY=en_US.iso88591
LC_NUMERIC=en_US.iso88591
LC_TIME=en_US.iso88591
ONCONFIG=onconf.cars
PATH=/opt/carsi/install/cis:/opt/perl514/bin:/bin:/usr/bin:/usr/local/bin:/o
pt/carsi/install/utl:/opt/carsi/install/bin:/opt/informix/bin:/opt/aCC/bin:/
opt/gnu/bin:/opt/java6/bin:/opt/openldap/bin:/usr/contrib/bin:/usr/bin/X11:/
usr/contrib/bin/X11:/opt/imake/bin:/opt/less/bin:/opt/ncftp/bin:/opt/pine/bi
n:/opt/ytalk/bin/X11:/opt/carstrain/install/scp/graceland/
SERVER_LOCALE=en_US.819
SHELL=/bin/csh
SQLPID=13835058056507097136
TZ=CST6CDT
_=/tmp/test.csh
771
SQL: New Run Modify Use-editor Output Choose Save Info Drop Exit
Run the current SQL statements.
----------------------- cars@carsitcp ---------- Press CTRL-W for Help
--------
(expression)
Failed, error 668
1 row(s) retrieved.
sury cars: ll /tmp/test.log
/tmp/test.log not found
sury cars:
Still can't get sury to get the proc to run. :-(
David, to answer your question our ERP provides a command 'SU' that allows
admins to substitute for another user. I have tried their command and also
logged on to the server as root and su - ury or su - sury. The results seem
the same either way. Just to double check I changed the two users passwords
on
this DR/test server to something I know and logged on directly and ran the
proc and get the same results. So all three ways the results are the same.
Jim, your problem sounds a bit different than mine as all our users have a
local user and home directory on our HPUX server. I've checked all the
permissions on each of the home directories can have not found anything
different.
John
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Thursday, November 01, 2012 10:21 AM
To: ids@iiug.org
Subject: RE: I have a puzzling situation [28690]
Hi John,
1) Unless the user ID that the script failed for is in the Unix Group
"financial", the test script will not be able to write into the
/tmp/test.log
file because the owner is "ury" and there are no World write rights on the
file after the user who has not had problems ("ury"?) ran the test first
which
created the file and left it with write permisions only for the owner and
group.
You should probably delete the test.log file between attempts at running the
test.
2) I shoud not have included the stuff in parenthesis to the right of each
of
the "id" commands that I asked you to put into the test shell script. I was
trying to put a note to you about what each of the "id" commands does, and I
should have put it elsewhere. Did you put it into the test script exactly as
you show below. If so, that is invalid syntax and is probably why I don't
think that I see any output from those commands .
You cannot be sure that the script was not run for the userid which has
problems. The shell script's file permissions problem might have caused it
to
fail right from the start.
That needs to be fixed before you run the test again.
3) Your environment looks OK but it is hard to say what is going on until we
can compare the output from the user with the failure against that from the
output from a successful test.
Do you want to try this again and send me the output from each?
By the way, I still am having problems with one user here (my boss!) and it
must be something in the environment that is created for his sub-shell that
is
being created on the IDS host machine versus how the environment or dot
files
or home directory are configured for users without the problem.
So, if I find out anything in the meantime I will be sure to post it.
Thanks,
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of John
Adamski
Sent: Thursday, November 01, 2012 9:10 AM
To: ids@iiug.org
Subject: RE: I have a puzzling situation [28689]
Jim,
Below is a series of steps I did based on you suggested proc to find the
cause
of my problem. This post is also a bit long.
First I verified that the two users .cshrc & .login are the same. Both what
inside and what permission are of the files. As the below commads show no
difference in the files and the permissions are seem to be the same.
adamski cars# diff ~sury/.cshrc ~ury/.cshrc adamski cars# diff ~sury/.login
~ury/.login adamski cars# ll ~sury/.cshrc
-rw-r--r-- 1 sury financial 347 Mar 26 2007 /home/carsids/sury/.cshrc
adamski
cars# ll ~ury/.cshrc
-rw-r--r-- 1 ury financial 347 Nov 7 2003 /home/carsids/ury/.cshrc adamski
cars# ll ~sury/.login
-r--r--r-- 1 root financial 317 Oct 29 10:52 /home/carsids/sury/.login
adamski
cars# ll ~ury/.login
-r--r--r-- 1 root financial 317 Oct 29 10:53 /home/carsids/ury/.login
adamski
cars#
I then tried setting the path to nothing and then doing the csh to show what
the path is.
sury cars: set PATH
sury cars: echo $PATH
sury cars: csh
sury cars: echo $PATH
/opt/carsi/install/cis:/opt/perl514/bin:/bin:/usr/bin:/usr/local/bin:/opt/ca
rsi/install/utl:/opt/carsi/install/bin:/opt/informix/bin:/opt/aCC/bin:/opt/g
nu/bin:/opt/java6/bin:/opt/openldap/bin:/usr/contrib/bin:/usr/bin/X11:/usr/c
ontrib/bin/X11:/opt/imake/bin:/opt/less/bin:/opt/ncftp/bin:/opt/pine/bin:/op
t/ytalk/bin/X11:/opt/carstrain/install/scp/graceland/
ury cars: set PATH
ury cars: echo $PATH
ury cars: csh
ury cars: echo $PATH
/opt/carsi/install/cis:/opt/perl514/bin:/bin:/usr/bin:/usr/local/bin:/opt/ca
rsi/install/utl:/opt/carsi/install/bin:/opt/informix/bin:/opt/aCC/bin:/opt/g
nu/bin:/opt/java6/bin:/opt/openldap/bin:/usr/contrib/bin:/usr/bin/X11:/usr/c
ontrib/bin/X11:/opt/imake/bin:/opt/less/bin:/opt/ncftp/bin:/opt/pine/bin:/op
t/ytalk/bin/X11:/opt/carstrain/install/scp/graceland/
I then created the script per your suggestion and change the proc to run the
script.
adamski cars: cat /tmp/test.csh
#!/bin/csh -f
##
printenv | sort > /tmp/test.log
id -r >> /tmp/test.log (print "real" ID of user running this script)
id -u >>/tmp/test.log (print "effective" ID of user running it)
adamski cars: cat testsysfail.sql
drop procedure testsysfail;
create procedure testsysfail()
returning char(32);
on exception in (-668)
return "Failed, error 668";
end exception;
--system "/bin/env > /tmp/1";
SYSTEM " /tmp/test.csh";
return "succeded";
end procedure;
grant execute on testsysfail to public;
After this I logged in as the person that has been able to run the proc
without problems. I get the 668 error now on them but it runs the script and
I
have the output below.
SQL: New Run Modify Use-editor Output Choose Save Info Drop Exit Run the
current SQL statements.
----------------------- cars@carsitcp ---------- Press CTRL-W for Help
--------
execute procedure testsysfail()
SQL: New Run Modify Use-editor Output Choose Save Info Drop Exit Run the
current SQL statements.
----------------------- cars@carsitcp ---------- Press CTRL-W for Help
--------
(expression)
Failed, error 668
1 row(s) retrieved.
ury cars: ll /tmp/test.log
-rw-rw---- 1 ury financial 791 Oct 31 15:48 /tmp/test.log ury cars: cat
/tmp/test.log
CLIENT_LOCALE=en_US.8859-1
DBCENTURY=C
DBPATH=:OBJ:/opt/carsi/schema/common:/opt/carsi/install/frm/common:.:
DBTEMP=/tmp
DB_LOCALE=en_US.819
INFORMIXDIR=/opt/informix
INFORMIXSERVER=newt
LC_COLLATE=en_US.iso88591
LC_CTYPE=en_US.iso88591
LC_MONETARY=en_US.iso88591
LC_NUMERIC=en_US.iso88591
LC_TIME=en_US.iso88591
ONCONFIG=onconf.cars
PATH=/opt/carsi/install/cis:/opt/perl514/bin:/bin:/usr/bin:/usr/local/bin:/o
pt/carsi/install/utl:/opt/carsi/install/bin:/opt/informix/bin:/opt/aCC/bin:/
opt/gnu/bin:/opt/java6/bin:/opt/openldap/bin:/usr/contrib/bin:/usr/bin/X11:/
usr/contrib/bin/X11:/opt/imake/bin:/opt/less/bin:/opt/ncftp/bin:/opt/pine/bi
n:/opt/ytalk/bin/X11:/opt/carstrain/install/scp/graceland/
SERVER_LOCALE=en_US.819
SHELL=/bin/csh
SQLPID=13835058056514756656
TZ=CST6CDT
_=/tmp/test.csh
ury cars:
I then logged on to the user that has always been getting the error and get
the error but the script is not run and there is no output.
NEW: ESC = Done editing CTRL-A = Typeover/Insert CTRL-R = Redraw
CTRL-X = Delete character CTRL-D = Delete rest of line
----------------------- cars@carsitcp ---------- Press CTRL-W for Help
--------
execute procedure testsysfail()
SQL: New Run Modify Use-editor Output Choose Save Info Drop Exit Run the
current SQL statements.
----------------------- cars@carsitcp ---------- Press CTRL-W for Help
--------
(expression)
Failed, error 668
1 row(s) retrieved.
sury cars: ll /tmp/test.log
/tmp/test.log not found
sury cars:
None of this seems to point to any cause to me. Does anything I'm shown here
point to something?
John
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Wednesday, October 31, 2012 11:51 AM
To: ids@iiug.org
Subject: RE: I have a puzzling situation [28686]
John,
Thanks for your reply and the info.
I have several comments about what you have said below. Unfortunately that
has
made this message very long and I hope you can preserver until the end of
it.
The MOST IMPORTANT items from the below are:
- a test procedure I suggest that should eliminate all variables and
uncertainty and tell you exactly what is happening in the Environment that
your scripts/ commands are failing in when run by SYSTEM.
- a very interesting and probably not too well known security feature that
could cause the .cshrc file to NOT be executed in the sub-shell created.
That
would leave $PATH and other important Env Vars of the sub-shell unset and
cause problems!!!
1) is the SYSTEM command used in a database server Stored Procedure in SPL
or
is in a User-Defined Routine (UDR) ? I am familiar with using SYSTEM from
SPL
but not had much UDR experience. I am assuming that the term "procs" you are
using is the same as Stored Procedure.
2) have you tried explicitly specifying the path to everything on the
command-line run with SYSTEM? If so, did it help?
3) in your message you were checking PATH to make sure that /bin was in it.
I
would think that it should also have /usr/bin too.
3) From my experience with this same problem you are having, I feel that you
have to be careful about the exact context for the environment that you echo
$PATH from.
So, below when you show the TEST results from running "echo $PATH" and
"which", were those commands run from an interactive login shell?
Or were they run from inside a Stored Procedure with the SPL command SYSTEM
"
echo $PATH ; which ... "
4) Regarding what you said below:
" Their .cshrc seem to set their PATH based on logon so if I'm reading it
correctly the logon and sub-shell should have the same PATH."
The .cshrc should execute at login after the system-wide login scripts and
it
should execute when SYSTEM creates a sub-shell to run your command.
But when you say that the login and sub-shell should have the same PATH,
that
is not necessarily true. That would depend upon which script is setting
$PATH:
a. ~/.chsrc - which is executed at beginning of both login and sub shell b.
~/.login - which is executed only at the start of login shell c.
/etc/csh.login - which is executed only at login before either of the 2
above
So, with reference to what Art said in an earlier reply to this, only the
.....cshrc file is going to be executed when SYSTEM creates a sub-shell.
You have to make sure that the minimal path needed for things that are run
by
the sub-shell created by SYSTEM are set in the .cshrc file, such as /bin,
/usr/bin, and any others that the command run by SYSTEM needs. If the
command
run by SYSTEM is a script, it will inherit the environment and Env Vars from
the sub-shell that gets created, so it will have the PATH that the ~/.cshrc
file creates when the sub-shell is created.
5) One way to be fairly sure that these necessary directories are present in
the $PATH of the sub-shell created by SYSTEM is to do this:
- login to the account under which your db client app (yes, dbaccess is good
for this test) will connect to the IDS server.
- unset PATH in this login shell
- run a sub-shell by typing: csh
- echo $PATH and see if the PATH in the sub-shell has been restored by
~/.cshrc file (or any files ~/.cshrc in turn executes to alter the
environment)
6) One way to make darn sure of the PATH and other Environment Variables in
the sub-shell created by the SYSTEM call is to do this:
- create a shell script , for example: /tmp/test.csh
- include in this script the commands:
printenv | sort > /tmp/test.log
id -r >> /tmp/test.log (print "real" ID of user running this script)
id -u >>/tmp/test.log (print "effective" ID of user running it)
- alter the Stored Procedure SYSTEM command to run this debugging script:
SYSTEM " /tmp/test.csh"
- from whichever user account is experiencing the problem, execute dbaccess
and run the Stored Procedure.
The 1st command in the debug script is to be exactly sure of the environment
under which your command or script is run as a result of using SYSTEM.
The reason for the next two commands is not at all clear and was suggested
to
me by our very experienced, lead Unix/Linux Systems Administrator after
reading the following part of a man page, although it is for the Bash Shell
on
Linux:
" If the shell is started with the effective user (group) ID not equal to
the
real user (group) id, and the -p option is not supplied, no startup files
are
read, shell functions are not inherited from the environment, the SHELLOPTS
variable, if it appears in the environment, is ignored, and the effective
user
id is set to the real user id. If the -p option is supplied at invocation,
the
startup behavior is the same, but the effective user id is not reset."
What if the "real User ID" that starts the sub-shell is that of oninit,
which
is run under either root or informix User ID, and then before starting to
execute your command/script in the sub-shell the process that created the
shell (probably the "system" C Language call) then changes the "effective"
User ID" that your command/script is run under to that of the user running
the
Stored Procedure and SPL SYSTEM command??
If this actually is how things are implemented when using SYSTEM, and if
this
behavior I quoted from the man page for "bash" is the way that the Operating
System of the host system for your IDS behaves, then your .cshrc file will
NOT
get executed by the sub-shell and whatever it is supposed to do to Env Vars
in
the sub-shell environment will NOT HAPPEN.
You could end up
with $PATH completely unset for your command or script that is run.
The only way to be sure is to use the test procedure immediately above.
7) My problems with -668 errors, which also began after upgrading to 11.70,
have been drastically reduced by explicitly specifying the path to every
command used in the command-line specified by SYSTEM.
If you find out anything else and report that back to me, I would appreciate
it.
Jim
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of John
Adamski
Sent: Wednesday, October 31, 2012 9:58 AM
To: ids@iiug.org
Subject: RE: I have a puzzling situation [28683]
Jim,
Our developers use the SYSTEM command for a number of things from 'echo' to
running scripts. Most of the procs seem to run a script and this is causing
us
the most problem. One of the procs I know of does an echo to a file in /tmp.
And this echo does fails and this seems to have started around the time we
upgraded from 11.50 to 11.70.
The question on PATH, I have taken my two test users out of the menu system
and they have command line access on our DR/test system. I got what looks
like
normal $PATH and they are the same between the two users. I did this change
to
remove one layer of complexity, I just now logon as them and run dbaccess to
test the procs.
echo $PATH
/opt/carsi/install/cis:/opt/perl514/bin:/bin:/usr/bin:/usr/local/bin:/opt/ca
rsi/install/utl:/opt/carsi/install/bin:/opt/informix/bin:/opt/aCC/bin:/opt/g
nu/bin:/opt/java6/bin:/opt/openldap/bin:/usr/contrib/bin:/usr/bin/X11:/usr/c
ontrib/bin/X11:/opt/imake/bin:/opt/less/bin:/opt/ncftp/bin:/opt/pine/bin:/op
t/ytalk/bin/X11:/opt/carstrain/install/scp/graceland/
which echo
/bin/echo
which mailx
/bin/mailx
And /bin is in the path.
Their .cshrc seem to set their PATH based on logon so if I'm reading it
correctly the logon and sub-shell should have the same PATH. I have testing
at
the command line doing a echo like the proc and it works, and then try the
proc and it fails. Which would indicate that I am reading what the .cshrc is
doing and it somehow is changing the PATH making the proc fail.
I think I will change the test proc to use /bin/echo or /bin/mailx instead
of
echo/mailx to see if that makes any difference.
Will report back.
John
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
jim-cramer@uiowa.edu
Sent: Tuesday, October 30, 2012 1:22 PM
To: ids@iiug.org
Subject: RE: I have a puzzling situation [28677]
John,
Based on my reasoning, mentioned below, my question to you is:
Do all commands, such as "echo", that are included in the string that SYSTEM
hands to the shell to execute, have *explicit paths* ?
If you know the answer to this question, would you mind replying with it to
this post?
I have been experiencing what sounds like the same problem that you are
having. My problem is with some Stored Procedures which use the SYSTEM call
and which had run without problem for years under IDS 10. My problems with
the
-668 error began right away after switching to IDS 11.7.FC1GE. I would like
to
determine if what is going on is caused by our environment & code and fix it
or, if this is a bug, if I can upgrade to a 11.7 maintenance release where
it
has been addressed.
If I understand correctly , you said in you post that you thought your tests
had been failing on the "echo" command,.
As Art says below in his response about this issue, SYSTEM will execute the
command formed by the string that you hand it in a *sub-shell* and not by a
login shell.
Perhaps some or all of the users who are having the -668 SYSTEM Call error
have the /usr/bin and /bin parts of their $PATH set by the system scripts
run
by the login shell, and not by their personal "dot files"?
This could scenario could cause a failure of the shell command run by SYSTEM
if everything in that command line is not explicitly path'd..
Regards,
Jim Cramer
Univ of Iowa
-----Original Message-----
From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art
Kagel
Sent: Monday, October 29, 2012 12:23 PM
To: ids@iiug.org
Subject: Re: I have a puzzling situation [28668]
The user's complete environment will not be set up when SYSTEM is called as
the csh profile scripts (/etc/login and $HOME/.login) is only executed by a
login shell, not a sub-shell which is what the engine will be using to
execute
the command. The sub-shel will only execute the user's $HOME/.cshrc script.
Maybe the users who have the problem have more of their environment set up
in
/etc/login or $HOME/.login and are missing something in their .cshrc or
maybe
they don't have write privs on /tmp (unusual I know, but worth a quick
check).
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Mon, Oct 29, 2012 at 12:28 PM, John Adamski <adamski@graceland.edu>wrote:
> Art, Mark & Paul:
>
> I have verified that the two users I am using in testing have the same
> default shell (csh) and that their PATHs are the same. At least an
> echo $PATH returns the same. Our ERP does strange things with the path
> variable so still could be a PATH thing.
>
> I can't upgrade to FC5 or FC6 as our ERP provider is, hmm how to say
> this politely - doesn't believe in keeping up to date with the latest
> release
of
> software they us. So, that option is not an option. :-(
>
> Since this sounds more like an OS permission problem I will continue
> searching for what is different between my two test users.
>
> Side note: I'm not exactly sure what the production procedure does as
> I don't think the developer told the name of the production proc. He
> just gave me his test proc.
>
> Since all the people they are talking about are in the same department
> (accounting) and I guessing which proc is having the problem. It
> echo's
the
> script call with parameters to a file in /tmp then calls the script.
> It looks like it fails on the echo.
>
> The test proc was created as it is time consuming to setup a situation
> and
> get
> the production proc to run.
>
> Thanks for the help.
>
> John
>
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of
> Art Kagel
> Sent: Monday, October 29, 2012 9:13 AM
> To: ids@iiug.org
> Subject: Re: I have a puzzling situation [28657]
>
> Missed the procedure source below. Make sure that everyone has mailx
> (or
> whatever) in their default PATH or script the commands with a PATH set
> in the script.
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> Blog: http://informix-myview.blogspot.com/
>
> Disclaimer: Please keep in mind that my own opinions are my own
> opinions and do not reflect on my employer, Advanced DataTools, the
> IIUG, nor any other
> organization with which I am associated either explicitly, implicitly,
> or by inference. Neither do those opinions reflect those of other
> individuals affiliated with any entity with which I am affiliated nor
> those of the entities themselves.
>
> On Mon, Oct 29, 2012 at 10:09 AM, Art Kagel <art.kagel@gmail.com> wrote:
>
> > If the SYSTEM command is running a shell script, check to see if the
> > users who are getting the -668 error have a different default shell
> > or have a shell other than their default shell set in the SHELL
> > environment variable that may be returning an error due to some
> > syntax that these users' shells are not recognizing. Or possibly the
> > script lists a shell in the first line (#!bash) but not a full path
> > and these users' PATHs are not set the same as everyone else's. A
> > simple fix to either problem may be to make sure that the script
> > that is executed includes a "#!" line that includes that fill path
> > to the shell it needs
> to
> run properly.
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > Blog: http://informix-myview.blogspot.com/
> >
> > Disclaimer: Please keep in mind that my own opinions are my own
> > opinions and do not reflect on my employer, Advanced DataTools, the
> > IIUG, nor any other organization with which I am associated either
> > explicitly, implicitly, or by inference. Neither do those opinions
> > reflect those of other individuals affiliated with any entity with
> > which I am affiliated nor those of the entities themselves.
> >
> >
> >
> >
> > On Mon, Oct 29, 2012 at 9:48 AM, John Adamski <adamski@graceland.edu
> >wrote:
> >
> >> HPUX 11.31 on BL8709c Integrity server IDS 11.70.FC4
> >>
> >> A little over a month ago we upgraded to 11.70 and the developers
> >> say that since then some users have been having problems executing
> >> procedures that have the SYSTEM command in them.
> >>
> >> One of the developers has created a test procedure to help identify
> >> the cause of this reported problem. So far we know of two users
> >> that can't run the test procedure, they get a 668 error. All other
> >> users we have tried can execute the procedure successfully.
> >>
> >> Checking permission on the users that work and the ones that don't
> >> did not identify any cause. We check both OS and Informix.
> >>
> >> We are testing using dbaccess using this command
> >>
> >> execute procedure testsysfail()
> >>
> >> The two users that fail get this message when they run.
> >>
> >> SQL: New Run Modify Use-editor Output Choose Save Info Drop Exit
> >> Run the current SQL statements.
> >>
> >> ----------------------- cars@carsitcp ---------- Press CTRL-W for
> >> Help
> >> --------
> >>
> >> (expression)
> >>
> >> Failed, error 668
> >>
> >> 1 row(s) retrieved.
> >>
> >> I have included the latest version of the test procedure that the
> >> developer is using below. Does anyone have any idea what might be
> >> causing these two users to get a 668 error when they run the
> >> procedure? Or what I might do to resolve this?
> >>
> >> {
> >> Revision Information (Automatically maintained by 'make' - DON'T
> >> CHANGE)
> >> -------------------------------------------------------------------
> >> --
> >> ----
> >> $Header: procskeleton,v 8.0 2002/05/09 08:36:56 debarthe Released $
> >> -------------------------------------------------------------------
> >> --
> >> ----
> >> }
> >> drop procedure testsysfail;
> >>
> >> create procedure testsysfail()
> >> returning char(32);
> >>
> >> {The SQL data type subset includes all the SQL data types except
> >> BYTE, SERIAL, and TEXT.} {char, nchar, date, datetime, decimal,
> >> numeric, float, integer, money smallfloat, smallint, real, varchar,
> >> nvarchar {define global var1 integer default default 0;} {define
> >> var2 like id_rec.ss_no;} {define var3 char(10);}
> >>
> >> define sys_var char(256);
> >>
> >> {This exception traps for error 284 multiple records from subquery
> >> and must immediately follow the defines} on exception in (-668)
> >>
> >> return "Failed, error 668";
> >> end exception;
> >>
> >> Set isolation to dirty read;
> >>
> >> set optimization low;
> >>
> >> --set debug file to "debugxxx" with append; --trace on;
> >> -- let sys_var = "echo this is a test > /tmp/"||USER||"test.test";
> >>
> >> let sys_var = "mailx -s 'This is a test' debarthe"; system sys_var;
> >>
> >> return "succeded";
> >> end procedure;
> >>
> >> grant execute on testsysfail to public;
> >>
> >> {Add an execute for testing and to try to force optimization}
> >>
> >> --execute procedure testsysfail();
> >>
> >>
> >>
> >>
>
>
>
****************************************************************************
***
> >> Forum Note: Use "Reply" to post a response in the discussion forum.
> >>
> >>
> >
>
> --e89a8f3ba7836ca74204cd3342fd
>
>
>
>
****************************************************************************
***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
>
>
****************************************************************************
***
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--e89a8f3b9c3f13a6f204cd35eb62
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
****************************************************************************
***
Forum Note: Use "Reply" to post a response in the discussion forum.
