TN3270E RFC - Reply (fwd)

Bill Kelly <kellywh@mail.auburn.edu> Mon, 19 July 1993 19:18 UTC

Date: Mon, 19 Jul 1993 14:04:03 -0500
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Kelly <kellywh@mail.auburn.edu>
Subject: TN3270E RFC - Reply (fwd)
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9307191518.aa13002@CNRI.Reston.VA.US>

Third (and final) forwarded message...

-Bill

---------- Forwarded message ----------
Date: Mon, 19 Jul 93 19:23:54 +0200
From: azi <rndi!azi@uunet.UU.NET>
To: uunet!mail.auburn.edu!kellywh@uunet.UU.NET
Subject: TN3270E RFC - Reply

Bill,

Thanks for the quick response. Regarding the SCS data for 3270 terminals:

Indeed I meant the SSCP-LU session ,which does not use the 3270 datastream
but SCS characters, and is infact SCS data stream. There are several
solution to avoid the need for SSCP-LU session (the "USS") in TN3270 products -
automatic logon is one of them. We have a product - GATELINX 1000
which sends to the user (in a 3270 formatted screen) a list of
applications - and the user chooses the one he needs.

But using the 'SCS-DATA' data_type to indicate SSCP-LU session can solve both
the  session establishment (by using the USS mechanism) and the SYS-REQ.
The immediate result will be that TN3270 client will operate exactly as
normal 3270 terminals.

This ofcourse will work only for SNA TN3270 servers.

B.T.W. Why didn"t you take the SNA RH asis for the header ? It surly contain
all the information, and even shorter...... It will save the server
the need to encode and decode the 'RH' the the TN3270E header.

Fill free to post everything to the list,

Elazar (Azi) Ronen ,RADLINX

TN3270E RFC - Reply (fwd) Bill Kelly