Re: SSCP-LU session and SYS-REQ

[Bill Kelly <[e-mail]>]

On Thu, 22 Jul 1993, azi wrote:

> 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.

This is Bill, not Peter (he commented on an earlier posting).  I think
most of us have an understanding of the basics of the use of the SYSREQ
key as it functions to "toggle" ownership of the display and keyboard
between the PLU-SLU session and the SSCP-LU session.

>
> 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.

I have repeatedly asked you to describe exactly how you intend to
implement the SYSREQ-LOGOFF sequence.  You continue to state that we don't
need AO, and further that your method solves all the USS command issues,
but I am still waiting for you to post *specifics*.  Is there a key that
the user is told maps to SYSREQ?  If so, what happens when it is pressed?
Is anything sent to the server immediately?  If so, what?  If not, what is
next?  How do you (or do you?) intend to associate a USSTAB with an
application LU at the host-based server?  I quote from our chairman:

>There will be two sorts of responses to Bill's draft:
>
>1       Comments and Questions - these will stimulate ideas, but might not
>        change the draft.
>
>2       Text changes - This is where someone submits the actual rewording of
>        a section in the draft.  These are taken seriously.  If you take the
>        time to write out your ideas in a format that can go into an RFC,
>        then you have given a lot of thought to your ideas.
>
>I have seen this in other lists.  We can do it too.

I am not trying to be stubborn here.  I am simply waiting for you to post
some suggested text for the RFC that is *specific* and can be read and
analyzed by the group.  I have posted my guesses as to *exactly* how you
want things to work.  I do not intend to spend any more time doing that.
Please either post text suitable for inclusion in the RFC or drop the
subject.

Thanks,
Bill

Bill Kelly               phone: [phone]
Auburn University     Internet: [e-mail]