Conference noted::hackers_v1

I have played around with this before.  I'm not absolutely certain
I have it right, but the way I think it works is:

UCB$L_TT_TYPAHD points to a "typeahead block".  Offsetting from that
block, TTY$W_TA_INAHD contains the number of chars in the typeahead buffer.
TTY$L_TA_GET points to the characters in the buffer.

I think your confusion might be because you're expecting characters
to be in the TAB when they're not.  When you type a couple of chars
but not <CR>, the data is not in the TAB; rather it has already been
buffered into a system buffer.  The key is to type some input BEFORE
a read is active.  An example of how to do this: type DIR/FULL, then
type NOSCROLL, then type a few chars.  Since the output of the DIR
is stalled, DCL's next read is not yet queued, and the chars you
type will be sitting in the TAB.  SDA will confirm this.

	Rico

     Both my first note and the initial reply contain incorrect information. 

>>   I formatted @(UCB+UCB$L_TT_TYPAHD) /TYPE=TTY while in SDA,
>>   after setting my process index to the process being examined,
>>   but evaluating the offsets results in strangness (see below)
>>   also it seemed that @(UCB+UCB) pointed to the text in the 
>>   buffer but then it did not and all references to text were lost. 
	
     Setting the process index is irrelevant, @(UCB+UCB) does not 
     point to the TAB rather @(UCB+UCB$L_TT_TYPAHD)+TTY$L_TA_DATA
     does. This is misleading since the buffer gets filled in a 
     circular fashion such that one must examine the whole buffer
     to locate where the relevant (Stuff typed but not yet entered
     with return key) information is stored. The problem is it is 
     sort of random since it gets filled where the last string ended.
     
>>   Offsets TTY$L_TA_GET and TTY$L_TA_PUT always seem to point 
>>   to the same location as each other, although their pair of 
>>   actual values do change.   

     I believe this is due to the fact that the above pointers 
     (Get and put) point to the stuff put in and not fetched out.
     These not often different so they appear identical. This also 
     explains why TTY$_INAHD is often zero, because it points to
     what how much stuff is put in and not fetched out. 

>>   What does point to the Type-ahead buffer?
     The contents of (UCB+UCB$L_TT_TYPAHD)+TTY$L_TA_DATA does.
	
>>   What does point to the length?.
     UCB$L_TT_TYPAHD(UCB)-TTY$W_TA_SIZE(UCB$L_TT_TYPAHD(UCB))

>    TTY$W_TA_INAHD contains the number of chars in the typeahead buffer.
     Actually the number of chars put in and not yet fetched out

>    TTY$L_TA_GET points to the characters in the buffer.
     Again, the characters put in and not yet fetched out

>    I think your confusion might be because you're expecting characters
>    to be in the TAB when they're not.  When you type a couple of chars
>    but not <CR>, the data is not in the TAB; rather it has already been
>    buffered into a system buffer.  

     I believe this is erroneous, reviewing the above mentioned modules
     (v4.4) seems to imply the read does not influence what is buffered.
	
>    The key is to type some input BEFORE a read is active.  
>    An example of how to do this: type DIR/FULL, then
>    type NOSCROLL, then type a few chars.  Since the output of the DIR
>    is stalled, DCL's next read is not yet queued, and the chars you
>    type will be sitting in the TAB.  SDA will confirm this.
     
     I, respectfully, do not agree with any of this. The read is active,
     SDA confirms that.  
	 
     Thanks to Rico, and anyone else that can shed some light on this,

     John

>>>   Offsets TTY$L_TA_GET and TTY$L_TA_PUT always seem to point 
>>>   to the same location as each other, although their pair of 
>>>   actual values do change.   

>     I believe this is due to the fact that the above pointers 
>     (Get and put) point to the stuff put in and not fetched out.
>     These not often different so they appear identical. This also 
>     explains why TTY$_INAHD is often zero, because it points to
>     what how much stuff is put in and not fetched out. 

	True. The typeahead buffer is a circular buffer;
	characters are inserted at TTY$L_TA_PUT and it is then
	incremented; fetches are done at TTY$L_TA_GET.
	If a read is pending, these will be equal, as the
	characters PUT in have been GET (got) out to the user's
	buffered I/O packet.

>>    I think your confusion might be because you're expecting characters
>>    to be in the TAB when they're not.  When you type a couple of chars
>>    but not <CR>, the data is not in the TAB; rather it has already been
>>    buffered into a system buffer.  
>
>     I believe this is erroneous, reviewing the above mentioned modules
>     (v4.4) seems to imply the read does not influence what is buffered.
	Not quite true. With the exception of the case where a PASSALL,
	NO ECHO read is active when the character arrives, ALL input
	goes thru the typeahead buffer. Now, they'll be REMOVED right
	away, but the stuff is still there..


	-Rick

I think you are right in saying that all data goes through the
typeahead buffer unless a PASSALL or PASTHRU read is active.
But as you say each character has a short life there.
If you type a character and it has been echoed, almost certainly
that character is not in the TAB but has been read into an
intermediate buffer already.

Back to the DIR/FULL example: If you type DIR/FULL, carriage return,
then type NOSCROLL before the output is complete, then there will
NOT be a read pending.  A write operation will likely be pending,
but not a read.  Leaving the terminal in NOSCROLL, type some characters.
They WILL be in the typeahead buffer.  I have confirmed this before
with SDA.  Presumably, DIRECTORY.EXE is doing QIOWs to do its output,
which of course means that the subsequent read will not be queued
until all the writes have completed.

	Rico