John >> Doesn't the LU-SSCP session use SCS rather than 3270 buffer orders?
When the environment is pure SNA - Oh happy days - the text on the SSCP- LU session was required to be the SNA Character String (SCS). This was so even when the device normally supported the 3270 data stream. However, the TN3270E RFC - and this thread is all about TN3270E - take a peek at the original post, in defining how the TN3270E server and the TN3270E client should simulate the USS command and message flow over the TN3270 server to TN3270 client connection, allows not only SCS but also 3270 data stream. The original question could have been more technically correct if it had been couched the other way round, perhaps more as "Since the TN3270E server acts in a manner very similar to the VTAM LU simulation logic, shouldn't it always be just the 3270 data stream and not SCS?" The reason that VTAM permits USS messages to be defined with the 3270 data stream is that, for those device configurations where the 3270 data stream is required, such as with the "non/pre-SNA" channel-attached 3270, VTAM necessarily passes the data stream, whether it is to be treated as flow on the SSCP-LU session or the eventual LU-LU session, through some LU simulation logic.[1] The LU simulation logic acts in a manner similar to the TN3270E server and converts the USS commands into a format which can then be further handled by VTAM as if it was a formatted SNA INIT type request. As was also mentioned recently in this thread, this is one of the least troublesome tasks out of the very many undertaken by the VTAM SSCP function. The VTAM developers could have added the function to the LU simulator to work with SCS in addition to the 3270 data stream. However, 3270 devices defined as "non/pre-SNA" devices would not have known what to do with it since, at the very least, it would not have the "command" and "write control character" prepended to the data stream. All of this has nothing at all to do with the mode table entry associated with any eventual session and not only because the USS command is needed first in order to specify - even if by default - what the mode table entry name should be! What you may have in mind is the possibility to specify two USS table names in the USSTCP statement, the first using messages defined with the 3270 data stream and the second using messages defined with SCS. The first name is chosen based on the TN3270 client being capable only of the TN3270 protocol level and the second name is chosen based on the TN3270 client being additionally capable of the TN3270*E* protocol level. If there is no second name, the TN3270E server and client are required to be clever enough to work with the 3270 data stream and thus can use the table with the first name. - That's an interesting suggestion that a LINEMODE TELNET connection could be supported with USS processing. Unfortunately, the possibility to use USS processing with the TN3270E server came after I had test systems to play with or I would have spotted this apparently missing function and made sure it really was missing. The Communications Server Configuration Guide says nothing about USS and LINEMODE. Of course, if USS processing were to be supported, the format of the table would need to be SCS or, just possibly, the formatting used for an NTO device (SSCPFM=USSNTO). But, unless anyone has information to the contrary, this is all idle speculation. - >> Aren't the USS messages actually sent in an interim LU-LU session? > I thought that "by definition" the USS messages under discussion originate at the SSCP. Take a look at RFC 2355. Probably what was meant here is that, the TN3270E client is prepared for the use of 3270 data stream in the USS flow by means of a TN3270E "BIND" followed by a TN3270E "UNBIND" when the USS flow is complete. This may be described - by some stretch of the imagination - as "an interim LU-LU session". The SSCP "sees" nothing of these shenanigans! Here's the text of a handy "Usage note" from the description of the USSTCP statement: <quote> If an SCS format USS table is specified, it is used for all TN3270E connections. Non-TN3270E connections continue to use the 3270 format USS table. If no SCS format USS table is specified, all connections use the 3270 format USS table. In this case, a BIND/UNBIND is sent to the TN3270E client before/after USS processing. </quote> Chris Mason [1] This is all laid out in Chapter 11, "Programming for the IBM 3270 Information Display System". The purpose of the chapter is explained in the first paragraph: <quote> This chapter describes VTAM application programming for sessions that use LU type 0 protocols. Other 3270 protocols (for example, for LU types 1, 2, and 3) are not described here; refer to the 3270 manuals for these protocol descriptions. </quote> ---------------------------------------------------------------------- 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
