Subject: [TN3270E Extensions draft]

From: Jim Mathewson II <[email-masked]>
Date: Mon, 20 Jul 1998 11:30:08 -0400

Following is from reading a couple of appends on subject:

Some Generic comments:

I believe we should make a clear definition, and then clear useage of "AID
inhibit mode",
"Keyboard Lock",  "input inhibited",  "keyboard buffering", "typeahead mode"
and maybe
a couple of others we may stumble across.

I prefer the term "Typeahead Mode" to mean the ability to "buffer keystrokes"
when the keyboard is
locked due to an AID operations.  This is because at one time all products
didn't support the keyboard
buffering capability.  It appears that now though all products support
typeahead so the distinction between
the ability and use is not required. It appears that the use of "keyboard
buffering" is used interchangeably
with "typeahead mode" to mean the actual buffering of keystrokes I have no
problem which term is used
buf I believe the use of a single term with a crystal clear definition is
perferred in an architecture document
such as the one we review. I would prefer the term keyboard buffering but again
I have no strong preference.

> GP: AID inhibit mode may be OpenConnect-ese, I doubt you will find it in SNA
(IBM) manuals.
> It refers to the times the client is no supposed to forward 3270 AID messages
to the server.
> Although the client may send SYSREQ or ATTN.
In SNA (IBM) manuals you may find reference to receive state.  Which is what I
think you mean by
"AID inhibit mode".  A Client should post a Minus Function when an
AID-generating function is invoked
in "AID inhibit mode".   I agree with this definition.

"Keyboard Lock" - I read as X-CLOCK or X-SYSTEM is displayed and keystrokes are
being buffered waiting
for contention or send state to be entered to have the buffered ("stacked")
keystrokes be processed.  I prefer
the using the X-CLOCK and/or X-SYSTEM explicitly since keyboard lock has
traditionally been used interchangeably
with "input inhibited" but for the TN3270 if the distinction will be whether
keystrokes are processed immediately or
buffered ("stacked") then I have no problem with this definition.

"Input Inhibit" - I read as a condition where keystrokes are NOT being buffered.

On whether the keyboard lock state should be entered or not when a BID or a
SIGNAL by the PLU is positively
responded to by the SLU I have no opinion either way.  I can make rational
arguments on both sides and I believe
each CLIENT developer can go either way.

On the RESET function.  I believe that RESET should clear the typeahead buffer
under all conditions except the removal
of INSERT MODE function.  In a note from [email-masked] he indicated that reset
should NOT clear the typeahead buffer
when the reset is used to remove an error condition.  I believe it should as I
believe that the operator was typing ahead
assuming NO errors to be encountered and if an error was encountered all the
keystrokes they typed would not be appropriate.
This is also true when the RESET function is used to get rid of the X-SYSTEM
condition since the normal method for an application
to indicate an ERROR in the previous AID operation is to update the
Presentation Space with an error message, blinking field in
error or something similiar with no keyboard restore in the WCC and CD in the
RH.

On the TN3270E Extentions draft:  (Using the definitions above)

4.2 Implied Keyboard Restore Problem
(comment)
CD is NOT an implied keyboard restore.  EB is an implied keyboard restore and
today a SERVER can/should send to
the CLIENT a F1C2 to turn the implied keyboard restore detected by the SERVER
via the EB into an explicit keyboard restore
detectable by the CLIENT.  (I don't believe any new architecture is required
here.)

4.3 BID Problem
(proposed new words for the first two paragraphs)
In SNA, when a session is BETB (Between Brackets), the Primary LU (PLU), or
host, may bid for the bracket by
either sending an explicit BID or implicit BID.  The Secondary LU (SLU),
controller or terminal, processes the BID,
either granting the bracket to the host or rejecting the request.  Having
granted the bracket the SLU must enter "AID
Inhibit mode"

An implicit BID occurs when the session is BETB and the host (PLU) sends a
message to the SLU with Begin Bracket (BB)
indicated.  No BID actually flows but is implied.  The SLU may accept or reject
as if an explicit BID had been sent.

(rewording on fourth paragraph last sentence)
Having granted the BID (postive response), the client must enter the "AID
inhibit mode" until the SLU reenters contention or
send  state.

4.5.1 Send Data Indicator (SDI)
(comment)
SDI is not required for NON-SNA, in fact it has no meaning.  It should never be
sent.
In the fourth paragraph you indicate the SID will be sent for non-SNA
implementations when the session enters
contention state?!  There is no such state for non-SNA.  Since the BIND only
flows on SNA contentions make it
a condition for the use of SDI.  NO BIND flow, no SDI.

SDI is NOT an implied keyboard restore!!!

In the eighth paragraph you discuss/suggest that the keyboard restore in the
WCC should be the sole determinator
as to whether the "buffered keystrokes" should be processed.  You might find it
useful to wait for both WCC keyboard
restore and SDI before you process the "buffered keystrokes"  This would
allievate X-SYSTEM problems with attempting
to process a "buffered" AID key prior to receiving the SDI.

On the GP: note.  I think the SERVER should just throw away successive ATTNs.

What is a RESTORE key?  Do you mean RESET key?  If so remember RESET key won't
reset X-CLOCK which
is what should be displayed when you support this SDI function after an AID key
is depressed.  Along these lines I
believe a writeup on how X-CLOCK and X-SYSTEM work with the SDI implementation.

4.5.2 BID Data Type
(comment)
In the sixth paragraph you indicate the keyboard should remain unlocked, refer
to my comment/response above
on whether the keyboard should be AID inhibited or not.

4.5.3 SIGNAL Indicator
Same discussion on keyboard being left unlocked.

I don't understand you statement on buffered type-ahead data.  SIGNAL should
NOT purge the typeahead queue.
I also believe the race condition you described should allow the SERVER to send
the data received by the CLIENT
along with CD to the host.  Don't throw the data away.

That's all for now.

---

From: "Derek W. Bolton" <[email-masked]>
Date: Fri, 24 Jul 1998 10:36:05 +1000 (EST)

Jim,

Unfortunately you were working with the copy that Michael
forwarded to the list.  Right after that, Gene posted a
revised copy that addresses some of your points.

> I believe we should make a clear definition, and then clear usage
> of "AID inhibit mode", "Keyboard Lock", "input inhibited", "keyboard
> buffering", "typeahead mode" and maybe a couple of others we may
> stumble across.

> I prefer the term "Typeahead Mode" to mean the ability to "buffer
> keystrokes" when the keyboard is locked due to an AID operations.
> This is because at one time all products didn't support the keyboard
> buffering capability.  It appears that now though all products
> support typeahead so the distinction between the ability and use is
> not required. It appears that the use of "keyboard buffering" is
> used interchangeably with "typeahead mode" to mean the actual
> buffering of keystrokes I have no problem which term is used buf I
> believe the use of a single term with a crystal clear definition is
> perferred in an architecture document such as the one we review. I
> would prefer the term keyboard buffering but again I have no strong
> preference.

Agree.

> In SNA (IBM) manuals you may find reference to receive state.  Which
> is what I think you mean by "AID inhibit mode".  A Client should
> post a Minus Function when an AID-generating function is invoked in
> "AID inhibit mode".  I agree with this definition.

> "Keyboard Lock" - I read as X-CLOCK or X-SYSTEM is displayed and
> keystrokes are being buffered waiting for contention or send state
> to be entered to have the buffered ("stacked") keystrokes be
> processed.  I prefer the using the X-CLOCK and/or X-SYSTEM
> explicitly since keyboard lock has traditionally been used
> interchangeably with "input inhibited" but for the TN3270 if the
> distinction will be whether keystrokes are processed immediately or

> "Input Inhibit" - I read as a condition where keystrokes are NOT

Because keyahead was not part of the original 3270 function, the usage
of the term "Input Inhibited" is inconsistent in the manuals.
Appendix E of the 3174 Functional Description (which is copied
verbatim from earlier 3270 manuals) defines it to include both
keyboard buffering states (Time, System Lock, Printer [Very] Busy),
and keyboard disabled states (the rest).

I suggest the spec should define:

 - Keyahead states (Time, System Lock, Printer [Very] Busy)
 - Keyboard disabled states (X -f etc.)
 - xxx Inhibited == (keyahead | keyboard disabled), where
   xxx is either "Input" or "AID".  I.e. we should use one or other
   of these terms, but not both.  I prefer Input Inhibited because
   (a) that is the term used in the manuals, and (b) because AID
   Inhibited seems to imply that the only thing that's affected is
   AID keys, whereas, in fact, data keys are blocked from reaching
   the screen image.
 - Ready == not Input Inhibited
 - Time == X-CLOCK
 - System Lock == X-SYSTEM, etc.

In summary:

  --------------------------------------------------------------
  Ready  |                    Input Inhibited
         |------------------------------------------------------
         | Keyahead                    | Keyboard disabled
         |-----------------------------+------------------------
         | Time | Sys Lk | Prtr Busy   | X -f | .....
  --------------------------------------------------------------

Finally, SYSREQ and ATTN bypass the keyahead queue and are not
affected by Input Inhibited.

> On whether the keyboard lock state should be entered or not when a
> BID or a SIGNAL by the PLU is positively responded to by the SLU I
> have no opinion either way.  I can make rational arguments on both
> sides and I believe each CLIENT developer can go either way.

Appendix E states that Bid puts the terminal in Time state.
Signal is not specifically mentioned, presumably because it is
not the receipt of Signal that changes the state but the inbound
message resulting from the Signal.  I agree that this is really
outside the scope of tn3270 specification.

> On the RESET function.  I believe that RESET should clear the
> typeahead buffer under all conditions except the removal of INSERT
> MODE function.  In a note from [email-masked] he indicated that
> reset should NOT clear the typeahead buffer when the reset is used
> to remove an error condition.  I believe it should as I believe that
> the operator was typing ahead assuming NO errors to be encountered
> and if an error was encountered all the keystrokes they typed would
> not be appropriate.

> This is also true when the RESET function is used to get rid of the
> X-SYSTEM condition since the normal method for an application to
> indicate an ERROR in the previous AID operation is to update the
> Presentation Space with an error message, blinking field in error or
> something similiar with no keyboard restore in the WCC and CD in the
> RH.

I agree.  I think the version you attribute to Michael came from my
misreading of the 3174 manual, but now I believe the manual is
ambiguous here, and your reading makes more sense.  See the
description of the RESET function in Chapter 4.

> CD is NOT an implied keyboard restore.

This has been corrected in the later draft.

> EB is an implied keyboard restore and today a SERVER can/should send
> to the CLIENT a F1C2 to turn the implied keyboard restore detected
> by the SERVER via the EB into an explicit keyboard restore
> detectable by the CLIENT.  (I don't believe any new architecture is
> required here.)

OK - so you're saying:

 CD -> SDI
 EB -> SDI F1C2

Sounds OK, though I don't see that as better or worse than adding a
KRI flag.

> In SNA, when a session is BETB (Between Brackets), the Primary LU
> (PLU), or host, may bid for the bracket by either sending an
> explicit BID or implicit BID.  The Secondary LU (SLU), controller or
> terminal, processes the BID, either granting the bracket to the host
> or rejecting the request.  Having granted the bracket the SLU must
> enter "AID Inhibit mode"

> An implicit BID occurs when the session is BETB and the host (PLU)
> sends a message to the SLU with Begin Bracket (BB) indicated.  No
> BID actually flows but is implied.  The SLU may accept or reject as
> if an explicit BID had been sent.

> Having granted the BID (positive response), the client must enter the
> "AID inhibit mode" until the SLU reenters contention or send state.

> SDI is not required for NON-SNA, in fact it has no meaning.  It
> should never be sent.  In the fourth paragraph you indicate the SDI
> will be sent for non-SNA implementations when the session enters
> contention state?!  There is no such state for non-SNA.  Since the
> BIND only flows on SNA contentions make it a condition for the use
> of SDI.  NO BIND flow, no SDI.

How does the client know whether it is SNA or non-SNA?  Or are you
saying that CONTENTION-RESOLUTION should only be negotiated by a SNA
server?  Are there no equivalents to the BID and Signal problems in
the non-SNA case?

> SDI is NOT an implied keyboard restore!!!

Already amended.

> In the eighth paragraph you discuss/suggest that the keyboard
> restore in the WCC should be the sole determinator as to whether the
> "buffered keystrokes" should be processed.  You might find it useful
> to wait for both WCC keyboard restore and SDI before you process the
> "buffered keystrokes" This would allievate X-SYSTEM problems with
> attempting to process a "buffered" AID key prior to receiving the
> SDI.

> On the GP: note.  I think the SERVER should just throw away

If the server has not yet received RSP(Signal), yes.

> What is a RESTORE key?  Do you mean RESET key?

Already amended.

> If so remember RESET key won't reset X-CLOCK which is what should be
> displayed when you support this SDI function after an AID key is
> depressed.  Along these lines I believe a writeup on how X-CLOCK and
> X-SYSTEM work with the SDI implementation.

Which write-up do you believe ;-)?

> In the sixth paragraph you indicate the keyboard should remain
> unlocked, refer to my comment/response above on whether the keyboard
> should be AID inhibited or not.

> Same discussion on keyboard being left unlocked.

I accept that Signal does not of itself lock the keyboard.  But the
secondary responds with an inbound message - either real data or a
null RU CD.  Either way, that should indeed cause the keyboard to
become locked through the normal "AID sent" process.

In the tn3270e environment, the null RU CD will be generated by the
server on behalf of the client, therefore the SIGNAL Indicator must
lock the keyboard:

Server behavior:

 send +rsp to signal
 if host already has direction, or in contention state,
   nothing more to do
 else
   /* client has direction */
   send forced bid (i.e. BID with signal indicator) to client and wait
   for reply or data...
   if receive data first
     forward data to host as normal (will carry CD)
   else
     /* rsp first */
     send null RU CD to Host (with BB if necessary)

Client behavior:

  rcv forced bid:
  if host has direction (i.e. inbound crossed with bid)
    accept bid, or ignore it, or whatever the BID spec says now
    for this race condition
  else
    accept bid

  lock keyboard

> I don't understand your statement on buffered type-ahead data.
> SIGNAL should NOT purge the typeahead queue.  I also believe the
> race condition you described should allow the SERVER to send the
> data received by the CLIENT along with CD to the host.  Don't throw
> the data away.

The data should not be discarded, I agree.  But if the AID key has not
yet been pressed then the client should not forward any data at this
time.  It should just accept the bid.  Diagrammatically, the client
then has:

    <---- data entered before Bid ---->|<- keyahead data after Bid ->

    ^ This data is in the screen image ^

So the appl can do a Read Buffer, update the portion of the screen it
wants to change, put the cursor back to the right place for the
suspended input and restore the keyboard.  The client then streams the
keyahead queue into the screen image.

Regards,
  Derek

---

From: Michael Boe <[email-masked]>
Date: Fri, 24 Jul 1998 11:08:03 +1000 (EST)

Just a couple comments embedded....

>  - System Lock == X-SYSTEM, etc.

I'd prefer a KRI flag (actually, a flag that says "Implied KRI" :-) over the
specific F1C2 sequence because I think that's easier for full-SNA-stack clients
to implement (ie, brainlessly do the reverse mapping from IKRI-->EB). Client
implementors may want to comment here.

>     accept bid, or ignore it, or whatever the BID spec says now

agree. This interaction should perhaps be in an appendix?

> keyahead queue into the screen image.

Yes, that seems right. One could argue the design merits of purging/not-purging
the typeahead queue....but the design merits aren't huge either way.  So
historical usage should decide.  Again, this interaction should be
explicated(as above) in an appendix?

/msb