Subject: Re: [TN3270E Extensions draft]

From: Jim Mathewson II <[email-masked]>
Date: Mon, 27 Jul 1998 10:01:56 -0400

Agree with your additional conditions.  Added a comment,  see #,  for
clarification on "emptying"
the typeahead queue.

Jim,

One comment - right at the end.

> I apologize for reading a down level copy.  I missed the fact that
> it was updated.  I'm glad to see some of the changes/comments I made
> were already included, I guess that means we must be getting close
> to what we want.

> Please note @ in the first column for my responses/comments.

> Just a couple comments embedded....

> On 23-Jul-98 at 20:39, Derek W. Bolton ([email-masked]) wrote:
> > 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.
> >
> > > Following is from reading a couple of appends on subject:
> >
> > > Some Generic comments:
> >
> > > 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 but I
> > > believe the use of a single term with a crystal clear definition is
> > > preferred 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.
> >
> @
> @ It appears that we also like the term keyahead.  It appears they are
> @ equivalent.
> @
> > > > 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.
> >
> > 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.
> >
> @
> @ OK
> @
> > > 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.
> >
> > > On the TN3270E Extensions draft:  (Using the definitions above)
> >
> > > 4.2 Implied Keyboard Restore Problem
> >
> > > (comment)
> >
> > > 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.

> 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 (i.e. brainlessly do the reverse
> mapping from IKRI-->EB). Client implementors may want to comment
> here.

> @ The better from my perspective is that there is no new
> @ architecture required to solve this problem.  All the required
> @ tools are available with existing architecture.  Additionally A
> @ Client would be required to change to process the KRI flag as the
> @ Server must be change to generate the KRI flag.  With the use of
> @ the F1C2 proposal ONLY the Server has to make a change, AND I
> @ believe most well mannered Servers already do this today.

> >
> >
> > > 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 (positive 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 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?
> >

> @ Either the receipt of the BIND image would inform the Client it is
> @ SNA or as you have proposed the Server will only negotiate if SNA.
> @ There are no equivalent to BID/SIGNAL in non-SNA, which is easy to
> @ understand why the tn3270 architecture didn't address this since
> @ tn3270 was modeled on non-SNA.

> > > 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 determination 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 alleviate 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.
> >
> > 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 write-up on how X-CLOCK and
> > > X-SYSTEM work with the SDI implementation.
> >
> > Which write-up do you believe ;-)?

> @ Mine ;-} I believe I wrote this up once already and appended to this
> @ forum.  I could do again if you like.

> >
> > > 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 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
> >

> @  just accept bid simpler logic.

> >   lock keyboard

> agree. This interaction should perhaps be in an appendix?

> >
> > > 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.

> 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?

> @ I believe before the Client responds to the BID the typeahead queue
> @ should be emptied.  This way if an AID key is in the typeahead
> @ queue the AID will be sent in in response to the BID.  At least
> @ all the keystrokes stacked will be processed so that a READ BUFFER
> @ will actually get updated Presentation Space.

When the client responded to the Bid:
- if the Host already had direction (race condition), the typeahead
queue should not be touched;
- if the Host did not have direction, the typeahead queue was almost
surely empty anyway.  I can think of two situations in which it would
not be empty:
  a. Backlog of work.  In this case, I agree that the client can
continue to process it as far as an AID before handling the Bid.
# Leaving the rest of the typeahead queue untouched.  (Condition when multiple
# AID functions in the typeahead queue.)
  b. Host sent CD but not KR (i.e. Sys Lock).  I think the typeahead
queue should not be touched here either.

Regards,
  Derek