Re: Comments to the TN3270E RFC (fwd)

Bill Kelly <> Mon, 19 July 1993 19:16 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa01016; 19 Jul 93 15:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01012; 19 Jul 93 15:16 EDT
Received: from by CNRI.Reston.VA.US id aa12898; 19 Jul 93 15:16 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 8047; Mon, 19 Jul 93 15:15:31 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 8043; Mon, 19 Jul 93 15:12:15 EDT
Date: Mon, 19 Jul 1993 14:00:46 -0500
Reply-To: IETF TN3270E Working Group List <>
X-Orig-Sender: IETF TN3270E Working Group List <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Kelly <>
Subject: Re: Comments to the TN3270E RFC (fwd)
X-To: TN3270E list <>
To: Multiple recipients of list TN3270E <>
Message-ID: <9307191516.aa12898@CNRI.Reston.VA.US>

Forwarded item #2

After thinking about it some more, I'm not sure my statement about sites
being able to customize the LOGOFF USS command is true.  It looks to me as
if that might be a carved-in-stone entry in the USS table?  Has anyone
found a need to have this command available in a language other than English?


Bill Kelly               phone: (205) 844-4512
Auburn University     Internet:

---------- Forwarded message ----------
Date: Mon, 19 Jul 1993 07:54:19 -0500 (CDT)
From: Bill Kelly <>
To: azi <rndi!azi@uunet.UU.NET>
Subject: Re: Comments to the TN3270E RFC

Hi Azi,

Thanks very much for taking the time to comment!  It appears your note was
sent directly to me, rather than to the list?  If you don't mind, I'd like
to post your comments on Bind image and when the server should establish the
PLU-SLU session to the list (along with some comments from me).

On Mon, 19 Jul 1993, azi wrote:

> Bill,
> I read the July 1993 edition of the TN3270E RFC and I have the following
> comments:
> 1. In section 10.3 - Why is the BIND image limited to display terminals ?
>    Why can't printer emulation use this function ?

My intention is that clients representing both terminals and printers can
use this function (as long as the server is SNA-based); perhaps the
confusion results from my terminology.  I purposely used the term "SNA 3270
devices" instead of "SNA 3270 terminals" in order to include both terminals
and printers.  "3270" is not intended to imply terminals only, and
throughout the document I refer to the "3270 family of devices" to
include both terminals and printers.  I am hoping that the use of this
terminology is made clear in the Abstract?  If not, perhaps I should
explicitly define my use of the term.

> 2. Why there is no support for SCS under terminals ? This will solve the
>    SSCP-LU session, not supported in current TN3270. This will also
>    give immediate solution for the SYS-REQ. The fact that the client
>    sends SCS data implies that the user pressed the SYS-REQ key.

I'm not sure we're talking about the same thing here.  I've never seen a
reference to SCS data (the SNA Character Stream) that applies to anything
other than a printer in an LU1 session.  Your last sentence makes me think
you're referring to USS (Unformatted Systems Services) data, which is indeed
exchanged on the SSCP-LU session after the user presses SYSREQ.  The
support for USS data in TN3270E is limited to the commonly used USS
command "LOGOFF", and in English only - I've been wondering if we couldn't
make that configurable at the server, given that installations can
customize their USS tables to use whatever they want for the equivalent of

If I've missed something completely about SCS data, could you point me to some
IBM documentation that might clear things up for me?

> 3. Section 10.3 - Whatif the BIND data is not received by the server at
>    the time of request ?
> 4. When should the server create the LU-LU session with the SNA host ?

Excellent point(s).  It seems to me that the server must wait until after
negotiation of both device-type and TN3270E function support is complete
(it would need information from both subnegotiations in order to know what
Bind it should accept on behalf of the client).  I need to put wording to
that effect somewhere in the document.

As to what happens if the client requests the Bind-image after negotiating
support for that function but before the server has established the PLU-SLU
session, I suppose we could do one of two things:

 - simply have the server delay its response; after all, it won't be
   sending any other 3270 data until after the SNA session is established
   (it probably wouldn't be sending any other TN3270E commands after
   subnegotiation is complete and before sending the Bind-image, either)

 - add a new value to the REQUEST-FLAG field, saying that Bind-image is not

>    Where is the application LU name is taken from ? (assuming that SSCP-LU
>    session is not supported).

If I understand your question correctly...

The choice of the initial host application with which the server should
establish a session would work the same way as it does today.  On IBM's MVS
TCP/IP, this is done through the DEFAULTAPPL keyword in the PROFILE.TCPIP
dataset; for TCP-SNA gateways such as OpenConnect's and McData's, I presume
this is done with the VTAM LOGAPPL keyword on each LU that the gateway
emulates.  Frequently, this initial application is a "network solicitor"
or "menu" application.

Thanks again for your comments!  Would you mind if I posted this to the list?


Bill Kelly               phone: (205) 844-4512
Auburn University     Internet: