You got close enough.Quote:>Hello,
>Sorry for the multi-group crosspost. I was not sure where to look.
[some stuff deleted]
I'm not sure I understand your problem. But here goes anyway.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.
Stupid question, but I have to ask; What about getty? ttymon?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.
>I would think that if a port had *NO* port service DEFINED (not just
>DISABLED), and no other process had it opened, it should be 300 baud.
>So, something has to have it and we are not sure how to tell whom. Under
>SVr3 (SCO), the pstat command aided in locating open inodes and their
>opening processes. But (and here is the real reason for my post), how
>do you do it under SVr4??????? :-) And, maybe it is not what I am
>leaning towards at all and if you have another thought (anything! :-)),
>we would be most appreciative to you! If SVr4 was in house and used
>everyday here, no biggie, I am sure, but this is one of those "HHhhmmm....
>how did I manage to get in this #^%#&^% mess?" situtations and we are
>Thank you for your time and endurance!
>Mark J. Bailey, N4XHX _______/====X11====\_______
>USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 | JobSoft |
>VOICE: +1 615 893 0098 | Design & Development Co.|
>UUCP: ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb | Murfreesboro, TN USA |
Alan Edmonds Texas Instruments, Inc.
I don't speak for TI; TI doesn't speak for me M/S 8513
Work phone: (214)575-6427 6620 Chase Oaks Blvd.