| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2544.1 | Please read before entering a new note | DECWIN::JMSYNGE | James M Synge, VMS Development | Fri Mar 30 1990 14:06 | 11 |
| >How do I find out what this error means?
If you read the many other notes with "io error" or "connection
aborted" as topics, you'd probably find out.
But, to answer more directly, it means the server or network killed
the connection. I'd take a look at the server's log file,
DECW$SERVER_0_ERROR.LOG, to see if it gives more info about what
happened.
James
|
| 2544.2 | Yeah, but where's the TEXT??? | VINO::WITHROW | Mass. recall petitions available here! | Mon Apr 02 1990 16:49 | 8 |
| RE .-2: It's listed with a title of 0dba whatever, as in
dir/all/tit=<hex error code>...
RE .-1: My question, after a year and a half of seing this question
asked again and again is: Where the heck is the text of that
message???? Why in the world doesn't the text of that message print
out? Should this be/has this been qared? I tried a set message of
various DECW$*.exe files in sys$message and get nothing.
|
| 2544.3 | DECW$TRANSPORTMSG | AGBEAR::HORNER | A.G.Bear, Old fashion teddy bear | Tue Apr 03 1990 08:46 | 8 |
| It's in DECW$TRANSPORTMSG.EXE. I do a
$ SET MESSAGE SYS$MESSAGE:DECW$TRANSPORTMSG.EXE
$ EXIT %X...
and get the text displayed.
Dave
|
| 2544.4 | | DECWIN::JMSYNGE | James M Synge, VMS Development | Tue Apr 03 1990 11:09 | 10 |
| Re .2
>Where the heck is the text of that message?
As .3 noted, it is SYS$MESSAGE:DECW$TRANSPORTMSG.EXE. Unfortunately,
the link of that image was wrong in V5.1 and V5.3 (though we may have
shipped a fixed image, but I don't remember). I fixed this at the
beginning of November, so the V5.4 image works.
James
|
| 2544.5 | Ah Ha | AGBEAR::HORNER | A.G.Bear, Old fashion teddy bear | Tue Apr 03 1990 13:23 | 5 |
| RE: .4
I'm on a T5.4 system. Now I see the source of confusion.
Dave
|
| 2544.6 | | KYOA::KOCH | My brother did not lose the election | Tue Apr 17 1990 12:54 | 7 |
| Folks,
I appreciate finding out how to get the message. Since I don't
have access to a 5.4 system, can you please post the text of
the message for us?
Ted
|
| 2544.7 | You are already seeing the text of the message | STAR::VATNE | Peter Vatne, VMS Development | Tue Apr 17 1990 14:35 | 17 |
| I did this on a V5.4 system:
$ set message sys$message:decw$transportmsg
$ exit %x02dba002
%DECW-E-CNXABORT, connected aborted
What is confusing everyone (and confused me, at first) is the part
of the XIO error message that says "non-translatable vms error code".
This does not mean that VMS could not find the error message text,
as the log clearly shows the above error message. What it means is
that XIO in Xlib couldn't map the error onto one of its own error
statuses.
I think this message is confusing and should be changed. I don't
know if anyone has QARed this, but it definitely wouldn't hurt to
QAR it again!
|
| 2544.8 | How can I find the source of this problem? | KYOA::KOCH | My brother did not lose the election | Wed Apr 18 1990 11:21 | 11 |
| >This does not mean that VMS could not find the error message text,
>as the log clearly shows the above error message. What it means is
>that XIO in Xlib couldn't map the error onto one of its own error
>statuses.
Ok, it seems that this is catch-all error. Now we know why that
connection aborted, but how do we determine why it aborted? Why aren't we
getting more info about why the connection is aborting? This is happening
randomly on my connections every few days between my V5.1 ad V5.3 systems.
How can I set things up to catch enough information to determine the cause
of the problem?
|
| 2544.9 | You are running old software... | STAR::VATNE | Peter Vatne, VMS Development | Wed Apr 18 1990 13:05 | 14 |
| The reason you aren't getting more information about why the connection
is aborting is because you are running old software. VMS V5.3 DECwindows
does a better job of reporting client errors than VMS V5.1 DECwindows.
However, when you do upgrade, you will most likely get one of the
following error messages:
%SYSTEM-F-LINKDISCON, network partner disconnected logical link
%SYSTEM-F-LINKABORT, network partner aborted logical link
%SYSTEM-F-LINKEXIT, network partner exited
%SYSTEM-F-PATHLOST, path to network partner node lost
Note 2544.1 gave you very good advice on what to do to get more
information on this problem.
|
| 2544.10 | I don't get a log file with the error info. | KYOA::KOCH | My brother did not lose the election | Wed Apr 18 1990 18:36 | 6 |
| Ok, I re-read .1. However, I have not gotten log files with the
name listed on the server nor the client end of the connection. Is this
supposed to be the standard or do I have to "turn" something "on" in order
to get the log file?
Thanks,
|
| 2544.11 | Where to find the server log file | STAR::VATNE | Peter Vatne, VMS Development | Wed Apr 18 1990 20:58 | 2 |
| The server's log file is in SYS$MANAGER:DECW$SERVER_0_ERROR.LOG, on
the server's workstation. It is always created.
|
| 2544.12 | Must be a V5.1 client to V5.3 server problem | KYOA::KOCH | My brother did not lose the election | Thu Apr 19 1990 17:03 | 16 |
| AHA! I have found it. However, not much more information is being
provided at the server side. The 20e4 is network partner aborted logical
link, which tells me that the client did the disconnection due to some
internal failure at the client side. It would seem that the client software
needs to be more explicit as to why it is failing. Given that this seems to
be solely a V5.1 client to a V5.3 server problem, the answer is UPGRADE. Our
upgrade is being done, so I'll wait and see if it happens between like
versions of VMS between my 2 systems. All my V5.3 client/server connections
have been up for weeks, indicating the problem has been fixed. We'll see...
Some excerpts from the log file:
19-APR-1990 10:14:23.8 Connection 356200 is closed by Txport(status = 20e4)
19-APR-1990 10:28:48.0 Connection 356238 is closed by Txport(status = 20e4)
19-APR-1990 10:28:54.1 Connection 356238 is closed by Txport(status = 20e4)
19-APR-1990 10:29:52.2 Connection 356238 is closed by Txport(status = 20e4)
|
| 2544.13 | Not here it isn't | TALK::BONNETT | Mistakes were made. | Fri Apr 20 1990 11:57 | 22 |
|
We've been having the same problem. This log is from a LAVC satellite WS
losing connections to cluster boot members. All systems involved are running
VMS 5.3-1.
18-APR-1990 14:38:42.0 Connection 214af0 is closed by Txport (status = 20e4)
18-APR-1990 14:38:42.8 Txport status = 20e4 ( copy and write) on client 6
19-APR-1990 09:49:27.6 Connection 30ea18 is closed by Txport (status = 20e4)
19-APR-1990 09:49:28.3 Txport status = 20e4 ( copy and write) on client 8
19-APR-1990 09:50:31.4 Connection 430400 is closed by Txport (status = 20e4)
19-APR-1990 10:05:48.4 Connection 430400 is closed by Txport (status = 20e4)
19-APR-1990 10:17:07.0 Connection 2f32a0 is closed by Txport (status = 20e4)
19-APR-1990 14:16:44.6 Connection 4402c0 is closed by Txport (status = 20e4)
19-APR-1990 14:46:55.5 Connection 470400 is closed by Txport (status = 20e4)
19-APR-1990 15:03:18.0 Connection 470400 is closed by Txport (status = 20e4)
19-APR-1990 15:07:19.8 Connection 470400 is closed by Txport (status = 20e4)
19-APR-1990 15:08:00.4 Connection 470400 is closed by Txport (status = 20e4)
What is the significance of the 'client' numbers in a couple of these entries ?
Rick
|
| 2544.14 | Client numbers are the server's internal numbers | STAR::VATNE | Peter Vatne, VMS Development | Fri Apr 20 1990 12:53 | 9 |
| > 18-APR-1990 14:38:42.8 Txport status = 20e4 ( copy and write) on client 6
The client numbers are just the server's internal numbers for the connection.
The server is not completely consistent in its messages when identifying
connections. Sometimes it uses the address of the connection block, sometimes
it uses the connection index. The main thing to note is that all of your
connections are getting "Network partner aborted logical link".
I've put it on my list to make all the server messages consistent.
|