Thomas > Thanks for Your information! I will consume it on Monday.
How are you getting on digesting my previous post? I'm afraid it also contains some misleading information! By suggesting that it was very likely that the USS function of the SNA-oriented TELNET server did not support the VTAM module ISTINCDT, I probably gave you the impression that there was no default USS table in the case of the SNA-oriented TELNET server. Not - strictly - true! Thinking about this presumed lack of a default USS table, I started to wonder what would be used for an USS message if a customized USS table had provided, say, for only the USS messages which feature in the description of the USS function in the z/OS Communications Server IP Configuration Guide and Reference manuals, 10 and 7. Thus the messages which are need to be presented when the operator's use of the keyboard is less than 100% precise will need to be found from somewhere. Having noted that the message which RFC 2355 prescribes for the case where, the SysReq function having been invoked, a mess is made of trying to enter the characters "logoff" or "LOGOFF" is "COMMAND UNRECOGNIZED" and that this must be "hard-coded", I imagined that the default text for "missing" USS messages may well be "hard-coded" and correspond to the messages as defined in the z/OS Communications Server SNA Messages manual, possibly without variable substitution as in the case of the response to the incorrect "LOGOFF" command. But I needed to check - and it's just as well I did! There is a default USS table in the case of the SNA-oriented TELNET server and it resides in the same partitioned data set as the EZBTNINI module so it should always be available. The name is EZBTPUST.[1] The default EZBTPUST USS table is used in one of two ways: 1. It can be specified as the value of the USSTCP statement in a BEGINVTAM/ENDVTAM block of statements so that it is always used in support of an operator selecting a primary LU for the SNA session concatenated to the TELNET TCP connection. 2. A customised USS table can be created[2] and stored in an appropriate partitioned data set. If there are any USS messages not defined in the customised USS table, should any ever be needed, the USS message will be taken from the EZBTPUST USS table.[3] Thus, as far as USS messages are concerned, there *is* a default USS table and it is the EZBTPUST module. What about USS commands? In the first case, the USS LOGON commands are available for use. In the second case, the USS LOGON commands are *not* available for use. This reluctance to use the commands defined in the EZBTPUST module when a customised USS table is specified by the USSTCP statement explains why you could not use the "FORMAT=PLI" flavour of the "LOGON" command because a friendly VTAM system programmer in the past had set up a customised USS table for you, and, because the customised USS table set up by that friendly VTAM system programmer happened to define a "FORMAT=BAL" version of the generalised LOGON command, you succeeded with that version of the LOGON command. - You'll notice I have provided a changed Subject. I really intended to do that with my previous post but the hexadecimal garbage which appeared when I "quoted" - using the archive functions - your post distracted me - and I forgot! - [1] There are actually two supplied, default, USS tables. One, EZBTPUST, is described as an example for "The name of the 3270 format USS table load module", the first positional parameter value of the USSTCP statement and the other, EZBTPSCS, is described as an example for "The name of the SCS format USS table load module", the second positional parameter value of the USSTCP statement. In terms of actual function they are identical![1.1] Specifically the USS messages are defined identically. The only difference is that the former provides some sample source for an USS message 10 using the BUFFER rather than the TEXT format made up of a 3270 data stream and the latter provides some sample source for an USS message 10 using the BUFFER rather than the TEXT format made up of an SCS data stream. Other than consulting the source for these two tables which, despite not having a z/OS system to hand, I happen to have available, most of what I cover in these posts comes from the "Using the Telnet solicitor or USS logon screen" section of the z/OS Communications Server IP Configuration Guide: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3b1/2.2.1.4.15 [1.1] I am discounting the weird "FREDT" command which some bright spark of a developer must have slipped into EZBTPUST not intending it should stay, promptly got promoted and nobody later responsible for the module dared remove! [2] ... or copied from a partitioned data set still used or previously used as a data set in the concatenation of data sets referenced by the VTAMLIB DD-statement. [3] And, if the system programmer has managed to remove the EZBTPUST module so that the SNA-oriented server cannot gain access to it and an USS message needs to be presented, there is a "hard-coded" USS message 14 - which sort-of brings us back to what this post is all about! - Chris Mason On Sun, 1 Jul 2012 14:53:10 +0200, Thomas Berg <[email protected]> wrote: <garbage as before - I've had to "engineer" adding my previous post in order to present a more complete story - but it should have happened automatically!!!> On Fri, 29 Jun 2012 11:11:40 -0500, Chris Mason <[email protected]> wrote: >Thomas > >When giving advice it behoves the adviser not to be quite so careless with >terminology! > >> Make sure You connect to a proper VTAM profile (that support the >> alternate/dynamic screen size). > >The IP component of z/OS Communications Server uses files called "PROFILE" for >both the main address space and the SNA-oriented TELNET server. VTAM has >nothing to do with any sort of "PROFILE"! > >Your bracketed explanation helps us to understand that you are referring to an >SNA mode, otherwise known as a logon mode table entry. > >> Make sure ... > >There are five ways to "make sure", in the order of processing: > >1. When using USS, specify the logon mode table entry name (LMTEN), D4C32XX3 >for example, in the USS command, how depending on whether the VTAM system >programmer who constructed your USS table allowed for the specification of an >LMTEN and, if so, how - or - use the default LOGON command[1]. > >2. When using USS, have the VTAM system programmer set up an USS LOGON command >in the USS table where the following macro follows the USSCMD macro: > > USSPARM PARM=LOGMODE,DEFAULT=D4C32XX3 > >3. Depending on the TN3270 client emulator product, specify the "device type" >to be "IBM-DYNAMIC" so that, during TELNET negotiation, in the internal >version of the table created by TELNETDEVICE statements, the "device type" >selects LMTEN D4C32XX3. It's important that the TELNETDEVICE statement for >"TELNET device type" "IBM-DYNAMIC" has not been specified and the LMTEN >changed to some name other than D4C32XX3 (with the exception of D4A32XX3, to >be strictly accurate) or has been specified but the name is still D4C32XX3 (or >D4A32XX3) - which is clearly a waste of time! > >4. Do not bother with specifying the "device type" as "IBM-DYNAMIC" - which >may be impossible or cumbersome with the particular TN3270 client emulator >product in use. Either find out what it is[2] - I will use IBM-3278-E-2 as an >example - and specify the associated TELNETDEVICE statement so that LMTEN >D4C32XX3 (or D4A32XX3) is selected: > >TELNETDEVICE IBM-3278-E-2 ,D4C32XX3 > >Note that, as is surely inevitable these days, I have assumed that the TN3270 >client emulator product supports RFC 2355. > >Alternatively, specify *all* the TELNETDEVICE statements for "display" "device >types" so that LMTEN D4C32XX3 (or D4A32XX3) is selected. > >5. As 4 but specify "NONE" in the relevant TELNETDEVICE statement(s) and >specify D4C32XX3 (or D4A32XX3) as the value of the DLOGMOD operand on the >typically these days "model" APPL statement for the secondary LU >representations used by the SNA-oriented TELNET server. > >- > >[1] The default LOGON command allows for a LMTEN to be specified as follows: > >LOGON APPLID(primary-LU-name)LOGMODE(logon-mode-table-entry-name) > >> logon applid=???,logmode=d4c32xx33 > >It is clear that, at some time in the past, the VTAM system programmer of the >day in your installation thought that it was a good idea to provide a version >of the default, generalised, USS table LOGON command which used the >"assembler" format rather than the PL/1 format. In this case, the culprit s >not "terminology" but a realisation that what works "chez vous" does not >necessarily apply everywhere! > >Note that, even if your VTAM system programmer has provided the "assembler" >version of the generalised USS LOGON command, the PL/1 version is always >available since, just as default logon mode table ISTINCLM is always >"concatenated" to whatever logon mode table name is specified as the value of >a MODETAB operand, USS table name ISTINCDT is always "concatenated" to >whatever USS table name is specified as the value of a USSTAB operand and USS >table ISTINCDT specifies the PL/1 version of the generalised USS LOGON command. > >[2] You can find out what "device code" is used with the DISPLAY TCPIP command >directed to the address space of the SNA-oriented TELNET server as follows: > >D TCPIP,TELNET,CONN,CONN=nnn > >where "TELNET" is that name of the SNA-oriented TELNET server address space >and "nnn" is the identification of the TELNET connection. > >You will find a line in the output similar to the following: > >PROTOCOL: TN3270E LOGMODE: SNX32702 DEVICETYPE: IBM-3278-2-E > >In order to determine what to specify for "nnn", you can use the command > >D TCPIP,TELNET,CONN > >which shows both the "CONN" number and the IP address of the TELNET client. > >- > >Chris Mason > > >On Fri, 29 Jun 2012 10:39:42 +0200, Thomas Berg <[email protected]> >wrote: > >>If You by that mean You want to use a bigger screensize (dynamic) You can do >>like I do: >> >> >>1: Edit the xxx.ws pcomm session profile file and have: >> >>. . . >>[Telnet3270] >>TerminalTypeString=IBM-DYNAMIC >>. . . >>[3270] >>. . . >>ScreenSize=64x128 <--- 64 rows x 128 columns (Whatever You like) >>. . . >> >> >>2: Make sure You connect to a proper VTAM profile (that support the >>alternate/dynamic screen size). >> >>Alternatively You can do what I do, make a pcomm macro that enters the vtam >>logon like: >> >>logon applid=???,logmode=d4c32xx33 <--- ??? = the applid for TSO, can be >>whatever You VTAM prog thought of... >> >> >>The macro code: >> >>wait 1 seconds >>"logon applid=tsosy5,logmode=d4c32xx33 <--- d4c32xx33 is the standard >>logmode for alternate/dynamic size >>[enter] >>[wait inp inh] >>"??? <--- write You tso userid here >>[enter] >> >> >> >> >>Regards, >>Thomas Berg ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
