FT> sometimes one of the lines on the bbs gets stuck. the 
FT> caller exits, the bbs sends the line back to frontdoor, 
FT> which can't initialize the port any longer
FT> 
FT> Solution tried:
FT> 
FT> a) all softwares I could get my hands on to reset the com port.
FT> But there aren't that many to begin with, since the dos once  usually
FT> don't work under os/2 and when they do run, they  don't do a thing.
FT> b) write my own I tried the library provided with speed pascal 1.0 
FT> - no way I tried the GIO2 library provided with GNU EMX 0.9a - ditto
FT> 
FT> Then what ?
FT> 
FT> The more I look at it, the more I am convinced that the 
FT> problem comes from the fact that all those libraries, 
FT> sooner or later, go down to the devioctl() of the os/2 API. 
FT> And the api won't let you touch the port if it is used by 
FT> another application. the problem is that the other 
FT> "application" is non existant.
FT> 
I can duplicate the problem readily using SIO (1.53).  SIO thinks the
port is closed, OS/2 doesn't - it thinks a DOS session still owns it. 
Of course,, the DOS session no longer exists.....  I CANNOT duplicate
the problem using the stock COMM drivers.  I intended to drop a note to
Ray Gwinn about this, since it would appear to be an SIO glitch, but
never got around to it.  I did find a simple solution, tho.  If I open
TE/2 and ask for that port from the OS/2 program, it opens just fine. 
When I then close the port, it is closed for DOS sessions as well.  The
phantom goes away.  Try it, it might work.  I'm not sure how you
automate this for the BBS, tho.

___
 X KWQ/2 1.2i X Nothing is foolproof.  Fools are SO ingenious!

--- Maximus/2 2.02