Re: Bugs in INFORMIX 4.0 SE, 4GL (?)

->From: uunet!nas.nasa.gov!jcarter (John R. Carter Sr.) ->Date: 9 Apr 92 18:32:48 GMT ->Message-Id: <1992Apr9.183248.3434@nas.nasa.gov> ->Subject: Bugs in INFORMIX 4.0 SE, 4GL (?) ->Organization: Numerical Aerodynamic Simulation Facility NASA ->X-Informix-List-Id: <news.993> -> ->We recently ported a running application from a Sun 3 with 4.0 OS using ->Informix 2.1 with 4GL and ESQL/C to a Sparc 2 with 4.1 OS using ->Informix 4.0 using SE, 4GL, and ESQL/C. The system is networked with ->IP/TCP to many other hosts composed of SGI 4D, Sun 3, Sun 4, Sparc 1, ->and Sparc 2 systems. The IRIS systems will use either iris-ansi-net ->or xterm. The Sun systems will use either sunview or xterm. The users ->sometimes will set TERM on login to vt100 rather than take the default ->emulation. -> ->Problem #1: ->The application is normally run with the operators logged into the Sun ->from another system over the net from one of the other hosts. The ->terminal emulation is either iris-ansi-net, xterm, or vt100. The ->problem noted is when the user is logged in from an IRIS using xterm ->(from a Sun with xterm there is no problem). -> ->The application uses the RUN command to execute a C program in the ->following manner: -> -> LET cmd = "pgm ", arg1 CLIPPED, arg2 CLIPPED -> RUN cmd RETURNING status This is dangerous coding practice; you are using the Informix variable STATUS for your own purposes, which is dangerous. You MUST treat STATUS as a volatile variable, and generally, as readonly too. If the code was: LET cmd = "pgm ", arg1 CLIPPED, arg2 CLIPPED RUN cmd RETURNING p_status then I think you would find that p_status was set to zero and STATUS might well indicate an error, though off the top of my head, I don't know which one. In your original code, do you know whether the overall status of the run command is set before or after the RETURNING STATUS clause is executed? I don't! ->When logged in from an IRIS using the xterm emulation the application ->seems to run fine but it is noticed that the C program executes too ->quickly. When we exit from the application we notice that the user's ->shell shows an error, "pgm not found". The application does not check ->the RUN status itself, only the returned variable 'status' which we ->find is set to 0 indicating no problem. -> ->When I run the application with the debugger while logged in to the Sun ->from the same SGI system using the same terminal emulation there is no ->problem. This more or less confirms that the problem is with Informix ->and not anything else. I am not at all convinced by this conclusion. I would have drawn the conclusion that there is a difference between the Sun xterm and the Iris xterm. (All xterms are not the same!) However, there is a possibility that I am misunderstanding this second test; if so, please contact me by email to discuss the problem further. ->I modified the application as follows: -> -> LET cmd = "/fullpath/pgm ", arg1 CLIPPED, arg2 CLIPPED -> RUN cmd CLIPPED RETURNING status -> ->The new program now works fine on an SGI using xterm. This confirms my ->suspicion that the PATH is not being passed from parent to child when ->using the RUN command, and only when logged in over the net from an SGI ->system. This is incorrect: PATH is definitely passed over. It seems more likely to me that PATH is not set correctly under the Iris xterm. You should test this by modifying the I4GL to call fgl_getenv("PATH") and display the result. If the PATH value includes the place where "pgm" is located, then we'll need to think again. Until then, I would suspect that the xterm does not set the complete path. (Given the version of the software you are using, you may not have the function fgl_getenv; it is simply the 4.1 way of accessing an environment variable. I can provide equivalent code if needed.) ->Problem #2: ->The errorlog command in Informix 4.0 does not trim trailing blanks from ->the variable passed before writing the variable contents to the error ->log as it used to with Informix 2.1. With the variable defined as a ->CHAR(512), each line in the error log file is now 512 bytes long even ->though the error message itself may be NULL. By modifying the CALL ->statement to CLIP the message, the problem is resolved: -> -> CALL errorlog(msg CLIPPED) This is the correct behaviour, even if not what is intuitively expected. Basically, the ERRORLOG function records exactly what you pass it; if you pass it 512 characters, it records 512 characters. Your fix is the correct way to get the desired behaviour. Yours sincerely, Jonathan Leffler (johnl@obelix.informix.com)