Subject: FW: Keyboard Restore/BID problems

From: [email-masked]
Date: Sun, 7 Dec 1997 09:46:19 -0800

Below is my original posting regarding the Keyboard Restore/BID
problems.  Following that text I've included the two responses I
received to the posting.
        Unlike many of the enhancement-oriented issues we've been
discussing over the last several months, this posting is about fixing
"bugs" in our original TN3270E spec that prevents TN3270E from
functioning properly in many environments.  As a result, I urge this
group to give these issues some attention so we can reach a consensus
about how to fix them.

        This issue is on the agenda for the upcoming IETF meeting in
Washington, D.C.

Rodger D. Erickson
Technologist
Wall Data Inc.
[email-masked]
(314) 721-4640

-----Original Message-----
From:   Erickson, Rodger [SMTP:[email-masked]]
Sent:   Saturday, May 31, 1997 7:30 PM
To:     tn3270e
Subject:        Keyboard Restore/BID problems

As a result of our interim working group meeting in Raleigh, I am
posting some "food-for-thought" on some holes in the current RFC (1647)
with respect to: a) when is the keyboard *really* unlocked, and b) how
should a BID be handled.
I don't profess to be an SNA guru so while any and all comments are
welcome, I would especially appreciate any corrections/additions that
others want to make to any statements I make below with respect to SNA.

"KEYBOARD RESTORE PROBLEM"
The first problem concerns uncertainty about when the client can send
data to the TN3270E server.  TN3270E provides for an End-Of-Record (EOR)
mechanism which allows the client to determine where the boundry is
between 3270 Data Stream Commands.  The Server sends EOR whenever it
sends data to the client for which the LIC (Last-in-chain) indicator was
set.  Today, Clients have no choice but to interpret the presence of EOR
as an indication that it is okay to go ahead and send data back to the
host (providing the 3270 DataStream has restored the keyboard).  Since
it
is not uncommon for the Server to receive a LIC from the host with no
CDI
(Change Direction Indicator) set, a serious problem is created where the
Client will send data to the Server when it does not own the half-duplex
Send State.  The Server has three options, all of which are bad.  It
can:
a)      send the Client data up to the host which will result in an SNA
State error (causing the session to be unbound), b) throw the client
data away (resulting in lost data), or c) queue the client data until it
owns the Send State.
Option C seems to be the best of the three.  However, there are still
problems when data continues to flow inbound from the Server and gets
treated by the Client as a response to what it has just sent out.  This
causes data synchronization problems because this new data has nothing
to do with the data the Client just sent out (because it's still queued
at the Server).  Often, the end result is a hung session.
The solution is for the Server to provide the Client with an indication
that it is okay to go ahead and send data.  Let's call this the SDI
(Send
Data Indicator).  The Server should send the SDI to the Client under the
following circumstances (NOTE: the items below refer to SNA information
like CDI, EBI and DRI.  These items do not flow down to the client and
reference to them implies presence in the data received from the host
before it is translated to TN3270E format and sent down to the Client):
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.

The actual mechanism for sending the SDI to the Client will be discussed
later in the document.

"BID PROBLEM"
The second problem involves both explicit and implicit BID.  When the
SNA Session is in the BETB (Between Bracket) state, the host (PLU) may
bid for the Send State by either sending an Explicit or Implicit BID.
In normal SNA, the Client must process this BID, either granting the
Send State to the host or rejecting the request.  Having granted the
request, it must wait its turn before attempting to send out any data.
In the TN3270 world, there is no mechanism for including the Client in
this BID process.  Thus, the Server must process the BID on the Client's
behalf.  The Server has some options on how it can proceed-all of them
bad.  It can: 1) always reject the explicit/implicit BID (this is bad
because it will prevent some host applications from working properly, 2)
accept the BID but forward Client data up to the host (will result in a
state error and the session will be unbound), 3) accept the BID and
throw away any subsequent data the Client sends the Server while the
host owns the Send State (this results in lost data), or 4) accept the
BID and queue any data sent by the Client until the Client has the Send
State.  Option 4) may seem on the surface as the best way to go.
However, there are many applications that will be hosed by this approach
(in a manner similar to the Keyboard Restore problem discussed
previously).  If the Client continues to send data up to the Server
after the Server has granted a BID, the server will queue that data.
However, the Client may interpret the data it receives from the host as
a response to the data it has just sent out (that's still queued at the
Server).  This will result in a hung/confused application.
This problem can be fixed by allowing the BID to be propagated down to
the Client.  Whenever the Server receives a valid BID (implicit or
explicit) from the PLU (i.e. one that occurs in the BETB (Between
Bracket) state), it should propagate it down to the Client.  The client
will then respond either positively or negatively.  Having responded
positively, the Client must enter the "input inhibited" state until the
PLU has returned the Send State to the Client.

IMPLEMENTATION OF SOLUTIONS:
A new TN3270E FUNCTION will be introduced (e.g. 07).  Negotiating this
Function implies that both the Client and the Server will be able to
handle both the SDI and the BID.
The SDI will be sent by setting the "REQUEST-FLAG field" to 0x01.
Currently, the REQUEST-FLAG field is defined only for a data-type of
REQUEST.  Given that this BYTE is pretty much wasted, it makes sense to
use this field for SDI.  A value of 0x01 in this field will be
interpreted as SDI for all data types except REQUEST (for REQUEST it
will retain its current definition from RFC1647).  When the Client
receives the SDI, it implies that after processing the current TN3270E
message (i.e. when it sees the EOR) it will be okay to send data to the
server.  Note that the Client will still be allowed to send RESPONSES to
the Server, even if it has not received the SDI.  Also, in the case
where the Server is waiting for a definite response from the Client
before sending down the SDI, the RU sent to the Client that contains the
SDI will be NULL.
BID requires a new TN3270E datatype (e.g. 0x09).  The Server will
indicate that it has received either an implicit or explicit BID by
sending this data type to the Client.  Even if the RESPONSES function
has not been negotiated, the Client MUST respond to the BID (the Server
should also send a SEQ-NUM which should be used by the Client in its
response).  It sends a positive response to the server via the RESPONSE
data type with the data byte containing POSITIVE-RESPONSE (as defined in
the current RFC).  It rejects the BID via the RESPONSE data type with
the data byte containing NEGATIVE-RESPONSE (as defined in the current
RFC).  The server is then responsible for constructing the appropriate
SNA response to the host.
There is a potential race condition where the Client sends data to the
Server after the Server has sent the BID to the Client (presumably the
Client hadn't seen the BID before it sent data).  In this race condition
case where the Server sees data from the Client before it sees a
positive/negative response to the BID, it should treat the Data as an
implied negative response and reject the BID before sending the Client
data up to the host.  The Client will know that such a race has ocurred
because it will see a BID come from the Server before it receives the
SDI.  In this case, the Client can just silently discard the BID (no
response should be sent to the Server because the Server will already
have responded negatively to the host).
*******************************

This is intended as a starting point-a straw man to throw things at (or
you could even set it on fire if you're so inclined :-)

Rodger Erickson
Wall Data

********************* Response sent by khang Le
***************************************

Hi Rodger,

Your Keyboard Restore/BID problem was clearly described, and your
solution very effective. I don't seem to see any hole in it. On the
other hand I find that the solution is a bit complicate.
The solution seems to introduce the notion of SNA bracket between the TN
server and client. But at the same time it doesn't really do so since it
does it only partially. There is a flow from the server to client to
indicate the BID, but there is nothing to delimit the bracket ( i.e. to
indicate the start and end of a bracket). If after a bracket is ended
and the host application starts bidding for another bracket, the TN
server will issue another BID to the client. I don't know if this may
cause any confusion at the client, since there was nothing to delimit
the previous bracket. For a session with many brackets, the client don't
really see any brackets but flows of 3270 data exchanged and many BIDs
from the server here and there in between.
Also in the solution, the client responds to BID from the server by
using the RESPONSE data type even if the RESPONSE function was not
negotiated.  I don't know but this may not look very 'clean'. It's like
we're violating the negotiation rule be introducing some exceptions. I
think that may be it is preferable to say that negotiation for the BID
function also implicitely includes the RESPONSE function. But this may
not be good neither if for, whatever reason, some client or server many
not want to implement the RESPONSE function, but the BID function.

Your solution is very good and I think if we slightly change the way to
present it, it can look simpler and more integrated to the current
Tn3270E protocol.
After some long reflexion, I can look at this problem and your solution
as follow:
This whole Keyboard Restore/BID problem is actually due to the fact that
TN is a full-duplex protocol. And the solution you proposed is basically
to make it half-duplex (as it is for SNA).
Basically when the server has the SEND state and wants to give it to the
client, it sends the SDI. You didn't specifically say so but I assume
that at this time the server can not send any other 3270 data to the
client. For each 3270 record the client sends to the server, it also
implicitely sends back the SDI. Then the server can send other 3270 data
records to the client until it gives again the SDI.
As far as the BID is concern, I think that it is better not to pass the
notion of SNA bracket to the TN client. I think it is a server problem
and thus to leave it at the server side. Otherwise it may look like a
patch. Thus instead of sending the BID to the client, we can see it as a
request-to-send command. Initially when the session is started, we can
consider the client as having the SEND state. If the SNA host bids for a
bracket, the server then sends the request-to-send command to the
client.  This is because the client does not know about bracket, it only
knows that the server wants to send some 3270 data. Here instead of
using the RESPONSE function, the client can send the SDI to indicate a
positive response. The client can send the SDI flag in a null data of
type 3270-DATA or SCS-DATA (depending on whether it is a display or
printer and whether the function DATA-STREAM-CTL or SCS-CTl-CODES was
negotiated) to indicate a positive response. For a negative response, it
depends on whether the user has just entered data or has also initiated
an enter operation (e.q. presses ENTER key). If the user just entered
data but not the ENTER key, the client can send a null data as above but
without the SDI flag. In this case the server can return sense code
0x081B to the host to reject the BID. If the user pressed the ENTER key,
the client simply sends the 3270 data as it normally does. The server
then sends sense code 0x0813 and the 3270 data to the host along with
the BB (Begin Bracket) bit. Note that any 3270 data record send from the
client (that is not null) always implicitely includes the SDI. In this
case the SDI does not mean a positive response to the BID. It only means
that after processing the 3270 data, the server has the SEND state.
So the function to negotiate could be called something like Half-Duplex
function. And the additional flag and data needed are the SDI and
something like RSD (for Request Send Data).
Basically the solution remains the same, only the interpretation is
different. And in my opinion this is simpler to understand, but this is
only my opinion. You or others may not think so, or that it does not
really add anything more to your original proposition. So as you said so
well "you could even set it on fire if you're so inclined".
Khang  Le
Eicon Technology

******************* Response sent by Derek Bolton (original text is more
indented than the responses)*****

        > Derek,
        >
        > Can you send 081B to a BID ?

You're right - I shouldn't have relied on my memory.  A real 3274 would
send either 0813 (when the Bid crosses with inbound BB) or 081B (when a
key has been pressed but not an AID key yet).  0814 is for printers.
However, the way 0814 is used would make it appropriate for the case in
which the local key press is later cancelled.  That makes it tough
because at the time of sending the -rsp you don't know which is going to
happen.
I suspect that at least one of the following two schemes is workable:
*       Send 0814 instead of 081B.  If the data is later sent to the
Host (as BB) maybe the Host appl will accept it and no longer expect
RTR.
*       Send 081B, but if the data is cancelled send RTR.

The latter sounds safer.
        > I don't think the spec. should define client behaviour for a
key
        > being pressed and then receiving BID, as that is standard SNA
        > function. The smart ones will put something on line25.

I don't want to define the client behaviour.  I want to leave it open
for the client to have the smarts to cancel the input.  If there's no
way to send "RTR" (e.g. +rsp to a Bid having earlier sent a -rsp) then
the client is limited.
Regards,
Derek
        > Best Rgds, Peter H.
        >
        >
        > At 02:33 PM 22-07-97 +1000, you wrote:
                > >Hmm.. don't know why selecting 'reply' didn't send
this to the
                > >alias..  Resending:
                >
>----------------------------------------------------------
                > >
                > >Rodger,
                > >
                > >Sorry for the looooong delay...
                > >
                > >The proposal looks very reasonable.  (If I'd seen any
major issues
                > >I'd have replied earlier ;-).  Some comments
embedded.
                > >
                > >Regards,
                > >  Derek
                > >
                        > >> As a result of our interim working group
meeting in Raleigh, I am
                        > >> posting some "food-for-thought" on some
holes in the current RFC
                        > >> (1647) with respect to: a) when is the
keyboard *really* unlocked,
                        > >> and b) how should a BID be handled.
                > >
                        > >>  I don't profess to be an SNA guru so while
any and all comments are
                        > >> welcome, I would especially appreciate any
corrections/additions
                        > >> that others want to make to any statements
I make below with respect
                        > >> to SNA.
                > >
                > >
                        > >>  "KEYBOARD RESTORE PROBLEM"
                > >
                        > >>  The first problem concerns uncertainty
about when the client can
                        > >> send data to the TN3270E server.  TN3270E
provides for an
                        > >> End-Of-Record (EOR) mechanism which allows
the client to determine
                        > >> where the boundry is between 3270 Data
Stream Commands.  The Server
                        > >> sends EOR whenever it sends data to the
client for which the LIC
                        > >> (Last-in-chain) indicator was set.  Today,
Clients have no choice
                        > >> but to interpret the presence of EOR as an
indication that it is
                        > >> okay to go ahead and send data back to the
host (providing the 3270
                        > >> DataStream has restored the keyboard).
Since it is not uncommon for
                        > >> the Server to receive a LIC from the host
with no CDI (Change
                        > >> Direction Indicator) set, a serious problem
is created where the
                        > >> Client will send data to the Server when it
does not own the
                        > >> half-duplex Send State.  The Server has
three options, all of which
                        > >> are bad.  It can: a) send the Client data
up to the host which will
                        > >> result in an SNA State error (causing the
session to be unbound), b)
                        > >> throw the client data away (resulting in
lost data), or c) queue the
                        > >> client data until it owns the Send State.
                > >
                        > >>  Option C seems to be the best of the
three.  However, there are
                        > >> still problems when data continues to flow
inbound from the Server
                        > >> and gets treated by the Client as a
response to what it has just
                        > >> sent out.  This causes data synchronization
problems because this
                        > >> new data has nothing to do with the data
the Client just sent out
                        > >> (because it's still queued at the Server).
Often, the end result is
                        > >> a hung session.  The solution is for the
Server to provide the
                        > >> Client with an indication that it is okay
to go ahead and send data.
                        > >> Let's call this the SDI (Send Data
Indicator).  The Server should
                        > >> send the SDI to the Client under the
following circumstances (NOTE:
                        > >> the items below refer to SNA information
like CDI, EBI and DRI.
                        > >> These items do not flow down to the client
and reference to them
                        > >> implies presence in the data received from
the host before it is
                        > >> translated to TN3270E format and sent down
to the Client):
                > >
                        > >>  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.
                > >
                        > >>  The actual mechanism for sending the SDI
to the Client will be
                        > >> discussed later in the document.
                > >
                > >
                        > >>  "BID PROBLEM"
                > >
                        > >>  The second problem involves both explicit
and implicit BID.  When
                        > >> the SNA Session is in the BETB (Between
Bracket) state, the host
                        > >> (PLU) may bid for the Send State by either
sending an Explicit or
                        > >> Implicit BID.  In normal SNA, the Client
must process this BID,
                        > >> either granting the Send State to the host
or rejecting the request.
                        > >> Having granted the request, it must wait
its turn before attempting
                        > >> to send out any data.  In the TN3270 world,
there is no mechanism
                        > >> for including the Client in this BID
process.  Thus, the Server must
                        > >> process the BID on the Client's behalf.
                > >
                        > >>  The Server has some options on how it can
proceed-all of them
                        > >> bad.  It can: 1) always reject the
explicit/implicit BID (this is
                        > >> bad because it will prevent some host
applications from working
                        > >> properly, 2) accept the BID but forward
Client data up to the host
                        > >> (will result in a state error and the
session will be unbound), 3)
                        > >> accept the BID and throw away any
subsequent data the Client sends
                        > >> the Server while the host owns the Send
State (this results in lost
                        > >> data), or 4) accept the BID and queue any
data sent by the Client
                        > >> until the Client has the Send State.
                > >
                        > >>  Option 4) may seem on the surface as the
best way to go.  However,
                        > >> there are many applications that will be
hosed by this approach (in
                        > >> a manner similar to the Keyboard Restore
problem discussed
                        > >> previously).  If the Client continues to
send data up to the Server
                        > >> after the Server has granted a BID, the
server will queue that data.
                        > >> However, the Client may interpret the data
it receives from the host
                        > >> as a response to the data it has just sent
out (that's still queued
                        > >> at the Server).  This will result in a
hung/confused application.
                > >
                        > >>  This problem can be fixed by allowing the
BID to be propagated down
                        > >> to the Client.  Whenever the Server
receives a valid BID (implicit
                        > >> or explicit) from the PLU (i.e. one that
occurs in the BETB (Between
                        > >> Bracket) state), it should propagate it
down to the Client.  The
                        > >> client will then respond either positively
or negatively.  Having
                        > >> responded positively, the Client must enter
the "input inhibited"
                        > >> state until the PLU has returned the Send
State to the Client.
                > >
                > >
                        > >>  IMPLEMENTATION OF SOLUTIONS:
                > >
                        > >>  A new TN3270E FUNCTION will be introduced
(e.g. 07).  Negotiating
                        > >> this Function implies that both the Client
and the Server will be
                        > >> able to handle both the SDI and the BID.
                > >
                        > >>  The SDI will be sent by setting the
"REQUEST-FLAG field" to 0x01.
                        > >> Currently, the REQUEST-FLAG field is
defined only for a data-type of
                        > >> REQUEST.  Given that this BYTE is pretty
much wasted, it makes sense
                        > >> to use this field for SDI.  A value of 0x01
in this field will be
                        > >> interpreted as SDI for all data types
except REQUEST (for REQUEST it
                        > >> will retain its current definition from
RFC1647).  When the Client
                        > >> receives the SDI, it implies that after
processing the current
                        > >> TN3270E message (i.e. when it sees the EOR)
it will be okay to send
                        > >> data to the server.
                > >
                > >Shouldn't it be defined as a bit rather than as a
byte value?
                > >(Then I can use another bit for FMH.)
                > >
                        > >>  Note that the Client will still be allowed
to send RESPONSES to the
                        > >> Server, even if it has not received the
SDI.  Also, in the case
                        > >> where the Server is waiting for a definite
response from the Client
                        > >> before sending down the SDI, the RU sent to
the Client that contains
                        > >> the SDI will be NULL.
                > >
                        > >>  BID requires a new TN3270E datatype (e.g.
0x09).  The Server will
                        > >> indicate that it has received either an
implicit or explicit BID by
                        > >> sending this data type to the Client.  Even
if the RESPONSES
                        > >> function has not been negotiated, the
Client MUST respond to the BID
                        > >> (the Server should also send a SEQ-NUM
which should be used by the
                        > >> Client in its response).  It sends a
positive response to the server
                        > >> via the RESPONSE data type with the data
byte containing
                        > >> POSITIVE-RESPONSE (as defined in the
current RFC).  It rejects the
                        > >> BID via the RESPONSE data type with the
data byte containing
                        > >> NEGATIVE-RESPONSE (as defined in the
current RFC).
                > >
                        > >>  The server is then responsible for
constructing the appropriate SNA
                        > >> response to the host.
                > >
                > >There are two possible sense codes: 0813 and 0814.
The latter
                > >promises to let the Host know when it can send.
                > >
                > >A nasty problem with 3270 is that the end user may
have started
                > >to key some data.  When the Host sends Bid, the SLU
sends 0814 (say).
                > >But what if the user pressed a key by mistake?  It is
not unknown
                > >for the user to press the spacebar and not even
notice.  It is a
                > >good idea for the emulator to have some smarts to
time out the
                > >input (especially if all blank), or at least give the
user some
                > >way to cancel the input.  But if 0814 was sent, the
emulator must
                > >now send in RTR.  (Sending a null message is not
advised because
                > >that can be a significant event for the Host appl -
e.g. the TSO
                > >editor will leave input mode.)
                > >
                > >So there would be benefit in architecting that the
client,
                > >having sent a -rsp to Bid, should eventually send
                > >either input data or a +rsp to the same Bid.
                > >
                        > >>  There is a potential race condition where
the Client sends data to the
                        > >> Server after the Server has sent the BID to
the Client (presumably the
                        > >> Client hadn't seen the BID before it sent
data).  In this race condition
                        > >> case where the Server sees data from the
Client before it sees a
                        > >> positive/negative response to the BID, it
should treat the Data as an
                        > >> implied negative response and reject the
BID before sending the Client
                        > >> data up to the host.  The Client will know
that such a race has ocurred
                        > >> because it will see a BID come from the
Server before it receives the
                        > >> SDI.  In this case, the Client can just
silently discard the BID (no
                        > >> response should be sent to the Server
because the Server will already
                        > >> have responded negatively to the host).
                > >
                > >That looks solid.
                > >
                        > >> *******************************
                > >
                        > >>  This is intended as a starting point-a
straw man to throw things at
                        > >> (or you could even set it on fire if you're
so inclined :-)
                        > >>  Rodger Erickson
                        > >>  Wall Data