Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
USS message 7 (Was: LU Lookup failed - sense 00003003)
664 views
Skip to first unread message
Chris Mason
Jul 26, 2012, 5:07:56 AM7/26/12
to
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 <WGSh...@BENEKEITH.COM> wrote:
> <an impenetrable string of characters without blanks>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
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 <WGSh...@BENEKEITH.COM> wrote:
> <an impenetrable string of characters without blanks>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Greg Shirey
Jul 27, 2012, 11:39:58 AM7/27/12
to
I can appreciate that Chris wanted to respond to my post for the sake of the archives, and he is of course correct about the message source being associated with USS MSG 7. That cleared up some confusion for me - I haven't had trouble with TN3270 connections for so long, I've forgotten a lot, it seems.
Since changing to a different static IP address did get the device connected, I no longer had an "urgent" situation, so I posted to TCP-L that I had it resolved so that no one would expend any effort on my behalf.
I was still left wondering why had gotten "LUs in use" message, however, so I kept looking.
I finally saw this message in SYSLOG:
EZZ6038I TN3270 COMMAND INACT WTST COMPLETE
It seems that, the other day, before the VTAM activate command had been issued, the user had already attempted to connect the device to CICS. Since at that point no entry was found in VTAM, the luname was placed in the Telnet server Inactive pool. I did a D TCPIP,TN3270,INACTLUS command a while ago, and indeed found WTST in the list.
Sigh... Had I noticed the message in SYSLOG, I could have just issued the V TCPIP,TN3270,T,ACT,ALL command and spent a whole lot less time on this.
So, my new rule of thumb when someone reports an "LU LOOKUP FAILED" message is to check the list of inactive LUs. Oh, and also, we are going to issue the Vary command periodically. No sense carrying around a bunch of inactive LUs...
Have a great Friday,
Greg Shirey
Ben E. Keith Company
-----Original Message-----
From: IBM Mainframe Discussion List On Behalf Of Chris Mason
Sent: Thursday, July 26, 2012 4:08 AM
<snip>
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.
<snip>
Since changing to a different static IP address did get the device connected, I no longer had an "urgent" situation, so I posted to TCP-L that I had it resolved so that no one would expend any effort on my behalf.
I was still left wondering why had gotten "LUs in use" message, however, so I kept looking.
I finally saw this message in SYSLOG:
EZZ6038I TN3270 COMMAND INACT WTST COMPLETE
It seems that, the other day, before the VTAM activate command had been issued, the user had already attempted to connect the device to CICS. Since at that point no entry was found in VTAM, the luname was placed in the Telnet server Inactive pool. I did a D TCPIP,TN3270,INACTLUS command a while ago, and indeed found WTST in the list.
Sigh... Had I noticed the message in SYSLOG, I could have just issued the V TCPIP,TN3270,T,ACT,ALL command and spent a whole lot less time on this.
So, my new rule of thumb when someone reports an "LU LOOKUP FAILED" message is to check the list of inactive LUs. Oh, and also, we are going to issue the Vary command periodically. No sense carrying around a bunch of inactive LUs...
Have a great Friday,
Greg Shirey
Ben E. Keith Company
-----Original Message-----
From: IBM Mainframe Discussion List On Behalf Of Chris Mason
Sent: Thursday, July 26, 2012 4:08 AM
<snip>
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.
0 new messages