Tony > Well, the restatement is still rather overspecified. TN3270 is a protocol, > not a particular set of client and server software, originally rather loosely specified, which has been more clearly and accurately defined over time in RFCs 1647 and 2355.
Strictly TN3270 is not a protocol but a set of "practices" built upon the TELNET protocol - I guess that's what you mean to imply with "rather loosely specified". What RFCs 1647 and 2355 describe is a formal statement of an enhanced protocol TN3270E. RFC 2355 refers to RFC 1576 as defining "traditional" TN3270 but the title of RFC 1576 is "TN3270 Current Practices". I take it from all of this that "TN3270" is the short-hand in the RFCs rather than a strict protocol. Certainly hairs are being split here! However TN3270 is most definitely a piece of (at least) server software. You need only locate chapter 15 of the CS IP Configuration Reference manual. Since the server gained TN3270E capability it has named itself the TN3270E server. I tend not to bother with the "E" which, in any case, represents an optional capability. > Obviously TN3270 servers for non z platforms are fairly rare, since there is not often native application support for 3270 data streams, but they do exist as part of commercial products. I believe that TN3270 - probably today TN3270E - servers may be regarded as mainstream products - even if a small number - since they would behave as, for example, 3174s. There existence is anticipated in RFC 2355 in, at least, the discussion of the SSCP function where they constitute what I call the "passthrough" mode of support for USS traffic. This topic has been discussed many times in this list. There is no need to insist on "native application support for 3270 data streams" for the TN3270 server! > The System z TN3270 clients for both z/OS and z/VM are a little unusual in two respects: > They are both called TELNET rather than TN3270, though they behave about like any other TN3270 client; At least for the z/OS client, TELNET is a quite correct - and so "usual" - designation for a product that behaves as a basic TELNET client as well as being able to negotiate additional function such as 3270 data stream support. I just don't get your point here! > Since they are invoked from a terminal session that is already logged in to a 3270, they don't have to remap keyboard input and screen output to a foreign platform such as dumb ASCII datastreams or the Windows presentation interface; rather, they offer a "passthrough" or "transparent" mode, and rely on the existing 3270 session to understand the EBCDIC datastream with only the minimal unwrapping of the TN3270 protocol that is needed. I sort-of buy this second "unusual" although there is a mapping from 3270 data stream to whatever technology presents the image on the monitor at some stage in the path from the arriving data stream to the signals sent to the monitor and vice versa. Whether there is no involvement or some involvement by the software which constitutes the TN3270 client product is of no great concern to users - although a developer would have an intense interest in such a point! > There is also no need to bring SNA into the picture, ... SNA was mentioned only because the OP seemed to be thinking in SNA terms. When accessing legacy z/OS applications SNA becomes relevant to TN3270 servers in one of 3 ways: 1. As with the z/OS CS IP TN3270E server, the server concatenates a TN3270 connection to an SNA session to a primary LU application using the VTAM API acting as the secondary LU and uses "formatted" requests on the SSCP-LU session. 2. The TN3270 server concatenates a TN3270 connection to an SNA session to a primary LU application using the platform SNA API acting as the secondary LU and, typically, uses "unformatted" requests on the SSCP-LU session. 3. The TN3270 server concatenates a TN3270 connection to a pre/non-SNA 3270 channel appearance. VTAM supports this appearance and converts it into an SNA session to a primary LU application using VTAM's non-SNA 3270 LU simulator acting as the secondary LU. > Although the z/OS implementation of a TN3270 server does map the TN3270 session to an SNA one, this is not logically necessary. ... as indicated by case 3 since the channel appearance can be to a function other than the VTAM simulator. Chris Mason On Thu, 26 Jun 2008 13:26:08 -0400, Tony Harminc <[EMAIL PROTECTED]> wrote: See extracts above ---------------------------------------------------------------------- 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
