Subject: Re: Keyboard Restore Bid Proposal II

From: Jim Mathewson II <[email-masked]>
Date: Thu, 18 Dec 1997 08:23:48 -0500

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

Signal if received in CONTENTION STATE  will be positively responded to by the
SLU.
The SLU will not send CDI until an AID key has been depressed on the keyboard
and the SLU responds with BBI & CDI.
Therefore this is NOT some sneaky way for the PLU to circumvent the rejection
of the BID due to the SLU modifying the Presentation Space.

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.

James M. Mathewson II
Senior Software Engineer
IBM

[email-masked] on 12/16/97 06:58:11 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet
Subject: Re: Keyboard Restore Bid Proposal II

Rodger,

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

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

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

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

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.

>       Rodger

---

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

> Signal if received in CONTENTION STATE  will be positively responded to by
> the SLU.
> The SLU will not send CDI until an AID key has been depressed on the
> keyboard and the SLU responds with BBI & CDI.
> Therefore this is NOT some sneaky way for the PLU to circumvent the
> rejection of the BID due to the SLU modifying the Presentation Space.

I'm unsure why you say this. The 3174 Function Description is clear on this
regarding what the SLU does when presented with a Signal command (Section
4.1.5.3.8):
   "A request with CD but no data (a null RU) will be sent if the SLU is in
send state but has not started transmitting."

This seems to contradict your statement.  Please clarify.

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

You're correct. This is in fact what we do today to partially work around the
problem.

/msb