Subject: Keyboard Restore Bid Proposal II

From: [email-masked]
Date: Mon, 8 Dec 1997 11:07:37 -0800

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

Server sends CTS (Clear To Send - RS232 Lives!)
        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.
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.  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].

                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.

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

                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

---

From: "Derek W. Bolton" <[email-masked]>
Date: Tue, 9 Dec 1997 15:51:34 +1100 (EST)

Rodger,

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

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

>                 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

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
FUNCTION is rather a mouthful.  How about ... BID function :-)?

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.

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

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.

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.

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

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

> response from the Client for a data chain that had the CDI or EBI
> (End Bracket Indicator) set.

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?

> *NOT* set, as soon as it *sends* a chain to the Client that has
> either the CDI or EBI set.

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

> 3) embedding new Telnet commands within the datastream would be even
> worse

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

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

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?

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

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

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

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?

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

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

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.

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

>                 Wall Data

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.

Regards,
  Derek