From:	GALAXY::GLEEVE        8-NOV-1992 19:23:56.17
To:	MERC::"uunet!IT.SUNQUEST.COM!GAVRON"
CC:	GLEEVE
Subj:	RE: query

Monitoring RT type devices is a substantially different problem
from monitoring normal TT type devices. Instead of having a
port/class interface to steal, you need to to the sort of thing
you use to monitor any device's I/O.
   That means you get your codein their either at FDT time or
at start-io time. On writes to the device, you can just grab off
a copy of the date to your monitor program; sending it thru
exe$writembx (probably a spelling error there) can do the
trick, provided you can find the mailbox fast. Or you can find
some other way to dump the data to your desired place. Capturing 
reads is harder: you need to arrange (pref. via stealing irp$l_pid)
to get control before the I/O completes, and grab whatever data
returned from the read. With terminal I/O this is complicated
by the fact that the return data can either be in a normal
buffer, or can be in an itemlist QIO return, which must be
at least partly parsed to get info on where the data will be going.
   Now, getting the data to a real terminal can also be interesting
since in principle you might need to capture an itemlist I/O
and reissue it or a copy to the real terminal. I personally believe
that for many purposes just getting the input and the heck with
the prompt strings and so on would be fine. Certainly for monitoring
security data that should be OK. For remote helping, it isn't
always so good. In any case, you're going to be waiting for the
user I/O to complete (i.e. not seeing each character as it comes
in; DECnet does have some mode that can force char. I/O but it
really impacts performance.
   You steal the control from ctdriver of course...
Hope this helps...
Glenn
everhart@raxco.com
  (I've suggested this method in public forums in the hope someone
would do it, but nobody has yet..)
   Perhaps when I provide an example FDT stealer driver on the tapes
(which I hope will happen for F92) by way of a standard way to keep
vector stealing from walking over other vector stealers this will
be easier to code. I've got some code written, but need to get it
debugged. Then I'll pull the code for the stuff I'm doing for a
product and leave the example driver part, with maybe a short
example of doing a little poking at a user's I/O.
Glenn