Subject: Re: Keyboard Restore Bid Proposal II

From: "Derek W. Bolton" <[email-masked]>
Date: Wed, 10 Dec 1997 12:11:01 +1100 (EST)

Rodger,

>       Thanks for your detailed response.  I will preface my response
> by saying that there was some interest in removing SNA terminology
> as much as possible from the wire protocol.

DB2: Even if the devil has the best tunes?

> That's why the wire protocol deals with terms like CTS and RTS
> rather than BID.  Do others have strong opinions about the
> semantics?  I'm not wedded to either approach - I was merely
> reacting to feedback that I had received.  I'd be interested in
> hearing from other group members about their feelings on this...

DB2: I don't mind trying to avoid SNA terminology, I just wanted the
names to reflect the function accurately.  I can live with RTS and
CTS.  My main objection to the names is re HALF-DUPLEX as the
function.

> See my responses below (they start with "RE2")...

>   >         After further review of my original proposal and
>   > conversations with some of the working group members I have a new
>   > proposal for how I believe that we should implement this (with
>   > special thanks to Khang Le of Eicon for his input).

>   >         It has been pointed out (by Khang Le in particular) that my
>   > original proposal stopped just sort of saying that we need a way to
>   > force TN3270E into half-duplex mode and that by acknowledging that
>   > we were, in fact, making it half duplex could lead to a simpler
>   > solution.  How about the following:

>   > Negotiate HALF-DUPLEX FUNCTION:

>   >                 Add a new TN3270E FUNCTION called HALF-DUPLEX
>   > (function number 0x05).  Its purpose is to force TN3270E to operate
>   > in what is effectively half-duplex mode.  Since SNA is half duplex,
>   > it can be argued that TN3270E should also be half-duplex (especially
>   > when being full-duplex leaves holes in the protocol like the ones
>   > related to Keyboard Restore and BID).  Even though this function
>   > will make use of things like REQUEST-FLAG and RESPONSE-FLAG,
>   > negotiation of the RESPONSES function is not required.  This is
>   > because I expect there will be customers that want this new
>   > functionality without necessarily paying the performance penalty
>   > often associated with full-blown RESPONSES.  [If there is
>   > disagreement on this point we can certainly go ahead and make
>   > RESPONSES a prerequisite of HALF_DUPLEX].

    DB1: Well, SNA 3270 is not strictly half duplex.  After the Host
sends EB (and gets a response if nec.) the session is in contention.
The key question is who resolves contention.  Your previous proposal,
and this one, have the client as contention resolver.

    DB1: So I'd prefer to name this differently.  CONTENTION RESOLUTION
FUNCTION is rather a mouthful.  How about ... BID function :-)?

> RE2: You're correct about this.  I just think that terms like
> CONTENTION RESOLUTION and BID are too SNAish.  I was shooting for
> something more generic.

DB2: OK - how about SEND PERMISSION?  Or just RTS?

    DB1: What LU types would this be negotiated for?  I've assumed it's
only LUT2.  Is there any need for it on LUT1/3?  It might be
nontrivial to extend it to printers.  E.g. an RTS framed as a null
record might trigger a blank page.

> RE2: Good point.  I think that this should only be for LU Type2

DB2: Another issue is SSCP v. LU-LU.  In SNA, the SSCP-LU session is
FDX these days, so I'd argue that RTS/CTS should only operate after
the Bind.  Which means that BIND function is a pre-req.  Is that a
problem?

>   > Server sends CTS (Clear To Send - RS232 Lives!)

    DB1: This is not *strictly* necessary.  For a start, it's not quite
the right terminology.  Since the client is the contention resolver,
the server does not need to give the client permission to send. Really
this is an end-of-output marker for output that consists of multiple
chains.  Its true function is to replace the keyboard restore flag
(as, indeed, EB/CD do replace the keyboard restore flag in SNA). Even
as that it is not essential.  The server can (and the CIP server does
today) dicker with the keyboard restore flag in the Host output so as
to make it reflect the SNA state.  But that's a messy operation,
particularly with WSFs, and it does make sense to map EB/CD more
directly to something in the TN3270 datastream.

> RE2: Again, I don't want to get bogged down in the SNAness
> involved. Servers care about this but clients do not.  Thus we
> should try and avoid it in the wire protocol between server and
> client.  You're right that it is an end of input marker, but isn't
> that the same thing as saying "I'm done for now - your turn?"  Your
> point about dickering with the WCC is well taken.  That would be
> another way of doing it.  Some server vendors take that approach
> today but I didn't feel right about making that the official
> proposal.

DB2: OK.  I was just trying to point out that the benefit of CTS is in
avoiding the server having to touch the datastream.  See below for why
I wanted to make that point.

    DB1: So in a sense this is a separate issue from whether BID
function is negotiated.  It is the 'end of output' function.  But I
don't want to proliferate functions to be negotiated either, so I'm
happy that it comes as part of the package.

    DB1: The corollary is that if BID function is negotiated then the
client must ignore the keyboard restore flag in the WCC.

> RE2: I'm not sure that I agree with this.  Just as I'm trying to
> avoid having the servers dicker with the 3270 datastream, I want the
> clients to be able to deal with it cleanly as well.  Could you
> explain why the client should ignore the keyboard restore flag in
> the WCC?

DB2:
Because that is in the definition of SNA 3270!  EB/CD completely
replaces the keyboard restore flag in the WCC.  There are SNA 3270
applications which do not bother to set keyboard restore.  Ever.
There are applications which send multiple chains, with keyboard
restore in the first chain and EB/CD on the last chain.

If the client won't guarantee to ignore the flag in the WCC then
the server will still have to get into the datastream and turn it off
in some places, thus losing much of the point in inventing CTS.

As for the name, it seems to me that LAST would be more natural.
Or we could make the two names more consistent: FIRST (instead of
BID/RTS) and LAST (instead of CTS).  Then the negotiated function
could be OUTPUT BRACKETTING or FIRST/LAST or START/STOP or BEGIN/END
or .....

> RE2: Again, this is a terminology difference.  Does anyone else have
> a preference about the direction we should go in?  Toward SNA?  Away
> from it?

DB2: It's no big deal.

>   >         To address the Keyboard Restore problem, the server must
>   > indicate when it is done sending to the client (thus it is okay for
>   > the client to start sending data up to the server).  It does this by
>   > sending a CTS (REQUEST-FLAG set to 0x01).  Here are the three cases
>   > for when CTS should be sent by the server:

>   > 1) If the TN3270E RESPONSES function has been negotiated and DRI
>   > (Definite Response Indicator) is set, as soon as it *receives* a
>   > response from the Client for a data chain that had the CDI or EBI
>   > (End Bracket Indicator) set.

    DB1: This seems like an unnecessary extra exchange.  Why can't I
set CTS/LAST in the REQUEST-FLAG of the TN3270E header of the final
chain of data to the client?  The client should know not to act on the
LAST until it has sent the response.  Why do I need to send another
request after the client has sent the resp?  Am I missing something?

> RE2: What you say makes sense.  I think I had forgotten that the
> client must send back the RESPONSE before sending any data.

>   > 2) If the TN3270E RESPONSES function has been negotiated and DRI is
>   > *NOT* set, as soon as it *sends* a chain to the Client that has
>   > either the CDI or EBI set.

>   > 3) If the TN3270E RESPONSES function has *NOT* been negotiated, as
>   > soon as it *sends* a chain to the Client that has either the CDI or
>   > EBI set.

>   >                 Some might argue that overloading the REQUEST-FLAG
>   > is a bad idea.  However, it is currently only used for when the
>   > client wants to indicate that a printer error condition has been
>   > cleared. Here are four reasons as to why we shouldn't worry about
>   > overloading the RESPONSE-FLAG for this (and possibly other)
>   > commands:

>   > 1) This is such a rare thing
>   > 2) adding an additional byte to the header would be wasteful
>   > 3) embedding new Telnet commands within the datastream would be even
>   > worse
>   > 4) the server never sends the REQUEST command so there's never any
>   > question as to how that flag should be interpreted.

>   >                 Note that since the flag is set to 0x01 this leaves
>   > room for other bits to be used.  Implementors should expect that
>   > these bits will find other uses in the future (e.g. see the next
>   > section).

>   > Server sends RTS (Request To Send - RS232 Lives!)

>   >                 Whenever the server receives a BID or an implied BID
>   > from the host and the client owns the send state, the server should
>   > send an RTS to the client.  Hey, why not use another bit in the
>   > REQUEST-FLAG to accomplish this!  Let's say that a REQUEST-FLAG with
>   > a value of 0x02 implies an RTS when sent by the server to the
>   > client.  This command should be sent in a TN3270 message with the
>   > valid data-type for the session (e.g. 3270-DATA, SCS-DATA). My
>   > current thinking is that this should otherwise be a NULL RU.

    DB1: You mean a null record, yes?  Could this be awkward for some
clients?  How about, for LUT2, there is at least a Write cmd and a
WCC?

> RE2: You're correct, I meant a NULL TN3270E record (i.e. TN Header
> plus EOR).

DB2: And you don't think it would be easier for clients if the server
sent a 2-byte record (Write+WCC) instead of a null one?

>   > However, if this is an implied BID, there may be some performance
>   > reasons (i.e. fewer round trips) to sending along the associated
>   > data [need further feedback on this point].

    DB1: That seems to be a server implementation choice.

>   >                 If the client wants to grant the RTS, it sends back
>   > a positive response (RESPONSE command with RESPONSE-FLAG of
>   > POSITIVE-RESPONSE).  If it wants to reject the RTS it sends back a
>   > negative response (RESPONSE command with RESPONSE-FLAG of
>   > NEGATIVE-RESPONSE).  No reason code should be given for the
>   > NEGATIVE-RESPONSE.  Note that the RESPONSE command and the
>   > RESPONSE-FLAG are used regardless of whether or not the RESPONSES
>   > function was negotiated.  Again, this is because some
>   > implementations may want the performance benefits of disabling
>   > RESPONSES but yet have the proper functionality provided by
>   > HALF-DUPLEX.

    DB1: ... and if the client sends -rsp with no reason code then the
server should send 081B to the Host.

    DB1: There is an awkward situation that can arise.  What if the
user has started typing but has not yet pressed enter?  The client
will naturally send a -rsp.  But now the user thinks better of it and
wants to cancel the input (in fact, a key might have been depressed by
accident).  Assuming the client has some way to decide that it wants
to grant RTS after all, how does it tell the server and how would the
server tell the Host?  I don't know how real 3270s handle this.  It
ought to be by using RTR, but as I understand it that's only used for
printers.  Anyone?

DB2: I had this reply from Peter Haig:

  PH1: I believe the answer is that the host on receiving an 081B can
choose to send a SIGNAL, which will cause the 3270 to lock the
keyboard and send in a NULL RU CD.

DB2: Now, that's rather interesting.  We've no TN3270E mapping for a
SIGNAL from the Host.  I guess we could use RTS here too, except that
we need a FORCE flag to tell the client to discard keyboard input.
Peter goes on to say:

  PH1: Then the host sends the data and no doubt gets a -ve resp
082A(?) - the one which says I did the update but not sure of PS
Integrity cause the user was typing something.

DB2: But I don't think that's correct.  082A (and 084A) are only for
the case in which the user overrode direction (by pressing Reset).  I
believe the data from the Host would be processed without error.

>   >                 Any kind of packet received by the server from the
>   > client between the time the server sends the RTS and receives a
>   > RESPONSE, should be interpreted as a negative response.  This deals
>   > with the race case where the client sends data to the server before
>   > receiving the RTS.

    DB1: ... and the server should send -rsp 0813 to the Host.  This
can be done before or after forwarding the data.

>   > The client must still send the explicit response once it sees the
>   > RTS.  However, the server should ignore this response (because if
>   > the response is negative then it's redundant and if it's positive
>   > it's too late because the intervening RU was interpreted as a
>   > negative response - thus either way it's useless information to the
>   > server).

    DB1: I assume that the server must not send RTS unnecessarily, for
otherwise the client can not tell that the RTS lost the race.  So
after the client sends in data, if it receives RTS before data then it
must judge that the RTS has failed.  There is therefore no point in
sending a +rsp to this RTS.  I believe the client should send -rsp
here to avoid any confusion.

> RE2: You're right that this is a sticky point.  To make things
> better the server should certainly NOT send RTS unnecessarily.  As
> long as there will always be a response from the server forthcoming
> everytime the client sends 3270 data, then the client will be able
> to detect the race and should know to send a -rsp to the RTS.  Is
> there ever a case where the host won't send back data to something
> coming from the client?  If there is (and I can't think of one),
> then the client won't be able to detect the race and the server
> should treat either response as negative.

DB2:
In terms of the server<->appl flow, there is no exception.  The
appl must reply to each inbound message.  But in TN3270 there are
flows that do not map to server<->appl flows: Clear (when entered in
the SSCP-LU session) and Sysreq are the two examples I can think of.
Since I claim RTS/CTS should be for LU-LU only, we can ignore the
Clear case.

Fortunately, there would only be a problem if it could happen that the
client would send something in and not know whether to expect a reply.
In the case of Sysreq, the client expects no reply to the Sysreq
itself, but does expect a reply to the following data.  So if RTS
crosses with a Sysreq (or Sysreq+data) then both server and client
will be aware of it.  So the Sysreq should win.

Anyway, I don't think it would suffice to say that the server should
treat either response as negative.  If there is a situation in which
the client cannot detect the race and therefore sends +rsp, but the
server does detect it and therefore takes it as -rsp, then the
architecture is broken.  Both ends think the other has direction.

Regards,
  Derek

>   >                 If RESPONSES is negotiated, then the client response
>   > must contain the proper matching sequence number that accompanied
>   > the RTS.  If RESPONSES are disabled, then the SEQ-NUM field should
>   > be set to 0 by the client and ignored by the server.

>   >                 [NOTE: Some have suggested that CTS should be used
>   > by the client to indicate a positive response to RTS from the
>   > server.  I believe that this creates too much ambiguity since each
>   > RU sent by the client is implicitly a CTS.  Thus, there could easily
>   > be confusion about whether a particular command is a positive
>   > response or a negative response to a CTS.  If we force the client to
>   > always set CTS when it's okay for the server to send and clear it
>   > when it isn't, there could still be some race conditions where the
>   > server inadvertently interprets something as a positive response
>   > when it isn't.  Using a separate (already fairly well-defined)
>   > mechanism for the client responses should make it cleaner for the
>   > server to interpret.  If RESPONSES have been negotiated then the
>   > client includes the SEQ-NUM of the RTS so the server knows for sure
>   > that this is the response.  If RESPONSES are not used then it will
>   > know by the RESPONSE command that it receives that it can only be a
>   > response to an RTS].

>   > I hope that others will find this to be a cleaner approach to
>   > solving the Keyboard Restore/BID problems.  I believe that this
>   > solution is an improvement over the previous one because it:

>   > 1)      is easier to implement
>   > 2)      has cleaner and more consistent semantics
>   > 3)      does a better job of making this look like a single problem
>   > rather than two probems.

>   >                 As always, feedback is appreciated

>   >                 Rodger Erickson
>   >                 Wall Data

    DB1: The interaction with ATTN and SYSREQ needs to be defined.
The client must be allowed to send these even though it has granted
RTS to the server.  I think the server can just send ATTN on (as
signal) to the Host.  I don't see any need to check the
send/receive/bracket state.

> RE2: I think you're correct.  ATTN and SYSREQ will work exactly the
> same as before.

---

From: Gene Pullen <[email-masked]>
Date: Wed, 10 Dec 1997 10:06:09 -0600

I agree!  With SNA we have a known and fairly well documented quantity.
If we get too generic (or general) we are opening things up to more
interpretation. And we all know what a dangerous thing that can be.

Along those lines I was hoping for something less complex then what I
am seeing here to address the problem of letting the client know when to
send data.  I would like to see us just figure out a way to pass along the
bracket state and/or session direction to the client and let it follow
the SNA rules.  I know this is really very SNAish, in fact it is extending
SNA over the LAN.  But is that really so terrible?

I know this takes a lot of the pressure off servers and puts it on clients to
get bracketing and keyboard lock right.  However, the current proposal also
seems to put a lot of pressure on clients to determine contention winner.

I am not saying we should abandon non-SNA protocols or Rodger's
BID/CONTENTION ideas.  Maybe we can define a couple of functionalities (one
SNA, the other generic) and let the implementers and the market decide.

Gene

At 07:04 PM 12/9/97 -0600, Michael Boe wrote:
>My preference is to base the terminology on the SNA. RTS & CTS remind me
>of modems,
>and that can't be good.  At least with the SNA terminology, a user can
>go look up those terms in some SNA books and gain some understanding of
>the problems involved.  They've got no hope if they go consult modem
>manuals :-).
>
>/msb
>
>
>[email-masked] wrote:
>>
>>         Derek,
>>
>> by saying that there was some interest in removing SNA terminology as
>> much as possible from the wire protocol.  That's why the wire protocol
>> deals with terms like CTS and RTS rather than BID.  Do others have
>> strong opinions about the semantics?  I'm not wedded to either approach
>> - I was merely reacting to feedback that I had received.  I'd be
>> interested in hearing from other group members about their feelings on
>> this...
>>
>> See my responses below (they start with "**")...
>>
>>         -----Original Message-----
>>         From:   Derek W. Bolton [SMTP:[email-masked]]
>>         Sent:   Monday, December 08, 1997 10:52 PM
>>         To:     [email-masked]
>>         Cc:     [email-masked]
>>         Subject:        Re: Keyboard Restore Bid Proposal II
>>
>>         Rodger,
>>
>>         Well, SNA 3270 is not strictly half duplex.  After the Host
>> sends
>>         EB (and gets a response if nec.) the session is in contention.
>>         The key question is who resolves contention.  Your previous
>>         proposal, and this one, have the client as contention resolver.
>>
>>         So I'd prefer to name this differently.  CONTENTION RESOLUTION
>> **You're correct about this.  I just think that terms like CONTENTION
>> RESOLUTION and BID are too SNAish.  I was shooting for something more
>> generic.
>>
>>         What LU types would this be negotiated for?  I've assumed it's
>>         nontrivial to extend it to printers.  E.g. an RTS framed as
>>         a null record might trigger a blank page.
>>
>> **Good point.  I think that this should only be for LU Type2
>>
>>         This is not *strictly* necessary.  For a start, it's not quite
>> the
>>         right terminology.  Since the client is the contention resolver,
>> the
>>         server does not need to give the client permission to send.
>> Really
>> **Again, I don't want to get bogged down in the SNAness involved.
>> Servers care about this but clients do not.  Thus we should try and
>> avoid it in the wire protocol between server and client.  You're right
>> that it is an end of input marker, but isn't that the same thing as
>> saying "I'm done for now - your turn?"  Your point about dickering with
>> the WCC is well taken.  That would be another way of doing it.  Some
>> server vendors take that approach today but I didn't feel right about
>> making that the official proposal.
>>
>>         So in a sense this is a separate issue from whether BID function
>>         is negotiated.  It is the 'end of output' function.  But I
>>         don't want to proliferate functions to be negotiated either,
>>         so I'm happy that it comes as part of the package.
>>
>>         The corollary is that if BID function is negotiated then the
>> client
>>         must ignore the keyboard restore flag in the WCC.
>>
>> **I'm not sure that I agree with this.  Just as I'm trying to avoid
>> having the servers dicker with the 3270 datastream, I want the clients
>> to be able to deal with it cleanly as well.  Could you explain why the
>> client should ignore the keyboard restore flag in the WCC?
>>
>> As for the name, it seems to me that LAST would be more natural.  Or
>>         we could make the two names more consistent: FIRST (instead of
>> **Again, this is a terminology difference.  Does anyone else have a
>> preference about the direction we should go in?  Toward SNA?  Away from
>> it?
>>
>>         This seems like an unnecessary extra exchange.  Why can't I set
>>         CTS/LAST in the REQUEST-FLAG of the TN3270E header of the final
>> chain
>>         of data to the client?  The client should know not to act on the
>> LAST
>>         until it has sent the response.  Why do I need to send another
>> request
>>         after the client has sent the resp?  Am I missing something?
>>
>> **What you say makes sense.  I think I had forgotten that the client
>> must send back the RESPONSE before sending any data.
>>
>>         You mean a null record, yes?  Could this be awkward for some
>> clients?
>>         How about, for LUT2, there is at least a Write cmd and a WCC?
>>
>> **You're correct, I meant a NULL TN3270E record (i.e. TN Header plus
>> EOR).
>>
>>         That seems to be a server implementation choice.
>>
>>         ... and if the client sends -rsp with no reason code then the
>> server
>>         There is an awkward situation that can arise.  What if the user
>>         has started typing but has not yet pressed enter?  The client
>>         will naturally send a -rsp.  But now the user thinks better of
>>         it and wants to cancel the input (in fact, a key might have
>>         been depressed by accident).  Assuming the client has some
>>         way to decide that it wants to grant RTS after all, how does it
>>         tell the server and how would the server tell the Host?
>>         I don't know how real 3270s handle this.  It ought to be by
>>         using RTR, but as I understand it that's only used for printers.
>>         Anyone?
>>
>>         ... and the server should send -rsp 0813 to the Host.  This can
>>         be done before or after forwarding the data.
>>
>>         I assume that the server must not send RTS unnecessarily, for
>>         otherwise the client can not tell that the RTS lost the race.
>>         So after the client sends in data, if it receives RTS before
>>         data then it must judge that the RTS has failed.  There is
>>         therefore no point in sending a +rsp to this RTS.  I believe
>>         the client should send -rsp here to avoid any confusion.
>> **You're right that this is a sticky point.  To make things better the
>> server should certainly NOT send RTS unnecessarily.  As long as there
>> will always be a response from the server forthcoming everytime the
>> client sends 3270 data, then the client will be able to detect the race
>> and should know to send a -rsp to the RTS.  Is there ever a case where
>> the host won't send back data to something coming from the client?  If
>> there is (and I can't think of one), then the client won't be able to
>> detect the race and the server should treat either response as negative.
>>
>>         The interaction with ATTN and SYSREQ needs to be defined.  The
>> client
>>         must be allowed to send these even though it has granted RTS to
>> the
>>         server.  I think the server can just send ATTN on (as signal) to
>> the
>>         Host.  I don't see any need to check the send/receive/bracket
>> state.
>>
>> **I think you're correct.  ATTN and SYSREQ will work exactly the same as
>> before.
>>
>>         Regards,
>>           Derek
>>
>>   ------------------------------------------------------------------------
>>
>>    Part 1.2       Type: application/ms-tnef
>>               Encoding: base64
>
--------------------------------------------------------------------------
      OOOO   CCCC   SSSS            Gene B. Pullen ([email-masked])
    OO  OO CC  CC SS  SS            Senior Software Engineer
   OO  OO CC     SS                 OpenConnect Systems, Inc.
  OO  OO CC       SS                2711 LBJ Freeway, Dallas, TX  75234
 OO  OO CC         SS               Tel: (972)888-0600  Fax: (972)888-0686
OO  OO CC  CC SS  SS
OOOO   CCCC   SSSS  "Transforming Separate Networks Into Seamless Systems"
==========================================================================

---

From: Gene Pullen <[email-masked]>
Date: Wed, 10 Dec 1997 10:19:55 -0600

I guess what I am saying is I like Rodger's first set of Keyboard Restore/Bid
Proposal the best.

Gene

---

From: [email-masked]
Date: Mon, 15 Dec 1997 15:01:11 -0800

Derek,

        I'm finally getting around to responding to your last email.
I've pulled out most of our exchange because I've decided to go back
toward my original proposal.  I've already modified it to address your
comments and objections (successfully, I hope).  There are just a couple
of remaining points I'd like to get clear on before posting a new
revision to the list (please my comments see below prefaced by RE3)...

>     DB1: The corollary is that if  []  CONTENTION RESTORE function is
> negotiated then the
        []  RE3:  I think that emulators already have to deal with this
issue.  Not all of the TN Server vendors tweak the WCC bit today.  The
all clients have to be prepared to deal with the fact that the keyboard
restore flag in the WCC may or may not be set correctly.  I think that
the correct way to state this is that clients will now have extra
information that can help them make a more informed decision about the
keyboard state.  It might, in fact, be in their best interest to ignore
the keyboard restore flag in the WCC.  However, I am not prepared to
make a blanket statement that the client SHOULD or MUST ignore it
because it may cause incorrect behavior in some application.  Can we
agree to keep silent on this point?

> believe the data from the Host would be processed without error.
        []  RE3: My feeling here is that the client can't change its
mind.  The response from the client is either positive or negative.
Once a negative response has gone out that's it -- no changing your
mind.  Once a positive response goes out input is inhibited and that's
the end of it (until the server sends SDI).

        Rodger

---

From: "Derek W. Bolton" <[email-masked]>
Date: Wed, 17 Dec 1997 10:31:01 +1100 (EST)

Rodger,

> toward my original proposal.  I've already modified it to address
> your comments and objections (successfully, I hope).  There are just
> a couple of remaining points I'd like to get clear on before posting
> a new revision to the list (please my comments see below prefaced by
> RE3)...

> issue.  Not all of the TN Server vendors tweak the WCC bit today.
> The all clients have to be prepared to deal with the fact that the
> keyboard restore flag in the WCC may or may not be set correctly.

I don't understand how they can deal with it.  They have no other
information to go on.  It's the server that has to deal with the
consequences - like queueing up inbound data.  But that is not
a safe solution.  There is nothing the server can do that is safe.
If there are gateway servers that do not fix up the WCC then it's
my bet there are customers who simply cannot use those servers.
Not that I should complain about that!

> I think that the correct way to state this is that clients will now
> have extra information that can help them make a more informed
> decision about the keyboard state.  It might, in fact, be in their
> best interest to ignore the keyboard restore flag in the WCC.
> However, I am not prepared to make a blanket statement that the
> client SHOULD or MUST ignore it because it may cause incorrect
> behavior in some application.

I do not see how it could cause incorrect operation.  If the server is
mapping TN3270E Bid (or whatever it's called now) from an SNA
datastream then it is guaranteed to be the right thing to do because
the bit simply has no function in SNA 3270.  If the server is not SNA
on the upstream side, why would it negotiate TN3270E Bid?  If there is
a valid reason for that then it looks like a separate negotiation is
needed to say how to handle Keyboard Restore.  (Except that it's not a
negotiation - the server must simply tell the client which way to do
it.)

> Can we agree to keep silent on this point?

'Fraid not.  As I see it, this is an essential part of the proposal.
Without it, we might just as well muddle on the way we are now.

> mind.  Once a positive response goes out input is inhibited and
> that's the end of it (until the server sends SDI).

Your feelings, wonderful as I'm sure they are, do not address a
practical and very real problem.  It is an important, though little
known, part of SNA 3270 architecture that the Host appl can override
the contention winner by sending Signal.  The TN3270E architecture
does not allow us to support that today, but let's take the
opportunity to fix it.  All it requires a FORCE flag on the Bid.

---

From: Michael Boe <[email-masked]>
Date: Thu, 18 Dec 1997 13:50:26 -0800 (PST)

Jim,

Thanks for that.  A few comments embedded...

>> ....(as, indeed, EB/CD do replace the keyboard restore flag in SNA)...
>> ...Because that is in the definition of SNA 3270!  EB/CD completely
>> replaces the keyboard restore flag in the WCC....
>
> This is VERY wrong and maybe part of the whole problem in understanding an
> appropriate method to resolve the subject problem(s).

Not quite sure the view expressed above is VERY wrong. There's one case that's
different in theory (but probably not in practice), and another that is
different in practice and theory. Let's clear these up....

>
> SNA LU2 implementation:
> Assume the SLU is in SEND/CONTENTION State.
>
> When an operator performs an AID operation the keyboard is LOCKED (X-CLOCK)
> an INBOUND Data Stream (DS) is generated and the
> SLU enters RECEIVE STATE.
> An RU containing an OUTBOUND DS with WCC keyboard restore in which case the
> keyboard is UNLOCKED.  What this means is the
> the operator may enter data into the Presentation Space.  But if the RU
> does not contain CDI or EBI then the operator may not perform an AID
> operation.

No problem so far. To use 3174 F.D. terminology, the terminal may enter the
SEND/not-transmitting substate, but it cannot enter the SEND/transmit state.

>  If in fact an operator attempts to perform an AID operation the
> keyboard will be LOCKED - (X-f "MINUS FUNCTION") which simply
> indicates the operation you attempted to perform is not allowable at this
> time. An RU containing an OUTBOUND DS with WCC without keyboard restore
> and without CDI/EBI in which case the keyboard will remain LOCKED
> (X-CLOCK).  Reset key will not remove this input inhibit condition.
> An RU containing an OUTBOUND DS with WCC without keyboard restore but with
> CDI and not EBI would continue to have the keyboard LOCKED
> (X-SYSTEM).

WCC[keyboard-restore] && !CD/EBI is different from what I thought:  I believed
that lack of CD was equivalent to not restoring the keyboard. Of course, I'm
not sure that makes a lot of difference in typeahead environments, does it?

IMO, the more important difference is the other one:  CD but not
keyboard-restore. I've always assumed that there was no *useful* difference
between the two, and therefore they could be treated equivalently.  Not that I
had a lot of choice in the matter wrt TN3270 :-).

> Reset key will remove this input inhibit condition.  An AID
> operation would be allowed.
> An RU containing an OUTBOUND DS with WCC without keyboard restore but with
> EBI would unlock the keyboard, same as WCC keyboard restore
> but now an AID operation would be allowed.

OK.  So maybe we're just arguing semantics here, but it would appear to me the
EBI overrides (ie replaces) keyboard-restore action here.

>
> So you see the WCC keyboard restore and CDI/EBI are related but not
> replacements for each other.

I think you've taken a step too far here.  The behavior of CD/EBI
overrides/replaces the behavior of WCC keyboard-restore, but the converse was
never claimed.

In any case, your description coincides with what I perceive to be reality...so
let's move on if no one else disagrees.

>
> In the case of WCC keyboard restore without CDI/EBI this allows an operator
> to modify the Presentation Space prior to actually receiving the entire
> Presentation Space and prior to the host ready to allow an inbound
> operation. This was useful prior to type-ahead functions that post dated
> the 3270 and SNA LU2 architecture definitions.

Right.  But probably near useless or even harmful in type-ahead environments,
correct?

>
> In the case of WCC without keyboard restore with CDI and without EBI this
> function allows an application to keep the keyboard locked so that the
> operator may not modify the Presentation Space prior to reading something
> on the Presentation Space.  Useful in heads down typing for data entry
> with an invalid field in a previous transaction.  The application
> implementation might have the operators start typing, filling in the "next"
> form, when the audible
> alarm sounds, designated in the WCC.  In the non error case all is fine, in
> the error case the operator starts typing when they hear the audible alarm
> and they start typing the keyboard responds differently because it is locked
> and the operator then looks at the Presentation Space notices the error
> message, resets the keyboard corrects the error and continues.

OK. I've never heard a good explanation for why things should work like this
before now.  Thanks.  The point here is that the user MUST hit the reset key,
because the host is not going to be sending any more data.  Interesting UI
behavior. Certainly would get the user familiar with the RESET key.  Not
something I'd like to encourage users to become used to doing, but I've got
20/20 hindsight working here...

>
> I can generate a State Diagram for the WCC keyboard restore, CDI, EBI
> interaction and the interaction with the keyboard and Aid generation
> allowed if you think that would help.
>
> As an asside on the BID discussion I believe the Server should always
> reject the BID since the BID should be rejected whenever the operator has
> modified the Presentation Space.  This is so no operator input will be lost
> because the HOST remodifies the Presentation Space.  I say reject always
> because ALL applications have to be able to handle a rejection since it is
> really a RACE condition as to whether the operator has had a chance to
> modify the Presentation Space prior to the HOST's desire to remodify it
> (Usually with a special warning, error condition, host going away as
> opposed to an integral part of the application.)  Since applications have
> to be able to handle receiving an 081B it is easier to always reject a BID
> with 081B.  This way
> the client doesn't have to become involved in the BID.

Let's go down that path a ways:  Suppose an asynchronous-update application
(like NETSTAT). If the TN3270 Server always rejects the BID, then the user's
screen will never be updated when the user never touches the keyboard. Correct?

>
> I welcome the chance to continue this discussion and to become involved in
> attempting to correct the TN3270 architecture to allow a better migration
> of existing SNA applications to the TCP/IP world.
>
> Also has anyone discussed the READ STATE architecture of 3270?  This is
> also important when considering keyboard management.

Tell us more...

/msb

>
>
> James M. Mathewson II
> Senior Software Engineer
> IBM
>
>
>
>
> [email-masked] on 12/18/97 03:56:20 PM
> Please respond to [email-masked] @ internet
> To: Jim Mathewson II/Raleigh/IBM@IBMUS
> cc: [email-masked] @ internet
> > I will pass on the request.
>
> Thanks.
>
> > I have also tried to append another item on this subject though I haven't
> > seen it pop up and I have not received
> > a response indicating it was received.   Have received any indication
> > that another append by my on the same
> > subject addressing a confusion on CD/EB/WCC keyboard interaction?
> > THanks.
>
> Was it this one?
>
> > On the discussion on modifying  WCC in a data stream.  I don't think you
> > would want to have a design that required modifications to WCCs i n the
> > Data Stream since that would require scanning the entire data stream to
> > find Outbound 3270DS Structured Fields.  Remember WCC is not just the
> > second byte in the outbound message but also exists in the Outbound
> > 3270DS structured field and is handled exactly the same as on the WRITE,
> > ERASE/WRITE, and ERASE/WRITE ALTERNATE Commands.
>
> That's the only other topic I've seen from your email address in the last
> few days.  And that was in the same note as the SIGNAL discussion.
>
> /msb
>
>
>

---

From: [email-masked]
Date: Mon, 29 Dec 1997 09:07:28 -0800

Here are a couple of points to add to this discussion.  I'll use
a # to signify my comments...

Rodger D. Erickson
Wall Data Inc.
[email-masked]

        -----Original Message-----
        From:   Jim Mathewson II [SMTP:[email-masked]]
        Sent:   Friday, December 19, 1997 9:48 AM
        To:     [email-masked]
        Cc:     [email-masked]
        Subject:        Re: Keyboard Restore Bid Proposal II

        Nothing *but* typeahead in TN3270.  OK, you can disable
typeahead on some
        clients, but that's really just typeahead with a type-ahead
buffer of zero. Not
        quite the same as non-typeahead.  That's cuz TN3270 didn't allow
CD or EBI to
        flow to the client (hence there was no need to distinguish
between
        non-typeahead and typeahead with a queue-length of zero).
        % I believe this stems from the fact that the keyboard is not
locked at AID
        % generation time with X-CLOCK but only with X-SYSTEM. Which is
the NON-SNA
        % method of handling AID functions.

        # Not really.  Given that many TN3270 emulators were originally
SNA-based 3270 emulators that didn't understand non-SNA device types
        # I believe that many products are doing X-CLOCK.  The problem
arises when the application releases the contents of its type-ahead
        # buffer prematurely because it is forced (under the current
protocol) to interpret WCC w/Keboard Restore + EOR as an indication that
it's okay
        # to send.  This issue won't only affect type-ahead, but
keyboard macros/scripts as well.

        % And if the operator had depressed a single key to modify the
Presentation
        Space
        % then walked away for a cup of coffee you get the same result.
This could have
        % been done by queueing keystrokes which would have been
processed immediately
        % upon receipt of the EB.  Again all we have have is a race
condition on when
        the
        % operator modified the Presentation Space.
        %
        % I am quite curious as to why the application was coded that
way.  What
        function
        % is achieved in this manner that couldn't be achieved by:

        HOST                WS
          <-------------------FMD(EXR,BB,CD)
               [application sits for OVER 20 seconds in this state]
          FMD(BBIU,FIC,EXR)---->
        % I am sure you could find others however how many applications
can you find
        that
        % simply rejecting the BID without communicating to the CLIENT
to determine if
        a
        % BID should be accepted or not, which might still be denied
because the
        PRESENTATION
        % SPACE has been modified even if you did communicate to the
CLIENT.
        % Note I am attempting to explore solutions that would not
require changes to
        % any CLIENT code, since if this is achievable it would bring
all the existing
        % CLIENT EMULATORS into the SNA/TCPIP world with only a SERVER
change.  It
        would be a
        % value add to any SERVER that handled BID better on behalf of
the
        SERVER/CLIENT pair.

        # We have a customer that has an application (I don't know the
SNA flows in detail) that sends down a BID whenever there's an incoming
        # customer call that occurs.  The application pulls that
customer's record (or creates on) and sends it to a customer service
representative
        # via the BID.  If the BID is rejected, the application just
retries another LU.  Any policy that always rejects BIDs will break this
application.
        # The application relies on the fact that eventually one of the
customer service representatives will come free and be able to process
the
        # new record.  It uses BID so that it can quickly find another
LU if the current one is busy.
        # Thus always rejecting the BID seems unacceptable.