- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Failed/slow DECnet copy
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2008 04:11 PM
тАО08-06-2008 04:11 PM
Failed/slow DECnet copy
%COPY-E-READERR, error reading ES40::DISK$DGA205:[STUDENT_DB_BU]STUDENT_DB_FULL_BACKUP.RBF;1109
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-LINKEXIT, network partner exited
%COPY-W-NOTCMPLT, ES40::DISK$DGA205:[STUDENT_DB_BU]STUDENT_DB_FULL_BACKUP.RBF;11
09 not completely copied
%COPY-E-CLOSEIN, error closing ES40::DISK$DGA205:[STUDENT_DB_BU]STUDENT_DB_FULL_BACKUP.RBF;1109 as input
-RMS-F-WBE, error on write behind
-SYSTEM-F-LINKABORT, network partner aborted logical link
The copy command looks thusly (on the test Alpha):
$ copy/log es40::student_db_backup_dir:student_db_full_backup.rbf; student_db_backup_dir:*
I tried a copy of a smaller file (4685 blocks) and it took about 3 minutes to complete, where it should take just seconds.
Neither of the Alphas crash when the copy fails.
We've had the slow copy problem before, and the solution was to make sure the switch ports were the same as the NICs on the Alphas (100 bps/full duplex), which they are now. But I don't remember seeing the copy fail before.
NETSERVER.LOG on the "remote" node doesn't show any errors.
Any thoughts on this?
Thanks in advance!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2008 04:46 PM
тАО08-06-2008 04:46 PM
Re: Failed/slow DECnet copy
A duplex mismatch can cause all kinds of problems, including slow transfers and failures.
Use $ MCR LANCP SHOW DEVICE/INTERNAL to see the state of your adapter and any duplex mismatch warnings (depending on what version you're running).
I'd STRONGLY recommend you set all your adapters on all systems to AUTONEGOTIATE, and make sure all your switch ports are set the same. Any rumours you hear about autonegotiate not working are ancient history and long since fixed. If you want reliable network connections, set everything to auto.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2008 05:25 PM
тАО08-06-2008 05:25 PM
Re: Failed/slow DECnet copy
--
John's advice is spot on, as always.
The chap from VMS Engineering who writes the ethernet device drivers has advocated the above for quite some time. Assuming an adapter of DE500-BA or newer, you absolutely, without question, should be able to set the relevant console variable to autonegotiate. Even older adapters like the
DE500-AA and -XA should work, but the -BA is
known to be much more robust.
There may be old, ancient
switches that may be problematic, but I'd not assume that to be the case here.
Forget any device settings via LANCP, at least initially. While there are certainly valid reasons for setting permanent characteristics via LANCP, for the purposes
of resolving physical layer issues (which is likely the case here), start with the something simple.
For completeness, what's the version of VMS and the type of ethernet adapter(s) involved?
Are both nodes on the same switch?
-- Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2008 09:53 PM
тАО08-06-2008 09:53 PM
Re: Failed/slow DECnet copy
$ mc ncp sh k node counters
(or from one node
$ mc ncp sh 'other' counters)
$ mc ncp sh exe cou
and see if you have some "response timeouts", that is the number of lost packets.
It is (marginally more) efficent to do from Alpha1
$ copy file alpha2::"user pass":
than, on alpha2
$ copy alpha1::"user pass":file *.*
You can try to monitor the "quality" of your link with a basic procedure
$ loop:
$ sh ti
$ copy file remote::
$ sh ti
$ del remote::file
$ goto loop
and have a look at the times needed to copy the same file.
Then you can give some info to your network colleagues.
By the way, Vax/Alpha/Itanium, Vms version, all relevant patches applied ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-06-2008 10:05 PM
тАО08-06-2008 10:05 PM
Re: Failed/slow DECnet copy
Are both nodes in the same Decnet area , e.g. 12.100 and 12.101 ?
A slow/saturated Decnet router may be involved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-07-2008 12:03 PM
тАО08-07-2008 12:03 PM
Re: Failed/slow DECnet copy
Can that be a clue?
I also looked at "Response timeouts" in NCP after zeroing the counters and trying a large file copy, but it stayed at zero.
Also: VMS v8.2, TCPIP v5.5 eco 1, DECnet IV
Thanks again!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-07-2008 07:10 PM
тАО08-07-2008 07:10 PM
Re: Failed/slow DECnet copy
Interpreting the resulting error counts from incorrect settings can be interesting. I recently had a case where the error counts did not show anything, and the only symptom was extremely slow transfers [the problem was a duplex mismatch].
Problems can also be caused by loading on the other system, or network contention on other hops in the network.
More data is always helpful.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2008 02:27 AM
тАО08-11-2008 02:27 AM
Re: Failed/slow DECnet copy
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2008 11:49 AM
тАО08-11-2008 11:49 AM
Re: Failed/slow DECnet copy
It turns out that the problem was the switch. (Not the switch port.) The switch was setup to (I hope I remembered this right) be included in a "spanning tree". Removing it fixed the problem.
Also, the network guy that I talked to from HP support told me that any NIC that's less than 1 GB should not be set up for auto_negotiate.