Subject: Re: TN3270 and Read State logic?

From: Jim Mathewson II <[email-masked]>
Date: Wed, 21 Jan 1998 18:01:11 -0500

Sorry I haven't responded quicker I was away from the office for
a bit getting better educated.

In response to the question as to whether or not I have a proposal
on what the Server could do in lieu of the Client for Read State
implementation the answer is NO.  The Client is the only reasonable
place to put requirements in the system for read states to be handled
properly.  My whole intent here was to highlight to the client creaters
of the world that their implementation for SNA I would guess was sorely
lacking and with what comes out of this exercise in cleaning up keyboard
unlocking definitions and new OKAY TO SEND architecture that the read
state implementation can also be cleaned up providing the Client developer
wishes to spend the development dollars.

JM1:

Please note a small clarification on CD.  What I stated is for CD
for a WRITE type command NOT a READ type command. CD with a READ
MODIFIED, or READ MODIFIED ALL or READ BUFFER, would not reset
X-CLOCK.

Question: Does TN3270E support the READ STATE architecture of 3270?
For example assume the following transaction.

Read Partition QUERY --------------->
           <--------------------------------------- QUERY
READ MODIFIED ---------------------->
           <--------------------------------------- QUERY
(Or does the CLIENT send PS data?)

another one: ASSUME SNA connection

           <-------------------------------------- ENTER AID
  Read Partition QUERY --------------------------->
           <-------------------------------------- REJECT 0871

yet ASSUME NON-SNA connection

           <--------------------------------------- ENTER AID
    Read Partition QUERY ------------------------->
           <--------------------------------------- QUERY
     WRITE -------------------------------->
           <--------------------------------------- ENTER AID
(Same as one previously sent!!)

So if TN3270 does all is well, if it doesn't are we ready to talk
about the READ Architecture?

DB2:

As you may realize, the TN3270 architecture was originally based
firmly on non-SNA operations.  TN3270E allows much more SNA-ness,
but the clients are still pretty non-SNA where there's a choice.
Besides, clients shouldn't have to care whether they're connected to
a Host-based server or an SNA gateway server.

The corollary is that an SNA gateway server needs to detect and
reject the RPQ in retry enter or retry read state.  I don't think
there's an impact on the TN3270E protocol itself.

JM3:

So you are suggesting that the server should scan and hold the
entire outbound message look for HOST ACKNOWLEDGEMENTS & READ
PARTITION SFs to determine whether it is correct to forward the
outbound message to the client?

DB4:

Maybe I've overlooked issues relating to multiple partitions.
Are you saying that the read state logic applies independently
to each partition?

Anyway, if it's going to be hard for the server to check this,
let's try another tack.  What goes wrong if we treat it like
non-SNA read state logic?  (I.e. the server lets the client
figure it out?)

Well, there's one impact immediately: we need a way for the client to
report the error to the server when the Host issues RPQ in any of the
states Data Pending/Read, Data Pending/Stacked Enter, Retry/Read or
Retry/Stacked Enter.  My preferred solution to that is something
I've already proposed as part of the FMH proposal: the client needs
to be able to send SNA sense codes.

JM5:

Where can I read your proposal on the FMH enhancements.  I do agree
that SNA sense codes should be sent by the client.

DB6:

It'll be on the archives of the mail list, but I'll send you a copy.

JM3:

I also gather that you believe that my example of the NON-SNA
connection above retransmitting the ENTER AID is what the existing
clients would do?  As well as the READ MODIFIED in my first example
that the client would send the QUERY data inbound and not Presentation
Space data?

DB4:

Oh no, I'm not saying that at all.  I'm saying that it's what clients
should do today.  I doubt many of them do it all perfectly.

But I don't see the need to replicate the whole of the 3270DS spec
in the TN3270E spec.  TN3270E merely addresses the protocol
between the client and the server.  The protocol between the client
and the appl should be unaffected.

JM5:

The problem is that before we gave the client the SDI indication the
client would not be privy to information needed to determine if an
outbound write was a HOST ACKNOWLEDGEMENT, CD and EB are both HOST
ACKNOWLEDGEMENTs.  Additionally since most implementations used a
non-sna keyboard management implementation, ie x-system not x-clock
on AID we would have allowed Presentation Space modification.

DB6:

That's right.  At best, clients today handle Read State correctly
as for non-SNA operation.  So for a SNA gateway, the question is
how much is it reasonable for the gateway to fix up and how much
has to be pushed onto the client.

Would you care to make a proposal?

Regards,
  Derek

JM5:

I do agree that we don't want to replicate the whole 3270DS spec in
the TN3270E spec, I am well aware of it's size.  However I am aware of
customer problems that I believe have arisen by the improper
implementation of the ENTER RETRY in a TN3270E client.  With the work
being done now on keyboard management, direction handling I would hope
we could clean up this implementation as well now that all the
information is at least available for use by the clients.  Maybe we
just leave this item as a value add for any client that wishes to
emulate a SNA connection better than their competitors.