aries@skorpio.usask.ca (Aries Project) (10/19/89)
I am having trouble with what seems to be a bug in the serial device. What I am doing is opening up the serial device a second time in shared mode while someone is online. I'm almost positive I am doing things correctly (only one incarnation of the device is active at a time). The problem is that about 1/10 times, dtr is dropped when the serial device is opened the second time. I can get around this by forcing dtr, but I don't want to. This is not just a problem with my software. Every program that I have tried that uses the serial device in shared mode does the same this. Any solutions?? -Mike Oliphant
hassinger@lmrc.uucp (Bob Hassinger) (10/23/89)
In article <1989Oct19.163629.9047@dvinci.usask.ca>, aries@skorpio.usask.ca (Aries Project) writes: > I am having trouble with what seems to be a bug in the serial device. What > I am doing is opening up the serial device a second time in shared mode while > someone is online. I'm almost positive I am doing things correctly (only > one incarnation of the device is active at a time). The problem is that about > 1/10 times, dtr is dropped when the serial device is opened the second time. > I can get around this by forcing dtr, but I don't want to. > > This is not just a problem with my software. Every program that I have tried > that uses the serial device in shared mode does the same this. > > Any solutions?? > > -Mike Oliphant I have been looking for information on the general subject of the shared mode for the serial device. I have been unable to find anything about it so far and hardly anyone seems to know it even exists. Some exposition on exactly how it works and interacts would be greatly appreciated. My particular problem is that I need to come up with a small program that I can use to issue commands from the keyboard out the serial port to make a connection (via a DECserver 200) to a printer. After the connection is made I need to hold the modem control signals so the connection is not broken while I run a program such as Pro Page and do output to the printer, then additional commands need to be sent to the port to break the connection to the printer. Powering off the Amiga should break the connection too by dropping the modem control signals (DTR I think). Since I have not found a way to do this yet, my current work around is to program the DECserver to ignore the modem control signals on the Amiga port. However, that means that if the user forgets to go back and issue the commands to release the printer then even when the Amiga is turned off the printer remains connected to the Amiga port and other users (two VAXs worth in this case) can not get access to it. There are several questions here such as what can be expected of programs like Pro Page with respect to sharing of the serial port in this way and what options does the shared mode offer in situations like this? Do all programs sharing the port have to open it in shared mode or could my little program open it shared first and then another one like Pro Page open it without being required to specify the shared option. Oh, and BTW - anyone know of a suitable program (i.e. not a big full functioned terminal emulator, just a lean and mean keyboard to port and port to screen tool with sharing or some other way of controlling the modem control signals)? Bob Hassinger 508-435-9061 UUCP: ...uunet!ccavax!lmrc!hassinger
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (10/24/89)
I do this all the time (have one program hold the serial device
open whilst I execute another). Are you sure you are using the
1.3 serial.device ???
There is a problem... many terminal programs and other programs
do not open the serial.device SERF_SHARED !! THIS IS WRONG! You
programmers out there, ALWAYS OPEN SERIAL.DEVICE SERF_SHARED !!
The other problem is that the serial.device will refuse to
do a SDCMD_SETPARAMS call while active requests are pending, so
if you do use something similar to what I've described above you
have to be sure that the first program doesn't have any active
requests when it executes the second program.
-Mattpapa@pollux.usc.edu (Marco Papa) (10/25/89)
In article <8910240641.AA22293@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: | There is a problem... many terminal programs and other programs | do not open the serial.device SERF_SHARED !! THIS IS WRONG! You | programmers out there, ALWAYS OPEN SERIAL.DEVICE SERF_SHARED !! I disagree. Terminal programs should give you the "option" of opening the serial device in SHARED mode. A-Talk III allows you to do that by using the SHARED keyword either on the CLI command line or in a Tooltype. | The other problem is that the serial.device will refuse to | do a SDCMD_SETPARAMS call while active requests are pending, so | if you do use something similar to what I've described above you | have to be sure that the first program doesn't have any active | requests when it executes the second program. Quite true. The comm program must give you a 'menu' selection that aborts all active requests and optionally saves the current serial device status. A-Talk III does that too. Of course, none of these problems are present when using and XPR-based protocol library. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma, Diga and Caligari!" -- Rick Unland -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
aries@dvinci.UUCP (Aries Project) (10/26/89)
From article <8910240641.AA22293@postgres.Berkeley.EDU>, by dillon@POSTGRES.BERKELEY.EDU (Matt Dillon): > > I do this all the time (have one program hold the serial device > open whilst I execute another). Are you sure you are using the > 1.3 serial.device ??? > > There is a problem... many terminal programs and other programs > do not open the serial.device SERF_SHARED !! THIS IS WRONG! You > programmers out there, ALWAYS OPEN SERIAL.DEVICE SERF_SHARED !! > > The other problem is that the serial.device will refuse to > do a SDCMD_SETPARAMS call while active requests are pending, so > if you do use something similar to what I've described above you > have to be sure that the first program doesn't have any active > requests when it executes the second program. > > -Matt
aries@skorpio.usask.ca (Aries Project) (10/26/89)
Subject: Re: Problems with serial device in shared mode Newsgroups: comp.sys.amiga.tech References: <8910240641.AA22293@postgres.Berkeley.EDU> From article <8910240641.AA22293@postgres.Berkeley.EDU>, by dillon@POSTGRES.BERKELEY.EDU (Matt Dillon): > > I do this all the time (have one program hold the serial device > open whilst I execute another). Are you sure you are using the > 1.3 serial.device ??? > > There is a problem... many terminal programs and other programs > do not open the serial.device SERF_SHARED !! THIS IS WRONG! You > programmers out there, ALWAYS OPEN SERIAL.DEVICE SERF_SHARED !! > > The other problem is that the serial.device will refuse to > do a SDCMD_SETPARAMS call while active requests are pending, so > if you do use something similar to what I've described above you > have to be sure that the first program doesn't have any active > requests when it executes the second program. > > -Matt I am indeed using the 1.3 serial.device, and I've also tried the new 1.3.2 serial.device. Both of my programs open the serial device in shared mode and when I open it for the second time the first program is in a suspended state and has no active requests. Here's some background info. The main program using the serial port is a souped up aux handler. When I want to do a file transfer, I suspend the operations of the aux handler and have the protocol open a second incarnation of the serial device. When the transfer is finished, the handler resumes its operations. This works just fine 90% of the time, but all too frequently I lose DTR when the protocol tries to open the serial device. I am currently forcing DTR and things work fine, but I want to hang up by dropping DTR... -Mike Oliphant
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (10/27/89)
Ok. Well, at least terminal and other programs should have an
*option* to open the serial.device SERF_SHARED.
:I am indeed using the 1.3 serial.device, and I've also tried the new
:1.3.2 serial.device. Both of my programs open the serial device in
:shared mode and when I open it for the second time the first program
:is in a suspended state and has no active requests.
:
:Here's some background info. The main program using the serial port
:is a souped up aux handler. When I want to do a file transfer, I
All I can think of is that, somehow, you are closing one
instance of the device before openning the second, causing DTR
to drop momentarily. Or maybe my modem isn't as sensitive.. I'd
have to get a scope on the DTR line to be sure and I don't have
a scope.
-Matt