Very Computer

Quote:>Hello,

>Sorry for the multi-group crosspost.  I was not sure where to look.

[some stuff deleted]

Quote:>OK history aside, what is now happening is that the initial parameters
>on the ports in question are 9600 (and so on), ie, not what you would
>expect, and after our open call and ioctl calls, NOTHING *Y CHANGES
>at all, our program output gets post processed (because for some reason
>OPOST [along with everything else] that we clear [which worked on the
>ports never having had terminal service] in not getting cleared), and
>things are a mess.  

This is normal behavior.  The ports will revert to what the kernal
wants them to be (300 baud, etc), when the LAST open terminates.
SO, you can open the port, dink with it, but when you close it BAM,
back to 300 baud.  The "trick" is to keep the port open with
something like "sleep 999999 </dev/ttynn &".  This will keep the port
open so when your setup terminates, the changes will keep.  You can
test this by trying to change the port with stty and see if the changes
take.  Then do the same changes after running the sleep command above.

Quote:>I REMOVED ports services for the ports in question and no change.  We
>contacted the software vendor for the other application that is also on
>this system, and to their knowledge, there is nothing in their package
>that would go out and open these ports AND KEEP THEM OPEN.  It is this
>concept of something, somewhere, that is opening these ports and
>keeping them open (or somehow locked) (and thus preventing our ioctl's
>from having any effect) that we are now focusing on.  This is also
>supported by the fact that initial port parms should have a baud rate
>of 300.  On the ORIGINAL ports we used, as I said, they were initially
>300 baud, went to 9600 after our inits, then at close, immediately went
>back to 300 baud.