This is re: a letter suggesting how to capture RT terminal I/O. The
suggestion is to steal the FDT code in CTdriver, and for reads
reset the irp$l_pid field to some of my code in pool which would
grab the data, then replace the original pid and finish the I/O.
The normal I/O list operations (or anything else) would take
place, and all I'd return would be the data typed by the remote
user, decoding no more than necessary to figure out where that
was. Somehow the IRP address and original irp$l_pid field would
have to be coupled, perhaps by allocating an IRPE at the time of
stealing the IRP, but more likely by allocating another structure
which could be searched for when the IRP returned. The scheme
used in vddriver, where the return address encoded the extra
info, might even be tried if very extended, since a fairly large
number of outstanding IRPs must be permitted.
 Glenn Everhart

From:	AITGW::"kenney@star.enet.dec.com" "Forrest A. Kenney" 14-JAN-1992 15:03:46.95
To:	arisia::everhart
CC:	
Subj:	RE: Boss etc.

Received: by AITGW.DECnet (utk-mail11 v1.5) ; Tue, 14 Jan 92 15:04:50 EST
Received: from enet-gw.pa.dec.com by aitgw.ge.com (5.65/GE Gateway 1.4)
	id AA23819; Tue, 14 Jan 92 15:04:45 -0500
Received: by enet-gw.pa.dec.com; id AA29912; Tue, 14 Jan 92 11:55:30 -0800
Message-Id: <9201141955.AA29912@enet-gw.pa.dec.com>
Received: from star.enet; by decwrl.enet; Tue, 14 Jan 92 12:01:53 PST
Date: Tue, 14 Jan 92 12:01:53 PST
From: Forrest A. Kenney <kenney@star.enet.dec.com>
To: arisia::everhart
Apparently-To: everhart@arisia.dnet.ge.com
Subject: RE: Boss etc.
 
>   As for monitoring RT terminals, I've been looking a bit aty
>the terminal driver manual. It is clear to me one can steal the
>CTdriver fdt entry so that read/write are first seen by my
>code. Since an IRP should exist by then, I can also arrange
>to have my code gain control on I/O completion if it's a read,
>so that I should be able to capture a copy of whatever comes
>back. This would not need any mods to the QIO$, though it would
>only give the I/O info back on completion of each line, not in
>real time as watch does for tty class terminals. For logging
>purposes, though, this ought to be adequate.
 
	That actually goes further than I had intended to go but I see no
reason why it would not work just fine.  
 
>   What's not clear is that there's any need for using itemlist,
>or rather why one should do such a thing on read. I gather there's
>some mode that can be set to get quicker echoes, but it seems
>one will need to get control back on I/O completion by stuffing
>the irp$l_pid field and THEN grabbing the data off. Certainly
>it seems like a horrible hack if one tried to turn the read
>into a set of single-byte QIO$s or something of the sort.
 
	Item list reads  are really needed for extended field validation
support used by FORMS packages.  It gets kind of messy to deal with them, I
would probably skip trying to do much with them.  If you wanted to get real
fancy you would want to capture the READ description, and try and unpack it to
sort out the display, and the results in the watching code.  I will send you a
driver that you can look at to see how we approached dealing with item list
reads.
 
	Under no condition would I try to break them up and do single character
I/Os ofer the DECnet link.
 
Forrest