| Title: | SNA GATEWAY NOTEFILE |
| Notice: | Note 1.* -> kits and doc, 288.* -> obtaining product support |
| Moderator: | EDSCLU::GARROD |
| Created: | Fri Feb 07 1986 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 7116 |
| Total number of notes: | 28576 |
I have reached a deadlock with a customer, and the only way forward is for me to ask the question here (no matter how stupid it appears to be). The customer's application, layered on DECMessageQ LU6.2, received the error: %SNATERM-E-FAIESTSES, failed to establish session -SNA-E-SESNOTAVA, session address has not been activated However they insist that, at the time, the LU *WAS* activated. The Gateway is a Peerserver V1.3, and the applcation is on VMS using LU6.2 2.2-14. My question, is it possible that this configuration could ever return a SESNOTAVA status for any other reason than the documented "session address has not been activated"? The problem was confined to a single LU. ~Ian.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 7111.1 | EDSCLU::PORCARO | Fri May 30 1997 10:24 | 37 | ||
Ian,
Peer Server has both dependent and independent halves of the LU.
The dependent half has to be active. Below are two LU's in our
Peer Server status. Notice the second one will not allow DMQ access
for the reason of SESNOTAVA.
Bill
Status
UID =
6FB6ADC0-D85C-11D0-8004-00009308529F
State = On
Protocol State = Active
Active Ports = 0
Active Sessions = 0
Peak Active Sessions = 0
Queued Sessions = 0
Peak Queued Sessions = 0
Activation Time = 1997-05-29-15:48:30.000-04:00I-----
Dependent LU Protocol State = Active
Status
UID =
733DD860-D85C-11D0-8004-00009308529F
State = On
Protocol State = Active
Active Ports = 0
Active Sessions = 0
Peak Active Sessions = 0
Queued Sessions = 0
Peak Queued Sessions = 0
Activation Time = 1997-05-29-15:47:57.000-04:00I-----
Dependent LU Protocol State = Inactive
| |||||
| 7111.2 | KERNEL::WEGG | Ian Wegg - UK TSC | Fri May 30 1997 12:05 | 18 | |
Bill,
Thanks for the information. When I spoke to the customer the LU
was as you describe in the second case (i.e. Dependent LU Protocol
State = Inactive ) and therefore expected. They insist
that it WASN'T like this when they had the problem, but I'm not
convinced they really knew this.
I'll get them to reactive the LU and try it again with tracing.
If I can get any evidence of SESNOTAVA with the Dependent LU
protocol State of Active I'll be in touch, but please don't lose
any sleep. :-)
As a side issue, what is engineering's position with VMS 6.1
and LU6.2 V2.2? Would an escalation still be accepted on these
versions or would you insist on the customer upgrading?
~Ian.
| |||||
| 7111.3 | EDSCLU::PORCARO | Mon Jun 02 1997 12:02 | 7 | ||
You can escallate with those versions, but analysis may prove
a fix already exists, or change in functionality changed the
behavior with the V2.3 release.
I would suggest you upgrade to V2.3 ECO-01.
Bill
| |||||