Greg
This is a summary for IBM-MAIN subscribers interested in this topic.
Following your posting of a copy of your original post in IBMTCP-L, it has been
pursued there.
You reported that your workstation user is no longer experiencing the problem
following a reconfiguration involving a change of IP address and so you need no
further support.
Unfortunately the problem didn't get solved and so it may appear again - and
cause trouble again!
I'm pretty sure that the message your workstation user reported was an USS
message 7 where the extension to the USS message 7 which allows problems
specifically involving the SNA-oriented TELNET server while attempting to set
up the conditions to initiate the SNA session to be presented to the user of
the 3270 emulator acting as a TELNET client was evident. The RUNAME variable is
the "LU lookup" text and the SENSE variable is "00003003" where "3003" is the
EZZ6035I return code meaning - without the RUNAME 10 character restriction -
"LUs are all in use.". This may mean no LUs are available or the LU(s) that
have/has been provided are/is still in session. Unfortunately definitions were
not in place which would cause the actual EZZ6035I multiline message to be
shown so we have no further information on the original problem. Nor was there
any checking in order to see whether or not the LU name was in fact in session.
> Thanks for the reply. By "pool", do you mean LUGROUP definition?
I shouldn't have made that comment. I put it down to tiredness after a long
day! There was nothing wrong with your LUMAP statement in the context of the
statements shown.
> ... and the MODETAB is ISTINCLM.
Actually I asked for the mode table *entry* name, not the mode table name. The
mode table name is *always*, in effect, ISTINCLM; even if you supply a
customised mode table as the value of the MODETAB operand, mode table ISTINCLM
is always searched for the mode table *entry* if the mode table *entry* is not
found in the customised mode table. I expect you can see that specifying
MODETAB=ISTINCLM is a bit of a waste of time since, if a misspelled mode table
*entry* name is used as a mode name, MODETAB=ISTINCLM will cause mode table
ISTINCLM to be searched once sensibly and once again pointlessly.
As I pointed out to Scott Ford, the technical ability of the developer who put
together the sample APPL statement definitions for the SNA-oriented TELNET
server in SEZAINST member VTAMLST is not of the highest. Specifying
MODETAB=ISTINCLM is just about forgivable since that is the way the VTAM manual
rather inaccurately represents the default but AUTH=NVPACE is utter nonsense.
An actually technically correct and useful sample would be as follows:
VBUILD TYPE=APPL
TN* APPL EAS=1,SESSLIM=YES,REGISTER=NO
Note that I am proposing a model APPL statement - where, of course, the name
would need to match the model for the "LU names" in the PROFILE data set.
Chris Mason
On Tue, 24 Jul 2012 08:43:38 -0500, Greg Shirey <wgshi...@benekeith.com> wrote:
> <an impenetrable string of characters without blanks>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
