grubin@BBN-SPCA.ARPA (Gail Rubin) (09/09/85)
We used the method of patching the TTDRIVER to get broadcast messages to PASSALL terminals under VMS V3.x. Now with VMS 4, we rewrote our editor to use the new PASSTHRU terminal characteristic which does not prevent broadcast messages from coming through AND allows you to use flow control. If you control the software that uses PASSALL, I think this is the preferred method. (Yeah, I'm getting multiple copies of info-vax too.) -- Gail Rubin (grubin@bbn-spca or @bbn-unix)
NEVILLE%umass-cs.csnet@CSNET-RELAY.ARPA (09/10/85)
Yes, using the new PASTHRU setting does solve much of the problem, although sometimes i'd rather have *all* input available instead of losing ^S, ^Q to flow control. Usually i'd rather have flow control. What i should have emphasized is that the (BRDCSTMBX) method i described allows you to gain control over how the broadcast messages are handled. You can choose to scribble them on the display just like the TTDRIVER, store them up for display on program exit, issue them into a special "broadcast" window, or whatever. You can even use it to screen your PHONE calls! Note that it will also work from another process in your session. i sometimes spawn a background process for the express purpose of handling broadcast messages. Neville Newman neville@umass-cs (CSnet)
KVC@engvax.UUCP (09/11/85)
> Yes, using the new PASTHRU setting does solve much of the problem, although > sometimes i'd rather have *all* input available instead of losing ^S, ^Q to > flow control. I believe that you can toggle the interception of ^S/^Q in PASTHRU mode with the /TTSYNC setting. Disabling TTSYNC should let the characters through the driver and into your buffer. I haven't tried this, but I was given to understand that PASTHRU is part of an effort to break control of the terminal driver's interpretation of data out to several parameters, allowing users to mix and match to get just the right amount of driver-level interpretation for their application. This is as opposed to a single parameter (like PASSALL) which allows an all-or-nothing choice. I have one concern in all this. PASSALL mode let characters drop right through the driver very very quickly, and was ideal for situations where the latency time of the character through the driver had to be minimal. Checking a combination of characteristics (PASTHRU | NOTTSYNC etc.) may not be as fast. Can anyone out there offer an informed opinion of whether PASSALL mode is significantly faster than the equivalent PASTHRU, etc. modes? If not, is PASSALL mode going to remain for the few (if any) situations where this is required? /Kevin Carosso engax!kvc @ CIT-VAX.ARPA Hughes Aircraft Co.