Subject: RE: BID proposal

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

Rodger,

I'm sorry, I omitted to address Jim's statements about the 3174
and Signal.

Here's a trace I took with CM/2.  I had two users logged on to VM/CMS.
The CM/2 user, USER2, typed some garbage on the input line but did not
press an AID key.  Then USER1 sent the USER2 a message.  The sequence
looks to me to be exactly as in the 3174 manual:

    Host                    SLU

    BB EB data ->
                    <- -rsp 081b
    Signal ->
                    <- +rsp Signal
                    <- BB CD null
    EB data ->

FMTTRACE
(C) Copyright IBM Corporation 1990, 1991, 1993

Line:     20 Recv MU
Time stamp: 02:56:41.72
DLC type: IBMTRNET
Adapter number: 00
Destination address: 4000747000E708
ALS ID: 68D3CF917E23437C
||TH: FID2, OIS, LFSID=0x00102, SNF=0x000e
||RH: RQ, FMD, OIC, RQE1, BB, EB
||User data - remainder of RU follows:
||   Hex dump:
||      f1c7115b 5f2903c0 c1410042 f7115d6b      <1G.[_).{AA.B7.]k>
||      2903c060 410042f2 d9e4d5d5 c9d5c740      <).{`A.B2RUNNING >
||      4040d9c1 d3e5d4d7 c340401d 60115050      <  RALVMPC  .`.PP>
||      28410028 42f51de8 f0f27af0 f07af0f8      <(A.(B5.Y02z00z08>
||      40405c40 d4e2c740 c6d9d6d4 40e4e2c5      <  \ MSG FROM USE>
||      d9f14040 407a40c8 c91d60                 <R1   z HI.`     >

Line:     29 Send MU
Time stamp: 02:56:41.72
DLC type: IBMTRNET
Adapter number: 00
Destination address: 4000747000E708
ALS ID: 68D3CF917E23437C
||TH: FID2, OIS, LFSID=0x00102, SNF=0x000e
||RH: -RSP, FMD, SDI, RQD1
||Sense data: 0x081b0000
||FMD -rsp

Line:     33 Recv MU
Time stamp: 02:56:41.88
DLC type: IBMTRNET
Adapter number: 00
Destination address: 4000747000E708
ALS ID: 68D3CF917E23437C
||TH: FID2, Exp, OIS, LFSID=0x00102, SNF=0x000e
||RH: RQ, DFC, FI, OIC, RQD1
SIGNAL rq
||   Signal code = 0x0001
||   Signal extension = 0x0000

Line:     37 Send MU
Time stamp: 02:56:41.88
DLC type: IBMTRNET
Adapter number: 00
Destination address: 4000747000E708
ALS ID: 68D3CF917E23437C
||TH: FID2, Exp, OIS, LFSID=0x00102, SNF=0x000e
||RH: +RSP, DFC, FI, RQD1
SIGNAL +rsp

Line:     41 Send MU
Time stamp: 02:56:41.88
DLC type: IBMTRNET
Adapter number: 00
Destination address: 4000747000E708
ALS ID: 68D3CF917E23437C
||TH: FID2, OIS, LFSID=0x00102, SNF=0x0007
||RH: RQ, FMD, OIC, RQE1, BB, CD

Line:     44 Recv MU
Time stamp: 02:56:41.94
DLC type: IBMTRNET
Adapter number: 00
Destination address: 4000747000E708
ALS ID: 68D3CF917E23437C
||TH: FID2, OIS, LFSID=0x00102, SNF=0x000f
||RH: RQ, FMD, OIC, RQD1, EB
||User data - remainder of RU follows:
||   Hex dump:
||      f1c7115b 5f2903c0 c1410042 f7115d6b      <1G.[_).{AA.B7.]k>
||      2903c060 410042f2 d9e4d5d5 c9d5c740      <).{`A.B2RUNNING >
||      4040d9c1 d3e5d4d7 c340401d 60115050      <  RALVMPC  .`.PP>
||      28410028 42f51de8 f0f27af0 f07af0f8      <(A.(B5.Y02z00z08>
||      40405c40 d4e2c740 c6d9d6d4 40e4e2c5      <  \ MSG FROM USE>
||      d9f14040 407a40c8 c91d60                 <R1   z HI.`     >

Line:     53 Send MU
Time stamp: 02:56:41.94
DLC type: IBMTRNET
Adapter number: 00
Destination address: 4000747000E708
ALS ID: 68D3CF917E23437C
||TH: FID2, OIS, LFSID=0x00102, SNF=0x000f
||RH: +RSP, FMD, RQD1
||FMD +rsp

The message appeared on USER2's screen.  The input garbage
was still there since CMS operates with distinct input and
output areas on the screen.
At this point, USER2 pressed enter and the garbage was sent in:

Line:     56 Send MU
Time stamp: 02:56:50.94
DLC type: IBMTRNET
Adapter number: 00
Destination address: 4000747000E708
ALS ID: 68D3CF917E23437C
||TH: FID2, OIS, LFSID=0x00102, SNF=0x0008
||RH: RQ, FMD, OIC, RQE1, BB, CD
||User data - remainder of RU follows:
||   Hex dump:
||      7d5bf011 5b6081a2 92918486 88878192      <}[0.[`askjdfhgak>
||      a2918486 8788                            <sjdfgh          >

Line:     61 Recv MU
Time stamp: 02:56:51.13
DLC type: IBMTRNET
Adapter number: 00
Destination address: 4000747000E708
ALS ID: 68D3CF917E23437C
||TH: FID2, OIS, LFSID=0x00102, SNF=0x0010
||RH: RQ, FMD, OIC, RQE1, EB
||User data - remainder of RU follows:
||   Hex dump:
||      f1c3115b 5f125d6b 115b5f29 03c0c141      <1C.[_.]k.[_).{AA>
||      0042f713 115d6b29 03c06041 0042f2d9      <.B7..]k).{`A.B2R>
||      e4d5d5c9 d5c74040 40d9c1d3 e5d4d7c3      <UNNING   RALVMPC>
||      40401d60 11d16028 41002842 f781a292      <  .`.J`(A.(B7ask>
||      91848688 878192a2 91848687 8811d2f0      <jdfhgaksjdfgh.K0>
||      28410028 42f4e495 929596a6 9540c3d7      <(A.(B4Unknown CP>
||      61c3d4e2 40839694 94819584               <aCMS command    >

Peter Haig, who managed a 3270 network 20 years ago, told me that's
how SNA 3274s always worked.  If 3174 does not do that today then
it seems it's a regression.

Some more comments embedded below.

>       Derek,

>       I believe we're getting VERY close.  The only questions that I
> have involve the host-generated SIGNAL.  Let me make sure I'm
> following you.  You're saying that the host has the right to
> override the client's rejection of the BID (or at least that the
> host has the ability to send a BID that the client can't reject).

>       I'm concerned about this for the following reasons because it
> seems to trash user input without warning.  I guess I'm also a
> little suspicious about this because RUMBA has never supported the
> host-based SIGNAL.  That's a lot of SNA users out there that have
> never had a need for such a thing.

>       Just because we don't do it though, doesn't make it a bad
> thing.  If it's just a matter of adding a 2nd flag to the
> REQUEST-FLAG byte that says "FORCE" and then defining some
> unambiguous client behavior (that works fine regardless of
> type-ahead) then I'll put it in.  However, Jim Mathewson seemed to
> allude to the notion that the client could reject this just as
> easily as the first one (which would make sense to me).  If this is
> the case, then it seems redundant to support this.  Why can't we
> assume that "no" from the client means "no" and not "no, but ask me
> again if you really want me to".

> I don't think it's any secret that I've long lamented that we didn't
> just encapsulate SNA over TCP rather then adding more and more
> complexity in an effort to avoid SNA on the desktop.  However, given
> that we've proceeded down this rathole, I'd like to avoid "repairs"
> to the protocol which aren't really fixing anything.

> Thanks!

>       ----------
>       From:  Derek W. Bolton [SMTP:[email-masked]]
>       Sent:  Monday, December 29, 1997 12:23 AM
>       To:  [email-masked]
>       Cc:  [email-masked]
>       Subject:  Re: BID proposal

>   Rodger,

>   With the version of your original proposal that's attached as a
>   base, here's my understanding of where we are.  Or at least, where
>   I am:

>   1. The CD/EB -> SDI map you describe satisfies 'end of host
>   output' requirement.  The client effectively ANDs this with the
>   Keyboard Restore state.  To put that another way, the server can
>   send KR at any time during the output, but it should not be
>   actioned until SDI.  A local Reset clears the keyboard lock but
>   does not override the need for SDI.

>   Contrary to my earlier claim, SDI is not sufficient in itself to
>   unlock the keyboard.

>   2. There is no need to withhold SDI pending a response from the
>   client.  The client knows to send the rsp before any data.
>   Consequently, there is no need to redefine the meaning of the
>   request flag for any data type other than 3270DS.

>   3. I would prefer that you only use one bit in the request flag
>   for SDI.

>   4. It needs to be made clear that the server must not send BID to
>   the client unless it has sent SDI since the last input from the
>   client.  Without that proviso, the client cannot tell whether to
>   accept a BID that arrives after sending in data.  It might or
>   might not be a race.

>   5. The BID needs a FORCE option.  The server maps Signal from the
>   Host to BID+FORCE.

>   On receiving BID+FORCE, the client discards any keyed data (that
>   has made it past the keyahead queue) and sends a +rsp.

Correction - the client should not discard the input data.  It may get
overwritten by output data, but that's not the client's problem.
On receiving the rsp from the client, the server sends null RU,
BB CD to the Host.  (It should already have sent +rsp Signal.)

There are two race conditions to consider when the user presses AID
after rejecting the initial BID but before the BID FORCE.

1. Server sees AID before Signal.

When the Signal arrives, the Host already has direction, so the
server responds to the Signal but takes no further action.
The client is not involved.

2. BID FORCE crosses with AID from client.

As with normal BID, client discards BID FORCE without responding.
Server forwards inbound data as normal.

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.

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

>    Rodger Erickson
>    Wall Data