Subject: Re: [TN3270E Extensions draft]

From: "Stan Ratliff" <[email-masked]>
Date: Sat, 25 Jul 1998 18:29:11 -0500

One comment on the KRI flag.

-----Original Message-----
From: Derek W. Bolton <[email-masked]>
To: Jim Mathewson II <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>
Date: Friday, July 24, 1998 7:37 PM
Subject: Re: [TN3270E Extensions draft]

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

IMHO, the better approach is to send the KRI flag. TN3270 has been
plagued for years with things like this (if the server sent F1C2, it
REALLY meant EB), and it always seems to bite us on the backside.
I think we should be explicit, and send the flag. Eschew obfuscation ;-).

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