JD>>   When a port is "locked", the BPS rate cannot be changed by an
JD>>   application program.

 CG>     Okay, then how does an application program change the BPS rate?

not when going thru a com driver that supports (un)locking a port...

JD>>   If an application can change the BPS rate of a serial device,
JD>> then the device is not, by definition, "locked".

 CG>     Does it have to "unlock" it first, and then
"relock" it?  I
 CG> haven't seen anything the IOCtl functions for locking and unlocking.

port (un)locking comes mainly (i think) from FOSSIL comms... i note,
though, that the MODE command supports, at least, setting the port speed
but have not tested to see if a program can still change the port speed
afterward... i note, also, that the SIO stuff is also by the same person
that wrote a DOS FOSSIL known as X00... it stands to reason in my mind,
that operating systems that support driver based comms would then also
support what we from the DOS world know as (un)locking a port... this would
include *NIX, OS/2, VMS, and any other OS' that use drivers for their
comms...

[moderator, please don't mind this li'l DOS'ism]

the analogy here would be to a DOS BBS system that has to use a FOSSIL for
the BBS but not for a door game. for the BBS, we lock the port. during the
install of the door, we miss the part about using locked ports so
unknowlingly, we have allowed the game to adjust the port speed  behind the
FOSSIL's back. when a caller connects, the port speed is not changed to the
callers connect speed. when the caller enters the door, the door alters the
port speed to the caller's connect speed. one of two things happens now...

  1. the caller sees garbage...
            =OR=
  2. the caller completes the door and
     sees garbage when the bbs reloads.

the first one happening means that the door is unable to "resync"
the modem to the new port speed.

the second one happening means that the door was able to "sync"
the modem to the new port speed but additionally that it does not restore
the port and modem to their previous state.

there are extremely few doors that do actually alter the port and modem and
then restore them properly afterward...

IT IS much safer to accept the port as it is and just use it by checking
the buffers or by utilizing buffering signals...

as it stands, i believe that there are few combinations of hardware and
software that do offer this capability but it is, i believe, dependent on
them. BINKLEY has the ability to operate locked or unlocked (as do most
mailers and other software) AND when used with USR modems, couriers at
least, can adjust buffering in the modem and i think port speed. this is
done by analyzing the connect string(s), putting the modem into command
mode, sending an init string that tells the modem to change to another
template or directly switch speeds, and then returning to online mode.

this is WAAAY too much work when one considers the simplicity of driver
based comms and using locked ports... the above just would not have to be
done at all!! -=B-)

)\/(ark