On 09/11/11 11:02, Saku Set l wrote:
I tried also from my Alpha with V8.3:
OpenVMS V8.3 on node DS20 9-NOV-2011 13:38:08.04 Uptime 266 18:41:29
No difference, same error.
--Saku
What are you after Saku? It's probably on SLAVE, do you want to try and pull it from there just for comparison purposes?
Mark.
Oh! I misunderstood. Ignore my comment...
I'll do some more experimentation instead.
Johnny
On 2011-11-09 11:41, Johnny Billquist wrote:
Hmm. GORVAX and RHESUS are on the same local ethernet segment, I would
think. That suggests that is indeed some problem with the I64 system?
Anyone have an Alpha system with VMS V8 who can try?
Johnny
On 2011-11-09 02:27, Saku Set l wrote:
I tried from GORVAX and it breaks the same way..
MAISA::SYSTEM$ dir gorvax::
Directory GORVAX::SYS$SPECIFIC:[FAL$SERVER]
MNENG1.SYS;1 MNENG2.SYS;1 NETSERVER.LOG;75
NETSERVER.LOG;74
NETSERVER.LOG;73 NETSERVER.LOG;72 NETSERVER.LOG;71
NETSERVER.LOG;70
PR0801ENG.SYS;1 PS0801ENG.SYS;1 SH1601ENG.SYS;1 WWENG1.SYS;1
Total of 12 files.
copy/log GORVAX::SYS$SPECIFIC:[FAL$SERVER]*.*.* []
%COPY-E-READERR, error reading
GORVAX::SYS$SPECIFIC:[FAL$SERVER]MNENG1.SYS;1
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-LINKEXIT, network partner exited
%COPY-W-NOTCMPLT, GORVAX::SYS$SPECIFIC:[FAL$SERVER]MNENG1.SYS;1 not
completely copied
%COPY-E-CLOSEIN, error closing
GORVAX::SYS$SPECIFIC:[FAL$SERVER]MNENG1.SYS;1 as input
-RMS-F-WBE, error on write behind
-SYSTEM-F-LINKABORT, network partner aborted logical link
--Saku
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Hmm. GORVAX and RHESUS are on the same local ethernet segment, I would think. That suggests that is indeed some problem with the I64 system?
Anyone have an Alpha system with VMS V8 who can try?
Johnny
On 2011-11-09 02:27, Saku Set l wrote:
I tried from GORVAX and it breaks the same way..
MAISA::SYSTEM$ dir gorvax::
Directory GORVAX::SYS$SPECIFIC:[FAL$SERVER]
MNENG1.SYS;1 MNENG2.SYS;1 NETSERVER.LOG;75
NETSERVER.LOG;74
NETSERVER.LOG;73 NETSERVER.LOG;72 NETSERVER.LOG;71
NETSERVER.LOG;70
PR0801ENG.SYS;1 PS0801ENG.SYS;1 SH1601ENG.SYS;1 WWENG1.SYS;1
Total of 12 files.
copy/log GORVAX::SYS$SPECIFIC:[FAL$SERVER]*.*.* []
%COPY-E-READERR, error reading GORVAX::SYS$SPECIFIC:[FAL$SERVER]MNENG1.SYS;1
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-LINKEXIT, network partner exited
%COPY-W-NOTCMPLT, GORVAX::SYS$SPECIFIC:[FAL$SERVER]MNENG1.SYS;1 not
completely copied
%COPY-E-CLOSEIN, error closing
GORVAX::SYS$SPECIFIC:[FAL$SERVER]MNENG1.SYS;1 as input
-RMS-F-WBE, error on write behind
-SYSTEM-F-LINKABORT, network partner aborted logical link
--Saku
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I tried from GORVAX and it breaks the same way..
MAISA::SYSTEM$ dir gorvax::
Directory GORVAX::SYS$SPECIFIC:[FAL$SERVER]
MNENG1.SYS;1 MNENG2.SYS;1 NETSERVER.LOG;75 NETSERVER.LOG;74
NETSERVER.LOG;73 NETSERVER.LOG;72 NETSERVER.LOG;71 NETSERVER.LOG;70
PR0801ENG.SYS;1 PS0801ENG.SYS;1 SH1601ENG.SYS;1 WWENG1.SYS;1
Total of 12 files.
copy/log GORVAX::SYS$SPECIFIC:[FAL$SERVER]*.*.* []
%COPY-E-READERR, error reading GORVAX::SYS$SPECIFIC:[FAL$SERVER]MNENG1.SYS;1
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-LINKEXIT, network partner exited
%COPY-W-NOTCMPLT, GORVAX::SYS$SPECIFIC:[FAL$SERVER]MNENG1.SYS;1 not completely copied
%COPY-E-CLOSEIN, error closing GORVAX::SYS$SPECIFIC:[FAL$SERVER]MNENG1.SYS;1 as input
-RMS-F-WBE, error on write behind
-SYSTEM-F-LINKABORT, network partner aborted logical link
--Saku
Did some additional checking. Doing a dir from MIM to MAISA actually do work. So there is something funny going on with RHESUS.
Looking with tcpdump at the UDP packets, the one thing that looks a little different is that MAISA actually sends 584 byte length packets. Thinking about it, 609 is a rather odd value.
Since RHESUS is an I64, I'm ready to blame that modern junk. :-)
I can't spot what the problem is right now anyway. More to follow, I guess. Anyone else feel like trying to figure it out?
Johnny
On 2011-11-08 21.25, Johnny Billquist wrote:
Tried from MIM, and I can't even do a directory.
Got a "remote disconnect or line failure" error.
But I can talk NICE to RHESUS... Looking at MIM counters, everything
looks fine. Looking at RHESUS counters, it has plenty of response timeouts.
So it appears the data from RHESUS to MIM gets lost sometimes. In this
case just for doing a directory on RHESUS...
Looking at the UDP traffic, it looks like the packets are coming in to
Update, so it might be an issue with E11 (I've had an issue before where
it could drop ethernet packets under some circumstances).
But I'm not sure why it fails for you, Saku, since your traffic should
not pass by MIM anyway, even though it do pass through Update.
But anyway, it (for me) definitely does not look like I have problems
with packets being thrown away. Actually, the packet size of individual
UDP packets is 609 bytes. DECnet normally do not send lager packets than
defined by the EXEC parameter "segment buffer size" (or "buffer size" in
VMS). And the default for this is 576 bytes. Add some overhead to that,
and 609 bytes sounds reasonable.
Johnny
On 2011-11-08 17.50, Saku Set l wrote:
Hi,
First I tried ISO images from SYS$SPECIFIC:[FAL$SERVER.MEDIALIB]
but since it didn't work I tried smaller files from [FAL$SERVER] but it
still didn't work out. Directory comes out fine.
Regards,
--Saku
On Tue, Nov 8, 2011 at 3:06 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
On 2011-11-08 05.38, Saku Set l wrote:
Sampsa&Co,
I tried to pull some files from RHESUS media library, but don't get
anything, just
-SYSTEM-F-LINKABORT, network partner aborted logical link
I have no problem on copying files from MIM.
MTU issues on the internet uplink?
Nope. Whatever it is, I seriously doubt that is it.
Unless some firewall blocks fragmenting, the MTU is not really ever
an issue.
The error might be because of excessive lost packets. Maybe some
throttling could help. What files are you trying to pull? I can try
and experiment some.
Johnny
Tried from MIM, and I can't even do a directory.
Got a "remote disconnect or line failure" error.
But I can talk NICE to RHESUS... Looking at MIM counters, everything looks fine. Looking at RHESUS counters, it has plenty of response timeouts.
So it appears the data from RHESUS to MIM gets lost sometimes. In this case just for doing a directory on RHESUS...
Looking at the UDP traffic, it looks like the packets are coming in to Update, so it might be an issue with E11 (I've had an issue before where it could drop ethernet packets under some circumstances).
But I'm not sure why it fails for you, Saku, since your traffic should not pass by MIM anyway, even though it do pass through Update.
But anyway, it (for me) definitely does not look like I have problems with packets being thrown away. Actually, the packet size of individual UDP packets is 609 bytes. DECnet normally do not send lager packets than defined by the EXEC parameter "segment buffer size" (or "buffer size" in VMS). And the default for this is 576 bytes. Add some overhead to that, and 609 bytes sounds reasonable.
Johnny
On 2011-11-08 17.50, Saku Set l wrote:
Hi,
First I tried ISO images from SYS$SPECIFIC:[FAL$SERVER.MEDIALIB]
but since it didn't work I tried smaller files from [FAL$SERVER] but it
still didn't work out. Directory comes out fine.
Regards,
--Saku
On Tue, Nov 8, 2011 at 3:06 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
On 2011-11-08 05.38, Saku Set l wrote:
Sampsa&Co,
I tried to pull some files from RHESUS media library, but don't get
anything, just
-SYSTEM-F-LINKABORT, network partner aborted logical link
I have no problem on copying files from MIM.
MTU issues on the internet uplink?
Nope. Whatever it is, I seriously doubt that is it.
Unless some firewall blocks fragmenting, the MTU is not really ever
an issue.
The error might be because of excessive lost packets. Maybe some
throttling could help. What files are you trying to pull? I can try
and experiment some.
Johnny
Hi,
First I tried ISO images from SYS$SPECIFIC:[FAL$SERVER.MEDIALIB]
but since it didn't work I tried smaller files from [FAL$SERVER] but it still didn't work out. Directory comes out fine.
Regards,
--Saku
On Tue, Nov 8, 2011 at 3:06 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2011-11-08 05.38, Saku Set l wrote:
Sampsa&Co,
I tried to pull some files from RHESUS media library, but don't get
anything, just
-SYSTEM-F-LINKABORT, network partner aborted logical link
I have no problem on copying files from MIM.
MTU issues on the internet uplink?
Nope. Whatever it is, I seriously doubt that is it.
Unless some firewall blocks fragmenting, the MTU is not really ever an issue.
The error might be because of excessive lost packets. Maybe some throttling could help. What files are you trying to pull? I can try and experiment some.
Johnny
On 2011-11-08 05.38, Saku Set l wrote:
Sampsa&Co,
I tried to pull some files from RHESUS media library, but don't get
anything, just
-SYSTEM-F-LINKABORT, network partner aborted logical link
I have no problem on copying files from MIM.
MTU issues on the internet uplink?
Nope. Whatever it is, I seriously doubt that is it.
Unless some firewall blocks fragmenting, the MTU is not really ever an issue.
The error might be because of excessive lost packets. Maybe some throttling could help. What files are you trying to pull? I can try and experiment some.
Johnny
$ telnet chimpy 143
Trying 192.168.77.246...
Connected to chimpy.inside.sampsa.com.
Escape character is '^]'.
$ Set NoOn$ VERIFY = F$VERIFY(F$TRNLNM("SYLOGIN_VERIFY"))
What is going on? Why is the IMAP service outputting DCL code?
This is because either your system-wide login (SYS$STARTUP:SYLOGIN.COM) or your SYSTEM login (SYS$MANAGER:LOGIN.COM) is printing that out. (The IMAP server process runs using DCL, so whatever is in the (SY)LOGIN.COM files gets executed.)
Now, that said, VERIFY should be off by default, so I don't know why you're seeing it here. You don't have SYLOGIN_VERIFY defined to be 1, do you? (I don't think that would be the issue since the "$ Set NoOn" line was logged as well before the check in F$VERIFY().)
--Marc
