TR> Why in the Sam Hill do people lock the port with SIO, anyway?
 TR> Isn't the comm. software supposed to handle whether or not the
 TR> port is locked?
errr... tom... BBS systems that use a FOSSIL driver generally need to have 
the port locked for best thruput and handling... since the BBS software 
simply talks to the FOSSIL driver and (under OS/2) the FOSSIL (being vx00) 
talkes to the com port (under OS/2, SIO) then something somewhere has to lock 
the port... since SIO is at the base of the whole structure, SIO is the 
logical place to lock the port...
 TR> my situation, I use Qmodem 4.6 Test Drive for DOS, in a DOS
 TR> session under Warp 3.0, and Qmodem locks the port.  So, I
 TR> just let SIO float.  I don't recall programs like WiveWire
 TR> or Zap-O-Com *not* locking the port, but maybe they don't...?
that is fine in your situation but it's a lot different that running a bbs 
program... it would not surprise me in the least if there are some who are 
locking the port in SIO and using the software you are with the same 
configuration. i have to wonder, though, what would happen if SIO was locked 
at 115200 and your qmodem was locked at 57600... would it work or no?? ;-)
)\/(ark
---------------