Re: Recommended Install Order

>Have you considered using two separate INFORMIXDIRs - one for the >server, and a separate one for the tools? This obviates the install >order issue - you install the tools in whatever order you like in >their INFORMIXDIR, and IDS in its own separate INFORMIXDIR. Then what about the INFORMIXDIR environment var? One would then have to set it every time, depending on what one purposed to do during a specific user session, right? -- David Grove - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "I think not," said Descartes, and disappeared.

David E. Grove wrote: >> Have you considered using two separate INFORMIXDIRs - one for the >> server, and a separate one for the tools? This obviates the >> install order issue - you install the tools in whatever order you >> like in their INFORMIXDIR, and IDS in its own separate >> INFORMIXDIR. > > Then what about the INFORMIXDIR environment var? One would then > have to set it every time, depending on what one purposed to do > during a specific user session, right? Yes. The ordinary users would set INFORMIXDIR to the tools directory and never need the administration tools. Administrators have to think more carefully - but administrators are paid (in general) to think carefully. Generally speaking, though, if you are administering the system, and if you have I-Connect installed along with the server, and you have any home-built tools stored in a suitable alternative directory (like $HOME/bin, or $INFORMIXDIR/adm, or /usr/local/bin -- somewhere that is on your PATH), then you can use those anyway. If you're building applications, then you are - for the time being - a user and not an administrator. This is called 'role separation'; it involves the administrator recognizing that even though they are one individual, they have more than one role with respect to the database, and those different roles can require different settings. And it is not (all that) hard to set things up so that switches between the various environments are simple. I do it all the time. . 9.40.UC5 ...work with IDS 9.40.UC5 . 10.00.UC1 ...work with IDS 10.00.UC1 . 7.31.UD7 ...work with IDS 7.31.UD7 And each time, the environment is clean - that is, setting the 10.00.UC1 environment cleans out all the stuff related to 9.40.UC5, rather than continuously growing the environment. OK - that took me some effort to set up a number of years ago. But I'm still using the same basic code that I created in, oh, 1997. I changed it in 2003 to add version reporting (-V) and tracing (-t); the prior change was in 1999. I could make that code available if people were interested. It's a bigger set of programs than at first meets the eye - my tools use my other tools - but the set is finite and (for me) stable. * any of the scripts listed above (they're close to being clones). * escape - a C program to preserve spaces in argument lists. * setixd - a complex shell script to set Informix environment. * clnpath - a PATH variable editor script (cleans up duplicates). * dbenv - report (key, aka ancient) Informix-related env vars. There are some interesting bits of legacy stuff in there - support for OnLine/SE 4.x, NewEra, ON-Archive environment variables, and others. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/