Subject: Comment to "FMH support for TN3270E"

From: [email-masked]
Date: Wed, 10 Dec 1997 16:51:50 +0100

Response to "FMH support for TN3270E", by Derek W. Bolton.

When reading your draft some questions came to my mind. My concern is
specially the client part, and the client-server communication.

I will use the same part numbering as in your draft.

In this note the word data means the data portion of the TN3270E
package, without the TN3270E header.

1.4 Existing support of FMHs in "TN3270"
----------------------------------------

If I understand this correct you state that without adding to TN3270E
the server supports "silent FMH support", i.e. the server is
transparent and merely operates as a mailman between the client and
the host application. We have observed when trying this on a MS SNA
Server 3.0, that the server refuses our IPDS ACK reply (inbound data)
on the first IPDS command.
Is the server expecting to find a FMH as the first 6 bytes of the
data portion? If this is so what should the FMH be ( 0601008B6000 ?).
According to IBM's Pageprinter 3812 manual, this inbound data should
not be preceeded by an inbound FMH structured field.

2.4.3 SCS-DATA from client
--------------------------

Under what circumstances are the client supposed to send data with a
preceeding FMH, except from when determing IPDS capability.

host application        client

0601000B6000     -->

                 <--   0601008B6000

It seems that you expect the inbound data stream to be preceeded by
0601000B6000, and I think that is a mistake.

2.5.2 Sent FMH
--------------

Again under which circumstances are the client supposed to send
records with FMH's, except as a reply to 0601000B6000.

There seems to be some confusion about the FMH's. My interpretation
is as follows.

There are 3 types of FMH's related to IPDS we can receive.

1. Determing IPDS capability, 0601000B6000
2. Begin IPDS mode,           0601300D4000
3. Terminate IPDS mode,       0601300D2000

When the client receives Begin IPDS, there are no longer any FMH's in
the data records exhanged between the host application and the
client. All data are pure IPDS commands, replies and data.

If my interpretation is correct there dosn't seem to be any need for
the new functions and flags that you suggest in your draft.

All there is needed is for the server to be transparent and pass
along the data.

Reference: IBM Pageprinter 3812, S544-3101-00, Page 150

Best regards
Keld Stougaard

E-mail: [email-masked]
LCI Intermedium
Odinsvej 19
DK-2600 Glostrup, Denmark
Tel.: +45 43 26 02 94
Fax : +45 43 26 02 02

---

From: "Derek W. Bolton" <[email-masked]>
Date: Thu, 11 Dec 1997 09:51:09 +1100 (EST)

Keld,

Thanks for your review - most useful.

> When reading your draft some questions came to my mind. My concern
> is specially the client part, and the client-server communication.

> If I understand this correct you state that without adding to
> TN3270E the server supports "silent FMH support", i.e. the server is
> the host application.

No, even "silent FMH support" is an addition to the architecture.
There is a de facto standard for support of DBCS in Japan and Korea,
but it has not been blessed by the IETF.  When I wrote the proposal I
was not aware of any other attempts to pass FMHs through TN3270.

> We have observed when trying this on a MS SNA Server 3.0, that the
> server refuses our IPDS ACK reply (inbound data) on the first IPDS
> command.

Peter and Kasper showed us a trace of the IPDS problem.
Unfortunately, the trace was not from the start of the session, but
based on what I saw I concluded that the problem was nothing to do
with FMHs.  I expect that an FMH did flow, from Host to client,
earlier in the sequence.  The data I saw was not an FMH at all - it
was an IPDS header.  I cannot comment on why the server rejected it.

> data portion? If this is so what should the FMH be ( 0601008B6000 ?).

You mean, from the client?  No, it does not expect an FMH - that's the
point.  The problem with "silent FMH support" is that the receiver
must deduce the presence of an FMH either by context (it is the next
thing expected) or by value.

The client may be able to use context.  The server, having less
understanding of the datastream, must use value.  Clearly this will
only work for a restricted set of FMHs - those that don't look like
real data.  Moreover, it is necessary to list exactly those FMHs which
the server should recognise and handle.  (I.e., turn on the FMH flag on
the inbound RU.)

0601000B6000 is the only inbound FMH that I was aware of in SNA 3270.
It introduces a message in 3270DS.

> not be preceeded by an inbound FMH structured field.

Does that mean there are definitely no inbound FMHs for IPDS?  If so,
I believe my proposal will work for IPDS as well as for DBCS.
Anyway, thanks for the manual reference.  I'll get a copy.

> 0601000B6000, and I think that is a mistake.

Now I'm confused.  Are you saying that the above flow is what
happens in IPDS, or is it your guess as to what I was proposing?
If it is the actual flow, how about changing the proposal to
recognise 060100xB6000 as an inbound FMH?  Would that handle
DCA, I wonder?

> records with FMH's, except as a reply to 0601000B6000.

That's probably the only one.

> 3. Terminate IPDS mode,       0601300D2000

I think the proposal would allow all these to be sent.

> If my interpretation is correct there doesn't seem to be any need for

> All there is needed is for the server to be transparent and pass

If IPDS and DBCS are the only reasons for passing FMHs over TN3270
then the silent support, as defined in the proposal or as extended
to allow 060100xB6000 inbound, is enough.

That does leave two questions, though:

1. Possible futures:
- DCA support
- LUT0 support
- LUT6.2 support

2. Sense codes

I still think we need to start allowing SNA sense codes from the
clients.  I'll see what the 3812 sends.

> Reference: IBM Pageprinter 3812, S544-3101-00, Page 150

I'll send out an updated proposal after I've read it.

Thanks,
  Derek