WG> The real problem is that I don't know how to make 
 WG> curses use something else (e.g. a named pipe) for the 
 WG> controlling terminal.. there must be a way, but I'm not 
 WG> sure what it is. :)
 WG>  
 WG> One possible work-around would be to somehow attach 
 WG> Maximus to ptys that screen could use. That would be 
 WG> really elegant, as you'd be able to switch between 
 WG> maximus consoles, and have new ones dynamically 
 WG> generated as new task numbers are dynamically generated.

Interesting idea.....  If we were just running in a console enviornment, it
might be easy to leave some pty's not under getty control and then just
attach them to max for curses usage.  I don't remember if you can then use
fg to birng those jobs forward....  Hmmmm...  This is a slightly different
usage....  But I suspect you run a form of xwindows and would prefer the
pty in a window under X.  I haven't pulled off that type of stunt.....  

Guess I need to look at curses.  Does it use stdin and stdout for file
handles?  If so, it just a matter of manipulating those handles to point to
something else.....

 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....
 WG>  
 WG> The wonderful thing about the UNIX environment is that (except in rare 
 WG> cases), locking is "advisory" -- i.e., ignore at your 
 WG> own peril. Serial ports are traditionally "locked" with 
 WG> the UUCP port locking mechanism; a semaphore file in 
 WG> /var/spool/locks. If two programs open the same file 
 WG> (or block-character device, e.g. serial port), it's no 
 WG> big deal. If they both try to READ from it at the same 
 WG> time, you never know who's going to get the data.. but 
 WG> if Binkley is "handing off" to Maximus, it shouldn't be 
 WG> trying to do anything to port.

Ah....  Different type of locking.  I was talking about locking the baud
rate not access to the serial port.  Sorry....  Slipped back to OS/2 and
DOS think on that one.  Locking of the serial port is another issue that we
also need to address.  If I remember correctly, Binkley should be the one
to set the serial port lock if it is used.  But if Max is run in wait for
user mode, then max needs to set (and clear) the serial port lock.  From a
different comment (in another echo), I believe binkley already does set the
serial port lock.  From memory, the serial port locks were only advisory...
 in that it was a co-operative way to keep one process from clobbering
another process's usage of the modem.  Then there is the file locking stuff
that DOS and OS/2 support in opening up a file, for example with deny_all,
that type of file locking, from memory, also works in Unix.  We should be
using the same settings in this area as the existing code....

 WG> The one caveat is that Binkley shouldn't drop DTR 
 WG> during handoff (that would be retarded, anyhow); if it 
 WG> does, well have to run the modems in "ignore DTR" mode; 
 WG> yuck.

Binkley shouldn't be dropping DTR in the handoff, but it is documented that
in a Win32 environment, that Binkley dropping to a DOS shell that then
starts the BBS will cause problems because the DOS shell when it
initializes drops DTR.  :(  I don't expect that problem under Unix or
Linux.  If we hit something like that in Linux, we can submit a patch
against the offending code....

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01