isqlperl and SE 7.24

We're switching a system from SE 4.10 to SE 7.24.uc8 (4gl 7.20.ue1). I'm having trouble recompiling isqlperl 1.1 (or 1.2) with the new tools. There are several dozen isqlperl programs, I'd like to avoid rewriting them to use DBD::Informix if I can help it. There are two problems on the ESQL end. I've never had access to ESQL documentation, so I'm having a hard time with these. The isqlperl code is written to assume that the rtypalign() function returns a char *, but it looks to return an integer now instead. In one place it's used like pos = (int) rtypalign(pos, col->sqltype); so it doesn't look like that needs to change, but the other way it's used is cp = rtypalign(cp, col->sqltype); col->sqldata = cp; cp += col->sqllen; I can't intuit what rtypalign() is doing so I don't know how to translate this. The other problem is that the code's isql_shutdown() function is (by its own admission) breaking the rules by referring to the "undocumented libsql variable" forkflag. It tests this to avoid doing a close database or sqlexit() unless the flag is true. Does anyone know how this should be handled with the current release? Thanks for any advice or pointers. -- Roderick Schertler roderick@argon.org

On 26 Oct 1999 13:34:58 -0400, Roderick Schertler <roderick@argon.org> said: > > The isqlperl code is written to assume that the rtypalign() function > returns a char *, but it looks to return an integer now instead. I experimented with this a bit and concluded that it, given an address, rounds it up to the next appropriate alignment for the given type of data (or returns it as-is if the alignment is already usable). On normal machines it works the same for small integers (offsets into a structure, say) or addresses. I don't know why Informix changed it to take and return integers rather than characters pointers (I'd think the old way was more natural), but I just changed the code to call it like: pos = rtypalign(pos, col->sqltype); and cp = (char *)rtypalign((int)cp, col->sqltype); > The other problem is that the code's isql_shutdown() function is (by its > own admission) breaking the rules by referring to the "undocumented libsql > variable" forkflag. It tests this to avoid doing a close database or > sqlexit() unless the flag is true. This code was testing the flag to decide whether to run "$ close database" followed by sqlexit() from &isql_shutdown. If forkflag was false, they weren't called. Since &isql_shutdown is never called automatically, the only reasonable explanation I can make of the code is that it's meant to protect you from yourself if you call isql_shutdown() from a forked child. It seems that Informix's forkflag variable is backwards, but I can't see anything else this can mean. If anybody can correct me on either of these, I'd really appreciate it. -- Roderick Schertler roderick@argon.org

Roderick Schertler wrote: > On 26 Oct 1999 13:34:58 -0400, Roderick Schertler <roderick@argon.org> said: > > > > The isqlperl code is written to assume that the rtypalign() function > > returns a char *, but it looks to return an integer now instead. > > I experimented with this a bit and concluded that it, given an address, > rounds it up to the next appropriate alignment for the given type of > data (or returns it as-is if the alignment is already usable). On > normal machines it works the same for small integers (offsets into a > structure, say) or addresses. I don't know why Informix changed it to > take and return integers rather than characters pointers (I'd think the > old way was more natural), but I just changed the code to call it like: > > pos = rtypalign(pos, col->sqltype); > > and > > cp = (char *)rtypalign((int)cp, col->sqltype); Your analysis of what it does it correct. It should, of course, be messing around with void pointers in the interface. However, integers also work (as long as they're long integers, and as long as long integers are as big as pointers are, and ...). > > The other problem is that the code's isql_shutdown() function is (by its > > own admission) breaking the rules by referring to the "undocumented libsql > > variable" forkflag. It tests this to avoid doing a close database or > > sqlexit() unless the flag is true. > > This code was testing the flag to decide whether to run "$ close database" > followed by sqlexit() from &isql_shutdown. If forkflag was false, they > weren't called. Since &isql_shutdown is never called automatically, the > only reasonable explanation I can make of the code is that it's meant to > protect you from yourself if you call isql_shutdown() from a forked child. > It seems that Informix's forkflag variable is backwards, but I can't see > anything else this can mean. > > If anybody can correct me on either of these, I'd really appreciate it. IIRC, the forkflag was used to record whether a sqlexec or sqlturbo process had been forked off. With 7.x connectivity, of course, you don't always have a forked process, so the forkflag loses a lot of its meaningfulness, and that's one reason why it vanished. If you haven't got a record of whether there is a database connection, the best thing to do is to forcibly close down the connection and ignore any errors which say there was no connection to close -- CLOSE DATABASE anyway, in other words. Actually, more like DISCONNECT ALL or DISCONNECT CURRENT. Or call sqlexit() anyway. Etc. The forkflag test was an optimization; that optimization is no longer available to you, that's all. > > -- > Roderick Schertler > roderick@argon.org -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN #include <disclaimer.h>