BJ> I figured unix's (and assume Linux's) way of using 
 BJ> a controlling console and the way Maximus is 
 BJ> written would bite in this area.....  It's been a 
 BJ> while since I've had to deal with this issue.....  
 
Likewise, I just design around it these days. ;)
 
The real problem is that I don't know how to make curses use something else
(e.g. a named pipe) for the controlling terminal.. there must be a way, but
I'm not sure what it is. :)
 
One possible work-around would be to somehow attach Maximus to ptys that
screen could use. That would be really elegant, as you'd be able to switch
between maximus consoles, and have new ones dynamically generated as new
task numbers are dynamically generated.
 
 BJ> The -b38400 is the baud rate.  Under OS/2, I 
 BJ> handled the locking of the com port was handled 
 BJ> external to Maximus, via SIO.....  It could also be 
 BJ> via Binkley.  As such, when max is handed an 
 BJ> already connectec modem, a locked or unlocked com 
 BJ> port shouldn't matter....
 
The wonderful thing about the UNIX environment is that (except in rare
cases), locking is "advisory" -- i.e., ignore at your own peril.
Serial ports are traditionally "locked" with the UUCP port
locking mechanism; a semaphore file in /var/spool/locks. If two programs
open the same file (or block-character device, e.g. serial port), it's no
big deal. If they both try to READ from it at the same time, you never know
who's going to get the data.. but if Binkley is "handing off" to
Maximus, it shouldn't be trying to do anything to port.
 
The one caveat is that Binkley shouldn't drop DTR during handoff (that
would be retarded, anyhow); if it does, well have to run the modems in
"ignore DTR" mode; yuck.
 
Wes

--- Maximus/2 3.01