SSCP-LU session and SYS-REQ

azi <rndi!azi@uunet.uu.net> Thu, 22 July 1993 10:57 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00711; 22 Jul 93 6:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00707; 22 Jul 93 6:57 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa01506; 22 Jul 93 2:55 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 7115; Thu, 22 Jul 93 02:32:36 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 7110; Thu, 22 Jul 93 02:32:30 EDT
Date: Thu, 22 Jul 1993 09:23:05 +0200
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: azi <rndi!azi@uunet.uu.net>
Subject: SSCP-LU session and SYS-REQ
X-To: uunet!list.nih.gov!tn3270e@uunet.UU.NET
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9307220255.aa01506@CNRI.Reston.VA.US>

Peter ,

>I'm still waiting to see exactly how you want to use SCS-DATA to implement
>the SYSREQ-LOGOFF sequence.  The only thing I can think of is the
>following:

>  - as the draft currently states, the user presses SYSREQ, whereupon the
>    client sends Telnet AO, and the server enters "suspended mode" for the
>    session

>  - your modification would add that if the user types any characters and
>    presses Enter, the client should send that to the server with a header
>    in which the DATA-TYPE flag is set to SCS-DATA

>Other than that, the method in the draft would remain the same.  Is this
>what you have in mind?  It seems reasonable to me.  In fact, I'll be the
>first to admit that the draft is vague about the transmission of LOGOFF -
>it says nothing about the header flags, NVT-DATA -vs- 3270-DATA or anything.

I am trying to change the way SYS-REQ is handled to a standard SNA method. Let
me describe how it is done in 3174/3270 SNA terminals:

- The user presses the SYS_REQ key.
- The terminal/controller switches to the SSCP-LU session
- All the data typed by the user, is sent , as SCS character stream on the
  SSCP_LU session (local address 0 in the destination TH field)
- VTAM (using the USS mechanism) handles the request.(sends UNBIND etc).
  The server (in this case the 3174) does not do something special - VTAM
  handles everything.

Emulating that, by indicating the SSCP-LU session as 'SCS' session (just
an indication for that matter) will notify the server which is the session
that the client uses now. In fact, we could achieve the same result by adding
another byte to the header - session id. 0 will be the SSCP-LU session
other value will be the LU-LU session. But the SCS indication could be used
since it is not used in terminal sessions, and it is a nice description
of the data. Telnet AO message is not needed.

Other immediate result will be handling of all the USS option, including
logon requests. No more 'automatic logons' 'self generated application menu' or
usage of a VTAM session manager (unless it is needed for other reason).
The client will look like any real terminal. It's also simplifies the
customization of a server and smooth the migration from IBM coax
devices to TCP/IP clients.

Just one limit - only SNA servers. But the RFC'S method also ignore NON SNA
servers.

Elazar (Azi) Ronen, RADLINX