Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!tcdcs!wsl!harry
From: harry@wsl.UUCP (Henry M. Moreau on wsl)
Newsgroups: comp.databases
Subject: Re: INFORMIX bug?
Message-ID: <723@wsl.UUCP>
Date: 26 Nov 90 22:47:26 GMT
References: <8330@pbhyf.PacBell.COM> <1990Nov20.221658.19496@informix.com> <8335@pbhyf.PacBell.COM>
Reply-To: harry@wsl.ie (Henry M. Moreau on wsl)
Organization: Workhorse Systems, Dublin, Ireland
Lines: 20
Summary:
Expires:
Sender:
Followup-To:

In article <8335@pbhyf.PacBell.COM> jwas@PacBell.COM (Joe Wasik) writes:
>
>While I admit I hadn't even considered doing a close, it's now been tried
>and unfortunately it doesn't work.
>

I can't admit to knowing a lot about how 4GL talks to sqlexec, but the problem
you describe sounds like it could be something to do with an inherited
file descriptor.

If sqlexec reads its commands from some file descriptor, say on a pipe,
and your 4GL program forks off processes that inherit this
file descriptor then sqlexec will keep expecting input on the file descriptor
until all processes that could write on it terminate or close the file
descriptor.

If this is what's happening then your child process will have to close
the file descriptor explicitly itself.  If my diagnosis is correct, then 
yes, there is a bug in Informix - the file descriptor should have
had its CLOSE-ON-EXEC flag set in 4GL.