Subject: Re: TN3270E SSCP-LU Response Questions, more

From: "Burton C. Gearhart" <[email-masked]>
Date: Wed, 6 May 1998 16:39:14 -0500

I am not trying to trying to recall the draft, and would be happy to
work on contributions in this area.
_______________________________________
Burt Gearhart  [email-masked]
/__________________________________
Applied Computer Technology  972.271.6550     3270, 5250, RJE, APPC,
APPN
Garland, TX USA         FAX: 972.271.6466                    SNA &
TCP/IP
http://www.acomtech.com/act                 Testing for
Tomorrow...Today!
_____________________________  Conformance, Load/Stress with SDTF
and ITF

/____________________________________________

-----Original Message-----
From: Michael Boe <[email-masked]>
To: Burton C. Gearhart <[email-masked]>
Cc: Ed Bailey <[email-masked]>
Date: Wednesday, May 06, 1998 4:21 PM
Subject: Re: TN3270E SSCP-LU Response Questions, more

> Do you know the reasons or background as to why the
> SSCP-LU responses don't work exactly like SNA and the 3174?
>
> 10.5.1 Background
>
>          In SNA, there is a session between the host application
> (the
>          PLU, or Primary Logical Unit) and the TN3270E server
>          representing the client (the SLU, or Secondary Logical
> Unit).
>          This is referred to as the PLU-SLU session, and it is the
> one
>          on which normal communications flow.  There is also a
> session
>          between the host telecommunications access method (the
> SSCP, or
>          System Services Control Point) and the SLU, and it is
> referred
>          to as the SSCP-LU session.  This session is used to carry
>          various control information and is normally transparent
to
> the
>          user; normal 3270 data stream orders are not allowed in
> this
>          data.  For more information, refer to [7].
>
>       10.5.2 TN3270E Implementation of SYSREQ
> .....
>          While the connection
>          is "suspended," any data messages exchanged between the
> client
>          and server should have the DATA-TYPE flag set to
> SSCP-LU-DATA;
>          the data stream will be as defined in [7], specifically
the
>          section entitled "Operation in SSCP-SLU Session."
>
> Now going to the 3174 Functional spec.
> "The 3174 supports FM profile 0. Immediate control and immediate
> response modes are followed, and all requests are treated as
> definite response requests."
>
> The above implies that the RFC really implies that responses are
to
> be used
> maybe the RFC needs some clarification.
>
> What do you think?

1) Section 10.5.2 specifies that it is only the datastream (not the
TH/RH
control information) whose definition is being punted to the 3174
Functional
Spec.

2) There's no claim made in the RFC that TN3270E client is now the
SNA SLU
endpoint.

IMO, you haven't presented any information that substantially
weakens the
TN3270 (ver2) spec as a protocol standard. So I'd be very unwilling
to recall
the draft from IESG consideration as a Draft Standard.

That's not to say that we shouldn't fix this.  There's another draft
in the
works that extends TN3270E.  It's raison d'jtre is to fix the
cdi/bracket
problem...but that document would also be the right place to do this
stuff.

For instance, you could define an optional FUNCTION that
overrides/extends
certain pieces of the basic TN3270E behavior.  In particular, a new
FUNCTION
bit could be defined that "enforces" end-to-end SNA behavior on the
server and
client: that definite-response flows MUST flow e2e, that client
cannot respond
to a request until it has done what would have been done in the SNA
world, etc.
I feel that this would be valuable to organizations wanting
assurance that what
the behavior of their TN3270E clients is measurable in much that
same way as
they measure their remote-SNA 3270 client behavior (wrt
response-time,
semantics of response, etc). A connection which negotiates this bit
guarantees
that the session operates the same as a remote-SNA session would
(Burt, you
gotta say that testing compliance for this FUNCTION would be right
up your
alley :-).

Would you be interested in contributing something along these lines?

/msb

ps, I think this conversation probably belongs on the tn3270e
listserv.  If you
think the content is appropriate, could you copy the list on your
response?

>
> _______________________________________
> Burt Gearhart  [email-masked]
> /__________________________________
> Applied Computer Technology  972.271.6550     3270, 5250, RJE,
APPC,
> APPN
> Garland, TX USA         FAX: 972.271.6466                    SNA &
> TCP/IP
> http://www.acomtech.com/act                 Testing for
> Tomorrow...Today!
> _____________________________  Conformance, Load/Stress with SDTF
> and ITF
>
> /____________________________________________
>
> -----Original Message-----
> From: Michael Boe <[email-masked]>
> To: Burton C. Gearhart <[email-masked]>
> Cc: Ed Bailey <[email-masked]>; Michael Boe <[email-masked]>
> Date: Wednesday, May 06, 1998 1:14 PM
> Subject: Re: TN3270E SSCP-LU Response Questions
>
>
> >> We have had questions from our test suite customers about
> >> SSCP-LU responses here is what we think......
> >>
> >> Remember "when in Rome do as the Romans do", i.e. when doing
> SSCP-LU
> >> traffic do as SNA does when the RFC is non-specific.
> >> SNA has the following 3 session types which each use FM and TS
> >> profiles to describe their behavior.
> >> Session   FM Prof   TS Prof
> >> SSCP-PU      0         1
> >> SSCP-LU      0         1
> >> LU-LU        3         3
> >>
> >> The SSCP-LU FM Profile 0 says, 'primary/secondary chains
indicate
> >> definite response'.
> >>
> >> Therefore: we believe that outbound data from the server
> >> will have SSCP-LU-Data set in the data type field and the
> >> Response Flag set to Always.
> >
> >Uh....one would think that if the client negotiated use of the
> RESPONSES
> >function, then the RESPONSE flag can be set.  Unfortunately, the
> RFC implies
> >that this is not possible:
> >
> >      8.1.3 RESPONSE-FLAG Field
> >
> >         The RESPONSE-FLAG field only has meaning for certain
> values of
> >         the DATA-TYPE field.  For DATA-TYPE field values of
> 3270-DATA
> >
> >
> >
> >Kelly
> [Page 16]
> >
> >Internet Draft            TN3270 Enhancements
May
> 1997
> >
> >
> >         and SCS-DATA, the RESPONSE-FLAG is an indication of
> whether or
> >         not the sender of the data expects to receive a
response.
> In
> >         this case the possible values of RESPONSE-FLAG are: ....
> >
> >So no: the server is not allowed to set the RESPONSE-FLAG on
> SSCP-LU data
> >(actually, the RFC implies that the client should ignore the
> RESPONSE-FLAG
> >field for SSCP-LU data, but that's clearly unworkable in the real
> world since
> >Apertus is expecting a response). As I mentioned in an earlier
note
> (to
> >Diane?), the client should respond if the server sets the
> RESPONSE-FLAG (in the
> >spirit that an implementation should be conservative in what it
> sends, and
> >liberal in what it receives).
> >
> >I understand that this is a limitation of the RFC wrt
> SNA-adherence, but it
> >would seem to be a fairly minor one. That is, I don't really find
> that it gets
> >in the way of end-to-end functionality.  Do you disagree?
> >
> >btw, the RFC very specifically does not force the server to set
the
> >RESPONSE-FLAG to a non-zero value. So even if the RFC allowed the
> RESPONSE-FLAG
> >to be set on SSCP-LU traffic (or LU-LU traffic for that matter),
> nobody can
> >assume that a non-zero value will be present....
> >
> >Have either of you contacted Apertus/CNT/Brixton about this
> problem?
> >
> >/msb
> >
> >
> >>
> >> The response coming back will look like:
> >> Data Type Rsp-Flag   Data   Meaning
> >> SSCP-LU    0         None   Positive Response
> >> SSCP-LU    1         1 Byte Negative Response with 1 byte
> indicator
> >>
> >>
> >> Question on SSCP/LU response implementation
> >>
> >> >>>  RFC 1647, page 16, section 8.1.3 states that the
> RESPONSE-FLAG
> >> >>Field ..
> >> >>>
> >> >>>     "only has meaning for certain values of the DATA-TYPE
> field.
> >> >>For the
> >> >>>DATA-TYPE field values of 3270-DATA and SCS-DATA, The
> >> >RESPONSE-FLAG
> >> >>is an
> >> >>>indication of whether or not the sender of the data expects
to
> >> >>receive a
> >> >>>response.  ..."
> >> >>>
> >> >>>  We have just changed our client to only send RESPONSEs
when
> the
> >> >>outbound
> >> >>>data is of type 3270-DATA and SCS_DATA with ALWAYS-RESPONSE
or
> >> >>>ERROR-RESPONSE flag set in compliance with the above.   But
we
> >> >have
> >> >>found
> >> >>>that Apertus is sending  SSCP-LU-DATA with ALWAYS RESPONSE
> set.
> >> >>This
> >> >>>results in failed connection.  Both Attachmate and
Hummingbird
> >> >>clients
> >> >>>reply with a RESPONSE DATA-TYPE inbound message.
> >> >>>
> >> >>>  The question is, shall we code against the RFC?  What
should
> we
> >> >>all be
> >> >>>doing?
> >> >>>
> >> >>>  Thanks in advance,
> >> >>>    Dianne R. Kelly
> >> >>>
> >> >>>
> >> >>>Dianne R. Kelly                                 email:
> >> >>[email-masked]
> >> >>>FTP Software                    phone:  978-684-6873
> >> >>>2 High Street                   fax:       978-684-2005
> >> >>>No Andover, MA  01845           www:    http://www.ftp.com
> >> >>>
> >> >>
> >>
> >>
> >
>