There is rather a lot of confusion throughout this thread. Even after much
pouring through it in order to try to work out what the problem was I'm
still not really clear what Ronald was trying to do and what his problems
are trying to get there.
The next point to make is that I used to teach this stuff and the last time
I did anything with the MVS TELNET server was 4 years ago and the use was
incidental to a project not directly involved with TELNET. Please understand
that I can only go now by what is in the manuals since I don't have systems
at hand to check things out like I used to.
Let's have a diagram to help show what is relevant to what:
VTAM SSCP
A
! SSCP-LU session
V
VTAM application <-----------------> TELNET server <----------------->
TELNET client
primary LU SNA LU-LU session secondary LU TELNET connection
TCP/IP
Note: It may well be that this diagram will be distorted as received. In
order to be able to view it properly, you can copy to a .txt file and
convert to a fixed width font, such as Courier, if necessary.
A mode table from which are derived mode table entries such as NSX32702 and
SNX32702 is stored in a library which the VTAM program running the relevant
SSCP entity can access. Such a mode table entry is offered to the primary LU
in the form of the suggested content of the BIND request to be sent to the
secondary LU.
The SNA USS table is used to present messages at the display component and
accept commands from the keyboard component of a "device-type" necessarily
secondary LU and the USS table it is stored in a library which the VTAM
program running the relevant SSCP entity can access. Such USS table data are
exchanged with the secondary LU over the SSCP to LU session. Such USS table
data will be exchanged only with an LU which is defined to support
unformatted system services (USS) rather than formatted system services
(FSS). This means that the data flow over the SSCP-LU session is in the form
of character strings appropriate to a human operator rather than sets of
fields with binary numbers and bit values in addition to the character
string parameters in a form
appropriate for a program.
The requests sent over the SSCP to LU session for the TELNET server acting
as secondary LUs logically concatenated to TELNET connections are FSS
requests. The TELNET secondary LUs are defined with APPL statements and, in
effect, for such SNA sessions, the appropriate SSCPFM specification is FSS.
(In fact there is an SSCPFM operand which is valid on an APPL statement but
it applies only to "program operator" requests which have nothing to do with
what a TELNET server does. The same applies to the USSTAB specification on
an APPL statement.)
The USS table "borrowed" by the TCP/IP for MVS product (today called CS IP)
has moved on since I originally used it from being limited to supporting
only the first token on input and only the USS10 message on output to as
full an implementation as is possible - as far as I can see. It is used to
present messages at the display component and accept commands from the
keyboard component of the TELNET client. This "borrowed" USS table - let's
call it the IP USS table - is stored in a library which the CS IP program
running the TELNET server can access.
The use of this IP USS table has no connection with the way the SNA USS
table described above is used. The two types of USS table are connected in
that the same table can be used in both contexts and - increasingly since I
used to teach this topic - can appear to do much the same thing. But note
how this "smoke and mirrors" probably works in the case of the "logon"
command (I say "probably" since I have only the manual to go on.):
In the case of the IP USS table, the mapping of application name, mode name
and logon data is performed by the TELNET server logic and transformed into
control block fields prior to execution of the code generated by the REQSESS
macro. When the SNA INIT-OTHER request unit reaches the appropriate SSCP,
the data are used to try to initiate the session.
In the case of the SNA USS table, the mapping of application name, mode name
and logon data is performed by the SSCP logic within VTAM which then itself,
probably by means of an internal "signal" corresponding to an equivalent
INIT-OTHER request unit, proceeds to try to initiate the session.
(That the initiate request is INIT-OTHER rather than what appears to be the
more logical request INIT-SELF, I can only suppose is a feature of SNA
evolution. In the case of INIT-OTHER the initiating LU (ILU) can, as a
special case, be one of the LUs participating in the session but, is, in
general, any LU.)
The above was what happens to data inbound. What can be said about data
outbound.
In the case of the SNA USS table it's important to set up the type of table
appropriate for the "device-type" LU. A 3767 LU, an ancient SNA typewriter,
needs to have SNA character string (SCS) format USS messages. 3270 devices
which use LU type 2 - or their emulators - need also to have SCS format USS
messages and, frankly, that "typewriter" or "printer" format doesn't work so
well on a display device monitor.
3270 devices which use the implementation of LU type 0 particular to 3270
devices, often referred to, potentially confusingly, as "non-SNA" 3270, need
to have 3270 data stream format USS messages.
For the record, such 3270 "devices" are the following:
1. The 3271-11 and 3271-12, the so-called SDLC 3270 control units,
supporting 3277 displays. These are long obsolete - the last one I saw I got
thrown out of the set of devices I and my colleagues used in our education
centre in about 1985. I'm only mentioning it because I think - it's so long
ago now - that this was the prototype for all the other LU type 0 3270
"devices". Any gray-beards reading this can comment if they know better.
2. All channel-attached 3270 devices with control unit types where each
display device had its own address. There's nothing SNA about these
configurations so they are genuinely "non-SNA" devices. Here VTAM maps the
read and write data from the 3270 CCWs to SNA request units. VTAM acts as an
emulator for the secondary LU.
3. The 3270 binary synchronous (BSC) control units supported through NCP use
some NCP code to convert the messages into a subarea SNA format, FID0, so
that the data can flow between subarea nodes, most simply NCP to an adjacent
VTAM. Here again VTAM, but in the node where the application resides, the
"primary end", rather than the node supporting the channel-attached devices,
the "secondary end", maps the FID0 data so that they appear to be the same
LU type 0 3270 flow.
The effect of all this is that the application isn't left with any clue as
to which of the 3 possibilities above the secondary LU represents - which is
as it should be when you're emulating something.
I hope I've got this right since I can't recall ever describing this in this
compressed manner before. It is evidently the case that this must be the way
it works since the specification of the protocol - which is all the primary
LU application has to go on - is the same, namely as shown in the S3270 mode
table entry at the very beginning of ISTINCLM, this being one of the
original sample mode table entries from the dawn of SNA in 1975.
(Just so as not to cause any room for disbelief, I am aware that APPN COS
entries were added to all the ISTINCLM mode table entries much later than
1975. That apart, S3270 is unchanged from the Precambrian era on SNA's
geological scale.)
If you have a look at the other 3270 LU type 0 entries in ISTINCLM, for
example NSX32702 or D4B32782 and similar entries, you will see that FMPROF,
TSPROF, PRIPROT, SECPROT and COMPROT are always the same. It's also
important that the first byte of PSERVIC is X'00' and, since PSERVIC is not
specified in S3270, you should know that any unspecified keyword takes a
null value of appropriate length. Your 3270-supporting application, TSO,
NetView and so on, will all look for that combination of protocol
specifications and know the secondary LU they are dealing with has all the
necessary characteristics to be this special type of "3270", referred to
rather oddly as the "non-SNA 3270".
IBMS3270 MODEENT
LOGMODE=S3270,FMPROF=X'02',TSPROF=X'02',PRIPROT=X'71',*
SECPROT=X'40',COMPROT=X'2000',
*
APPNCOS=#CONNECT
NSX32702 MODEENT LOGMODE=NSX32702,FMPROF=X'02',TSPROF=X'02',
*
PRIPROT=X'71',SECPROT=X'40',COMPROT=X'2000',
*
RUSIZES=X'0000',
*
PSERVIC=X'008000000000185000007E00',
*
APPNCOS=#CONNECT
D4B32782 MODEENT
LOGMODE=D4B32782,FMPROF=X'02',TSPROF=X'02',PRIPROT=X'7*
1',SECPROT=X'40',COMPROT=X'2000',RUSIZES=X'0000',PSERVIC*
=X'000000000000185000007E00',APPNCOS=#CONNECT
So, if your 3270 device corresponds to one of the 3 types above, you will
need to specify SSCPFM=USS3270 and use a USS table having the 3270 format.
(I don't expect however anyone has the old SDLC 3270 or indeed BSC control
units these days so the channel-attached non-SNA 3270 is the almost
certainly the only type likely to be seen today. Such a device is defined in
VTAM with the LOCAL statement and it may be noted that SSCPFM=USS3270 is
required - now I can't imagine why SSCPFM=USS3275 is an option since I
always thought the 3275 was only attached via BSC lines!)
If you are using TELNET 3270 you can decide to use LU type 2 or LU type 0
for the actual SNA session. From z/OS 1.6 (thanks to Dave Kutz for pointing
this out) the following applies:
1. For TN3270, you can use only a 3270 format USS table
2. For TN3270E, you can use either an SCS format USS table or a 3270 format
USS table.
You can always use either LU type on the SNA session - as specified through
the mode table entry names - no matter which format USS table you use.
Recall that, with "real" 3270 devices, you don't have a choice. You must use
the SCS format for the USS table if your 3270 uses LU 2 for sessions and the
3270 format if your 3270 uses LU 0 for sessions.
It's actually interesting to discuss what the advantages and disadvantages
of LU 0 and LU 2 are. In the early days of TCP/IP for VM and MVS I took this
matter up once with the developers. They insisted that LU 0 was the best.
Now that we have TN3270E they appear to have changed their minds. However it
may be that the penchant CS IP development has for the LU 2 mode table
entries with TN3270E is that the ATTN and SYSREQ key functions can be
supported in TN3270E.
On the other hand I have not spotted anything in the CS IP Configuration
Guide or Reference that describes the use of the SYSREQ key when using
TN3270E for, for example, SSCP-assisted logoff support. Perhaps folk with
systems of their own to play with can check on this. Note that RFC 2355, the
TN3270E RFC, seems to anticipate support for the SSCP-assisted logoff. There
is also another use of the possibility to call on the SSCP for
identification when the end-user calls the help desk.
With LU 0 you get full-duplex communication. This means the application can
send data to you, as the TELNET client, at any time and you can send data to
the application at any time. Of course, you can cause confusion this way,
particularly if you are impatient.
With LU 2 you get half-duplex communication. This means you send data to the
application and you wait for the application to respond before your next
input. You actually don't have to wait since you can use the Attn key to
invoke the SNA SIGNAL protocol which will cause the application to pass you
the "your-turn-to-send" logical baton at its earliest convenience typically
aborting the current output. I have always contended that this half-duplex
communication is least likely to cause confusion and so is to be preferred.
I have been discussing both USS tables and mode table entries but note that
neither use of the USS tables, the SCS format and the 3270 format, has
anything to do with mode table entries - except to pass the name to the SSCP
logic within the VTAM which has activated the secondary LU.
In the context of some of the discussion in this thread tangential to the
USS topic but maybe very important if there is a problem getting the right
mode table entry specified, it is now important to work out where a mode
table entry name can come from. Let's deal with the sequence.
1. It is specified by the end-user in the USS logon command as defined by
the USS table.
2. It is specified as the default mode table entry name in the USS logon
command used by the end-user where the mode table entry name is not
specified.
3. It is defined by the name on the selected TELNETDEVICE statement as
"negotiated" (the first for TN3270 and the second for TN3270E) when there is
no default mode table entry name and no mode table entry name was entered.
(This is a reasonable - I hope - guess because nothing else makes sense.) As
noted later, it is impossible not to specify a "terminal/device type" code
for both TN3270 and TN3270E. However it is now possible to specify NONE for
the mode table entry name, meaning the mode table entry name is still blank,
that is, hasn't been specified.
It's not completely clear that 1 and 2 are valid. It is however implied by
the following phrase in CS IP Configuration Guide 2.2.1.10.2 Using the
Telnet USS and INTERPRET support: "If the terminal user is specifying only
APPLID and DATA on the USS LOGON command, ...". By omission this implies
that LOGMODE can be specified. Thus you can override the "negotiated" mode
table entry name.
One of the above 3 can cause the appropriate mode table entry name - as the
mode name - to be present in the INIT-OTHER request unit sent to the SSCP of
the VTAM which activated the APPL statements used by the TELNET server using
the REQSESS macro.
All the following, 4 to 6, apply when no mode name is present in the
INIT-OTHER request.
4. The VTAM SSCP will use the mode table entry name specified by DLOGMOD on
the APPL statement if the mode name in the INIT-OTHER request unit is blank.
(I'm keeping this simple and assuming that the name specified by DLOGMOD can
be found either in the mode table specified by MODETAB on the APPL statement
or ISTINCLM.)
5. The VTAM SSCP will use the first mode table entry name in the mode table
specified by MODETAB on the APPL statement if DLOGMOD doesn't specify a
name.
6. The VTAM SSCP will use the first mode table entry name in the ISTINCLM
mode table if MODETAB on the APPL statement doesn't specify a name.
Since Ronald was trying different USS tables without telling us how they
were defined I guess he may also not have known every detail and there were
perhaps default mode table entry names present.
There's yet one more possible complication here in connection with mode
table entries. Assuming the dynamic definition of CICS "terminal entries" is
being used, the eventual BIND image, derived from the selected mode table
entry, which is presented to CICS, a key application for Ronald it would
seem, needs to be matched in a selection of parts with some CICS definitions
in order to determine how the CICS transactions will behave. This is one
more opportunity to get it wrong as far as CICS is concerned - or it used to
be when I last played with CICS.
Let us now cover the TELNETDEVICE statement which is all about the selection
of mode table entry names and nothing to do with USS tables.
The first point to mention is that you do not need to specify any
TELNETDEVICE statements since there is a set of defaults which is always
there in case you do not specify one of the "terminal/device type"* codes
for one or other of the two possibilities for TN3270 and TN3270E. It's
interesting that Ronald's original specification of TELNETDEVICE statements
is quite unnecessary since they are all defaults.
* RFC 1576 for TN3270 describes these codes as "terminal type" codes and
RFC 2355 for TN3270E describes these codes as "device type" codes.
In CS IP Configuration Reference 2.8.2.41 TELNETDEVICE Usage notes (after
the table) there is sentence which mentions this lack of need to specify
TELNETDEVICE statements. Although the sentence is ungrammatical, it seems to
indicate that, if you are happy with all the defaults, you need not code
TELNETDEVICE statements at all and that you need specify TELNETDEVICE
statements only where you wish to change the defaults: "Telnet is
initialized to the logmode names listed in Table 20 and are defined in
VTAM."
I would expect that the PC or UNIX machine program implementations of TELNET
clients these days would all support extended data streams and being
"queried" for presentation space dimensions, rows and columns, immediately
after the BIND. Thus, ideally, the only "device code" you should need to pay
any attention to is IBM-DYNAMIC even if the D4C32XX3 mode table entry, the
assumed mode table entry name for both TN3270 and TN3270E, is a quite
acceptable entry having all the necessary capabilities.
D4C32XX3 MODEENT
LOGMODE=D4C32XX3,FMPROF=X'03',TSPROF=X'03',PRIPROT=X'B*
1',SECPROT=X'90',COMPROT=X'3080',RUSIZES=X'87F8',PSERVIC*
=X'028000000000000000000300',APPNCOS=#CONNECT
You can see it has the "query" bit, the X'80' in the second byte of PSERVIC
and it has the "unspecified screen size" code in the penultimate byte of
PSERVIC. That's all you need and have needed ever since I used to teach this
topic well over 10 years ago in a purely SNA context. All the TELNETDEVICE
statements with other "terminal/device type" codes can be left to the
automatic defaults and many customers may never use them.
Unfortunately, I suspect the ideal is unlikely and something less desirable
will be used in practice. So let us speculate on how the "terminal type"
code (TN3270) or "device type" code (TN3270E) is determined.
A possible technique could be as follows:
IBM-3278-2 if rows=24 and columns=80
IBM-3278-3 if rows=32 and columns=80
IBM-3278-4 if rows=43 and columns=80
IBM-3278-5 if rows=21 and columns=132
In all cases -E is added if the 3270 "extended" data stream is specified or
just always available in the TELNET 3270 client implementation.
I can see other "terminal/device type" codes being specified only if the
client allows the "terminal/device type" code to be specified explicitly.
This would include IBM-DYNAMIC.
There may be an exception. If the TELNET 3270 client implementation allowed
"non-standard" rows and columns to be specified and the rows and columns
specified are not one of the settings above, IBM-DYNAMIC would have to be
used.
I did find a tantalising suggestion in searching the web in
http://www.zephyrcorp.com/terminal-emulation/readme.txt as follows:
Dynamic Screen Size Configuration
---------------------------------
PASSPORT now supports the TN3270E device type IBM-DYNAMIC. This
allows PASSPORT to accept and dynamically configure itself to all
the standard 3270 screen sizes: model 2 (80 x 24),
model 3 (80 x 32), model 4 (80 x 43) and model 5 (132 x 27).
This feature can be used to ease the administrative burden of
matching the screen size parameters for the terminal emulation
sessions with the LU definitions for the TN3270E server and host
VTAM tables.
Does this mean PASSPORT returns only IBM-DYNAMIC during "negotiation"?
I checked the PASSPORT PC to HOST User Guide and I can't be sure. It may all
depend on what is possible in the so-called "Screen Size area", namely
whether or not "non-standard" rows and columns can be specified, as to how
the TN3270E "device type" code is set.
Having mentioned TELNET "negotiation" a few times it may be handy to show a
typical "negotiation" from RFC 2355:
The following example shows a TN3270E-capable server and a TN3270E-
capable client establishing a generic pool (non-specific) terminal
session:
Server: IAC DO TN3270E
Client: IAC WILL TN3270E
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT anyterm
IAC SE
Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
(3270 data stream is exchanged)
This may not be so typical in that the TELNET 3270 client is claiming to
support TN3270E but only the most basic flavour of 3270. More typical - and
desirable - might be to replace IBM-3278-2 with IBM-DYNAMIC.
Given the significance of the "terminal/device type" code, it is a shame
that NETSTAT TELNET does not show the "terminal type" code (TN3270) or
"device type" code (TN3270E) selected. Being able to examine the TELNET
options agreed would also be very helpful especially when the TN3270 client
implementation's documentation is deficient. Of course, the implementation
of the TN3270 client could also display the agreed TELNET options thereby,
to some extent, compensating for deficient TN3270 server documentation.
Perhaps I just have failed to spot it in the manuals.
If you are creating your own mode table entries - in your own mode table
normally - you can map all the "terminal/device type" codes ending in -E and
IBM-DYNAMIC to the same mode table entry name. Of course this mode table
entry should be defined with the X'03' in the penultimate byte of PSERVIC
and X'80' in the second byte of PSERVIC. As for the "terminal/device type"
codes which do not end in -E, you will need just one entry for the model 2
rows and columns code, IBM-3278-2, one entry for the model 3 rows and
columns code, IBM-3278-3, one entry for the model 4 rows and columns code,
IBM-3278-4, and one entry for the model 5 rows and columns code, IBM-3278-5.
Here are the PSERVIC specifications for each of the above
IBM-DYNAMIC - PSERVIC=X'..8000000000000000000300'
IBM-3278-2 - PSERVIC=X'..0000000000000000000200' or
X'..0000000000185018507F00' or X'..0000000000185000007E00'
IBM-3278-3 - PSERVIC=X'..0000000000185020507F00'
IBM-3278-4 - PSERVIC=X'..000000000018502B507F00'
IBM-3278-5 - PSERVIC=X'..000000000018501B847F00'
The two dots are to be replaces by X'00' for LU 0 support or X'02' for LU 2
support - but take care to get the remaining protocol fields correct.
There is another slight complication in that the byte following the two dots
is used for bit indicators and the other bits have significance. Hunting
down the VM library, I found mention of X'40' for "new APL".
The following comments come from a study of RFC 2355 (replaces RFC 1647),
the TELNET 3270 "Enhancements" (TN3270E) RFC.
TELNETDEVICE names including 3279 are obsolete with TN3270E - see 1 7.1 of
RFC 2355. Thus the second mode table entry name on the IBM-3279-n(-E)
"terminal/device type" codes is pointless since it can never be selected.
TN3270E, as specified in RFC 2355, requires that the mode table entry
specified for TN3270E uses either the X'7F' value in the penultimate byte of
PSERVIC rather than the X'7E' value when the IBM-3278-n(-E) "device type"
codes are used (with the trivial exception hinted at above). In addition the
"default" dimensions, that is, those that apply when an "Erase Write"
command is the first byte of the output stream rather than an "Erase Write
Alternate", must be X'1850' representing 24 rows by 80 columns. Naturally
the "alternate" dimensions, that is, those that apply when an "Erase Write
Alternate" command is the first byte of the output stream, must be X'2050'
representing 32 rows by 80 columns for IBM-3278-3(-E), X'2B50' representing
43 rows by 80 columns for IBM-3278-4(-E) and X'1B84' representing 27 rows by
132 columns for IBM-3278-5(-E). Of course, for IBM-3278-2(-E), X'02' may be
used in place of X'7F' without any specification of dimensions and, for
IBM-DYNAMIC, X'03' is used in place of X'7F'.
I couldn't find as clear a description of the mapping of the "terminal type"
code to rows and column settings in RFC 1576 as I found for the mapping of
"device type" codes in RFC 2355 but I expect it's safe to use the RFC 2355,
TN3270E, as a guide also for appropriate mode table entries for "basic"
TN3270.
It is possible that, in supporting the SCS character string (SCS) for USS
simulation, the CS IP TELNET server is stepping outside what RFC 2355
envisages. The SCS-CTL-CODES TN3270E function is supposed to be acceptable
during "negotiation" only with the "printer" device type code IBM-3287-1. It
may be interesting to trace the TELNET negotiation when an SCS format USS
table is used in order to see whether or not the SCS-CTL-CODES TN3270E
function appears. A TELNET client claiming to support TN3270E may be
entitled not to understand and reject the SCS-CTL-CODES TN3270E function on
a TELNET connection where IBM-3278-n(-E) had been "negotiated" as the
"device type" code.
However, later I see that SCS format can be signaled by a code in the
TN3270E message header as an alternative to 3270 format. It may be that use
of the SCS-CTL-CODES TN3270E function is not required during "negotiation".
RFCs are not always as unambiguous as one might hope.
However, again, at the end of 10.3, the plot thickens and there is definite
ambiguity over the allowed "data types" when only "SSCP-LU-DATA" is allowed.
There is yet a further source of confusion in 10.5.1 regarding the data
allowed on the SSCP-SLU session.
Well, I'm sorry possibly to have led you all down the garden path. Once I
had refocused on what "NVT" meant (Network Virtual Terminal), it struck me
that maybe the TN3270E server is entitled to map SCS data streams to NVT
data streams - which, noting some description in RFC 854, the basic TELNET
RFC - looks to be very easy. The only complication is that the SCS newline
must be mapped to the NVT "line feed" and "carriage return", as usual.
(For those who know something about USS tables (and NCP and NTO), perhaps,
CS IP could have insisted on using the data stream format required by the
SSCPFM=USSNTO option rather than that required by the SSCPFM=USSSCS option
since then the required message format would be precisely the same - barring
the need to translate between EBCDIC and ASCII. One reason they didn't need
to add that complication is that the mainframe processor has storage move
instructions and the 3745 processor, used by NCP, does not.)
What the possibility that there is mapping between the SCS data stream and
the NVT data stream means is that, when TN3270E is "negotiated", without the
need of any additional TN3270E functions being "negotiated", the TELNET 3270
server is entitled to send either 3270 format data streams or NVT format
data streams. Thus there would be no "stepping" outside what RFC 2355
envisages" and there should be no difficulty with TELNET clients
implementing TN3270E.
Nevertheless it is probably important to check that point either by tracing
the data flow between the TELNET server and client or with CS IP development
or both.
I took a quick look at the RFC which describes TN3270 "best practice", RFC
1576, which covers the 3270 "terminal type" codes simply as a small subset
of a massive list in RFC 1340, where all IANA codes are supposed to be
found. It is interesting to see that RFC 1340 seems to know more about which
models of 3279 were ever available than CS IP developers! I can assure you
there never was, nor never will be, a 3279-4 or a 3279-5!
It was interesting to find a web page
http://www.zephyrcorp.com/terminal-emulation/techspecs.htm in which the
PASSPORT implementation also claimed to support 3279 models 4 and 5!
I strongly recommend getting to grips with the following section of the CS
IP Configuration Guide: 2.2.1.10.2 Using the Telnet USS and INTERPRET
support. Nevertheless I recommend using the VTAM manual, CS SNA Resource
Definition Reference, for information regarding how to code USS tables since
VTAM supplies the macros. However be aware that, for TN3270, there are
additional substitutions, potentially helpful to the TN3270 clients, in the
USS messages.
Let's have a look at these since there's an interesting suggestion that can
be made.
Both VTAM and CS IP support the following variables in USS messages:
@@LUNAME - LU name
@@@NETID - LU NetID
@@@@DATE - date
@@@@TIME - time
@@@@RUNAME - request unit name for the USS7 message
@@@SENSE - sense code for the USS7 message
VTAM offers all the following variables in addition in USS messages:
@@SSCPNM - VTAM (SS)CP name
@HOSTNET - VTAM NetID
@@@@@@@@@@@@@@NQN - fully qualified name (LU-NetID.LU-name)
CS IP offers the following variables in addition in USS messages:
@@@@@@@@@IPADDR - TELNET 3270 client IP address if v4
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IPADDR - TELNET 3270 client IP address if
v6
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IPHOSTNAME - TELNET 3270 client host name
@@PRT - TELNET 3270 client port number
There's a hint (the IPINFO start option) that the above are also somehow
available for a regular SNA USS table. Well, we are here to talk about the
IP USS table so I won't be researching that today. On the other hand there's
an indication that only CS IP knows what it is talking about regarding this
set of variables. VTAM describes the IP address variable as IPADD whereas CS
IP describes is as IPADDR. I'm inclined to believe the latter. This is
actually unusual for me since I would normally support the former!
I don't know where the following comes from. It is something to do with IP
version 6 but it is not supported by the IP USS table - for the moment
maybe.
@@@@@@@@@@ZONEID - v6 zone id
Note: In the case of the IP USS10 message @@LUNAME will be blank since the
LU name will not have been determined when the USS10 message is sent.
It's clearly handy to have the maximum amount of useful information
available, so I recommend that the IP USS10 message always contains all the
relevant fields above, just as I have always recommended to my students to
do the same with the SNA USS10 message. The same goes especially for the
USS7 message, most especially including the RUNAME and SENSE fields, because
that is vital information for the end-user to report when application logons
fail.
However there's a USS message other than the USS10 message which should also
be packed with relevant information, in fact all information available -
just in case. This is the USS5 message.
I now have to assume that the TELNET server supports USS sufficiently to be
able to handle a switch from the LU-LU session to the SSCP-LU session such
as would be needed for the SSCP-assisted logoff - which the TN3270E RFC
thinks should be being supported. If so the following is possible:
1. The end-user has a problem with, say, an unresponsive application.
2. The end-user calls the help desk
3. The help desk notes the problem and then asks the end-user for the
identification information
4. The end-user hits the SysRq key - or its equivalent on the PC or whatever
keyboard, the Esc key maybe - and hits enter
5. The USS5 message now appears in order to complain that no valid command
has been entered
6. The end-user reports all the vital names and numbers to be found on the
USS5 message which the systems programmer has carefully organised in this
message for the benefit of the help desk operator
7. The help desk operator now advises the end-user over what to do,
including probably to enter LOGOFF, the SSCP-assisted logoff
I hope you all find that suggestion useful - as my students did over the
many years I described how to do it with SNA USS tables. However, I'd be
grateful if someone could verify that the technique I described will still
work.
Above I recommended getting to grips with 2.2.1.10.2 Using the Telnet USS
and INTERPRET support. Unfortunately there are one or two errors to be found
there I should mention:
1. The paragraph starting "Telnet supports both 3270 format and SNA
character stream (SCS) format USS tables." is enormously confusing, confused
and internally inconsistent. I think a start to understanding it can be made
by appreciating that the references to BIND, UNBIND and SSCP-LU data refer
to TN3270E flows as described in RFC 2355 and not to the seemingly
equivalently named SNA flows.
2. "An LUMAP-DEFAPPL application will always be used instead of the USSMSG10
regardless of Client Identifier priority." Actually a USS command can be
entered no matter which USS message is currently displayed. This has been a
failure in the documentation to keep up with the enhancements to CS IP
support for USS messages from just 10 to all of them - either that or it
doesn't work as VTAM does and should be fixed.
3. "All character substitutions (@@'s) substitute the same number of
fields." "fields" should be "characters" or "bytes" in this sentence.
4. "The USS LOGON command is displayed on the terminal as it is typed, so
the password will be displayed." This is not necessarily so. Since attribute
characters are removed by VTAM when "parsing" USS command data, it is
possible with the SNA USS table to ensure that a password is entered in a
non-display field - as long as you are using 3270 format, of course. It is
very likely that CS IP does the same - because those attribute characters
will be there on the input stream and will have to be ignored.
Note that 2.2.1.10.2 Using the Telnet USS and INTERPRET support also covers
the INTERPRET table. This is very special and probably of no interest to
anyone. I'm amazed CS IP has bothered. They should have asked their
customers first. (I now expect someone out there will tell me "Oh but we use
it and it is vital!")
I'm glad I consulted my notes on this topic since I almost passed on the
wrong information. In my notes I find the following:
Logon Interpret tables were introduced in pre-program product VTAM as a way
of supporting the migration of APL users from a dedicated system like APL/SV
to VTAM-supported VSPC. It allowed nonstandard characters in the logon data
from a terminal user. Specifically, for APL users, it allowed the use of a
right bracket, ")", followed by the user's number for identification and
accounting. The logon interpret table provided a general means for handling
this very special migration issue, now, almost, long forgotten.
The use of the logon interpret table was extended, briefly, to provide a
function required by extended recovery facility, XRF, the USERVAR function.
At a quickly following VTAM release, the USERVAR function was enhanced and
part of the enhancement was to eliminate the need for logon interpret
tables.
Finally regarding USS tables, I didn't see any mention in the CS IP manuals
about support for the MVS Message Service whereby USS messages can be
created for use with different languages. This should be a possibility with
the SCS format. Perhaps it is yet to be developed in the general progress CS
IP is making in order to support USS tables with TELNET 3270 as fully as USS
tables are supported in CS SNA.
Chris Mason
----------------------------------------------------------------------
For IBMTCP-L subscribe / signoff / archive access instructions,
send email to ***@VM.MARIST.EDU with the message: INFO IBMTCP-L