Re: Error 25588 Cannot connect to OnLine

Agostino Brunamontini wrote: > > Hi, > > I need some help for the following error. > From Informix error messages: > > > -25588 The appl process cannot connect to OnLine server server- > > name. > > > This error can be caused by an error in the application. > > Check your CONNECT statement and the sqlhosts file. The > > error can also be caused by a system failure. If no immediate > > cause can be found for the failure, note the circumstances > > and contact your OnLine database administrator for > > assistance. > > > The shared memory communication subsystem is down or > > not functioning. Contact the OnLine database administrator > > to report the problem. > > Despite this error message everything seems to be ok. I mean, > the connect statement syntax, the sqlhosts file and the shared memory are ok. > I don't know if there is a system failure. (Which kind of failure could be?) > When I try to connect using dbaccess it works. > I doesn't work with ESQL/C. > > I'm using OnLine 7.x. > > Any ideas? > > Thank you very much. > > ===================== > Agostino Brunamontini > Rome. Italy. > ===================== Hello Agostino, try setting Environment Variable INFORMIXSHMBASE=0, this should normaly work if you try to connect via shared memory. I add two files I got from INFORMIX support after beating them really heavy: tech 8851 Happy holidays all, I wanted to pass on a lesson learned from two sites I've been to over the past two weeks. At site 1, they have a 4GL application program that is 17 MBytes. When they tried to access OnLine via shared memory they constantly received connection failures (small 4GL programs worked fine). At site 2, they received errors constantly in their ESQL/C programs when trying to perform mallocs or callocs of approximately 800K. Both sites were led to believe the problem was with the OnLine engine and that simply upgrading from 7.10 to 7.11 would fix the problem. Site 1 couldn't upgrade (O/S versions), and site 2 found the upgrade made no difference. In reality, the only thing they needed to do was to set the environment variable INFORMIXSHMBASE (which adjusts where shared memory attaches to a program). Note: don't confuse this variable with the configuration parameter SHMBASE (which is for the engine). The second site became rather angry when they discovered this was the solution since they are on a critical path for their conversion and in their words, "wasted 5 weeks working on a problem that Informix should have solved in 5 minutes". I spent an hour yesterday defending our methodologies at site 2 for the answers they received. I would probably have given them the SAME answers had I not known about INFORMIXSHMBASE. I promised site 2 I would send out a message on the problem and solution. Perhaps this will help others that might end up in the same situation. I trust my diagram below is accurate (corrections are welcome). What it illustrates is how INFORMIXSHMBASE affects where shared memory is attached to a program. +----------+ $INFORMIXSHMBASE (in K) (I used 0x0) | SHM | | | | | v | | | | ^ | | | | | BSS | +----------+ 19M | Data | +----------+ 17M | | | Text | | | +----------+ 0M Logical Normally, shared memory attaches around the 8M mark (implementation specific). Obviously, in the case of the 17M program, this wouldn't work as it was trying to attach logically into the programs text segment. By attaching shared memory at a higher offset, site 1's program was no longer overlayed, and site 2 had the room to grab 800M for their mallocs. I hope this helps someone out there... tech 4321 User must set INFORMIXSHMBASE = 0 When it is NOT SET, the system defaults to 8MB as the starting address for shared memory communications. By setting the variable to 0, the operating system will put the shared memory communications in an unused area of shared memory. The application was putting shared memory communications in an area which apparently started to run into another area of memory already used; hence the -4 unix errors. I also saw core dump error -25588. Many greetings Friedrich -- Universitaet Bielefeld Dezernat I / Datenverarbeitung Friedrich Kreienkamp Tel: 0521-106-4163 eMail: friedrich.kreienkamp@post.uni-bielefeld.de Postfach 100131 Universitaetsstra'e 25 33501 Bielefeld 33615 Bielefeld