Re: Online 7.13 error 25588

Mark Hall wrote: > > David Coburn wrote: > > > > >What is this error and what are the possible causes? > > > > Generally means that either your networking setup is hosed, or you > > cannot connect for some reason via shared memory. The actual error is > > > > $ finderr 25588> > -25588 The appl process cannot connect to OnLine server > > server-name. > > > > An error in the application can produce this message. Check your > > CONNECT > > statement and the sqlhosts file. A system failure can also produce > > this > > message. If you can find no immediate cause 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. > > > > I've most often seen it when there was some configuration > > problems...generally on the client side of a connection. > > > > David > The problem was finally solved by raising the max users in the > performance parameters from 50 to 100. We have 3 programmers working on > the box and no one else so we never should have even come close to 50. > Possibly the max user count means something other than the obvious > meaning. Hello Mark, this is what i got from Tech Support, try setting INFORMIXSHMBASE=0 Many greetings Friedrich 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. -- 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