RE: Tools vs Engine INFORMIXDIR ?

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF98CA.299C1998 Content-Type: text/plain; charset="iso-8859-1" Hello, We are in the process of making a minor upgrade in our IDS release, from 7.3.0.fc7 to 7.3.0.fc10 to get around a small but annoying bug. In the past all new release of tools and engine were installed in the /usr/informix directory. We now want to implement a new structure where the INFORMIXDIR will be in /usr/informix/"release". This should make it easier to maintain and test new releases. Also, this allows us a quicker "fallback" in the case of problems. Now the problem/question: #1 How can we keep the tools in a separate directory than the engine? We don't want to have to reinstall the tools each time we upgrade the engine. Also, in the future we will want to install and test new releases of the tools while development continues with the old tools (both using the current engine). question #2: When installing new releases of IDS there are "shared library files" that are updated. Are these files always backward compatible? If not, how does anyone have multiple releases if IDS 7.x running on the same machine? Is LD_LIBRARY_PATH the answer here? TIA ------_=_NextPart_001_01BF98CA.299C1998 Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD> <BODY> <DIV><FONT face=Arial size=2> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000>Hello,</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000>&nbsp;&nbsp; We are in the process of making a minor upgrade in our IDS release, from 7.3.0.fc7 to 7.3.0.fc10 to get around a small but annoying bug. In the past all new release of tools and engine were installed in the /usr/informix directory. We now want to implement a new structure where the INFORMIXDIR will be in /usr/informix/"release". This should make it easier to maintain and test new releases. Also, this allows us a quicker "fallback" in the case of problems.</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000>Now the problem/question: #1</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000>&nbsp;&nbsp; How can we keep the tools in a separate directory than the engine?&nbsp; We don't want to have to reinstall the tools each time we upgrade the engine. Also, in the future we will want to install and test new releases of the tools while development continues with the old tools (both using the current engine).</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000>question #2:</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000></SPAN></FONT>&nbsp;</DIV> <DIV><FONT size=2><FONT face=Arial><SPAN class=898105114-28032000>&nbsp; When installing new releases of IDS there are "shared&nbsp;<SPAN class=719262415-28032000>library&nbsp;</SPAN>files" that are updated.&nbsp; Are these files always backward compatible?&nbsp; If not, how does anyone have multiple releases if IDS&nbsp;<SPAN class=719262415-28032000>7.x </SPAN>running on the same machine?<SPAN class=719262415-28032000>&nbsp; Is LD_LIBRARY_PATH&nbsp;the answer here?&nbsp;</SPAN></SPAN></FONT></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000></SPAN></FONT>&nbsp;</DIV> <DIV><FONT face=Arial size=2><SPAN class=898105114-28032000>TIA</SPAN></FONT></DIV> <DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML> ------_=_NextPart_001_01BF98CA.299C1998--

Rogers Patterson wrote: > This message is in MIME format. Please don't post in MIME format! Or in HTML. > We are in the process of making a minor upgrade in our IDS release, from > 7.3.0.fc7 to 7.3.0.fc10 to get around a small but annoying bug. In the past > all new release of tools and engine were installed in the /usr/informix > directory. We now want to implement a new structure where the INFORMIXDIR > will be in /usr/informix/"release". This should make it easier to maintain > and test new releases. Also, this allows us a quicker "fallback" in the case > of problems. Excellent idea. I do it all the time. > Now the problem/question: #1 > > How can we keep the tools in a separate directory than the engine? We > don't want to have to reinstall the tools each time we upgrade the engine. > Also, in the future we will want to install and test new releases of the > tools while development continues with the old tools (both using the current > engine). Have two separate directories. :-) Cribbing from a lightly edited version of an answer sent to the DBI mailing list earlier today... You have to configure the tools INFORMIXDIR correctly, or set the environment correctly globally. Normally, I install IDS in /usr/informix/IDS-7.30.UC6 and I4GL in /usr/informix/I4GL-7.30.UC1 (or equivalent directories depending on the versions I'm using). The /usr/informix level would also, in general, contain: bin - private Informix admin tools (utils_jl from IIUG) etc - central sqlhosts file for machine; symlinks to onconfig files for each IDS system (I tend to have several on any given machine) log - console and message files for all IDS systems dev - symlinks to data storage On my Solaris machine, ls -CF /usr/informix yields: 5.10.UC7/ 7.30.UC3@ 9.20.UC2/ etc/ 7.20.UD1@ 7.31.UC2/ dev@ log@ I haven't set up the bin directory, and I've not used the product prefixes for historical reasons. Most of the stuff under there is symlinks to the master versions in /work4/informix, which contains: /work4/informix: 7.20.UD1/ D4GL-2.10.UC1/ IDS-7.31.UC2/ Servers-7.24.UC1/ CSDK-2.30.UC1/ I4GL-7.30.UC1/ IDS-9.20.UC2/ TclTk/ CSDK-2.40.FC1/ I4GL-7.30.UC1A2/ IIF-9.20.UC2/ dev/ CSDK-2.40.UC1/ IDS-7.30.UC3/ OnLine-5.10.UC7/ log/ You have two choices for how to access the central sqlhosts file. Option 1 is to set INFORMIXSQLHOSTS=/usr/informix/etc/sqlhosts (the central copy) for everybody at all times. Option 2 is to have a symlink (or a hard link, but in this context, I think symlinks are more reliable) in /usr/informix/I4GL-7.30.UC1/etc/ pointing to the central copy. This works even when people do not set the INFORMIXSQLHOSTS environment variable, and minimizing the environment is a good thing in general. For most people, most of the time, they can have INFORMIXDIR set to the CSDK directory, and their applications will run fine, and because the sqlhosts file gives the correct connectivity, there will be no problem. DB-Access becomes a mild nuisance; it is a user tool distributed with the servers, so if users need to use it, you probably need to copy it to the Tools INFORMIXDIR. I'm not sure whether there are any message files you need to add. I don't know because I create a composite INFORMIXDIR with IDS, CSDK and I4GL in it -- /work4/informix contains the single product installs, and /usr/informix contains composite INFORMIXDIRs. > question #2: > > When installing new releases of IDS there are "shared library files" that > are updated. Are these files always backward compatible? If not, how does > anyone have multiple releases if IDS 7.x running on the same machine? Is > LD_LIBRARY_PATH the answer here? If the libraries in /usr/lib are backwards compatible, the new version is used to replace the old one. If the libraries are not backwards compatible, the name changes so that both versions can coexist in /usr/lib. LD_LIBRARY_PATH is not the answer. Also, there are only a couple of libraries installed by IDS. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v1.00.PC1 -- see http://www.perl.com/CPAN #include <disclaimer.h>