Subject: Re: Keyboard Restore Bid Proposal II

From: Jim Mathewson II <[email-masked]>
Date: Wed, 31 Dec 1997 10:58:20 -0500

Greetings Derek,
I hope you had an enjoyable time off.

My comments preceded by &.

Jim,

Having triggered this storm, I was luckily too busy to take any
further part in it until now ;-).

As Michael observes below, TN3270 is always typeahead.  Although
I didn't bother to make it clear, it is in that context that I
believed CD/EB to replace KR.

But you've got me worried regarding the cases where the Host sends
EB/CD but not KR.  On the one hand, I believed we had observed apps
which assume KR is implied.  (As a result, we implemented generation
of KR when EB/CD received.)  On the other, it would certainly solve
problems for us if we do not need to infer a KR.

As far as TN3270 is concerned, suppose we said that the client
should freeze the queue until BOTH KR (either received from
the server or by local reset) AND CD/EB (indicated by some new
'end of output' message in the datastream).
What would go wrong in your view?

& This would be a fine implementation given typeahead is a basic
& component of TN3270.  This mirrors the 3174 implementation of typeahead
& and the freeing of the typeahead buffer.  Note that you would want to
& send this 'end of ouput' message whenever you received a CD/EB regardless
& of receipt of KR. A destinction must be made between 'end of output' with
& CD/!EB from 'end of output' with CD/EB or !CD/EB since in one case the
& keyboard may still be locked with X-SYSTEM if a KR has not been received.

More embedded...

> MBOE my comments now start with %
> > 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....
>
> > $ 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.
> > $ 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.

> Yes, but one which is actually impossible with today's TN3270 products.
> % WHY? Because we handle the keyboard incorrectly from a SNA perspective?
> % I thought that is what we are trying to address!  Part of the keyboard
> % handling problem came from the fact that the model used was the NON-SNA
> % model.  Which is fine for migration of NON-SNA applications to the TCP/IP
> % world.  But the problem we are addressing here is the migration of SNA
> % applications to the TCP/IP world without changing the applications.

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

I don't understand what the example proves.  Since CD and KR are both
present, the result is the same whether you consider CD to be an
implicit KR or not.

& CDI does not remove X-SYSTEM so if CDI/!EBI/!KR was received then the keyboard
& would still be locked with X-SYSTEM!!!

> > $
> > $#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)

This is the one that's causing a headache in TN3270.
We need the client not to dequeue the input yet.
I.e., to behave as though KR had not been received.

> > $ CDI/!EBI/!WCC KR (Keyboard is UNLOCKED -- NOT X-SYSTEM, hence CDI does
> > NOT override WCC KR)

Again, since the terminal has now received both CD and KR it's moot
as to whether CD implies KR.

& The result is NOT the same as in #1.  See my answer to your comment on #1.
& This is an important destinction especially with typeahead.  Let me explain.
& Assume a DATA ENTRY application, filling in insurance forms.  The operator
knows
& the series of Presentation Spaces the encompass the application and after
filling
& in form1 and depressing the enter continues typing (USING TYPEAHEAD) to start
& filling in form2.  The application notes that an error was detected in form1
and
& instead of sending out form2 to fill out resends form1 with the data that was
& entered with the field in error IN RED and BLINKING with CDI/!EBI/!KR.  This
will
& cause the keyboard to go from X-CLOCK to X-SYSTEM and require the operator to
& depress the RESET key to remove X-SYSTEM and PURGE the TYPEAHEAD QUEUE!

> > $
> > $#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)

Same as #2.

& This was to illustrate that previous receipt of previous KR would unlock the
& the keyboard and subsequent receipt of CD would not now post a X-SYSTEM as is
& the result in #2 above.

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

Same as #2 and #3, but with EB instead of CD.

The case that I expected you to present is:

  EBI, WCC !KR

This seems to me to be the only one in which, for tn3270, replacing
KR by EB||CD might not work.  (But now I appreciate that CD is also
an issue, as you describe below.)

Now, I was pretty sure we'd had a problem because an appl was sending
that sequence and we were not, at that time, generating KR to the
client.  So are you now telling me that the appl was at fault?  And
are you also saying that appl would not have worked with an IBM SNA
3270?  Because if it would work with a real SNA 3270 then, as I'm sure
you appreciate, we have little choice but to make it work with TN3270.

& !CDI/EBI/!KR would UNLOCK the keyboard.  I am also very familiar with
& this problem as the product on which I currently work also has the same
& problem with customers migrating applications from SNA to TN3270 that
& did not use KR to unlock the keyboard but used the EBI to unlock the
& keyboard.  That was done so that no matter what order an application might
& put multiple templates together to build a Presentation Space none of the
& individual writes had KR and the application let the EBI unlock the keyboard.
& So the application was not at fault but the TN3270 SNA architecture is at
& fault.  Which is why I believe we are all here in a hope to correct this
& oversight.

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

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

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

> % I believe this stems from the fact that the keyboard is not locked
>   at AID generation time with X-CLOCK but only with X-SYSTEM. Which
>   is the NON-SNA method of handling AID functions.

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

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

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

I must be missing something.  We reject the Bid; the appl retries; we
reject the Bid;.. where does this get us?  Remember that the gateway
has no idea whether the user intends to send something before the
next Host output.

& This is really irrelevant since the same could occur if you did
& query the CLIENT to determine if any modifications of the Presentation
& Space has occurred.

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

Netstat does it all the time.  In fact, it writes a screen with no
input fields.  A function key is the only valid input, and the result
of the input will be to exit the status window!  So requiring user
input for each output screen would destroy the usability.  A single
application like that is enough to blow away any hope of fixing this
without client code change.

& I accept that as a valid application and an answer on why rejecting the
& BID without checking with the CLIENT is not a solution.

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

> % And if the operator had depressed a single key to modify the
> Presentation Space then walked away for a cup of coffee you get
> the same result.  This could have been done by queueing keystrokes
> which would have been processed immediately upon receipt of the
> EB.  Again all we have have is a race condition on when the
> operator modified the Presentation Space.  I am quite curious as
> to why the application was coded that way.  What function is
> achieved in this manner that couldn't be achieved by:

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

This is CICS.  My understanding is that CICS itself sends the EB
then the appl behind CICS initiates a send.  CICS then generates
the Bid.

Regarding the 'touched spacebar' scenario, I've heard that the right
way for the appl to handle that would be to retry a few times then
eventually send Signal.  But you really don't want that delay on every
transaction, so you'd better do it only when a key really has been
touched.

Regards,
  Derek

> % I am sure you could find others, however how many applications can
> you find that simply rejecting the BID without communicating to the
> CLIENT to determine if a BID should be accepted or not, which might
> still be denied because the PRESENTATION SPACE has been modified
> even if you did communicate to the CLIENT.  Note I am attempting to
> explore solutions that would not require changes to any CLIENT code,
> since if this is achievable it would bring all the existing CLIENT
> EMULATORS into the SNA/TCPIP world with only a SERVER change.  It
> would be a value add to any SERVER that handled BID better on behalf
> of the SERVER/CLIENT pair.

> /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.
>
> > > 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
>
> > > > 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: "Derek W. Bolton" <[email-masked]>
Date: Fri, 2 Jan 1998 09:26:50 +1100 (EST)

Hi Jim,

I spy convergence!

> I hope you had an enjoyable time off.

Thanks - all too brief!

> DB2: As Michael observes below, TN3270 is always typeahead.
> Although I didn't bother to make it clear, it is in that context
> that I believed CD/EB to replace KR.

> What would go wrong in your view?

JM3: This would be a fine implementation given typeahead is a basic
component of TN3270.  This mirrors the 3174 implementation of
typeahead and the freeing of the typeahead buffer.  Note that you
would want to send this 'end of ouput' message whenever you received
a CD/EB regardless of receipt of KR. A distinction must be made
between 'end of output' with CD/!EB from 'end of output' with CD/EB
or !CD/EB since in one case the keyboard may still be locked with
X-SYSTEM if a KR has not been received.

DB3: OK - I see I jumped too far in the other direction.  You're
saying that EB *does* imply KR but CD doesn't.

Strictly speaking, that does not require two flavours of 'end of
output' though.  We could translate EB into Write KR.  (We do that
today in the CIP server.)  Do you see any benefit in having a
specific TN3270 flow for it?

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

> > > JM1: The SLU is not in SEND/not-transmitting substate in this case.
> > > A CDI is required to
> > > put the SLU in a SEND state.

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

> > > JM1: This is a very useful function.

> > JM2: WHY? Because we handle the keyboard incorrectly from a SNA
> > perspective?

> > I thought that is what we are trying to address!  Part of the keyboard
> > handling problem came from the fact that the model used was the NON-SNA
> > model.  Which is fine for migration of NON-SNA applications to the TCP/IP
> > world.  But the problem we are addressing here is the migration of SNA
> > applications to the TCP/IP world without changing the applications.

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

> > > JM1:#1
> > > CDI/!EBI/WCC KR (Keyboard is UNLOCKED) CDI does not replace or
> > > override WCC KR!!

> DB2: I don't understand what the example proves.  Since CD and KR
> are both present, the result is the same whether you consider CD to
> be an implicit KR or not.

JM3: CDI does not remove X-SYSTEM so if CDI/!EBI/!KR was received then
the keyboard would still be locked with X-SYSTEM!!!

DB3: Jim, the example you gave was CDI/!EBI/WCC KR (Keyboard is
UNLOCKED).  I guess the example you meant to give was CDI/!EBI/WCC !KR
(Keyboard is LOCKED).  If you agree with that then we're also in
agreement regarding the distinction from #3.  Otherwise I fail to see
why the end result of:

CDI/!EBI/WCC KR

should differ from that of the pair:

!CDI/!EBI/WCC KR
CDI/!EBI/!WCC KR

> > > JM1:#2
> > > Assume transaction contains multiple writes which is how VM

> > > !CDI/!EBI/WCC KR (Keyboard is UNLOCKED)

> DB2: This is the one that's causing a headache in TN3270.

> > > CDI/!EBI/!WCC KR (Keyboard is UNLOCKED -- NOT X-SYSTEM,
> > > hence CDI does NOT override WCC KR)

> DB2: Again, since the terminal has now received both CD and KR it's
> moot as to whether CD implies KR.

JM3: The result is NOT the same as in #1.  See my answer to your
comment on #1.  This is an important distinction especially with
typeahead.  Let me explain.  Assume a DATA ENTRY application, filling
in insurance forms.  The operator knows the series of Presentation
Spaces the encompass the application and after filling in form1 and
depressing the enter continues typing (USING TYPEAHEAD) to start
filling in form2.  The application notes that an error was detected in
form1 and instead of sending out form2 to fill out resends form1 with
the data that was entered with the field in error IN RED and BLINKING
with CDI/!EBI/!KR.  This will cause the keyboard to go from X-CLOCK to
X-SYSTEM and require the operator to depress the RESET key to remove
X-SYSTEM and PURGE the TYPEAHEAD QUEUE!

> > > JM1:#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)

> DB2: Same as #2.

JM3: This was to illustrate that previous receipt of previous KR would
unlock the the keyboard and subsequent receipt of CD would not now
post a X-SYSTEM as is the result in #2 above.

DB3: Small ambiguity there.  Do you mean that #2 and #3 have the same
end result (as I claim) or that #2 posts X-SYSTEM?  Unless I'm missing
something, the only difference in your #2 and #3 is that in #3 the CD
RU was a null RU.  Isn't null RU equivalent to Write WCC !KR for these
purposes?

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

> DB2: Same as #2 and #3, but with EB instead of CD.

> Now, I was pretty sure we'd had a problem because an appl was
> sending that sequence and we were not, at that time, generating KR
> to the client.  So are you now telling me that the appl was at
> fault?  And are you also saying that appl would not have worked with
> an IBM SNA 3270?  Because if it would work with a real SNA 3270
> then, as I'm sure you appreciate, we have little choice but to make
> it work with TN3270.

JM3: !CDI/EBI/!KR would UNLOCK the keyboard.  I am also very familiar
with this problem as the product on which I currently work also has
the same problem with customers migrating applications from SNA to
TN3270 that did not use KR to unlock the keyboard but used the EBI to
unlock the keyboard.  That was done so that no matter what order an
application might put multiple templates together to build a
Presentation Space none of the individual writes had KR and the
application let the EBI unlock the keyboard.  So the application was
not at fault but the TN3270 SNA architecture is at fault.  Which is
why I believe we are all here in a hope to correct this oversight.

DB3: OK - thanks.

Regards,
  Derek

> > > JM1: In the case of WCC keyboard restore without CDI/EBI this allows an

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

> > JM2: I believe this stems from the fact that the keyboard is not locked

> DB2: I must be missing something.  We reject the Bid; the appl
> retries; we reject the Bid;.. where does this get us?  Remember that
> the gateway has no idea whether the user intends to send something
> before the next Host output.

JM3: This is really irrelevant since the same could occur if you did
query the CLIENT to determine if any modifications of the
Presentation Space has occurred.

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

> DB2: Netstat does it all the time.  In fact, it writes a screen with
> no input fields.  A function key is the only valid input, and the
> result of the input will be to exit the status window!  So requiring
> user input for each output screen would destroy the usability.  A
> single application like that is enough to blow away any hope of
> fixing this without client code change.

JM3: I accept that as a valid application and an answer on why
rejecting the BID without checking with the CLIENT is not a solution.

> > JM2: And if the operator had depressed a single key to modify the

> DB2: This is CICS.  My understanding is that CICS itself sends the
> EB then the appl behind CICS initiates a send.  CICS then generates
> the Bid.

> eventually send Signal.  But you really don't want that delay on
> every transaction, so you'd better do it only when a key really has
> been touched.

> > JM2: I am sure you could find others, however how many applications can