Re: Accessing Environment Variables within a strored proc.

Jon Myatt wrote: > > And the environment handed to the program run by the 'system' call > > will not be the same as that of the user. > > Why is this? > > I've noticed that the environment a system call from SPL gets seems > to be a small subset of some environment or other - I can't figure > out why some vars get passed and some dont. Where is this environment > inherited from? Where should I set an env. var so that it is > available in the environment to a system call from a stored procedure? The environment typically depends on the environment when the oninit process is kicked off. If that happens automatically during system boot, then you get a minimal environment because the environment during the boot is itself minimal. If, on the other hand, someone kicks it off manually later, then you get all their environmental baggage. One of the more interesting examples of this problem occurs if you start the engine with DBDATE=y4md-, or any other format than MDY2/ or MDY4/ (where the punctuation character is not important). If your unsuspecting US citizen tries to use the OnLine system with no DBDATE set in their environment, then OnLine interprets the date strings using the DBDATE set in its environment -- and rejects what the US citizen tries to enter. I logged this as a bug, but it has rather low priority, funnily enough. Technically, I suppose, there's a documentation problem; if the user's environment does not include DBDATE, the default in the server is not necessarily the MDY4/ which is documented. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix -- see http://www.perl.com/CPAN #include <disclaimer.h>