|
HP OpenVMS Systemsask the wizard |
|
The Question is:
We have a VAX 7860 running 6.2 and an Alpha 4100
running 6.2-1H3. Both are using DECnet IV.
Intermittenly, when accessing files on the Alpha
from the VAX over DECnet, we encounter the
following error:
%TYPE-W-READERR, error reading ADMAX1::D1:[TEMP]A.LOG;4
-RMS-F-SYS, QIO system service request failed
-SYSTEM-F-LINKEXIT, network partner exited
%TYPE-W-CLOSEIN, error closing ADMAX1::D1:[TEMP]A.LOG;4 as input
-RMS-F-WBE, error on write behind
-SYSTEM-F-LINKABORT, network partner aborted logical link
The line counter on the VAX is as follows:
7561 Seconds since last zeroed
604408 Data blocks received
34183 Multicast blocks received
371 Receive failure, including:
Frame too long
136119604 Bytes received
2700717 Multicast bytes received
0 Data overrun
635141 Data blocks sent
3776 Multicast blocks sent
2229 Blocks sent, multiple collisions
1954 Blocks sent, single collision
2491 Blocks sent, initially deferred
149094526 Bytes sent
395512 Multicast bytes sent
0 Send failure
>65534 Collision detect check failure
371 Unrecognized frame destination
0 System buffer unavailable
11 User buffer unavailable
And the line counter on the Alpha is as follows:
>65534 Seconds since last zeroed
8090015 Data blocks received
184059 Multicast blocks received
5483 Receive failure, including:
Block check error
Framing error
908085207 Bytes received
12451483 Multicast bytes received
0 Data overrun
8982148 Data blocks sent
4696 Multicast blocks sent
0 Blocks sent, multiple collisions
0 Blocks sent, single collision
0 Blocks sent, initially deferred
3555041617 Bytes sent
192240 Multicast bytes sent
2 Send failure, including:
Carrier check failed
0 Collision detect check failure
0 Unrecognized frame destination
0 System buffer unavailable
0 User buffer unavailable
We have checked the hardware and it seems OK.
Could it be related to the executor settings
or the process quota?
The Answer is : If you have 7561 seconds since last zeroed -- that's about two hours -- and of 635141 data blocks traversing the VAX, the VAX system encountered problems sending 6674 of these blocks -- 2229 blocks deferred due to multiple collisions, 1954 blocks defered due to single collision, and 2491 blocks sent that deferred before sending, your network appears to have a problem -- these values tend to indicate your network is jammed. Contrast this with the Alpha, where no problems were encountered. The OpenVMS Wizard would recommend checking the VAX 7000 model 860 LAN network segment and the network controller for potential problems. Check for poor or missing termination, faulty LAN cables, incorrect LAN wiring, and similar problems. Also check to see if the transceiver heartbeat is set appropriately, with the appropriate cabling used -- there is an unusually large value for the number of collision detect check failures. Further, check the OpenVMS Alpha system, as it is possible that the network controller is triggering the problem with the OpenVMS VAX controller -- one potential cause of this behaviour is a network controller set to full-duplex operations on a half-duplex circuit. The user buffer unavailable count value indicates that the applications are occasionally getting bogged down, and not responding. (See the SDA command SHOW LAN/COUNT to try to track this application down.) If you are unable to locate the cause, please contact your hardware support organization.
|