Re: Mixing flavors of Informix

Jonathan Leffler <jleffler@earthlink.net> wrote: : bothwellno@spam.duke.edu wrote: : > We're in the process of upgrading the following in order to : > get into a configuration that is expandable, more current : > and supported: : > : > IDS: 7.31 to 9.40 : > SQL & 4GL: 7.22 to 7.32 : Please double check the SQL and 4GL version numbers; the releases were : 7.20, 7.30, 7.31, and 7.32 -- there never was a 7.22 I4GL or ISQL. : > AIX: 4.3.2 to 5.2 : Isn't 4.3.2 dead? As in unsupported by IBM? : > Our current server can only hold 3GB of RAM and we're : > running into issues with that limitation now. : > Our new production server has 8GB of RAM and we want to : > run it in 64-bit mode to get access to more RAM for BUFFERS. : > We're having some upgrade issues with the application vendor : > and are looking for short-term alternatives, such as a : > partial upgrade. : > The idea being floated now is this: : > : > Continue on our development server with our current combination : > of OS (4.3.2), IDS (7.31) and Tools (7.22). : You can do that, yes - as an interim step. : > Proceed with the upgrade of the production server to the desired : > levels of OS (5.2), IDS (9.40) and Tool runtimes (7.32). : Sounds good. : > Copy (not compile) the code generated with the 7.22 tools to : > the new production server. : Sounds bad. No. Don't try it. With 32-bit code, you may get away : with it - with 64-bit, you will not. And to run the 7.2x tools, you : would need a 7.2x environment on the new machine, thus using two : separate INFORMIXDIRs, one for the old stuff, and one for the new. : > Run the code (compiled with the 7.22 tools) on the new production : > server in 64-bit mode with shared memory connections (ipcshm). : Fugeddabartit. : 32-bit code cannot talk over 64-bit olipcshm connections. : > I've got the code copied over and the database loaded on the new : > server. I had to copy several Informix (version 7) libraries over : > to the new server as well. : > When I try to run the application with a shared memory connection : > specified in INFORMIXSERVER, : > the application appears to 'hang' for a few seconds and then : > displays the following message: : Seems plausible - don't try messing 32-bit apps and 64-bit servers : over shared memory. Network - OK; IPC streams (olipcstr - if : supported on AIX) is OK; shared memory - no OK. : > Loading program...Program stopped at "main.4gl", line number 22. : > 4GL run-time error number -25588. : > The appl process cannot connect to Dynamic Server appxshm. : OK - can't connect. : > If I change the INFORMIXSERVER to a TCP/IP connection, the : > application appears to work fine. : Yes; networks serialize the data and neutralize the 4-byte vs 8-byte : integer differences. : > I have set the server to 32-bit mode, rebooted and installed the : > 32-bit version of the engine. I was able to run in 32-bit mode : > with shared memory connections, but I am only able to set my : > BUFFERS to about 2GB. This does not help me out since I have : > that limitation already. : 32-bit apps vs 32-bit servers work the same as ever. : If you need more space than a 32-bit server can use, use 64-bit servers. : > I have a few questions: : > : > Is there any way to get this configuration to run with a shared : > memory connection? : No. : > I am not comfortable with this configuration since it is probably : > not supported at all by IBM. Has anyone else tried something like : > this and run into problems they'd like to share? : You've found most of the available problems - about the only one : you've not come up with is running 64-bit 4.3.x applications on 5.2, : which, as I mentioned earlier, is certainly unreliable if it works at all. : > Do any IBM/Informix people have some recommendations about why : > this should not be done? : It doesn't work, and is guaranteed not to work. This is usually a : good reason for not doing it. : -- : Jonathan Leffler #include <disclaimer.h> : Email: jleffler@earthlink.net, jleffler@us.ibm.com : Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ To clarify a few issues: The current development tools are 7.20.UE2 (not 7.22). The 64-bit tools installed on production are 7.32.FC1 I have not mixed 32 and 64 bit flavors on the produciton server. In my tests, I installed each in a separate directory and changed the INFORMIX* environment variables to use the version I wanted. As I mentioned, I copied the version 7 libraries over into a separate folder and used LIBPATH to help the applications find them. OK, so technically I did mix the versions, but I was under the spell of a consultant! AIX 4.3.2 is dead - and the very reason why we planned the upgrade in the first place. This gives you an idea of the trouble we're having with the vendor - so much that we're considering staying on an unsupported platform! Andew's comment about the issues with running different versions of the engine on development and production is something I have tried to explain here - the users may find a problem on production that cannot be duplicated on development. It would be worse if the project managers decide to pursue this mixed environment solution because the users may find a problem on production and the programmers would have very few ways to try and debug the problem. Thank you for all of the feedback. It confirms many things I have suspected since this was suggested. Don't hesitate to keep those cards and letters coming :-) Bob -- bothwellno@spam.duke.edu

bothwellno@spam.duke.edu wrote: >[SNIP massive quoting] - please trim in replies :-! > > To clarify a few issues: > > Andew's comment about the issues with running different versions > of the engine on development and production is something I have > tried to explain here - the users may find a problem on > production that cannot be duplicated on development. Exceedingly unlikely. The possibility of this scenario is much lower than the problems that are more likely by compromising other factors of the installation. Nothing is foolproof, but risk is managable, and using a 64 bit engine on production and 32 in development is a vary tiny risk. Don't sweat this one. The engines are very self-contained and independent of the clients too, which is why nobody is recommending any specific engine with any specific 4GL version. We've been delivering RDS developed on HP and Intel (SCO and Linux) to all sorts of platforms with all sorts of engines for over 10 years, and platform-specific engine bugs? I'm struggling to think of anything without a trivial workaround in configuration. Hell, setting up an engine is a bit of an art anyway; there are a few alternatives so just pick one that keeps running. I'm thinking here of a few HP's that didn't like to use KAIO and shared memory connectors and more than about 10% of their user load. So I just switched off KAIO and blamed it on yet another HP foible. > Thank you for all of the feedback. It confirms many things I have > suspected since this was suggested. Don't hesitate to keep those > cards and letters coming :-) As long as you don't send 'em all back with your cards and letters! Add simplicity and have a good time.