Re: 4GL 7.2: 4gi undef opcode, 4ge core

Update: I am happy to report partial progress in diagnosing thanks to Greg in Informix Technical Support. The problem seems to be that there is a custom-runner version of "fglgo" in a FourGen directory as well as the normal fglgo in $INFORMIXDIR/bin [bitsche@]/export/home/bitsche$ cd $fgtooldir/bin; ls -l fglgo 1 root other 1018896 Mar 20 17:36 fglgo [bitsche@]/usr3/fgtools4.12/bin$ ./fglgo -V INFORMIX-4GL Version 6.05.UD2 Pcode Version 602 [bitsche@]/usr3/fgtools4.12/bin$ cd $INFORMIXDIR/bin; ls -l fglgo 1 informix informix 1585464 Apr 8 13:22 fglgo [bitsche@]/usr3/informix7.24/bin$ ./fglgo -V INFORMIX-4GL Version 7.20.UC1 Pcode Version 602 Due to some other constraints, the $fgtooldir needs to be in the PATH before the INFORMIXDIR/bin, but I think we are on track to solve the 4gi croaking problem (I need to find out who/how/when the runner got built). The 4ge core dumps may be another matter entirely, but hey, progress is progress. -John John Bitsche wrote: > Greetings from the Heart of Texas (Austin): > > We recently upgraded 4GL to 7.2, recompiled, and though a lot of the > programs seem to work one particular (important) one barfs. > > ====== Environment ====== > SunOS venus 5.5.1 Generic_103640-17 > Ultra-Enterprise-10000 > gcc version 2.7.2.1 > DB-Access Version 7.24.UC2 > INFORMIX-ESQL Version 7.24.UC2 > INFORMIX-4GL Version 7.20.UC1 > INFORMIX-4GL Version 7.20.UC1 > INFORMIX-SQL Version 7.20.UC1 > > ====== 4gi ======= > When I run i_genjrn.4gi, > > Program stopped at "varText.4gl", line number 484. > FORMS statement error number -1345. > Undefined opcode. Please recompile with a compatible version of fglpc. > > I'm confused because we have definitely recompiled varText.4gl with > I-4GL 7.2, and at line 484 is > message d_buff > and of course "message" is a 4GL command. > > ====== 4ge ========= > To get more clues I decided to run the .4ge compiled version, but this > program cores out. I don't know much about cores (envision the 2001 > man-ape scratching his flea-bitten hide and puzzling over the > monolith). So far I tried running "crash core" to see if I get a clue > to my problem, but I get > > dumpfile = core, namelist = /dev/ksyms, outfile = stdout > crash: core: seek error on kvtopdata: Invalid argument > crash: core: unable to read kvtopdata > crash: core: unable to read kvtopdata > crash: cannot open kvm - dump file core > > which doesn't light any lightbulbs above my head. > > I've already checked that we have made the gcc-related "-fwritable" > change in c4gl: > $INFORMIXC -fwritable-strings \\ > -fpic -DASIAN -I$ITOOLS -I$IESQLC $A -L${LIBDIR} \\ > $SHAREDLIBS $STATLIBSUB $GLSLIB > > I can't think of anything better to try than a revert back to 4GL 6.0 to > see if the problem persists (maybe someone honked up our environment > during the 4GL upgrade?) Anyone have another idea I might try to shed > more light on the problem? > > -- > John Bitsche > Programmer/Analyst > Whole Foods Market > john.bitsche@wholefoods.com