Shmuel, > Is USS part of the SSCP or is it a separate service?
USS is part of the VTAM playing the role of the SSCP. The VTAM SSCP allows SSCP-LU flow to consist of formatted system services, SSCPFM=FSS, or unformatted system services, SSCPFM=USSxxx, where xxx is 3270, SCS or NTO. It's important to know that an LU statement requires a specification for the SSCPFM parameter - even if default. A LOCAL statement assumes SSCPFM=USS3270 and an APPL statement assumes, in effect, SSCPFM=FSS. If FSS applies the inbound command requests are according to the SNA Formats manual. If USSxxx applies, the requests are (supposed to be) user-friendly commands which correspond to (I guess I'd better say) a subset of the formatted requests and their options which VTAM kindly converts to the equivalent formatted request before processing them as formatted requests. If FSS applies the response to the inbound command requests are positive or negative responses. If USSxxx applies, the responses to the inbound command requests are (again supposed to be) user-friendly messages constructed by VTAM and corresponding to the formatted response (which is also returned the last time I used Session Monitor to check). In both cases, if the command was accepted, VTAM does what it was asked - to the best of its ability. In the case of USSxxx, VTAM uses the supplied USS table and the default table, or only the default table if no USSTAB operand value is provided, in order to convert the inbound command requests and select the outbound messages based on the appropriate response - and what was wrong about the command if appropriate. It may be of relevance in understanding all this that I used to think that a nonprogrammable machine such as a 3274 always used SSCPFM=USSxxx while a programmable machine always used SSCPFM=FSS. Thus I was surprised when asked to help with a word processing machine in the early '80s which used FSS for programmed LUs but used SSCPFM=USSSCS for 3270 emulation - sensible I suppose. (Maybe the 3790 3270 emulation required SSCPFM=FSS and my ideas became inappropriately fixed.) You need to read section 10.5 The SYSREQ Function of RFC 2355 in order to know why this discussion is taking place. RFC 2355 insists on one type of TN3270E server, a programmable computer acting as a TN3270E server "downstream" and a programmable node with an SSCP-dependent PU and SSCP-dependent LUs upstream. Such a computer can act as a "passthrough" node for USS commands and messages. If the TN3270E server logic is not supported by such a computer the RFC insists that the only other type can only send an UNBIND in order to logoff the session. Thus it specifies a "logoff" command and a message response if the command entered is not an acceptable version of the characters "logoff". This happens to correspond to the equivalent action with the default USS table. As we all know CS IP can use the VTAM USS table - accessible in its own libraries - in order to support the equivalent of VTAM behaviour while there is no LU-LU session in place, in other words, at "logon" time. In seems the developers are browbeaten by the RFC and, when there is an LU-LU session in place and the SysRq key must be used, in other words "logoff" time, they assume the dumb role rather than what I called the "passthrough" role as described above. I hope that explains > Passthrough of what? Why? The "Why?" is to be more consistent in support of the VTAM USS table. A complete VTAM USS table tells them how to do it, they just need to have the courage to do it. As you appreciate, TERMSESS has all the options they need. And USS messages, specifically USS message 5, become available after the SysRq key is used. I hope you appreciate my use of the verb "behave". I am talking about yet another *emulation* at "logoff" time, much the same emulation as is already used at "logon" time. Chris Mason ----- Original Message ----- From: "Shmuel Metz (Seymour J.)" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, 20 January, 2006 6:34 PM Subject: Re: TN3270 Question > In <[EMAIL PROTECTED]>, on 01/20/2006 > at 03:44 AM, Chris Mason <[EMAIL PROTECTED]> said: > > >But, but, but a VTAM application can access SSCP-LU functions for > >session termination through the TERMSESS macro. What it cannot do is > >define itself to VTAM as being able to send USS commands to the SSCP > >and receive USS messages. > > Is USS part of the SSCP or is it a separate service? Normally you > communicate with the SSCP by sending a formatted Request/Response (RR) > unit, or issuing an equivalent VTAM macro. What do you wan to do that > can't be done with an appropriate formatted RR unit? > > >Combining TERMSESS capability and USS table support, the same USS > >service can be offered to a TN3270E client as TN3270E server logic > >with USS passthrough capability does also for LOGOFF support. This > >would incidentally necessarily include support for USS messages - > >including the famous USS message 5. > > Passthrough of what? Why? > > >My proposal is that the CS IP TELNET server should behave as if it > >was also for LOGOFF support. > > That doesn't require passthrough of USS commands. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > ISO position; see <http://patriot.net/~shmuel/resume/brief.html> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
