Subject: Re: Keyboard Restore Bid Proposal II

From: Jim Mathewson II <[email-masked]>
Date: Thu, 18 Dec 1997 17:44:11 -0500

MBOE my comments started with $

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

$ The impression I got by the statement "completely replaces" indicates that
WCC
$ keyboard restore has NO effect on the unlocking of the keyboard and that is
NOT
$ correct.  If I have over reacted by my VERY wrong statement I apologize.
However
$ I have worked with 3270DS for 22 years and for a number of years have been
the lone
$ owner of the architecture and I have witnessed a number of incorrect
interpretations
$ of the architecture.

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

$ The SLU is not in SEND/not-transmitting substate in this case.  A CDI is
required to
$ put the SLU in a SEND 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?

$ In most implementations of typeahead the queued keys are not processed prior
to being
$ in either SEND or CONTENTION state, thus eliminating any X-f errors from
occurring do to
$ queued AID generating operations.

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

$ This is a very useful function.

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

$ I would still not like to refer to overrides or replaces if for no other
reason than
$ architecture purity as well as understanding how the relationship between EBI
and WCC KR
$ so to fully understand the problem we are addressing.  Additionally consider
the following:

$#1
$
$ CDI/!EBI/WCC KR (Keyboard is UNLOCKED)  CDI does not replace or override WCC
KR!!
$
$#2
$ Assume transaction contains multiple writes which is how VM works as well as
a number of
$ other applications that merge multiple templates to form a single
PRESENTATION SPACE.
$
$ !CDI/!EBI/WCC KR (Keyboard is UNLOCKED)
$ CDI/!EBI/!WCC KR (Keyboard is UNLOCKED -- NOT X-SYSTEM, hence CDI does NOT
override WCC KR)
$
$#3
$ VTAM will flow a NULL RU with CDI alot.
$
$ !CDI/!EBI/WCC KR (Keyboard is UNLOCKED)
$ CDI/!EBI/NULL RU (Keyboard is UNLOCKED -- NOT X-SYSTEM, hence again CDI does
not override)
$
$#4
$ Again assume transaction contains multiple writes
$ !CDI/!EBI/WCC KR (Keyboard is UNLOCKED)
$ !CDI/!EBI/!WCC KR (Keyboard is still UNLOCKED - here just to make sure we
understand unlocking)
$ !CDI/EBI/!WCC KR (Keyboard is still UNLOCKED, EBI essentially is a NOP as far
as unlocking the
$                      keyboard is concerned.)
$

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

$ Not that CDI did not override the behavior of WCC KR in my #1/#2 example
above.

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?

$ Remember you are working with applications that have been in existence since
the mid 70s.
$ So we have to consider its implication.  As noted above a type-ahead
environment
$ should not process its queued keystrokes until SEND/CONTENTION state is
entered.
$ Are we to assume that all client implementations of tn3270 uses type-ahead?
If not we
$ certainly have to keep the non-typeahead environment in mind.

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

$ Remember we are only talking about an error condition here. The normal UI
would have been
$ to UNLOCK the keyboard with WCC KR.  See #1 above.

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

$ That is correct.  Now how often does that occur?  The normal operation is for
an
$ application to expect the operator to perform a modification of the
PRESENTATION
$ SPACE and it is expected to occur in a reasonable timeframe.  As soon as an
AID
$ operation is performed the message would be transmitted to the SLU.

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

$ That can be done.
/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
> Subject: Re: Keyboard Restore Bid Proposal II
>
>
> > 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: Michael Boe <[email-masked]>
Date: Thu, 18 Dec 1997 15:44:16 -0800 (PST)

> > 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....
>
> $ The impression I got by the statement "completely replaces" indicates
> that WCC
> $ keyboard restore has NO effect on the unlocking of the keyboard and that
> is NOT
> $ I have worked with 3270DS for 22 years and for a number of years have
> been the lone
> > When an operator performs an AID operation the keyboard is LOCKED
> > (X-CLOCK) an INBOUND Data Stream (DS) is generated and the
> > An RU containing an OUTBOUND DS with WCC keyboard restore in which case
> > the keyboard is UNLOCKED.  What this means is the
> > 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?
>
> $ In most implementations of typeahead the queued keys are not processed
> prior to being
> between the two, and therefore they could be treated equivalently.  Not
> that I had a lot of choice in the matter wrt TN3270 :-).
>

Yes, but one which is actually impossible with today's TN3270 products.

> > An RU containing an OUTBOUND DS with WCC without keyboard restore but
> > with EBI would unlock the keyboard, same as WCC keyboard restore
> OK.  So maybe we're just arguing semantics here, but it would appear to me
> the EBI overrides (ie replaces) keyboard-restore action here.
>
> $ architecture purity as well as understanding how the relationship between
> EBI and WCC KR
> $ so to fully understand the problem we are addressing.  Additionally
> consider the following:
>
> $#1
> $
> $ CDI/!EBI/WCC KR (Keyboard is UNLOCKED)  CDI does not replace or override
> WCC KR!!
> $
> $#2
> $ Assume transaction contains multiple writes which is how VM works as well
> as a number of
> $ CDI/!EBI/!WCC KR (Keyboard is UNLOCKED -- NOT X-SYSTEM, hence CDI does
> NOT override WCC KR)
> $
> $#3
> $ CDI/!EBI/NULL RU (Keyboard is UNLOCKED -- NOT X-SYSTEM, hence again CDI
> does not override)
> $
> $#4
> $ !CDI/EBI/!WCC KR (Keyboard is still UNLOCKED, EBI essentially is a NOP as
> far as unlocking the

OK, we all should keep these cases in mind when discussing the solutions.

> 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?
>
> $ Remember you are working with applications that have been in existence
> since the mid 70s.
> $ Are we to assume that all client implementations of tn3270 uses
> type-ahead? If not we

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

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

Sure...just pointing out that it makes the RESET key a part of normal
day-to-day operations.  Day-to-day operations include the error processing you
describe above.  Just like when I type in a non-existent URL at my browser and
get the infamous HTTP 401 error. That can be considered "error processing," but
is hardly rare (at least with my fat fingers :-).

> > 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
> (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?
>
> $ That is correct.  Now how often does that occur?  The normal operation is
> for an
> $ SPACE and it is expected to occur in a reasonable timeframe.  As soon as
> an AID

Here's what happens with a real COBOL app doing some 3270 stuff for a SAP
application:

  HOST                WS
  <-------------------FMD(EXR,BB,CD)
  FMD(EXR,EB)[NULL]--->
  <--------------------+ve
  BID----------------->
  <-------------------+ve
       [application sits for OVER 20 seconds in this state]
  FMD(BBIU,FIC,EXR)---->

Now, if we had rejected the BID, the application would hang, waiting for the
eventual input from the client (which might never arrive 'cuz the client hasn't
done anything).

[Please remember that this is a REAL APPLICATION and not some bone-headed
example I've artificially constructed to bamboozle you.  With some hunting, I
could find a few more....]

/msb

>
> >
> > 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.
> >
> > > I have also tried to append another item on this subject though I
> > > haven't seen it pop up and I have not received
> > > 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.
> >