I have a puzzling situation

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();

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. > > --14dae9399c71da233304cd333861

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

Just as a thought=2C you should install FC5 which is a maintenance release.= It probably will not fix this issue=2C but could save you from a lot of ot= her issues. So the 2 users can execute echo hello|mailx -s 'This is a test' debarthe on the database host and when you echo $? the result is 0 Do the users also have the path to mailx set for their accounts on the data= base server host? In the stored procedure=2C what happens when you explicitly specify /usr/bi= n/mailx -----Original Message----- From: John Adamski Sent: 29 Oct 2012 13:48:58 GMT To: ids@iiug.org Subject: I have a puzzling situation [28655] 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 h= ave the SYSTEM command in them. One of the developers has created a test procedure to help identify the cau= se of this reported problem. So far we know of two users that can't run the te= st procedure=2C they get a 668 error. All other users we have tried can execut= e 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=2C 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 user= s to get a 668 error when they run the procedure? Or what I might do to resol= ve this? { Revision Information (Automatically maintained by 'make' - DON'T CHANGE) ------------------------------------------------------------------------- $Header: procskeleton=2Cv 8.0 2002/05/09 08:36:56 debarthe Released $ ------------------------------------------------------------------------- } drop procedure testsysfail=3B create procedure testsysfail() returning char(32)=3B {The SQL data type subset includes all the SQL data types except BYTE=2C SE= RIAL=2C and TEXT.} {char=2C nchar=2C date=2C datetime=2C decimal=2C numeric=2C float=2C intege= r=2C money smallfloat=2C smallint=2C real=2C varchar=2C nvarchar {define global var1 integer default default 0=3B} {define var2 like id_rec.ss_no=3B} {define var3 char(10)=3B} define sys_var char(256)=3B {This exception traps for error 284 multiple records from subquery and must immediately follow the defines} on exception in (-668) return "Failed=2C error 668"=3B end exception=3B Set isolation to dirty read=3B set optimization low=3B --set debug file to "debugxxx" with append=3B --trace on=3B -- let sys_var =3D "echo this is a test > /tmp/"||USER||"test.test"=3B let sys_var =3D "mailx -s 'This is a test' debarthe"=3B system sys_var=3B return "succeded"=3B end procedure=3B grant execute on testsysfail to public=3B {Add an execute for testing and to try to force optimization} --execute procedure testsysfail()=3B ***************************************************************************= **** Forum Note: Use "Reply" to post a response in the discussion forum.

FYI, 11.70.FC6 was released on Friday. It should be available for download from your PA accounts by now. There were some significant fixes in the .FC5 release (finally fixed the new readahead algorithm for example). I haven't had time to go through the .FC6 fix list yet, but I'm a big believer in using the latest and greatest. 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:21 AM, Mark Tyrer <m_tyrer@hotmail.com> wrote: > Just as a thought=2C you should install FC5 which is a maintenance > release.= > It probably will not fix this issue=2C but could save you from a lot of ot= > her issues. > > So the 2 users can execute echo hello|mailx -s 'This is a test' debarthe > on the database host and when you echo $? the result is 0 > > Do the users also have the path to mailx set for their accounts on the > data= > base server host? > > In the stored procedure=2C what happens when you explicitly specify > /usr/bi= > n/mailx > > -----Original Message----- > > From: John Adamski > Sent: 29 Oct 2012 13:48:58 GMT > To: ids@iiug.org > Subject: I have a puzzling situation [28655] > > 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 > h= > ave > the SYSTEM command in them. > > One of the developers has created a test procedure to help identify the > cau= > se > of this reported problem. So far we know of two users that can't run the > te= > st > procedure=2C they get a 668 error. All other users we have tried can > execut= > e 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=2C 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 > user= > s > to get a 668 error when they run the procedure? Or what I might do to > resol= > ve > this? > > { > Revision Information (Automatically maintained by 'make' - DON'T CHANGE) > ------------------------------------------------------------------------- > $Header: procskeleton=2Cv 8.0 2002/05/09 08:36:56 debarthe Released $ > ------------------------------------------------------------------------- > } > drop procedure testsysfail=3B> > create procedure testsysfail() > returning char(32)=3B> > {The SQL data type subset includes all the SQL data types except BYTE=2C > SE= > RIAL=2C > and TEXT.} > {char=2C nchar=2C date=2C datetime=2C decimal=2C numeric=2C float=2C > intege= > r=2C money > smallfloat=2C smallint=2C real=2C varchar=2C nvarchar > {define global var1 integer default default 0=3B} > {define var2 like id_rec.ss_no=3B} > {define var3 char(10)=3B} > > define sys_var char(256)=3B > > {This exception traps for error 284 multiple records from subquery > and must immediately follow the defines} > on exception in (-668) > > return "Failed=2C error 668"=3B > end exception=3B > > Set isolation to dirty read=3B> > set optimization low=3B > > --set debug file to "debugxxx" with append=3B > --trace on=3B > -- let sys_var =3D "echo this is a test > /tmp/"||USER||"test.test"=3B > > let sys_var =3D "mailx -s 'This is a test' debarthe"=3B > system sys_var=3B > > return "succeded"=3B > end procedure=3B > > grant execute on testsysfail to public=3B> > {Add an execute for testing and to try to force optimization} > > --execute procedure testsysfail()=3B > > > ***************************************************************************= > **** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae93411db09edfe04cd3398ac

You mean finally fixed the new readahead algorithm AGAIN :) Cheers Paul -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel Sent: Monday, October 29, 2012 9:37 AM To: ids@iiug.org Subject: Re: I have a puzzling situation [28659] FYI, 11.70.FC6 was released on Friday. It should be available for download from your PA accounts by now. There were some significant fixes in the ..FC5 release (finally fixed the new readahead algorithm for example). I haven't had time to go through the .FC6 fix list yet, but I'm a big believer in using the latest and greatest. 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:21 AM, Mark Tyrer <m_tyrer@hotmail.com> wrote: > Just as a thought=2C you should install FC5 which is a maintenance > release.= > It probably will not fix this issue=2C but could save you from a lot of ot= > her issues. > > So the 2 users can execute echo hello|mailx -s 'This is a test' debarthe > on the database host and when you echo $? the result is 0 > > Do the users also have the path to mailx set for their accounts on the > data= > base server host? > > In the stored procedure=2C what happens when you explicitly specify > /usr/bi= > n/mailx > > -----Original Message----- > > From: John Adamski > Sent: 29 Oct 2012 13:48:58 GMT > To: ids@iiug.org > Subject: I have a puzzling situation [28655] > > 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 > h= > ave > the SYSTEM command in them. > > One of the developers has created a test procedure to help identify the > cau= > se > of this reported problem. So far we know of two users that can't run the > te= > st > procedure=2C they get a 668 error. All other users we have tried can > execut= > e 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=2C 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 > user= > s > to get a 668 error when they run the procedure? Or what I might do to > resol= > ve > this? > > { > Revision Information (Automatically maintained by 'make' - DON'T CHANGE) > ------------------------------------------------------------------------- > $Header: procskeleton=2Cv 8.0 2002/05/09 08:36:56 debarthe Released $ > ------------------------------------------------------------------------- > } > drop procedure testsysfail=3B> > create procedure testsysfail() > returning char(32)=3B> > {The SQL data type subset includes all the SQL data types except BYTE=2C > SE= > RIAL=2C > and TEXT.} > {char=2C nchar=2C date=2C datetime=2C decimal=2C numeric=2C float=2C > intege= > r=2C money > smallfloat=2C smallint=2C real=2C varchar=2C nvarchar > {define global var1 integer default default 0=3B} > {define var2 like id_rec.ss_no=3B} > {define var3 char(10)=3B} > > define sys_var char(256)=3B > > {This exception traps for error 284 multiple records from subquery > and must immediately follow the defines} > on exception in (-668) > > return "Failed=2C error 668"=3B > end exception=3B > > Set isolation to dirty read=3B> > set optimization low=3B > > --set debug file to "debugxxx" with append=3B > --trace on=3B > -- let sys_var =3D "echo this is a test > /tmp/"||USER||"test.test"=3B > > let sys_var =3D "mailx -s 'This is a test' debarthe"=3B > system sys_var=3B > > return "succeded"=3B > end procedure=3B > > grant execute on testsysfail to public=3B> > {Add an execute for testing and to try to force optimization} > > --execute procedure testsysfail()=3B > > > ***************************************************************************= > **** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > **************************************************************************** *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae93411db09edfe04cd3398ac **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

B^} 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:42 AM, Paul Watson <paul@oninit.com> wrote: > You mean finally fixed the new readahead algorithm AGAIN :) > > Cheers > Paul > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art > Kagel > Sent: Monday, October 29, 2012 9:37 AM > To: ids@iiug.org > Subject: Re: I have a puzzling situation [28659] > > FYI, 11.70.FC6 was released on Friday. It should be available for download > from your PA accounts by now. There were some significant fixes in the > ...FC5 release (finally fixed the new readahead algorithm for example). I > haven't had time to go through the .FC6 fix list yet, but I'm a big > believer in using the latest and greatest. > > 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:21 AM, Mark Tyrer <m_tyrer@hotmail.com> wrote: > > > Just as a thought=2C you should install FC5 which is a maintenance > > release.= > > It probably will not fix this issue=2C but could save you from a lot of > ot= > > her issues. > > > > So the 2 users can execute echo hello|mailx -s 'This is a test' debarthe > > on the database host and when you echo $? the result is 0 > > > > Do the users also have the path to mailx set for their accounts on the > > data= > > base server host? > > > > In the stored procedure=2C what happens when you explicitly specify > > /usr/bi= > > n/mailx > > > > -----Original Message----- > > > > From: John Adamski > > Sent: 29 Oct 2012 13:48:58 GMT > > To: ids@iiug.org > > Subject: I have a puzzling situation [28655] > > > > 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 > > h= > > ave > > the SYSTEM command in them. > > > > One of the developers has created a test procedure to help identify the > > cau= > > se > > of this reported problem. So far we know of two users that can't run the > > te= > > st > > procedure=2C they get a 668 error. All other users we have tried can > > execut= > > e 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=2C 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 > > user= > > s > > to get a 668 error when they run the procedure? Or what I might do to > > resol= > > ve > > this? > > > > { > > Revision Information (Automatically maintained by 'make' - DON'T CHANGE) > > ------------------------------------------------------------------------- > > $Header: procskeleton=2Cv 8.0 2002/05/09 08:36:56 debarthe Released $ > > ------------------------------------------------------------------------- > > } > > drop procedure testsysfail=3B> > > > create procedure testsysfail() > > returning char(32)=3B> > > > {The SQL data type subset includes all the SQL data types except BYTE=2C > > SE= > > RIAL=2C > > and TEXT.} > > {char=2C nchar=2C date=2C datetime=2C decimal=2C numeric=2C float=2C > > intege= > > r=2C money > > smallfloat=2C smallint=2C real=2C varchar=2C nvarchar > > {define global var1 integer default default 0=3B} > > {define var2 like id_rec.ss_no=3B} > > {define var3 char(10)=3B} > > > > define sys_var char(256)=3B > > > > {This exception traps for error 284 multiple records from subquery > > and must immediately follow the defines} > > on exception in (-668) > > > > return "Failed=2C error 668"=3B > > end exception=3B > > > > Set isolation to dirty read=3B> > > > set optimization low=3B > > > > --set debug file to "debugxxx" with append=3B > > --trace on=3B > > -- let sys_var =3D "echo this is a test > /tmp/"||USER||"test.test"=3B > > > > let sys_var =3D "mailx -s 'This is a test' debarthe"=3B > > system sys_var=3B > > > > return "succeded"=3B > > end procedure=3B > > > > grant execute on testsysfail to public=3B> > > > {Add an execute for testing and to try to force optimization} > > > > --execute procedure testsysfail()=3B > > > > > > > > ***************************************************************************= > > > **** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > **************************************************************************** > *** > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --14dae93411db09edfe04cd3398ac > > > **************************************************************************** > *** > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9399c7141fda604cd3405eb

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.

On Mon, Oct 29, 2012 at 6: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. > Note that if the command executed exits with a non-zero exit status, you will get a -668 error (and the ISAM code will be the exit status). This was discussed extensively either in ids@iiug.org or in informix-list@iiug.org a few years ago. So, look hard at whether the scripts you run exit with a non-zero exit status for these two users. That might mean that something goes wrong in the script. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." --f46d0408394d984e2004cd35de67

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

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 o

>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. What's baffling is that these scripts were running fine before upgrading to 11.70.FC4, and "no changes were made to the scripts". 1. What was the previous servers version? 2. Where was it installed? 3. Where's 11.70.FC4 installed? 4. Do the scripts have any hardcoded INFORMIX-specific paths or environment variables being referenced, which could be pointing to the previous version settings? 5. Was 11.70.FC4 installed in a different path location than the previous version? 6. Is previous version still installed and scripts are looking for stuff there?

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/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/X 11:/opt/imake/bin:/opt/less/bin:/opt/ncftp/bin:/opt/pine/bin:/opt/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 getti

Frank 1. What was the previous servers version? IDS 11.50 can't remember which sub-release FC5 maybe 2. Where was it installed? It was installed on out DR/test & production HPUX BL870c server in the same location as old 11.50 version (i.e. over wrote 11.50) 3. Where's 11.70.FC4 installed? $INFORMIXDIR=/opt/informix 4. Do the scripts have any hardcoded INFORMIX-specific paths or environment variables being referenced, which could be pointing to the previous version settings? Very few of our scripts have any hardcoded PATH, almost all rely on $PATH being set when someone logs on. 5. Was 11.70.FC4 installed in a different path location than the previous version? No 6. Is previous version still installed and scripts are looking for stuff there? No WE (me & developers) cannot 100% prove there was not problems prior to the upgrade, our users don't always report problems. :-) We know of no problems prior to the upgrade and one of the procs that fails now a developer was review the script for a possible bug so it was working prior to the upgrade. So, we are guessing that the upgrade caused the problem. John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK J. COMPUTER Sent: Wednesday, October 31, 2012 3:01 AM To: ids@iiug.org Subject: Re: I have a puzzling situation [28681] >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. What's baffling is that these scripts were running fine before upgrading to 11.70.FC4, and "no changes were made to the scripts". 1. What was the previous servers version? 2. Where was it installed? 3. Where's 11.70.FC4 installed? 4. Do the scripts have any hardcoded INFORMIX-specific paths or environment variables being referenced, which could be pointing to the previous version settings? 5. Was 11.70.FC4 installed in a different path location than the previous version? 6. Is previous version still installed and scripts are looking for stuff there? ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

I doubt it is specfically the upgrade causing the issue more likle a difference in the environment used to run the server. To check create a procedure on both servers which just does does SYSTEM "full_path_to_env> > /tmp/1" SYSTEM "full_path_to_ps -ef > /tmp/2" and run on the both servers. Check - environment variables - shell spawned by Informix to run the command - any initialised done by the shell spawned by Informix - lack of resource on the host for the new server so it cannot spawn the command. All SYSTEM calls inside procedures should be only to the full path of a script which starts #!full_path_to_shell and then sets the environment before executing commands. There should be no dependency on $PATH in commands called via SYSTEM, from memory you get the a limited subset of the environment variables that the server got when it was started. The only environment I used to depend on was $INFORMIXSERVER being set to tell me which server I was being called from and I am not sure that is even documented. Regards, David. On 31 October 2012 at 15:12 John Adamski <adamski@graceland.edu> wrote: > Frank > > 1. What was the previous servers version? > IDS 11.50 can't remember which sub-release FC5 maybe > > 2. Where was it installed? > > It was installed on out DR/test & production HPUX BL870c server in the same > location as old 11.50 version (i.e. over wrote 11.50) > > 3. Where's 11.70.FC4 installed? > > $INFORMIXDIR=/opt/informix > > 4. Do the scripts have any hardcoded INFORMIX-specific paths or environment > variables being referenced, which could be pointing to the previous version > settings? > > Very few of our scripts have any hardcoded PATH, almost all rely on $PATH > being set when someone logs on. > > 5. Was 11.70.FC4 installed in a different path location than the previous > version? > > No > > 6. Is previous version still installed and scripts are looking for stuff > there? > > No > > WE (me & developers) cannot 100% prove there was not problems prior to the > upgrade, our users don't always report problems. :-) We know of no problems > prior to the upgrade and one of the procs that fails now a developer was > review the script for a possible bug so it was working prior to the upgrade. > So, we are guessing that the upgrade caused the problem. > > John > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK J. > COMPUTER > Sent: Wednesday, October 31, 2012 3:01 AM > To: ids@iiug.org > Subject: Re: I have a puzzling situation [28681] > > >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. > > What's baffling is that these scripts were running fine before upgrading to > 11.70.FC4, and "no changes were made to the scripts". > > 1. What was the previous servers version? > > 2. Where was it installed? > > 3. Where's 11.70.FC4 installed? > > 4. Do the scripts have any hardcoded INFORMIX-specific paths or environment > variables being referenced, which could be pointing to the previous version > settings? > > 5. Was 11.70.FC4 installed in a different path location than the previous > version? > > 6. Is previous version still installed and scripts are looking for stuff > there? > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

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 t

David, I got some interesting results from this round of testing. I'm using our DR/test server and only this server as I can duplicate all the 'problems' on it. First I simplified the test proc the developer created to just do the system command you suggested. My first test was to do the env command first by itself. Mainly to verify my new proc worked. I ran it on the user that doesn't have the problem and it worked, I than ran on the user that gets the error and they get the error with this one also. I then put in the ps command and now both users get the 668 error, but the one that was able to run the env still got that output. I then changed the proc to only run the ps command and both get the error. I haven't done any more investigation yet. This is the sql code I'm using to generate the proc. 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 "/bin/ps > /tmp/2"; return "succeded"; end procedure; grant execute on testsysfail to public; John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of david@smooth1.co.uk Sent: Wednesday, October 31, 2012 11:03 AM To: ids@iiug.org Subject: RE: I have a puzzling situation [28685] I doubt it is specfically the upgrade causing the issue more likle a difference in the environment used to run the server. To check create a procedure on both servers which just does does SYSTEM "full_path_to_env> > /tmp/1" SYSTEM "full_path_to_ps -ef > /tmp/2" and run on the both servers. Check - environment variables - shell spawned by Informix to run the command - any initialised done by the shell spawned by Informix - lack of resource on the host for the new server so it cannot spawn the command. All SYSTEM calls inside procedures should be only to the full path of a script which starts #!full_path_to_shell and then sets the environment before executing commands. There should be no dependency on $PATH in commands called via SYSTEM, from memory you get the a limited subset of the environment variables that the server got when it was started. The only environment I used to depend on was $INFORMIXSERVER being set to tell me which server I was being called from and I am not sure that is even documented. Regards, David. On 31 October 2012 at 15:12 John Adamski <adamski@graceland.edu> wrote: > Frank > > 1. What was the previous servers version? > IDS 11.50 can't remember which sub-release FC5 maybe > > 2. Where was it installed? > > It was installed on out DR/test & production HPUX BL870c server in the > same location as old 11.50 version (i.e. over wrote 11.50) > > 3. Where's 11.70.FC4 installed? > > $INFORMIXDIR=/opt/informix > > 4. Do the scripts have any hardcoded INFORMIX-specific paths or > environment variables being referenced, which could be pointing to the > previous version settings? > > Very few of our scripts have any hardcoded PATH, almost all rely on > $PATH being set when someone logs on. > > 5. Was 11.70.FC4 installed in a different path location than the > previous version? > > No > > 6. Is previous version still installed and scripts are looking for > stuff there? > > No > > WE (me & developers) cannot 100% prove there was not problems prior to > the upgrade, our users don't always report problems. :-) We know of no > problems prior to the upgrade and one of the procs that fails now a > developer was review the script for a possible bug so it was working prior to the upgrade. > So, we are guessing that the upgrade caused the problem. > > John > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > FRANK J. > COMPUTER > Sent: Wednesday, October 31, 2012 3:01 AM > To: ids@iiug.org > Subject: Re: I have a puzzling situation [28681] > > >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. > > What's baffling is that these scripts were running fine before > upgrading to 11.70.FC4, and "no changes were made to the scripts". > > 1. What was the previous servers version? > > 2. Where was it installed? > > 3. Where's 11.70.FC4 installed? > > 4. Do the scripts have any hardcoded INFORMIX-specific paths or > environment variables being referenced, which could be pointing to the > previous version settings? > > 5. Was 11.70.FC4 installed in a different path location than the > previous version? > > 6. Is previous version still installed and scripts are looking for > stuff there? > > > ******************************************************************************* > 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.

John, Is it possible for you to run this with SYSTEM: SYSTEM " /tmp/test.csh" where you create the file test.csh, in /tmp, containing: #!/bin/csh /usr/bin/id -r > /tmp/test.log echo " " >> /tmp/test.log /usr/bin/id -u >> /tmp/test.log echo " " >> /tmp/test.log /usr/bin/printenv | sort >> /tmp/test.log and then post back to this list the contents of /tmp/test.log (removing anything that is "sensitive" information from what the printenv command generated) Thanks, Jim -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of John Adamski Sent: Wednesday, October 31, 2012 3:12 PM To: ids@iiug.org Subject: RE: I have a puzzling situation [28687] David, I got some interesting results from this round of testing. I'm using our DR/test server and only this server as I can duplicate all the 'problems' on it. First I simplified the test proc the developer created to just do the system command you suggested. My first test was to do the env command first by itself. Mainly to verify my new proc worked. I ran it on the user that doesn't have the problem and it worked, I than ran on the user that gets the error and they get the error with this one also. I then put in the ps command and now both users get the 668 error, but the one that was able to run the env still got that output. I then changed the proc to only run the ps command and both get the error. I haven't done any more investigation yet. This is the sql code I'm using to generate the proc. 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 "/bin/ps > /tmp/2"; return "succeded"; end procedure; grant execute on testsysfail to public; John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of david@smooth1.co.uk Sent: Wednesday, October 31, 2012 11:03 AM To: ids@iiug.org Subject: RE: I have a puzzling situation [28685] I doubt it is specfically the upgrade causing the issue more likle a difference in the environment used to run the server. To check create a procedure on both servers which just does does SYSTEM "full_path_to_env> > /tmp/1" SYSTEM "full_path_to_ps -ef > /tmp/2" and run on the both servers. Check - environment variables - shell spawned by Informix to run the command - any initialised done by the shell spawned by Informix - lack of resource on the host for the new server so it cannot spawn the command. All SYSTEM calls inside procedures should be only to the full path of a script which starts #!full_path_to_shell and then sets the environment before executing commands. There should be no dependency on $PATH in commands called via SYSTEM, from memory you get the a limited subset of the environment variables that the server got when it was started. The only environment I used to depend on was $INFORMIXSERVER being set to tell me which server I was being called from and I am not sure that is even documented. Regards, David. On 31 October 2012 at 15:12 John Adamski <adamski@graceland.edu> wrote: > Frank > > 1. What was the previous servers version? > IDS 11.50 can't remember which sub-release FC5 maybe > > 2. Where was it installed? > > It was installed on out DR/test & production HPUX BL870c server in the > same location as old 11.50 version (i.e. over wrote 11.50) > > 3. Where's 11.70.FC4 installed? > > $INFORMIXDIR=/opt/informix > > 4. Do the scripts have any hardcoded INFORMIX-specific paths or > environment variables being referenced, which could be pointing to the > previous version settings? > > Very few of our scripts have any hardcoded PATH, almost all rely on > $PATH being set when someone logs on. > > 5. Was 11.70.FC4 installed in a different path location than the > previous version? > > No > > 6. Is previous version still installed and scripts are looking for > stuff there? > > No > > WE (me & developers) cannot 100% prove there was not problems prior to > the upgrade, our users don't always report problems. :-) We know of no > problems prior to the upgrade and one of the procs that fails now a > developer was review the script for a possible bug so it was working prior to the upgrade. > So, we are guessing that the upgrade caused the problem. > > John > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > FRANK J. > COMPUTER > Sent: Wednesday, October 31, 2012 3:01 AM > To: ids@iiug.org > Subject: Re: I have a puzzling situation [28681] > > >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. > > What's baffling is that these scripts were running fine before > upgrading to 11.70.FC4, and "no changes were made to the scripts". > > 1. What was the previous servers version? > > 2. Where was it installed? > > 3. Where's 11.70.FC4 installed? > > 4. Do the scripts have any hardcoded INFORMIX-specific paths or > environment variables being referenced, which could be pointing to the > previous version settings? > > 5. Was 11.70.FC4 installed in a different path location than the > previous version? > > 6. Is previous version still installed and scripts are looking for > stuff there? > > > **************************************************************************** *** > 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.

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/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/X 11:/opt/imake/bin:/opt/less/bin:/opt/ncftp/bin:/opt/pine/bin:/opt/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/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/X 11:/opt/imake/bin:/opt/less/bin:/opt/ncftp/bin:/opt/pine/bin:/opt/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-1DBCENTURY=C DBPATH=:OBJ:/opt/carsi/schema/common:/opt/carsi/install/frm/common:.:DBTEMP=/tmp DB_LOCALE=en_US.819 INFORMIXDIR=/opt/informix INFORMIXSERVER=newtLC_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:/opt/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/bin:/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.@@DQ

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-1DBCENTURY=C DBPATH=:OBJ:/opt/carsi/schema/common:/opt/carsi/install/frm/common:.:DBTEMP=/tmp DB_LOCALE=en_US.819 INFORMIXDIR=/opt/informix INFORMIXSERVER=newtLC_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:/opt/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 @@NL@

John, I just found out something about the -668 SYSTEM error problem, that I was having with 1 user only, and I think that it is worth your having this. We do not run the NFS client stuff on our IDS db host system. For users who connect and do NOT run any apps that will use a Stored Procedure with the SYSTEM command in it, the Home Directory of the user is unspecified. However, for users whose apps will use SYSTEM, I have to create a local Home Directory (ex: /home/username) on the IDS host. I just found that our Sys Admins missed setting the Home Dir for the user having the error to a local home directory in an NIS server and, instead, had specified in NIS the NFS mount path for the user's home directory, which he uses when logging in to Linux workstations. When I did an "su" from my shell on the data base host in order to change my user id to that of this user, I got an error complaining about not being able to find his HD. So, I then created a local home directory for the user, got the Admins to fix the HD path field in his entry in NIS to the local dir, and everthing that was failing consistently now works 100%. I think that, at least for my problem, all of the stuff about the Environment for the command that is to be run in the sub-shell is irrelevant to the problem. The SPL SYSTEM command calls the "system()" function in the host system's libraries, that function tries to create the sub-shell, gets this missing HD error, and errors out on the subshell creation without even attempting to try to run what was specified by SYSTEM. Perhaps you could check whether or not your user with the problem has a valid HD on the data base server's host machine? Let me know what happens if you do. Jim -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of John Adamski Sent: Thursday, November 01, 2012 9:09 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-1DBCENTURY=C DBPATH=:OBJ:/opt/carsi/schema/common:/opt/carsi/install/frm/common:.:DBTEMP=/tmp DB_LOCALE=en_US.819 INFORMIXDIR=/opt/informix INFORMIXSERVER=newtLC_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:/opt/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 @@NL

I have loosely followed this tread so this may not apply. When you test as each user are you doing su <testuser> from your normal user login or do you su to root first? I ran into a problem years ago. If I su to root then su to testuser it acted differently than if I su to testuser directly. On 11/1/2012 1:53 PM, jim-cramer@uiowa.edu wrote: > John, > > I just found out something about the -668 SYSTEM error problem, that I was > having with 1 user only, and I think that it is worth your having this. > > We do not run the NFS client stuff on our IDS db host system. For users > who connect and do NOT run any apps that will use a Stored Procedure > with the SYSTEM command in it, the Home Directory of the user is > unspecified. However, for users whose apps will use SYSTEM, I have to > create a local Home Directory (ex: /home/username) on the IDS host. > > I just found that our Sys Admins missed setting the Home Dir for the user > having > the error to a local home directory in an NIS server and, instead, had > specified in NIS the NFS mount path for the user's home directory, which he > uses > when logging in to Linux workstations. > > When I did an "su" from my shell on the data base host in order to change my > user id > to that of this user, I got an error complaining about not being able to > find > his HD. > > So, I then created a local home directory for the user, got the Admins to > fix the HD path field in his entry in NIS to the local dir, and everthing > that > was failing consistently now works 100%. > > I think that, at least for my problem, all of the stuff about the > Environment > for the command that is to be run in the sub-shell is irrelevant to the > problem. > The SPL SYSTEM command calls the "system()" function in the host system's > libraries, > that function tries to create the sub-shell, gets this missing HD error, and > errors > out on the subshell creation without even attempting to try to run what was > specified by SYSTEM. > > Perhaps you could check whether or not your user with the problem has a > valid > HD on the data base server's host machine? > > Let me know what happens if you do. > > Jim > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of John > Adamski > Sent: Thursday, November 01, 2012 9:09 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 >@@NL@

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-1DBCENTURY=C DBPATH=:OBJ:/opt/carsi/schema/common:/opt/carsi/install/frm/common:.:DBTEMP=/tmp DB_LOCALE=en_US.819 INFORMIXDIR=/opt/informix INFORMIXSERVER=newtLC_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:/opt/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/bin:/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@@NL

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-1DBCENTURY=C DBPATH=:OBJ:/opt/carsi/schema/common:/opt/carsi/install/frm/common:.:DBTEMP=/tmp DB_LOCALE=en_US.819 INFORMIXDIR=/opt/informix INFORMIXSERVER=newtLC_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:/opt/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

Hi John, The first id statement in your test.csh might have an error in it, so even when you execute the script correctly, you still get a non-zero exit status. Fix it, i.e. id -ru or id -rg depending on what you want, or explicitly put an exit 0 at the end of the script. It is also good practice to output stderr to the log as well as stdout. This will capture any errors from the commands in the script. e.g. >&test.log instead of just >test.log. This would show you the error with the id statement. You sure have checked a lot of different things. Here a couple more to keep you going. Change your exception handling to set a value containing the actual SQL and ISAM error codes, and include them in your returned string. Check you can successfully execute the script when logged in as each user, without using the stored procedure. Check for the existence of a .informix file in the users home directory, it is another way to get settings into a session. Make sure you are creating the stored procedure as the user Informix. Otherwise, contact tech support cause it might be a bug. HTH, Jason

Jim & Jason The latest results from things you have suggested. I changed the script to also capture the errors (added &), than ran at the shell and in dbaccess for both users. adamski cars: cat /tmp/test.csh #!/bin/csh -f ## printenv | sort >& /tmp/test.log id -rg >>& /tmp/test.log id -ru >>& /tmp/test.log exit 0 adamski cars: ury cars: /tmp/test.csh ury cars: cat /tmp/test.log AUTOTRANS=Y CARSADDR= Lamoni, IA 50140 CARSDB=cars CARSIQPATH=/opt/carsi/iq CARSNAME= Graceland University CARSOBJ=/opt/carsi CARSPATH=/opt/carsi CARSPRINTER=ptledlsr CARSPRINTERS=ptledlsr,ptledl-w,ptactlsr,ptactl-w,ptledmfp,cshprint,ptfinmfp,ptfi nm-w,ptinfmfp,ptinfm-w,sicprinter,sdsprint,email,fileprtr CARSRCS=/opt/carsi CARSSITE=GC CARSV=carsi CARSWSD=/opt/carsi CISCPATH=/opt/carsi COLUMNS=80 DBCENTURY=C DBPATH=:OBJ:/opt/carsi/schema/common:/opt/carsi/install/frm/common:.:HOME=/home/carsids/ury INFORMIXDIR=/opt/informix INFORMIXSERVER=carsitcpIQDIR=/usr/iq JAVA=/opt/java6/bin/java JAVA_HOME=/opt/java6 KRB5CCNAME=FILE:/tmp/krb5cc_16450_16454 LINES=24 LOGNAME=ury MANPATH=/opt/VRTS/vxfs5.0/man:/usr/share/man/%L:/usr/share/man:/usr/contrib/man/ %L:/usr/contrib/man:/usr/local/man/%L:/usr/local/man:/opt/ldapux/share/man/%L:/o pt/ldapux/share/man:/opt/ldapux/ypldapd/man:/opt/ipf/man:/opt/cifsclient/share/m an:/opt/openssl/man:/opt/openssl/prngd/man:/opt/wbem/share/man:/usr/dt/share/man :/opt/samba/man:/opt/samba/WTEC_Support_Tools/man:/opt/resmon/share/man/%L:/opt/ VRTS/man:/opt/graphics/common/man:/opt/sfm/share/man:/opt/hpsmdb/pgsql/man:/opt/ ssh/share/man:/opt/mx/share/man/%L:/opt/mx/share/man:/opt/amgr/man:/opt/amgr/man /%L:/opt/sec_mgmt/share/man:/opt/drd/share/man/%L:/opt/drd/share/man:/opt/dsau/m an:/opt/gnome/man:/opt/ignite/share/man/%L:/opt/ignite/share/man:/opt/sec_mgmt/s hare/man/%L:/opt/swa/share/man/%L:/opt/swa/share/man:/opt/gwlm/man/%L:/opt/gwlm/ man:/opt/aCC/share/man/%L:/opt/audio/share/man:/opt/langtools/share/man/%L:/opt/ langtools/share/man:/opt/perf/man/%L:/opt/perf/man:/opt/image/share/man:/opt/ima ke/man:/opt/samba/cfsm_man:/opt/caliper/man/%L:/opt/caliper/man:/opt/resmon/shar e/man:/opt/propplus/share/man:/usr/contrib/kwdb/share/man:/opt/perl_32/man:/opt/ perl_64/man:/opt/prm/man/%L:/opt/prm/man:/opt/psb/healthtest/share/man:/opt/swm/ share/man/%L:/opt/swm/share/man:/opt/sentinel/man/%L:/opt/sentinel/man:/opt/open ssl/fips/0.9.7/man:/opt/openssl/fips/0.9.8/man:/opt/icod/man/%L:/opt/icod/man:/o pt/aCC/share/man:/opt/cadvise/share/man/%L:/opt/cadvise/share/man:/opt/gnu/man:/ opt/perl/man MENUPATH=/opt/carsi/install/mnu ONCONFIG=onconf.carsPARENTDBS=cars PATH=/opt/carsi/install/cis:/opt/perl514/bin:/bin:/usr/bin:/usr/local/bin:/opt/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/bin:/opt/ytalk/bin /X11:/opt/carstrain/install/scp/graceland/ POSIXLY_CORRECT=1 PROMPT=cars: SACEISOL=DIRTY READ SHELL=/bin/csh SHLIB_PATH=/opt/informix/lib:/opt/informix/lib/tools:/opt/informix/lib/esql:/opt /openssl101/lib:/usr/lib/hpux32 TERM=vt100 TERMBOX=xqlkmj TERMCAP=/opt/carsi/install/sys/etc/termcap TERMINFO=/opt/carsi/install/sys/terminfo TODAY_MINUS_180=05/06/2012 TODAY_PLUS_180=05/01/2013 TXTPATH=/opt/carsi/text TZ=CST6CDT USER=ury UserSource=true WPPATH=/opt/carsi/wp 140 771 ury cars: Then run the procedure testsysfail in dbaccess and get this test.log file, there are some differences. ury cars: cat /tmp/test.log CLIENT_LOCALE=en_US.8859-1DBCENTURY=C DBPATH=:OBJ:/opt/carsi/schema/common:/opt/carsi/install/frm/common:.:DBTEMP=/tmp DB_LOCALE=en_US.819 INFORMIXDIR=/opt/informix INFORMIXSERVER=newtLC_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:/opt/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/bin:/opt/ytalk/bin /X11:/opt/carstrain/install/scp/graceland/ SERVER_LOCALE=en_US.819 SHELL=/bin/csh SQLPID=13835058056570282032 TZ=CST6CDT _=/tmp/test.csh 140 771 ury cars: rm /tmp/test.log ury cars: now to the user that fails. I can run it in the shell. sury cars: /tmp/test.csh sury cars: cat /tmp/test.log AUTOTRANS=Y CARSADDR= Lamoni, IA 50140 CARSDB=cars CARSIQPATH=/opt/carsi/iq CARSNAME= Graceland University CARSOBJ=/opt/carsi CARSPATH=/opt/carsi CARSPRINTER=ptinfmfp CARSPRINTERS=ptinfmfp,ptinfm-w,cshprint,ptledlsr,led3-w,ptactlsr,ptactl-w,ptledm fp,ptledl-w,ptfinmfp,ptfinm-w,sicprinter,sdsprint,email,fileprtr CARSRCS=/opt/carsi CARSSITE=GC CARSV=carsi CARSWSD=/opt/carsi CISCPATH=/opt/carsi COLUMNS=80 DBCENTURY=C DBPATH=:OBJ:/opt/carsi/schema/common:/opt/carsi/install/frm/common:.:HOME=/home/carsids/sury INFORMIXDIR=/opt/informix INFORMIXSERVER=carsitcpIQDIR=/usr/iq JAVA=/opt/java6/bin/java JAVA_HOME=/opt/java6 KRB5CCNAME=FILE:/tmp/krb5cc_16450_16454 LINES=24 LOGNAME=sury MANPATH=/opt/VRTS/vxfs5.0/man:/usr/share/man/%L:/usr/share/man:/usr/contrib/man/ %L:/usr/contrib/man:/usr/local/man/%L:/usr/local/man:/opt/ldapux/share/man/%L:/o pt/ldapux/share/man:/opt/ldapux/ypldapd/man:/opt/ipf/man:/opt/cifsclient/share/m an:/opt/openssl/man:/opt/openssl/prngd/man:/opt/wbem/share/man:/usr/dt/share/man :/opt/samba/man:/opt/samba/WTEC_Support_Tools/man:/opt/resmon/share/man/%L:/opt/ VRTS/man:/opt/graphics/common/man:/opt/sfm/share/man:/opt/hpsmdb/pgsql/man:/opt/ ssh/share/man:/opt/mx/share/man/%L:/opt/mx/share/man:/opt/amgr/man:/opt/amgr/man /%L:/opt/sec_mgmt/share/man:/opt/drd/share/man/%L:/opt/drd/share/man:/opt/dsau/m an:/opt/gnome/man:/opt/ignite/share/man/%L:/opt/ignite/share/man:/opt/sec_mgmt/s hare/man/%L:/opt/swa/share/man/%L:/opt/swa/share/man:/opt/gwlm/man/%L:/opt/gwlm/ man:/opt/aCC/share/man/%L:/opt/audio/share/man:/opt/langtools/share/man/%L:/opt/ langtools/share/man:/opt/perf/man/%L:/opt/perf/man:/opt/image/share/man:/opt/ima ke/man:/opt/samba/cfsm_man:/opt/caliper/man/%L:/opt/caliper/man:/opt/resmon/shar e/man:/opt/propplus/share/man:/usr/contrib/kwdb/share/man:/opt/perl_32/man:/opt/ perl_64/man:/opt/prm/man/%L:/opt/prm/man:/opt/psb/healthtest/share/man:/opt/swm/ share/man/%L:/opt/swm/share/man:/opt/sentinel/man/%L:/opt/sentinel/man:/opt/open ssl/fips/0.9.7/man:/opt/openssl/fips/0.9.8/man:/opt/icod/man/%L:/opt/icod/man:/o pt/aCC/share/man:/opt/cadvise/share/man/%L:/opt/cadvise/share/man:/opt/gnu/man:/ opt/perl/man MENUPATH=/opt/carsi/install/mnu ONCONFIG=onconf.carsPARENTDBS=cars PATH=/opt/carsi/install/cis:/opt/perl514/bin:/bin:/usr/bin:/usr/local/bin:/opt/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/b

Hi John, What might be most helpful for us would be if you could post the exact string, containing whatever is to be run by the shell, which is specified with SYSTEM in the proc. fyi: 1) in case any more questions about the environment for the command run by SYSTEM come up , I am including below what my test.sh script dumped out. However, I am on Linux SLES and you are on HPUX so perhaps the Linux OS does things differently when the use of SPL SYSTEM causes the OS system() function to fork off a shell for running the command specified with SYSTEM in. But I still thought that I would send it in case it helps as a reference to what you see in your test Environment. Also, it raises a couple of questions, And I have a suggestion too. NOTE 1 strange thing in the output, the Env Var near the end of the Env dump is: SHLVL=1 which means that a *login* shell (shell level 1) is being created by the OS to run the command in, which means that not only personal user dot files but system-wide scripts, depending upon the shell which ones, will run. This makes the questions about the shell's Env more complex. 2) Also, I thought that person earlier posted that the command executed in the shell due to the use of SYSTEM in a SP is executed in a *sub*-shell. Perhaps that is true on OS platforms for IDS and not true on others. I did not see the SHLVL Env Var in the Environment listing for your sucessful tests. I guess that you would have to consult man pages for either the HPUX or the particular shell, csh, used in the tests. 3) I seem to remember that you were redirecting standard error to the test's log file. You did that for each of the 3 commands in test.sh, right?. You could try this as the argument to SYSTEM to be run by the SP " /usr/bin/csh -f -v -x -c /tmp/test.sh >& /tmp/test.log " It will start a subshell for the test.sh script, not source in .cshrc and any other dot files, and echo to the log file every command before it executes so that you can see if test.sh even run and, if so, where it dies. The redirection of stdin and stdout on the command line SYSTEM specifies might dump something useful to stderr if it cannot even run the csh subshell. 4) ALSO, check the ~/.history file in the HD of the username that ran the Proc. This might tell you what ran and did not run, or if nothing ran at all. 5) Finally, I discovered that one of the "id" commands I gave you was wrong. "id -r" should have been "id -ru" That command will get the userid of the user under whose id the shell or subshell was created. See if it is the id of the user runing the proc, or else that of informix or root. "id -u" was correct and would give you the "effective" id, which would be different than the "real" if a different userid started up the shell under it's id but made the call to change the "effective" id to that of the user who ran the proc. In my platform and environment, the real id was mine, who ran the test. If that is the case then the "effective" id should be the same and no SETUID business is going on. That is why both ids immediately below for me are my user id, 13008. I would be interested in what the 2 ids turn out to be and who they belong to on your system if you happen to run the test.sh script again. Regards, Jim 13008 13008 CLIENT_LOCALE=en_us.8859-1DBCENTURY=C DBPATH=//ids_npDBTEMP=/tmp DB_LOCALE=en_us.8859-1 INFORMIXDIR=/opt/db/ids INFORMIXSERVER=ids INFORMIXSQLHOSTS=/opt/db/etc/sqlhostsLANG=POSIX LC_COLLATE=POSIX LC_CTYPE=en_US.UTF-8 LC_MONETARY=POSIX LC_NUMERIC=POSIX LC_TIME=POSIX ONCONFIG=onconfig PATH=/opt/bdl3.5r16b/bin:/opt/db/informix/fg_vdt3/bin:/opt/db/informix/fg_vdt3/bin:/opt/bdl3.5r16b/bin:/opt/db/bin:/opt/db/informix/4gltools7.3/bin:/opt /bdl3.5r16b/bin:/opt/db/informix/fg_vdt3/bin:/opt/db/informix/fg_vdt3/bin:/o pt/bdl3.5r16b/bin:/opt/db/bin:/opt/db/informix/4gltools7.3/bin:/opt/bdl3.5r1 6b/bin:/opt/db/informix/fg_vdt3/bin:/opt/db/informix/fg_vdt3/bin:/opt/bdl3.5 r16b/bin:/opt/db/bin:/opt/db/informix/4gltools7.3/bin:/user/eng/jcramer/bin: /usr/local/bin:/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/usr/contrib/bin:/usr/co ntrib/Q4/bin:/opt/perl/bin:/opt/ipf/bin:/opt/mpi/bin:/opt/hparray/bin:/opt/n ettladm/bin:/opt/fcms/bin:/opt/mozilla:/opt/netscape:/usr/local/bin:/opt/sec _mgmt/bastille/bin:/opt/resmon/bin:/opt/gnome/bin:/opt/graphics//phigs/bin:/ usr/bin/X11:/usr/sbin/diag/contrib:/usr/contrib/kwdb/bin:/opt/wbem/bin:/opt/ wbem/sbin:/opt/graphics/common/bin:/opt/sec_mgmt/spc/bin:/opt/mx/bin:/opt/hp smh/bin:/opt/upgrade/bin:/opt/gwlm/bin:/usr/contrib/bin/X11:/opt/aCC/bin:/op t/fortran90/bin:/opt/fortran90/contrib/bin:/opt/perf/bin:/opt/STK/bin:/opt/l angtools/bin:/opt/imake/bin:/usr/ui/class/com PDQPRIORITY=0 PWD=/home/jcramer SERVER_LOCALE=en_us.8859-1 SHELL=/usr/bin/bash SHLVL=1 SQLPID=1470959656 TZ=CST6CDT _=/usr/bin/env: -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of JASON HARRIS Sent: Thursday, November 01, 2012 11:34 PM To: ids@iiug.org Subject: Re: RE: I have a puzzling situation [28695] Hi John, The first id statement in your test.csh might have an error in it, so even when you execute the script correctly, you still get a non-zero exit status. Fix it, i.e. id -ru or id -rg depending on what you want, or explicitly put an exit 0 at the end of the script. It is also good practice to output stderr to the log as well as stdout. This will capture any errors from the commands in the script. e.g. >&test.log instead of just >test.log. This would show you the error with the id statement. You sure have checked a lot of different things. Here a couple more to keep you going. Change your exception handling to set a value containing the actual SQL and ISAM error codes, and include them in your returned string. Check you can successfully execute the script when logged in as each user, without using the stored procedure. Check for the existence of a .informix file in the users home directory, it is another way to get settings into a session. Make sure you are creating the stored procedure as the user Informix. Otherwise, contact tech support cause it might be a bug. HTH, Jason **************************************************************************** *** Forum Note: Use "Reply" to post a response in the discussion forum.

Jim, Here is the code (sql) using in my test procedure: drop procedure testsysfail; create procedure testsysfail() returning char(32); on exception in (-668) return "Failed, error 668"; end exception; SYSTEM " /tmp/test.csh"; return "succeded"; end procedure; grant execute on testsysfail to public; It is based on the production procedure, I just kept the few lines I needed that I thought to get a good equivalent procedure. As you can see the SYSTEM line only has SYSTEM " /tmp/test.csh" And this is the content of the test.csh script: #!/bin/csh -f ## printenv | sort >& /tmp/test.log id -rg >>& /tmp/test.log id -ru >>& /tmp/test.log exit 0 I reran the procedure as both users and get the same results one works one doesn't. I than changed the SYSTEM command to be like your suggestion below " /usr/bin/csh -f -v -x -c /tmp/test.sh >& /tmp/test.log ". I get the 668 error on the user that normally works. I also changed the SYSTEM command to go to test2.log, still get the 668 error. Then I did a which csh and changed the SYSTEM command to use /bin.csh and same results. If I'm understanding your logic, running csh in the SYSTEM should have forced a sub-shel - well that doesn't seem to working. Which might imply one user is getting a sub-shell and the other not. But I can't find any setup that is different between the two users. john -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of jim-cramer@uiowa.edu Sent: Friday, November 02, 2012 12:47 PM To: ids@iiug.org Subject: RE: RE: I have a puzzling situation [28698] Hi John, What might be most helpful for us would be if you could post the exact string, containing whatever is to be run by the shell, which is specified with SYSTEM in the proc. fyi: 1) in case any more questions about the environment for the command run by SYSTEM come up , I am including below what my test.sh script dumped out. However, I am on Linux SLES and you are on HPUX so perhaps the Linux OS does things differently when the use of SPL SYSTEM causes the OS system() function to fork off a shell for running the command specified with SYSTEM in. But I still thought that I would send it in case it helps as a reference to what you see in your test Environment. Also, it raises a couple of questions, And I have a suggestion too. NOTE 1 strange thing in the output, the Env Var near the end of the Env dump is: SHLVL=1 which means that a *login* shell (shell level 1) is being created by the OS to run the command in, which means that not only personal user dot files but system-wide scripts, depending upon the shell which ones, will run. This makes the questions about the shell's Env more complex. 2) Also, I thought that person earlier posted that the command executed in the shell due to the use of SYSTEM in a SP is executed in a *sub*-shell. Perhaps that is true on OS platforms for IDS and not true on others. I did not see the SHLVL Env Var in the Environment listing for your sucessful tests. I guess that you would have to consult man pages for either the HPUX or the particular shell, csh, used in the tests. 3) I seem to remember that you were redirecting standard error to the test's log file. You did that for each of the 3 commands in test.sh, right?. You could try this as the argument to SYSTEM to be run by the SP " /usr/bin/csh -f -v -x -c /tmp/test.sh >& /tmp/test.log " It will start a subshell for the test.sh script, not source in .cshrc and any other dot files, and echo to the log file every command before it executes so that you can see if test.sh even run and, if so, where it dies. The redirection of stdin and stdout on the command line SYSTEM specifies might dump something useful to stderr if it cannot even run the csh subshell. 4) ALSO, check the ~/.history file in the HD of the username that ran the Proc. This might tell you what ran and did not run, or if nothing ran at all. 5) Finally, I discovered that one of the "id" commands I gave you was wrong. "id -r" should have been "id -ru" That command will get the userid of the user under whose id the shell or subshell was created. See if it is the id of the user runing the proc, or else that of informix or root. "id -u" was correct and would give you the "effective" id, which would be different than the "real" if a different userid started up the shell under it's id but made the call to change the "effective" id to that of the user who ran the proc. In my platform and environment, the real id was mine, who ran the test. If that is the case then the "effective" id should be the same and no SETUID business is going on. That is why both ids immediately below for me are my user id, 13008. I would be interested in what the 2 ids turn out to be and who they belong to on your system if you happen to run the test.sh script again. Regards, Jim 13008 13008 CLIENT_LOCALE=en_us.8859-1DBCENTURY=C DBPATH=//ids_npDBTEMP=/tmp DB_LOCALE=en_us.8859-1 INFORMIXDIR=/opt/db/ids INFORMIXSERVER=ids INFORMIXSQLHOSTS=/opt/db/etc/sqlhostsLANG=POSIX LC_COLLATE=POSIX LC_CTYPE=en_US.UTF-8 LC_MONETARY=POSIX LC_NUMERIC=POSIX LC_TIME=POSIX ONCONFIG=onconfig PATH=/opt/bdl3.5r16b/bin:/opt/db/informix/fg_vdt3/bin:/opt/db/informix/fg_vdt3/bin:/opt/bdl3.5r16b/bin:/opt/db/bin:/opt/db/informix/4gltools7.3/bin:/opt /bdl3.5r16b/bin:/opt/db/informix/fg_vdt3/bin:/opt/db/informix/fg_vdt3/bin:/o pt/bdl3.5r16b/bin:/opt/db/bin:/opt/db/informix/4gltools7.3/bin:/opt/bdl3.5r1 6b/bin:/opt/db/informix/fg_vdt3/bin:/opt/db/informix/fg_vdt3/bin:/opt/bdl3.5 r16b/bin:/opt/db/bin:/opt/db/informix/4gltools7.3/bin:/user/eng/jcramer/bin: /usr/local/bin:/usr/bin:/opt/ansic/bin:/usr/ccs/bin:/usr/contrib/bin:/usr/co ntrib/Q4/bin:/opt/perl/bin:/opt/ipf/bin:/opt/mpi/bin:/opt/hparray/bin:/opt/n ettladm/bin:/opt/fcms/bin:/opt/mozilla:/opt/netscape:/usr/local/bin:/opt/sec _mgmt/bastille/bin:/opt/resmon/bin:/opt/gnome/bin:/opt/graphics//phigs/bin:/ usr/bin/X11:/usr/sbin/diag/contrib:/usr/contrib/kwdb/bin:/opt/wbem/bin:/opt/ wbem/sbin:/opt/graphics/common/bin:/opt/sec_mgmt/spc/bin:/opt/mx/bin:/opt/hp smh/bin:/opt/upgrade/bin:/opt/gwlm/bin:/usr/contrib/bin/X11:/opt/aCC/bin:/op t/fortran90/bin:/opt/fortran90/contrib/bin:/opt/perf/bin:/opt/STK/bin:/opt/l angtools/bin:/opt/imake/bin:/usr/ui/class/com PDQPRIORITY=0 PWD=/home/jcramer SERVER_LOCALE=en_us.8859-1 SHELL=/usr/bin/bash SHLVL=1 SQLPID=1470959656 TZ=CST6CDT _=/usr/bin/env: -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of JASON HARRIS Sent: Thursday, November 01, 2012 11:34 PM To: ids@iiug.org Subject: Re: RE: I have a puzzling situation [28695] Hi John, The first id statement in your test.csh might have an error in it, so even when you execute the script correctly, you still get a non-zero exit status. Fi

Original post: Jim, Here is the code (sql) using in my test procedure: drop procedure testsysfail; create procedure testsysfail() returning char(32); on exception in (-668) return "Failed, error 668"; end exception; SYSTEM " /tmp/test.csh"; return "succeded"; end procedure; grant execute on testsysfail to public; It is based on the production procedure, I just kept the few lines I needed that I thought to get a good equivalent procedure. As you can see the SYSTEM line only has SYSTEM " /tmp/test.csh" And this is the content of the test.csh script: #!/bin/csh -f ## printenv | sort >& /tmp/test.log id -rg >>& /tmp/test.log id -ru >>& /tmp/test.log exit 0 I reran the procedure as both users and get the same results one works one doesn't. I than changed the SYSTEM command to be like your suggestion below " /usr/bin/csh -f -v -x -c /tmp/test.sh >& /tmp/test.log ". I get the 668 error on the user that normally works. I also changed the SYSTEM command to go to test2.log, still get the 668 error. Then I did a which csh and changed the SYSTEM command to use /bin.csh and same results. If I'm understanding your logic, running csh in the SYSTEM should have forced a sub-shel - well that doesn't seem to working. Which might imply one user is getting a sub-shell and the other not. But I can't find any setup that is different between the two users. john <stuff removed> Response: Here's an idea you might try. Assuming you have a test instance where you can control the activity, you could try using HP-UX tusc utility. You would want to tusc the adm vp (it's the vp that would be forking and exec'ing the system command for the sql system command). There's a follow fork option that you would want to use (along with others probably) so perhaps you could use the tusc output to see if you might spot differences in what each user session (the working vs non-working) was doing as the OS level or if there was some error in in some of the output that might narrow in on some problem. You'd have to run the tusc command as root, and again you'd want to do it on a system with limited access so the adm vp wouldn't be doing tons of stuff (so it's easier to tell the good output vs bad output). I'll go ahead and warn you the adm vp will generate a decent amount of stuff for signal handling and alarm/time output on it's own, but you should also be able to spot where it does it's fork and then exec of the shell for the system command and if you follow the fork, get output for what you system command is doing. Jacques Renaut IBM Informix Advanced Support APD Team.

With all the tests you have conducted so far, can you rule out that installing 11.70 over 11.50 caused this problem? Perhaps when 11.70 was installed, overlaying 11.50, it wasn't installed exactly the same way as 11.50 was?.. I also suspect the problem has to do with permissions. Can you chmod 777, or other setting, to see if problem goes away? As a general habit, I usually install newer versions in a separate directory, versus overlaying previous versions, to make sure the newer version works before making the transition.

I haven't been following this thread, so it's possible this was already discussed: The way you have created the script seems to lead to a first successful execution and a failure in any other later execution by any other user. The first creates the *.log file and the second will not have permissions to overwrite it. Was this checked before? On Nov 5, 2012 7:11 PM, "JACQUES RENAUT" <jrenaut@us.ibm.com> wrote: > Original post: > > Jim, > > Here is the code (sql) using in my test procedure: > > drop procedure testsysfail;> > create procedure testsysfail() > returning char(32);> > on exception in (-668) > > return "Failed, error 668"; > end exception; > > SYSTEM " /tmp/test.csh"; > > return "succeded"; > end procedure; > > grant execute on testsysfail to public;> > It is based on the production procedure, I just kept the few lines I needed > that I thought to get a good equivalent procedure. As you can see the > SYSTEM > line only has SYSTEM " /tmp/test.csh" > > And this is the content of the test.csh script: > > #!/bin/csh -f > ## > printenv | sort >& /tmp/test.log > > id -rg >>& /tmp/test.log > > id -ru >>& /tmp/test.log > > exit 0 > > I reran the procedure as both users and get the same results one works one > doesn't. > > I than changed the SYSTEM command to be like your suggestion below " > /usr/bin/csh -f -v -x -c /tmp/test.sh >& /tmp/test.log ". I get the 668 > error > on the user that normally works. I also changed the SYSTEM command to go to > test2.log, still get the 668 error. Then I did a which csh and changed the > SYSTEM command to use /bin.csh and same results. > > If I'm understanding your logic, running csh in the SYSTEM should have > forced > a sub-shel - well that doesn't seem to working. Which might imply one user > is > getting a sub-shell and the other not. But I can't find any setup that is > different between the two users. > > john > > <stuff removed> > > Response: > > Here's an idea you might try. Assuming you have a test instance where you > can > control the activity, you could try using HP-UX tusc utility. You would > want > to tusc the adm vp (it's the vp that would be forking and exec'ing the > system > command for the sql system command). There's a follow fork option that you > would want to use (along with others probably) so perhaps you could use the > tusc output to see if you might spot differences in what each user session > (the working vs non-working) was doing as the OS level or if there was some > error in in some of the output that might narrow in on some problem. You'd > have to run the tusc command as root, and again you'd want to do it on a > system with limited access so the adm vp wouldn't be doing tons of stuff > (so > it's easier to tell the good output vs bad output). I'll go ahead and warn > you > the adm vp will generate a decent amount of stuff for signal handling and > alarm/time output on it's own, but you should also be able to spot where it > does it's fork and then exec of the shell for the system command and if you > follow the fork, get output for what you system command is doing. > > Jacques Renaut > IBM Informix Advanced Support > APD Team. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --20cf3074b6929ac33b04cdcebaf5

Add this to the script (at the top just after the csh header: exec 2 > /tmp/error_$$.log Then look for the last error_*.log file after failure... Hopefully it will contain the error in the script... Again, this was probably suggested before... On Nov 6, 2012 5:07 AM, "FRANK J. COMPUTER" <frank_in_pr@hotmail.com> wrote: > With all the tests you have conducted so far, can you rule out that > installing > 11.70 over 11.50 caused this problem? Perhaps when 11.70 was installed, > overlaying 11.50, it wasn't installed exactly the same way as 11.50 was?.. > I > also suspect the problem has to do with permissions. Can you chmod 777, or > other setting, to see if problem goes away? As a general habit, I usually > install newer versions in a separate directory, versus overlaying previous > versions, to make sure the newer version works before making the > transition. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --047d7b6d8b288047c804cdced023

On Mon, Nov 5, 2012 at 11:47 PM, Fernando Nunes <domusonline@gmail.com>wrote: > Add this to the script (at the top just after the csh header: > Was 'csh' a typo or has it been discussed before and I missed it? Has any checking been done on which shell the different users are configured to use? IIRC, IDS looks up the shell for the user in the password file entry (at least for regular users), and uses that to run the script. exec 2 > /tmp/error_$$.log > That wouldn't work in a csh script, AFAIK. > Then look for the last error_*.log file after failure... Hopefully it will > contain the error in the script... > Again, this was probably suggested before... > On Nov 6, 2012 5:07 AM, "FRANK J. COMPUTER" <frank_in_pr@hotmail.com> > wrote: > > > With all the tests you have conducted so far, can you rule out that > > installing > > 11.70 over 11.50 caused this problem? Perhaps when 11.70 was installed, > > overlaying 11.50, it wasn't installed exactly the same way as 11.50 was? > I > > also suspect the problem has to do with permissions. Can you chmod 777, > or > > other setting, to see if problem goes away? As a general habit, I usually > > install newer versions in a separate directory, versus overlaying > previous > > versions, to make sure the newer version works before making the > > transition. > -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." --f46d040121717860b004cdd60e9c

On Tue, Nov 6, 2012 at 4:26 PM, Jonathan Leffler <jonathan.leffler@gmail.com > wrote: > On Mon, Nov 5, 2012 at 11:47 PM, Fernando Nunes <domusonline@gmail.com > >wrote: > > > Add this to the script (at the top just after the csh header: > > > > Was 'csh' a typo or has it been discussed before and I missed it? Has any > checking been done on which shell the different users are configured to > use? IIRC, IDS looks up the shell for the user in the password file entry > (at least for regular users), and uses that to run the script. > > exec 2 > /tmp/error_$$.log > > > > That wouldn't work in a csh script, AFAIK. > > True... I should have tested it. In any case the point was that the user who tries to recreate the file will probably fail... Also check the shells as suggested. Regards -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --485b397dd4d990336404cdd6a598

Jacques It probably been 5-6 years since I last used tusc so will take me a little to clean out the cobwebs in my brain. But I do have a test/DR system I can use that usually only has me on it. I see there are a number of other replies so will go check them out. I hope to have time tomorrow to figure out tusc and try your suggestion. John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of JACQUES RENAUT Sent: Monday, November 05, 2012 1:11 PM To: ids@iiug.org Subject: Re: RE: RE: I have a puzzling situation [28704] Original post: Jim, Here is the code (sql) using in my test procedure: drop procedure testsysfail; create procedure testsysfail() returning char(32); on exception in (-668) return "Failed, error 668"; end exception; SYSTEM " /tmp/test.csh"; return "succeded"; end procedure; grant execute on testsysfail to public; It is based on the production procedure, I just kept the few lines I needed that I thought to get a good equivalent procedure. As you can see the SYSTEM line only has SYSTEM " /tmp/test.csh" And this is the content of the test.csh script: #!/bin/csh -f ## printenv | sort >& /tmp/test.log id -rg >>& /tmp/test.log id -ru >>& /tmp/test.log exit 0 I reran the procedure as both users and get the same results one works one doesn't. I than changed the SYSTEM command to be like your suggestion below " /usr/bin/csh -f -v -x -c /tmp/test.sh >& /tmp/test.log ". I get the 668 error on the user that normally works. I also changed the SYSTEM command to go to test2.log, still get the 668 error. Then I did a which csh and changed the SYSTEM command to use /bin.csh and same results. If I'm understanding your logic, running csh in the SYSTEM should have forced a sub-shel - well that doesn't seem to working. Which might imply one user is getting a sub-shell and the other not. But I can't find any setup that is different between the two users. john <stuff removed> Response: Here's an idea you might try. Assuming you have a test instance where you can control the activity, you could try using HP-UX tusc utility. You would want to tusc the adm vp (it's the vp that would be forking and exec'ing the system command for the sql system command). There's a follow fork option that you would want to use (along with others probably) so perhaps you could use the tusc output to see if you might spot differences in what each user session (the working vs non-working) was doing as the OS level or if there was some error in in some of the output that might narrow in on some problem. You'd have to run the tusc command as root, and again you'd want to do it on a system with limited access so the adm vp wouldn't be doing tons of stuff (so it's easier to tell the good output vs bad output). I'll go ahead and warn you the adm vp will generate a decent amount of stuff for signal handling and alarm/time output on it's own, but you should also be able to spot where it does it's fork and then exec of the shell for the system command and if you follow the fork, get output for what you system command is doing. Jacques Renaut IBM Informix Advanced Support APD Team. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Frank, Right now I can't remember how I did the production server and will have to see if my notes suggestion what I did. But I think I deleted everything out of /opt/Informix. I need to double check though as I honestly can't remember. About your question on chmod 777, I could do this on our test/dr server, as I have a request from the developers for the refresh. I might wait to do as a last resort and not sure what problem that might create. Don't want the cure to be worse than the problem. :-) John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK J. COMPUTER Sent: Monday, November 05, 2012 11:08 PM To: ids@iiug.org Subject: Re: RE: RE: I have a puzzling situation [28706] With all the tests you have conducted so far, can you rule out that installing 11.70 over 11.50 caused this problem? Perhaps when 11.70 was installed, overlaying 11.50, it wasn't installed exactly the same way as 11.50 was?.. I also suspect the problem has to do with permissions. Can you chmod 777, or other setting, to see if problem goes away? As a general habit, I usually install newer versions in a separate directory, versus overlaying previous versions, to make sure the newer version works before making the transition. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Fernando, To answer your other post question - I delete all *.log files between users so I have the same setup for each. I tried added your suggested line exec 2 > /tmp/error_$$.log and both users fail. I will double check tomorrow I didn't typo something. Today's been meeting day and I'm in between two right now and trying to do this fast. John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Fernando Nunes Sent: Tuesday, November 06, 2012 1:48 AM To: ids@iiug.org Subject: Re: RE: RE: I have a puzzling situation [28708] Add this to the script (at the top just after the csh header: exec 2 > /tmp/error_$$.log Then look for the last error_*.log file after failure... Hopefully it will contain the error in the script... Again, this was probably suggested before... On Nov 6, 2012 5:07 AM, "FRANK J. COMPUTER" <frank_in_pr@hotmail.com> wrote: > With all the tests you have conducted so far, can you rule out that > installing > 11.70 over 11.50 caused this problem? Perhaps when 11.70 was > installed, overlaying 11.50, it wasn't installed exactly the same way as 11.50 was?.. > I > also suspect the problem has to do with permissions. Can you chmod > 777, or other setting, to see if problem goes away? As a general > habit, I usually install newer versions in a separate directory, > versus overlaying previous versions, to make sure the newer version > works before making the transition. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --047d7b6d8b288047c804cdced023 ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Jonathan, All users use the csh (C shell), our ERP required us to choose between the csh or the ksh when we installed it around 1999. The csh was chosen. The only exception might be root or similar special account like daemon. Normal user have /bin/csh in the passwd file - the two users have /bin/csh Root has /sbin/sh in the passwd file. I'll check the permission on this tomorrow. Off to my last meeting of the day. Ya!!!! John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Jonathan Leffler Sent: Tuesday, November 06, 2012 10:26 AM To: ids@iiug.org Subject: Re: RE: RE: I have a puzzling situation [28709] On Mon, Nov 5, 2012 at 11:47 PM, Fernando Nunes <domusonline@gmail.com>wrote: > Add this to the script (at the top just after the csh header: > Was 'csh' a typo or has it been discussed before and I missed it? Has any checking been done on which shell the different users are configured to use? IIRC, IDS looks up the shell for the user in the password file entry (at least for regular users), and uses that to run the script. exec 2 > /tmp/error_$$.log > That wouldn't work in a csh script, AFAIK. > Then look for the last error_*.log file after failure... Hopefully it > will contain the error in the script... > Again, this was probably suggested before... > On Nov 6, 2012 5:07 AM, "FRANK J. COMPUTER" <frank_in_pr@hotmail.com> > wrote: > > > With all the tests you have conducted so far, can you rule out that > > installing > > 11.70 over 11.50 caused this problem? Perhaps when 11.70 was > > installed, overlaying 11.50, it wasn't installed exactly the same way as 11.50 was? > I > > also suspect the problem has to do with permissions. Can you chmod > > 777, > or > > other setting, to see if problem goes away? As a general habit, I > > usually install newer versions in a separate directory, versus > > overlaying > previous > > versions, to make sure the newer version works before making the > > transition. > -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." --f46d040121717860b004cdd60e9c ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

John Answered >>> All users use the csh (C shell), our ERP required us to choose between the csh or the ksh when we installed it around 1999. The csh was chosen. The only exception might be root or similar special account like daemon. Normal user have /bin/csh in the passwd file - the two users have /bin/csh Root has /sbin/sh in the passwd file. I'll check the permission on this tomorrow. Off to my last meeting of the day. Ya!!!! John >>> Shell settings have remained unchanged since 1999, but everything was working until upgrading from 11.50 to 11.70. Have you done a diff on each users .profile and on all the environment variables to see if the 11.70 install changed anything? What is different about the two users whose scripts are failing, compared to the rest of the users whose scripts don't fail?

Frank, I have yet to find anything that is different in the two users besides username and uid. adamski cars# diff ~ury/.profile ~sury/.profile adamski cars# diff ~ury/.cshrc ~sury/.cshrc adamski cars# diff ~ury/.login ~sury/.login adamski cars# grep ury /etc/passwd ury:*:771:140:Reta Ury:/home/carsids/ury:/bin/csh sury:*:1039:140:Stacie Ury:/home/carsids/sury:/bin/csh -rw-r--r-- 1 ury financial 243 Nov 7 2003 /home/carsids/ury/.profile -rw-r--r-- 1 sury financial 243 Mar 26 2007 /home/carsids/sury/.profile -rw-r--r-- 1 ury financial 347 Nov 7 2003 /home/carsids/ury/.cshrc -rw-r--r-- 1 sury financial 347 Mar 26 2007 /home/carsids/sury/.cshrc -r--r--r-- 1 root financial 317 Oct 29 10:53 /home/carsids/ury/.login -r--r--r-- 1 root financial 317 Oct 29 10:52 /home/carsids/sury/.login John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK J. COMPUTER Sent: Tuesday, November 06, 2012 6:40 PM To: ids@iiug.org Subject: Re: RE: RE: RE: I have a puzzling situation [28719] John Answered >>> All users use the csh (C shell), our ERP required us to choose between the csh or the ksh when we installed it around 1999. The csh was chosen. The only exception might be root or similar special account like daemon. Normal user have /bin/csh in the passwd file - the two users have /bin/csh Root has /sbin/sh in the passwd file. I'll check the permission on this tomorrow. Off to my last meeting of the day. Ya!!!! John >>> Shell settings have remained unchanged since 1999, but everything was working until upgrading from 11.50 to 11.70. Have you done a diff on each users ..profile and on all the environment variables to see if the 11.70 install changed anything? What is different about the two users whose scripts are failing, compared to the rest of the users whose scripts don't fail? ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Jacques I got a chance this morning to run tusc for both the uses. If I did it correctly here is the output from running it on the two test users. onstat -g glo IBM Informix Dynamic Server Version 11.70.FC4 -- On-Line -- Up 27 days 00:55:54 -- 1076296 Kbytes MT global info: sessions threads vps lngspins 0 73 17 0 sched calls thread switches yield 0 yield n yield forever total: 1407334795 132198003 1279812992 99794471 6475162 per sec: 0 0 0 0 0 Virtual processor summary: class vps usercpu syscpu total cpu 6 41932.54 248.43 42180.97 aio 1 3.73 12.11 15.84 lio 1 3.32 9.85 13.17 pio 1 3.24 10.08 13.32 adm 1 115.33 67.39 182.72 soc 5 82.06 241.21 323.27 msc 1 0.08 0.10 0.18 fifo 1 3.24 9.87 13.11 total 17 42143.54 599.04 42742.58 Individual virtual processors: vp pid class usercpu syscpu total Thread Eff 1 3737 cpu 798.41 31.10 829.51 889.49 93% 2 3834 adm 115.33 67.39 182.72 0.00 0% 3 3835 lio 3.32 9.85 13.17 13.17 100% 4 3839 pio 3.24 10.08 13.32 13.32 100% 5 3845 aio 3.73 12.11 15.84 15.84 100% 6 3848 msc 0.08 0.10 0.18 0.24 74% 7 3860 fifo 3.24 9.87 13.11 13.11 100% 8 3889 cpu 1492.38 40.75 1533.13 1598.08 95% 9 3891 cpu 1039.38 36.84 1076.22 1104.90 97% 10 3893 cpu 14266.45 53.33 14319.78 14456.13 99% 11 3899 cpu 11374.88 40.81 11415.69 11620.67 98% 12 3902 cpu 12961.04 45.60 13006.64 13176.86 98% 13 3903 soc 18.50 52.39 70.89 NA NA 14 3904 soc 17.23 51.24 68.47 NA NA 15 3905 soc 17.17 51.03 68.20 NA NA 16 3906 soc 17.40 51.20 68.60 NA NA 17 3907 soc 11.76 35.35 47.11 NA NA tot 42143.54 599.04 42742.58 tusc -f -o /var/adm/crash/jda_tmp/tusc.log 3834 for ury the one that works I get this: setgid(140) .............................................. = 0 setgroups(14, 0xc0000000414ad5f0) ........................ = 0 setuid(771) .............................................. = 0 umask(07) ................................................ = 07 chdir("/home/carsids/ury") ............................... = 0 execve("/bin/sh", 0xc000000047b213a0, 0xc000000049d91ec0) = 0 [32-bit] mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7d7fa000 open("/usr/lib/hpux32/dld.so", O_RDONLY, 0) .............. = 3 read(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 1024) ...... = 1024 mmap(NULL, 752624, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_FILE|MAP_SHLIB, 3, 0) = 0xc0040000 sysconf(_SC_PAGE_SIZE) ................................... = 4096 mmap(NULL, 7384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_SHLIB, -1, 0) = 0x7d7f8000 mmap(0x7d7f5000, 12120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FILE|MAP_SHLIB, 3, 786432) = 0x7d7f5000 close(3) ................................................. = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7d7f2000 sysconf(_SC_PAGE_SIZE) ................................... = 4096 stat("/usr/lib/hpux32/dpd", 0x7ffff7f0) .................. = 0 open("/usr/lib/hpux32/dpd", O_RDONLY, 0) ................. = 3 fcntl(3, F_SETFD, 0) ..................................... = 0 mmap(NULL, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7d7ec000 getdents(3, 0x7d7ec028, 8192) ............................ = 80 getdents(3, 0x7d7ec028, 8192) ............................ = 0 close(3) ................................................. = 0 getuid() ................................................. = 771 (771) getgid() ................................................. = 140 (140) open("/bin/sh", O_RDONLY, 0) ............................. = 3 pread(3, "\\\\0\\\\0\\\\002\\\\0\\\\0\\\\0, \\\\0\\\\0\\\\0\\\\aH P \\\\0\\\\0".., 60, 436) .. = 60 close(3) ................................................. = 0 utssys(0x7fffec40, 60, 0) ................................ = 0 procxsec(4, -1, 0x7fffec10, 40) .......................... = 0 open("/usr/lib/hpux32/libc.so.1", O_RDONLY, 0) ........... = 3 fstat(3, 0x7ffff730) ..................................... = 0 read(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 52) ........ = 52 pread(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 1024, 0) .. = 1024 mmap(NULL, 2987424, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_SHLIB, 3, 0) = 0xc0300000 madvise(0xc0300000, 0x2d95a0, MADV_NORMAL) ............... = 0 mmap(NULL, 47784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_SHLIB, -1, 0) = 0x7d7e0000 mmap(0x7d7d8000, 29796, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_SHLIB, 3, 3014656) = 0x7d7d8000 close(3) ................................................. = 0 mmap(NULL, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7d7d4000 open("/usr/lib/hpux32/libdl.so.1", O_RDONLY, 0) .......... = 3 fstat(3, 0x7ffff730) ..................................... = 0 read(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 52) ........ = 52 pread(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 1024, 0) .. = 1024 mmap(NULL, 16080, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_SHLIB, 3, 0) = 0xc0004000 mmap(NULL, 224, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_SHLIB, 3, 65536) = 0x7d7fe000 close(3) ................................................. = 0 sigsetreturn(NULL, 0x6211988, 48640) ..................... = 0 mmap(NULL, 3336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7d7f4000 sysconf(_SC_CPU_VERSION) ................................. = 768 sigprocmask(SIG_SETMASK, 0x7ffff7e0, 0x7ffff800) ......... = 0 brk(0x4001cbc0) .......................................... = 0 brk(0x4001ebb0) .......................................... = 0 brk(0x40020000) .......................................... = 0 sigprocmask(SIG_SETMASK, 0x7ffff800, 0x7ffff7e0) ......... = 0 sigprocmask(SIG_SETMASK, 0x7fffdad0, 0x7fffdaf0) ......... = 0 brk(0x40021000) .......................................... = 0 sigprocmask(SIG_SETMASK, 0x7fffdaf0, 0x7fffdad0) ......... = 0 sigprocmask(SIG_SETMASK, 0x7fffdad0, 0x7fffdaf0) ......... = 0 sigprocmask(SIG_SETMASK, 0x7fffdaf0, 0x7fffdad0) ......... = 0 open("/usr/lib/nls/loc/hpux32/locales.3/en_US.iso88591", O_RDONLY, 0) = 3 fstat(3, 0x7fffcff0) ..................................... = 0 pread(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 1024, 0) .. = 1024 stat("/usr/lib/hpux32/dpd", 0x7fffc610) .................. = 0 open("/usr/lib/hpux32/dpd/en_US.iso88591.bpd", O_RDONLY, 0) ERR#2 ENOENT mmap(NULL, 5952, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_SHLIB, 3, 0) = 0xc0bfe000 mmap(NULL, 14808, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_SHLIB, 3, 65536) = 0x7d7d0000 close(3) ................................................. = 0 stat("/usr/lib/nls/loc/hpux32/locales.3/en_US.iso88591", 0x7fffd5c0) = 0 sigprocmask(SIG_SETMASK, 0x7fffdad0, 0x7fffdaf0) ......... = 0 sigprocmask(SIG_SETMASK, 0x7fffdaf0, 0x7fffdad0) ......... = 0 open("/usr/lib/nls/loc/hpux32/locales.3/C", O_RDONLY, 0) . ERR#2 ENOENT sigprocmask(SIG_SETMASK, 0x7fffdad0, 0x7fffdaf0) ......... = 0 sigprocmask(SIG_SETMASK, 0x7fffda80, 0x7fffdaa0) ......... = 0 brk(0x40022000) .......................................... = 0 sigprocmask(SIG_SETMASK, 0x7fffdaa0, 0x7fffda80) ......... = 0 s

John: I don't see a setuid() call for the user that fails! That is strange! 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 Wed, Nov 7, 2012 at 9:38 AM, John Adamski <adamski@graceland.edu> wrote: > Jacques > > I got a chance this morning to run tusc for both the uses. If I did it > correctly here is the output from running it on the two test users. > > onstat -g glo> > IBM Informix Dynamic Server Version 11.70.FC4 -- On-Line -- Up 27 days > 00:55:54 -- 1076296 Kbytes> > MT global info: > sessions threads vps lngspins > 0 73 17 0 > > sched calls thread switches yield 0 yield n yield forever > total: 1407334795 132198003 1279812992 99794471 6475162 > per sec: 0 0 0 0 0 > > Virtual processor summary: > class vps usercpu syscpu total > cpu 6 41932.54 248.43 42180.97 > aio 1 3.73 12.11 15.84 > lio 1 3.32 9.85 13.17 > pio 1 3.24 10.08 13.32 > adm 1 115.33 67.39 182.72 > soc 5 82.06 241.21 323.27 > msc 1 0.08 0.10 0.18 > fifo 1 3.24 9.87 13.11 > total 17 42143.54 599.04 42742.58 > > Individual virtual processors: > vp pid class usercpu syscpu total Thread Eff > 1 3737 cpu 798.41 31.10 829.51 889.49 93% > 2 3834 adm 115.33 67.39 182.72 0.00 0% > 3 3835 lio 3.32 9.85 13.17 13.17 100% > 4 3839 pio 3.24 10.08 13.32 13.32 100% > 5 3845 aio 3.73 12.11 15.84 15.84 100% > 6 3848 msc 0.08 0.10 0.18 0.24 74% > 7 3860 fifo 3.24 9.87 13.11 13.11 100% > 8 3889 cpu 1492.38 40.75 1533.13 1598.08 95% > 9 3891 cpu 1039.38 36.84 1076.22 1104.90 97% > 10 3893 cpu 14266.45 53.33 14319.78 14456.13 99% > 11 3899 cpu 11374.88 40.81 11415.69 11620.67 98% > 12 3902 cpu 12961.04 45.60 13006.64 13176.86 98% > 13 3903 soc 18.50 52.39 70.89 NA NA > 14 3904 soc 17.23 51.24 68.47 NA NA > 15 3905 soc 17.17 51.03 68.20 NA NA > 16 3906 soc 17.40 51.20 68.60 NA NA > 17 3907 soc 11.76 35.35 47.11 NA NA > > tot 42143.54 599.04 42742.58 > > tusc -f -o /var/adm/crash/jda_tmp/tusc.log 3834 > > for ury the one that works I get this: > > setgid(140) .............................................. = 0 > setgroups(14, 0xc0000000414ad5f0) ........................ = 0 > setuid(771) .............................................. = 0 > umask(07) ................................................ = 07 > chdir("/home/carsids/ury") ............................... = 0 > execve("/bin/sh", 0xc000000047b213a0, 0xc000000049d91ec0) = 0 [32-bit] > mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x7d7fa000 > open("/usr/lib/hpux32/dld.so", O_RDONLY, 0) .............. = 3 > read(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 1024) ...... = 1024 > mmap(NULL, 752624, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_FILE|MAP_SHLIB, 3, > 0) = > 0xc0040000 > sysconf(_SC_PAGE_SIZE) ................................... = 4096 > mmap(NULL, 7384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_SHLIB, > -1, 0) = 0x7d7f8000 > mmap(0x7d7f5000, 12120, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FILE|MAP_SHLIB, > 3, 786432) = 0x7d7f5000 > close(3) ................................................. = 0 > mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x7d7f2000 > sysconf(_SC_PAGE_SIZE) ................................... = 4096 > stat("/usr/lib/hpux32/dpd", 0x7ffff7f0) .................. = 0 > open("/usr/lib/hpux32/dpd", O_RDONLY, 0) ................. = 3 > fcntl(3, F_SETFD, 0) ..................................... = 0 > mmap(NULL, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, > MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x7d7ec000 > getdents(3, 0x7d7ec028, 8192) ............................ = 80 > getdents(3, 0x7d7ec028, 8192) ............................ = 0 > close(3) ................................................. = 0 > getuid() ................................................. = 771 (771) > getgid() ................................................. = 140 (140) > open("/bin/sh", O_RDONLY, 0) ............................. = 3 > pread(3, "\\\\0\\\\0\\\\002\\\\0\\\\0\\\\0, \\\\0\\\\0\\\\0\\\\aH P \\\\0\\\\0".., 60, 436) .. = 60 > close(3) ................................................. = 0 > utssys(0x7fffec40, 60, 0) ................................ = 0 > procxsec(4, -1, 0x7fffec10, 40) .......................... = 0 > open("/usr/lib/hpux32/libc.so.1", O_RDONLY, 0) ........... = 3 > fstat(3, 0x7ffff730) ..................................... = 0 > read(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 52) ........ = 52 > pread(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 1024, 0) .. = 1024 > mmap(NULL, 2987424, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_SHLIB, 3, 0) = > 0xc0300000 > madvise(0xc0300000, 0x2d95a0, MADV_NORMAL) ............... = 0 > mmap(NULL, 47784, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS|MAP_SHLIB, > -1, 0) = 0x7d7e0000 > mmap(0x7d7d8000, 29796, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_SHLIB, 3, > 3014656) = 0x7d7d8000 > close(3) ................................................. = 0 > mmap(NULL, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, > MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x7d7d4000 > open("/usr/lib/hpux32/libdl.so.1", O_RDONLY, 0) .......... = 3 > fstat(3, 0x7ffff730) ..................................... = 0 > read(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 52) ........ = 52 > pread(3, "7fE L F 0102010101\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0\\\\0".., 1024, 0) .. = 1024 > mmap(NULL, 16080, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_SHLIB, 3, 0) = > 0xc0004000 > mmap(NULL, 224, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_SHLIB, 3, 65536) = > 0x7d7fe000 > close(3) ................................................. = 0 > sigsetreturn(NULL, 0x6211988, 48640) ..................... = 0 > mmap(NULL, 3336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x7d7f4000 > sysconf(_SC_CPU_VERSION) ................................. = 768 > sigprocmask(SIG_SETMASK, 0x7ffff7e0, 0x7ffff800) ......... = 0 > brk(0x4001cbc0) .......................................... = 0 > brk(0x4001ebb0) .......................................... = 0 > brk(0x40020000) .......................................... = 0 > sigprocmask(SIG_SETMASK, 0x7ffff800, 0x7ffff7e0) ......... = 0 > sigprocmask(SIG_SETMASK, 0x7fffdad0, 0x7fffdaf0) ......... = 0 > brk(0x40021000) .......................................... = 0 > sigprocmask(SIG_SETMASK, 0x7fffdaf0, 0x7fffdad0) ......... = 0 > sigprocmask(SIG_SETMASK, 0x7fffdad0, 0x7fffdaf0) ......... = 0 > sigprocmask(SIG_SETMASK, 0x7fffdaf0, 0x7fffdad0) ......... = 0 > open("/usr/lib/nls/loc/hpux32/locales.3/en_US.iso88591", O_RDONLY, 0) = 3 > fstat(3, 0x7fffcff0) ..................................... = 0 > pread(3, "7fE L F 0102010101\\\\0\\\\0\\\\

Original Post: Jacques I got a chance this morning to run tusc for both the uses. If I did it correctly here is the output from running it on the two test users. <stuff removed> tusc -f -o /var/adm/crash/jda_tmp/tusc.log 3834 for ury the one that works I get this: setgid(140) .............................................. = 0 setgroups(14, 0xc0000000414ad5f0) ........................ = 0 setuid(771) .............................................. = 0 umask(07) ................................................ = 07 chdir("/home/carsids/ury") ............................... = 0 execve("/bin/sh", 0xc000000047b213a0, 0xc000000049d91ec0) = 0 [32-bit] <stuff removed> It goes on a lot more sury the one that fails I get this: setgid(140) .............................................. = 0 setgroups(21, 0xc000000041eab510) ........................ ERR#22 EINVAL sigprocmask(SIG_BLOCK, 0x6000000000363790, NULL) ......... = 0 alarm(0) ................................................. = 0 sigaction(SIGALRM, 0x60000000003637e0, NULL) ............. = 0 sigprocmask(SIG_UNBLOCK, 0x60000000003637c0, NULL) ....... = 0 sigaction(SIGALRM, 0x6000000000363810, NULL) ............. = 0 getpid() ................................................. = 2247 (3834) exit(131) ................................................ WIFEXITED(131) Received signal 18, SIGCLD, in pause(), [caught] Siginfo: child pid 2247, CLD_EXITED (status 131), si_errno: 0 pause() .................................................. ERR#4 EINTR waitpid(-1, WIFEXITED(131), WNOHANG) ..................... = 2247 sigprocmask(SIG_BLOCK, 0x6000000000363580, NULL) ......... = 0 semop(55, 0x6000000000363590, 1) ......................... = 0 sigprocmask(SIG_UNBLOCK, 0x6000000000363580, NULL) ....... = 0 waitpid(-1, WIFEXITED(131), WNOHANG) ..................... = 0 Received signal 14, SIGALRM, in pause(), [caught], no siginfo pause() .................................................. ERR#4 EINTR time(0xc000000040625c60) ................................. = 1352299862 It looks like the setgroups() is different and not sure what that means or where it gets the values from. John Response: John, Let me take a look at this a bit, but from a quick first glance this looks to me like the server is not even getting to where it tried to exec the shell for the 2nd failed user and it does have something to do with the failing OS setgroups() call. I want to confirm that, and then see if I can track down what that might mean and how the server is determining if/what it should be doing. One thing you might check is since it appears to be related to groups, are both uses only in the same groups in the /etc/groups file (not just the original group from the /etc/passwd file, but if they are listed as members of any other groups...so what if any differences they have if you are just logged in as either user and ran the groups command). Jacques Renaut IBM Informix Advanced Support APD Team

Original post: Jacques I got a chance this morning to run tusc for both the uses. If I did it correctly here is the output from running it on the two test users. <stuff removed> John Response: I got on one of our itanium machines and did a man on setgroups() and it says it will return EINVAL if the 1st arg (21 in your case for the failing user) is greater then NGROUPS_MAX as defined in <limits.h>. On the machine I was looking at, NGROUPS_MAX was defined as 20 in /usr/include/limits.h>. So I'm going to guess that the user that is failing is assigned to 21 different groups in your /etc/groups file, which is causing the setgroups() call to fail which makes the server not follow on with the exec for the shell for the system command. Not sure if there is any other way at the OS level to be assigned to different groups other then the /etc/groups file, but I'd start checking there and see if that user is in that many groups, and if so, try and removing them from 1 to get them to 20 (or 2 to get to 19) and then see if it would now start to work. Jacques Renaut IBM Informix Advanced Support APD Team

Jacques, John: NGROUPS_MAX refers to the maximum length of the list of supplemental group ids that a process can belong to concurrently not the maximum group number or the number of groups defined per system. However, it may be that the users that fail are members of more than 20 supplemental groups (groups other than its primary group listed in /etc/passwd) while the ones that work are members of fewer supplemental groups. 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 Wed, Nov 7, 2012 at 10:18 AM, JACQUES RENAUT <jrenaut@us.ibm.com> wrote: > Original post: > > Jacques > > I got a chance this morning to run tusc for both the uses. If I did it > correctly here is the output from running it on the two test users. > > <stuff removed> > > John > > Response: > > I got on one of our itanium machines and did a man on setgroups() and it > says > it will return EINVAL if the 1st arg (21 in your case for the failing > user) is > greater then NGROUPS_MAX as defined in <limits.h>. On the machine I was > looking at, NGROUPS_MAX was defined as 20 in /usr/include/limits.h>. So I'm > going to guess that the user that is failing is assigned to 21 different > groups in your /etc/groups file, which is causing the setgroups() call to > fail > which makes the server not follow on with the exec for the shell for the > system command. Not sure if there is any other way at the OS level to be > assigned to different groups other then the /etc/groups file, but I'd start > checking there and see if that user is in that many groups, and if so, try > and > removing them from 1 to get them to 20 (or 2 to get to 19) and then see if > it > would now start to work. > > Jacques Renaut > IBM Informix Advanced Support > APD Team > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae93406d7b8fcc604cdea4e8d

Art & Jacques I checked the two known people that have this problem the first sury who I've been testing with has 21 groups the other has 22 groups (i.e. in 21/22 groups in /etc/group). Our EPR uses these groups to setup the Informix table permissions. Since sury is our head cashier and the other the head accountant I can see why they are in so many groups. I removed sury from one of the groups on the TEST/DR server she was in and re-ran the procedure and - poof it worked. So we found the cause. Yaaaaaaah!! I will now go check all users as I'm sure we have more than the two identified so far with more than 20 groups. Now the 64 thousand dollar question, how do I fix it. :-) I doubt I will be able to get rid of the groups on production server for this user, so will need a way to have more than 20 groups tied to a user. I will have to first review with the developers and see if we can do something about the number of groups. John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel Sent: Wednesday, November 07, 2012 10:36 AM To: ids@iiug.org Subject: Re: RE: RE: RE: I have a puzzling situation [28727] Jacques, John: NGROUPS_MAX refers to the maximum length of the list of supplemental group ids that a process can belong to concurrently not the maximum group number or the number of groups defined per system. However, it may be that the users that fail are members of more than 20 supplemental groups (groups other than its primary group listed in /etc/passwd) while the ones that work are members of fewer supplemental groups. 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 Wed, Nov 7, 2012 at 10:18 AM, JACQUES RENAUT <jrenaut@us.ibm.com> wrote: > Original post: > > Jacques > > I got a chance this morning to run tusc for both the uses. If I did it > correctly here is the output from running it on the two test users. > > <stuff removed> > > John > > Response: > > I got on one of our itanium machines and did a man on setgroups() and > it says it will return EINVAL if the 1st arg (21 in your case for the > failing > user) is > greater then NGROUPS_MAX as defined in <limits.h>. On the machine I > was looking at, NGROUPS_MAX was defined as 20 in > /usr/include/limits.h>. So I'm going to guess that the user that is > failing is assigned to 21 different groups in your /etc/groups file, > which is causing the setgroups() call to fail which makes the server > not follow on with the exec for the shell for the system command. Not > sure if there is any other way at the OS level to be assigned to > different groups other then the /etc/groups file, but I'd start > checking there and see if that user is in that many groups, and if so, > try and removing them from 1 to get them to 20 (or 2 to get to 19) and > then see if it would now start to work. > > Jacques Renaut > IBM Informix Advanced Support > APD Team > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae93406d7b8fcc604cdea4e8d ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

John: What does "cat /proc/sys/kernel/ngroups_max" return? What does "getconf NGROUPS_MAX" return? I did a search on the web and it looks like you have to get the glibc source, modify limits.h, recompile glibc to create a .a library and a .so shared library and install them. You will likely have to restart the Informix engine after that to pick up the updated library. You can verify whether the oninit process was linked to the dynamic version of glibc using "ldd $INFORMIXDIR/bin/oninit" to see if the libc.so is being linked at runtime and which version your environment's search path (LD_LIBRARY_PATH) is seeing. Supposedly this limit was raised in kernels 2.6.3 and later to 64,535. I have access to an RHEL5 machine and it reports 65535 from both /proc and getconf. So maybe the best/easiest fix will be to upgrade your OS or at least the kernel and glibc. 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 Wed, Nov 7, 2012 at 12:18 PM, John Adamski <adamski@graceland.edu> wrote: > Art & Jacques > > I checked the two known people that have this problem the first sury who > I've > been testing with has 21 groups the other has 22 groups (i.e. in 21/22 > groups > in /etc/group). > > Our EPR uses these groups to setup the Informix table permissions. Since > sury > is our head cashier and the other the head accountant I can see why they > are > in so many groups. I removed sury from one of the groups on the TEST/DR > server > she was in and re-ran the procedure and - poof it worked. > > So we found the cause. Yaaaaaaah!! > > I will now go check all users as I'm sure we have more than the two > identified > so far with more than 20 groups. > > Now the 64 thousand dollar question, how do I fix it. :-) I doubt I will be > able to get rid of the groups on production server for this user, so will > need > a way to have more than 20 groups tied to a user. I will have to first > review > with the developers and see if we can do something about the number of > groups. > > John > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art > Kagel > Sent: Wednesday, November 07, 2012 10:36 AM > To: ids@iiug.org > Subject: Re: RE: RE: RE: I have a puzzling situation [28727] > > Jacques, John: > > NGROUPS_MAX refers to the maximum length of the list of supplemental group > ids > that a process can belong to concurrently not the maximum group number or > the > number of groups defined per system. > > However, it may be that the users that fail are members of more than 20 > supplemental groups (groups other than its primary group listed in > /etc/passwd) while the ones that work are members of fewer supplemental > groups. > > 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 Wed, Nov 7, 2012 at 10:18 AM, JACQUES RENAUT <jrenaut@us.ibm.com> > wrote: > > > Original post: > > > > Jacques > > > > I got a chance this morning to run tusc for both the uses. If I did it > > correctly here is the output from running it on the two test users. > > > > <stuff removed> > > > > John > > > > Response: > > > > I got on one of our itanium machines and did a man on setgroups() and > > it says it will return EINVAL if the 1st arg (21 in your case for the > > failing > > user) is > > greater then NGROUPS_MAX as defined in <limits.h>. On the machine I > > was looking at, NGROUPS_MAX was defined as 20 in > > /usr/include/limits.h>. So I'm going to guess that the user that is > > failing is assigned to 21 different groups in your /etc/groups file, > > which is causing the setgroups() call to fail which makes the server > > not follow on with the exec for the shell for the system command. Not > > sure if there is any other way at the OS level to be assigned to > > different groups other then the /etc/groups file, but I'd start > > checking there and see if that user is in that many groups, and if so, > > try and removing them from 1 to get them to 20 (or 2 to get to 19) and > > then see if it would now start to work. > > > > Jacques Renaut > > IBM Informix Advanced Support > > APD Team > > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --14dae93406d7b8fcc604cdea4e8d > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --90e6ba6147748cf8db04cdec5952

So your test machine's OS version is different than production's? What architecture are production and test machines? Some have lower limits in the kernel source,(KERN_NGROUPS_MAX). What does "sudo /sbin/sysctl kernel.ngroups_max" return? It should be the same as /proc/sys/ngroups_max. You could use sysctl to increase it?

Art I'm on HPUX so the first command won't work on my system, the second returned: adamski cars: getconf NGROUPS_MAX 20 I did checked and the two users that have the problem are the only two that have more than 20 groups. I have two other people at 20 and one at 19. So I think I need to look at increasing the ngroup_max. HP man page on ngroups_max give a big long warning about changing it as might cause problems with older applications. How lovely. John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Art Kagel Sent: Wednesday, November 07, 2012 1:02 PM To: ids@iiug.org Subject: Re: RE: RE: RE: I have a puzzling situation [28730] John: What does "cat /proc/sys/kernel/ngroups_max" return? What does "getconf NGROUPS_MAX" return? I did a search on the web and it looks like you have to get the glibc source, modify limits.h, recompile glibc to create a .a library and a .so shared library and install them. You will likely have to restart the Informix engine after that to pick up the updated library. You can verify whether the oninit process was linked to the dynamic version of glibc using "ldd $INFORMIXDIR/bin/oninit" to see if the libc.so is being linked at runtime and which version your environment's search path (LD_LIBRARY_PATH) is seeing. Supposedly this limit was raised in kernels 2.6.3 and later to 64,535. I have access to an RHEL5 machine and it reports 65535 from both /proc and getconf. So maybe the best/easiest fix will be to upgrade your OS or at least the kernel and glibc. 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 Wed, Nov 7, 2012 at 12:18 PM, John Adamski <adamski@graceland.edu> wrote: > Art & Jacques > > I checked the two known people that have this problem the first sury > who I've been testing with has 21 groups the other has 22 groups (i.e. > in 21/22 groups in /etc/group). > > Our EPR uses these groups to setup the Informix table permissions. > Since sury is our head cashier and the other the head accountant I can > see why they are in so many groups. I removed sury from one of the > groups on the TEST/DR server she was in and re-ran the procedure and - > poof it worked. > > So we found the cause. Yaaaaaaah!! > > I will now go check all users as I'm sure we have more than the two > identified so far with more than 20 groups. > > Now the 64 thousand dollar question, how do I fix it. :-) I doubt I > will be able to get rid of the groups on production server for this > user, so will need a way to have more than 20 groups tied to a user. I > will have to first review with the developers and see if we can do > something about the number of groups. > > John > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > Art Kagel > Sent: Wednesday, November 07, 2012 10:36 AM > To: ids@iiug.org > Subject: Re: RE: RE: RE: I have a puzzling situation [28727] > > Jacques, John: > > NGROUPS_MAX refers to the maximum length of the list of supplemental > group ids that a process can belong to concurrently not the maximum > group number or the number of groups defined per system. > > However, it may be that the users that fail are members of more than > 20 supplemental groups (groups other than its primary group listed in > /etc/passwd) while the ones that work are members of fewer > supplemental groups. > > 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 Wed, Nov 7, 2012 at 10:18 AM, JACQUES RENAUT <jrenaut@us.ibm.com> > wrote: > > > Original post: > > > > Jacques > > > > I got a chance this morning to run tusc for both the uses. If I did > > it correctly here is the output from running it on the two test users. > > > > <stuff removed> > > > > John > > > > Response: > > > > I got on one of our itanium machines and did a man on setgroups() > > and it says it will return EINVAL if the 1st arg (21 in your case > > for the failing > > user) is > > greater then NGROUPS_MAX as defined in <limits.h>. On the machine I > > was looking at, NGROUPS_MAX was defined as 20 in > > /usr/include/limits.h>. So I'm going to guess that the user that is > > failing is assigned to 21 different groups in your /etc/groups file, > > which is causing the setgroups() call to fail which makes the server > > not follow on with the exec for the shell for the system command. > > Not sure if there is any other way at the OS level to be assigned to > > different groups other then the /etc/groups file, but I'd start > > checking there and see if that user is in that many groups, and if > > so, try and removing them from 1 to get them to 20 (or 2 to get to > > 19) and then see if it would now start to work. > > > > Jacques Renaut > > IBM Informix Advanced Support > > APD Team > > > > > > > > > > > ******************************************************************************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --14dae93406d7b8fcc604cdea4e8d > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --90e6ba6147748cf8db04cdec5952 ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Frank, Our production and test/dr server run the same OS (HPUX 11.31 or 11iv3). I user HP's make_tape_recovery process to copy the production server to the test server about quarterly. So, they are just about identical except for name and IP address. Our current ngroups_max is set to 20 SMH->Kernel Configuration->Tunables (All) -------------------------------------------------------------------------------- -------------------------- Tunable Tuning Current Next Boot Default Usage Module Capability Value Value Value ================================================================================ ========================== ngroups_max Dynamic 20 20 20 - pm_ngroups_max John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK J. COMPUTER Sent: Wednesday, November 07, 2012 3:21 PM To: ids@iiug.org Subject: Re: RE: RE: RE: RE: I have a puzzling situation [28731] So your test machine's OS version is different than production's? What architecture are production and test machines? Some have lower limits in the kernel source,(KERN_NGROUPS_MAX). What does "sudo /sbin/sysctl kernel.ngroups_max" return? It should be the same as /proc/sys/ngroups_max. You could use sysctl to increase it? ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Caveat: Increasing this kernel param might cause problems with that OS version. You may have to upgrade the OS.

Frank, I am on the latest version of HPUX, unless HP released a new version since 10/8 when I checked for patches. HPUX 11iv3 also called HPUX 11.31 is what I'm on. And I have read HP's big long warning about changing this kernel parameter. So, me and one of the developers are trying to figure out if we can reduce the number of groups these two uses have. So far we can get them both to 21 groups and no lower. Which probably means we will have to combine two groups just for them to use the new group name. John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of FRANK J. COMPUTER Sent: Wednesday, November 07, 2012 3:40 PM To: ids@iiug.org Subject: Re: RE: RE: RE: RE: RE: I have a puzzling situ.... [28734] Caveat: Increasing this kernel param might cause problems with that OS version. You may have to upgrade the OS. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Don't tell anyone I suggested this... Create two users for the same person... For just a few operations that require a couple of groups the person would have to use the second login... Would it work from an application perspective? Would the two users accept the workaround? Regards On Wed, Nov 7, 2012 at 9:56 PM, John Adamski <adamski@graceland.edu> wrote: > Frank, > > I am on the latest version of HPUX, unless HP released a new version since > 10/8 when I checked for patches. HPUX 11iv3 also called HPUX 11.31 is what > I'm > on. > > And I have read HP's big long warning about changing this kernel parameter. > So, me and one of the developers are trying to figure out if we can reduce > the > number of groups these two uses have. So far we can get them both to 21 > groups > and no lower. Which probably means we will have to combine two groups just > for > them to use the new group name. > > John > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > FRANK J. > COMPUTER > Sent: Wednesday, November 07, 2012 3:40 PM > To: ids@iiug.org > Subject: Re: RE: RE: RE: RE: RE: I have a puzzling situ.... [28734] > > Caveat: Increasing this kernel param might cause problems with that OS > version. You may have to upgrade the OS. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --047d7b67898a61d59104cdef6863

Fernando I won't tell... but no they will not except it. These are probably the two busiest Accounting people and adding another account they have to remember when to use wouldn't go too well. John -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Fernando Nunes Sent: Wednesday, November 07, 2012 4:41 PM To: ids@iiug.org Subject: Re: RE: RE: RE: RE: RE: I have a puzzling situ.... [28736] Don't tell anyone I suggested this... Create two users for the same person... For just a few operations that require a couple of groups the person would have to use the second login... Would it work from an application perspective? Would the two users accept the workaround? Regards On Wed, Nov 7, 2012 at 9:56 PM, John Adamski <adamski@graceland.edu> wrote: > Frank, > > I am on the latest version of HPUX, unless HP released a new version > since > 10/8 when I checked for patches. HPUX 11iv3 also called HPUX 11.31 is > what I'm on. > > And I have read HP's big long warning about changing this kernel parameter. > So, me and one of the developers are trying to figure out if we can > reduce the number of groups these two uses have. So far we can get > them both to 21 groups and no lower. Which probably means we will have > to combine two groups just for them to use the new group name. > > John > > -----Original Message----- > From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of > FRANK J. > COMPUTER > Sent: Wednesday, November 07, 2012 3:40 PM > To: ids@iiug.org > Subject: Re: RE: RE: RE: RE: RE: I have a puzzling situ.... [28734] > > Caveat: Increasing this kernel param might cause problems with that OS > version. You may have to upgrade the OS. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --047d7b67898a61d59104cdef6863 ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.