George I was going to say "To be sure you have understood this, be sure to read carefully the description of the TELNETDEVICE statement in the Communications Server (CS) IP Configuration Reference manual." but I'm not really sure that helps. I even took a peek at the Configuration Guide manual - which is supposed to have the "mission" to cover tricky topics and, really - apart from being misleading - that doesn't help either.
So, since you have been so confused over the topic, here's a little tutorial on session initiation with the CS TN3270E server - for TN3270 sessions, that is, excluding so-called "linemode" - and the role of the TELNETDEVICE statement in that session initiation process. First we'll deal with the table of codes and mode table entry names as held as an array, logically or indeed physically, in the TN3270E server storage. This array is initialised according to the famous Table 33 in the description of the TELNETDEVICE statement in the CS Configuration Reference manual. Recalling that we are restricting the discussion only to TN3270 sessions, I can say, with one exception to be covered later, that the mode table entry names are all to be found in the IBM-supplied mode table ISTINCLM as described in Appendix A of the CS SNA Resource Definition Reference manual. - If you want to change one of the mode table entry names so that it refers to a customised mode table entry in an installation-specific mode table, then you need to define the appropriate TELNETDEVICE statement to override the default mode table entry name with the installation-specific mode table entry - and - you need to set up an installation-specific mode table module named in the MODETAB operand of the APPL statement which the TN3270E server will use in order to support the SNA session initiation. - If you want to change one of the mode table entry names so that it refers to a mode table entry different from the default mode table entry but still one to be found in ISTINCLM, then you need to define the appropriate TELNETDEVICE statement to override the default mode table entry name with the other mode table entry. - If, for the purposes of documentation, you want to emphasise which mode table entry from ISTINCLM will be used in your installation as a result of the way you have prepared the customisation of the TN3270 client emulators, then you can define the appropriate TELNETDEVICE statement with the default mode table entry name. The array consists of three columns and a number of rows. The three columns are (1) the code, (2) the mode table entry that is used when "TN3270" protocols are used and (3) the mode table entry that is used when "TN3270E" protocols are used. There is a row for each of the possible codes. The table in storage is changed as follows according to the TELNETDEVICE statement prototypes: TELNETDEVICE code entry1,entry2 "code" matches a code in column 1 which selects a row. Then both entry1 replaces the default entry in the column 2 and entry2 replaces the default entry in the column 3. TELNETDEVICE code entry1 "code" matches a code in column 1 which selects a row. Then entry1 replaces the default entry in the column 2. The default entry is column 3 is unaffected. TELNETDEVICE code ,entry2 "code" matches a code in column 1 which selects a row. Then entry2 replaces the default entry in the column 3. The default entry is column 2 is unaffected. Once the TELNETDEVICE statements have been processed, we have the table in the state in which it will *possibly* be used in order to initiate the SNA sessions to be concatenated to the TN3270 connections, "possibly" because, after all this trouble, it may never be needed! Now the TN3270 client initiates a TN3270 TCP connection. The contacted TN3270 server initiates "negotiation" in a manner covered by the examples described in section 13.4 "Examples" of RFC 2355, for example, http://www.faqs.org/rfcs/rfc2355.html The TN3270 server offers to operate with the protocols associated with RFC 2355 by proposing "TN3270E". - If the TN3270 client refuses "TN3270E", we say we are using "TN3270" protocols, see the first example. - If the TN3270 client accepts "TN3270E", we say we are using "TN3270E" protocols, see all the other examples. Also, as part of the "negotiation", a code is agreed which is supposed to describe the nature and characteristics of the TN3270 connection. If we are using "TN3270" protocols, the code is referred to as a TERMINAL- TYPE whereas, if we are using "TN3270E" protocols, the code is referred to as a DEVICE-TYPE - again, see those examples.[1] The set of codes is the same in the two cases.[2] If an Unformatted System Services (USS) table is in use - rather than the "TELNET solicitor" panel, DEFAULTAPPL statement or DEFAPPL parameter, the name of the mode table entry to be used in the SNA session can be chosen by the logic involving the use of the USS LOGON command with the consequence that the storage array defined by the TELNETDEVICE statements - default or actual - can gather dust. USS LOGON logic is used for the purposes of defining three elements involved in an SNA session setup: 1. the primary LU name (application name) - required 2. the mode name (mode table entry name)[3] - required eventually but optional at this stage 3. data - intended for use as an identification to be associated with the human end user - optional If the mode name has been specified, the logic which is necessarily used when an USS LOGON command is not used and was always used prior to the enhancement which introduced the possibility to use an USS LOGON command is bypassed and whatever the TELNETDEVICE statements - default or actual - specify is irrelevant. At the point in the processing where the TN3270 server need to use the VTAM API in order to pass parameters to VTAM which will allow the SNA INIT-type request to be passed to the VTAM SSCP mimicking the behaviour of a traditional peripheral node "device-type" secondary LU, if the mode name has *not* been specified, a decision over what value should be put into the field which contains the mode name needs to be made. This is where the logical array constituting a table build from the TELNETDEVICE statements - default or actual - comes in. And, of course, now that all the circumstances have been explained, it is simplicity itself! The TERMINAL-TYPE or DEVICE-TYPE code determined during the negotiation shortly after the TN3270 TCP connection was established is used as a means to locate a row in the logical table. Whether the negotiation determined that "TN3270" protocols or "TN3270E" protocols should be used determines which mode table entry name will be selected as the mode name. If "TN3270" protocols, the mode name is taken from column 2, if "TN3270E", from column 3. But there is a small subtlety with which to deal. Actually the subtlety has a touch of stupidity in it. If the "special" mode name "NONE" is found, it is not regarded to be a mode name but to represent 8 blanks - a mode name field in SNA is always 8 positions long padded, if necessary, with trailing blanks AFAIK.[4] At this point the REQSESS, "request session", call is made over the VTAM API and the INIT-type request is sent, internally in the case of a TN3270 server supported in the same operating system as VTAM, to the VTAM SSCP. Until this point VTAM has been involved only in that, if USS facilities are used, VTAM supplied the macros which were used in order to create the USS tables. If, because an installation's standard assembly and linkage edit job or procedure was used in order to create the USS table object module and the object module is stored in a partitioned data set previously only used in the VTAMLIB concatenation in the VTAM procedure and possibly containing "VTAMLIB" as a token, that partitioned data set needs to be accessible by the EZBTNINI program running in the installation's TN3270E procedure. When the VTAM SSCP logic processes the INIT-type request, it checks in order to see whether or not the mode name field is 8 blanks. If the field does contain 8 blanks, VTAM undertakes to find a mode name from the definitions associated with the APPL statement which applies to the secondary LU in the SNA session in the process of being initiated from which the INIT-type request logically originated. - If this APPL statement specifies a value for the DLOGMOD operand, it is used as the mode name. The mode name specified can correspond to a mode table entry in either a mode table named in a MODETAB operand or the IBM-supplied mode table ISTINCLM.[5] - If this APPL statement does not specify a DLOGMOD operand, the first entry name in the applicable mode table is used as the mode name. -- If this APPL statement specifies a value for the MODETAB operand, this is the applicable mode table and the first entry name in this mode table is used as the mode name. -- If this APPL statement does not specify the MODETAB operand, the applicable mode table is the IBM-supplied mode table ISTINCLM and the first entry name in ISTINCLM is used as the mode name. Note that all these references to the DLOGMOD and MODETAB operands are relevant *only* if the systems programmer has taken the trouble actually to create at least one TELNETDEVICE statement which includes "NONE" in the position of a mode table entry name. If no such TELNETDEVICE statement is specified, there is no role whatsoever for the DLOGMOD operand of the APPL statement. At a later stage in the session setup process, the specified mode name is used as a means to select a mode table entry - hence the frequent use of the term "mode table entry name" as the concrete entity associated with the term "mode name" - and from that mode table entry the session setup requests continue with the defined "BIND image" included. - [1] It's also perhaps helpful to provide an opinion over why the name for the code changed in RFC 2355 from TERMINAL-TYPE to DEVICE-TYPE. The TN3270 enhancements associated with "TN3270E", first introduced with RFC 1647, introduced 3270 printer support. In the world of TN3270, a "display" is called a "terminal" but now "terminal types" need to cover printers and so the terminology needed to change. Thus the TERMINAL-TYPE became the DEVICE- TYPE. QED! It's interesting to note that IBM - perhaps, more strictly the probably graduate students in the university where the original product which became "TCP/IP for VM" was created - have always used the term "device" rather than "terminal". How prescient of them! I was able to check this as far back as "TCP/IP for MVS" V2R2.1 but I can't see why it need ever have been different. [2] This isn't strictly true. The DEVICE-TYPE codes which were mandated in RFC 2355 do not bother with the "3279" display device in their set of codes whereas the TERMINAL-TYPE codes do include "3279". Thus all TELNETDEVICE statements which include "3279" cannot ever invoke the mode table entry name in the second positional parameter position. While doing the "historical research" on this topic, I noted that it was only when the "configuration" manual was reorganised into two manuals between OS/390 V2R8 to OS/390 V2R10 - there were no "communications server" changes for OS/390 V2R9 - that, for whatever reason - not excluding some objection from a customer with clout - we all know who they are!, the developers decided that, contrary to RFC 2355, the codes extended to the "3279" as well as the "3278", thereby very belatedly announcing 3279 models 4 and 5! [3] The mode table entry name or mode name can be specified in one of three ways in USS LOGON logic: 1. The mode name can have been specified as a default name to be used with the USS LOGON command used which is typically - but not necessarily - a user-friendly version of the "application name", for example "CICS" instead of "A55CICSZ". 2. The mode name can have been keyed in by the end user as part of the USS LOGON command. 3. And, since we are using PCs running a TN3270 client emulator, some scripting logic may be implementing what would, in the case of a "dumb" device, be option 2. [4] The stupidity is that when this technique to deal with not wanting a mode name to be specified was dreamt up, it was no doubt assumed that nobody would ever think to use the token NONE as a mode name. This might be a just about reasonable assumption - as long as the folk involved used the English language ... I believe my point is made. [5] The IBM-supplied mode table ISTINCLM is always available even when you have specified a value for the MODETAB operand since, in effect, mode table ISTINCLM is always concatenated after the mode table you specify. The VTAM manuals are logically incorrect when they specify ISTINCLM as the default value for the MODETAB operand. The "small print" negates the syntax diagram: <quote> If you do not supply a logon mode table for <whatever> on the MODETAB operand, an IBM-supplied default logon mode table (ISTINCLM) is used. If you specify a table, both the table you specify and the default table are used. </quote> Chris Mason ---------------------------------------------------------------------- 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
