Re: Cursor name mangling

Will Hartung wrote: > I've got a program that's been running ducky in 4GL 4.11. > > Now, I have a shiny new computer with spanking fresh 4GL 7.2 on it, > and I'm trying to port the code over. > > I've getting the -4317 error: > Cursors must be uniquely declared within one program module. > > That's all just fine, save for: If you'd been paying attention to this issue about 3 years ago when it first surfaced, you'd know that I published a list of 2-letter combinations at the end of a cursor/statement name which will collide when hashed given the same prefix. I probably could dig up that list, but it actually isn't germane to your code -- probably. It is a hashing algorithm that's used to mangle names, and it is not perfect, and it might generate a collistion at any time. Since your names are unique in this code, maybe you should suppress the cursor name mangling -- with the -globcurs option. If your cursor names are unique across your entire program, then maybe you should set the environment variables C4GLFLAGS and/or FGLPCFLAGS to include -globcurs so that all cursor names are unmangled. In fact, I recommend doing that anyway if you have any thoughts of upgrading to D4GL which does not do cursor name mangling. In retrospect, providing the cursor name mangling was overly protective, and it would have been better to make people bite the bullet and fix their code way back when. I tried to protect people from the change by adding cursor mangling because I had a reasonably large number of customers in the UK who had code which I'd written which relied on the documented private cursor names, so it used c_select all over the place. Since I wasn't around to fix the code (being in the USA by then), I tried to save everybody the hassle of having to alter my (and their) code. It didn't work properly. Oh well, the road to hell is paved with good intentions. > $ fgrep -f prepare_and_declare header.4gl> > prepare read_specs from scratch > declare h_cursor cursor for read_specs > prepare str_lwhse from scratch > declare cur_lwhse cursor for str_lwhse > prepare str_lbox1 from scratch > declare cur_lbox1 cursor for str_lbox1 > prepare str_lbox2 from scratch > declare cur_lbox2 cursor for str_lbox2 > prepare str_lcarr from scratch > declare cur_lcarr cursor for str_lcarr > prepare str_lcust from scratch > declare cur_lcust cursor for str_lcust > prepare str_ldest from scratch > declare cur_ldest cursor for str_ldest > prepare str_lfob from scratch > declare cur_lfob cursor for str_lfob > prepare str_dup_chk from scratch > declare cur_dup_chk cursor for str_dup_chk > > You'll notice that none of these duplicate. For obvious reasons, I > suspected that perhaps the problem was with the lbox1 and lbox2 > cursors. cur_lbox happens to be 8 characters, but I can't find > anywhere that tells me how many characters in a cursor/statement > declaration are supposed to be unique. I was thinking more than 8 > though. Cursor and statement names can't be more than 18 characters, but the 18 characters are significant. To really find the names which are colliding, you'll have to look at the progr.4ec or prog.ec file for the mangled names. > But, the problem isn't with lbox1 and lbox2. The problem is with the > ldest section. Comment these two lines out of the code, and it > compiles just fine. Heck, it doesn't even complain that I'm USING > cur_ldest later in the code. > > This tells me that the names are being mangled internally by the > compiler, and that regardless of what I actually call the cursors, > Informix has its own idea and this seems to be an example of a name > collision using its internal hashing routine. > > Now, I seem to recall that since the older 4GLs were using module scope > cursors compared to the current global scope cursors (mind you, it > doesn't say this in the 6.0 manual, which is the current bulk > documentation, I think, though there may be an exception noted in one > of the 7.2 manuals - they're all a bit arduous to navigate). I also > recall there being a switch that mangled the file name into the cursor > name for "hack^H^H^H^Hbackward compatability", but I can't find that > switch either. > > Not that this switch would necessarily fix this specific problem as it > just happens being affecting only one module. > > So. > > How many characters are considered significant in determining the > uniqueness of a cursor name? > > What is the switch to mangle in the filename to the cursor names? Does > it exist in 7.2 anymore? > > Renaming the ldest cursor/statment to ldest1 fixes the problem, but > this is certainly annoying. Any other hints out there? -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.59 -- see http://www.perl.com/CPAN #include <disclaimer.h>