Subject: Re: [TN3270E Extensions draft]

From: Jim Mathewson II <[email-masked]>
Date: Fri, 24 Jul 1998 10:20:02 -0400

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

/msb

---

From: "Derek W. Bolton" <[email-masked]>
Date: Sat, 25 Jul 1998 10:30:59 +1000 (EST)

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.

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

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

> 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.
  b. Host sent CD but not KR (i.e. Sys Lock).  I think the typeahead
queue should not be touched here either.

Regards,
  Derek