United States    
compaq support options
support home
software & drivers
ask Compaq
reference library
support forum
frequently asked questions
support tools
warranty information
service centers
contact support
product resources
parts for your system
give us feedback
associated links
} what's new
} contract access
} browse patch tree
} search patches
} join mailing list
} feedback
patches by topic
} OpenVMS
} Security
} Tru64 Unix
} Ultrix 32
} Windows
} Windows NT
connection tools
} nameserver lookup
} traceroute
} ping
X25ALP X25ALP_E03B011 X.25 V1.1B for OpenVMS Alpha ECO Summary

TITLE: X25ALP X25ALP_E03B011 X.25 V1.1B for OpenVMS Alpha ECO Summary NOTE: An OpenVMS saveset or PCSI installation file is stored on the Internet in a self-expanding compressed file. The name of the compressed file will be kit_name-dcx_vaxexe for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha. Once the file is copied to your system, it can be expanded by typing RUN compressed_file. The resultant file will be the OpenVMS saveset or PCSI installation file which can be used to install the ECO. Copyright (c) Compaq Computer Corporation 1998. All rights reserved. PRODUCT: X.25 V1.1B for OpenVMS Alpha Systems COMPONENTS: API DECnet/X.25 Device Drivers X.25 Management X.25 Network Layer OP/SYS: OpenVMS Alpha SOURCE: Compaq Computer Corporation ECO INFORMATION: ECO Kit Name: X25ALP_E03B011 ECO Kits Superseded by This ECO Kit: X25ALP_E02B011 ECO Kit Approximate Size: 11264 Blocks DEC-AXPVMS-WANDDECO03-V0101-B-1.PCSI 2896 Blocks DEC-AXPVMS-X25ECO03-V0101-B-1.PCSI 8368 Blocks Kit Applies To: X.25 V1.1B for OpenVMS Alpha Systems OpenVMS Alpha V7.0 through V7.1 System/Cluster Reboot Necessary: Yes Rolling Re-boot Supported: Not Known Installation Rating: INSTALL_UNKNOWN Kit Dependencies: The following remedial kit(s) must be installed BEFORE installation of this kit: None In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: None ECO KIT SUMMARY: An ECO kit exists for X.25 V1.1B for OpenVMS Alpha Systems on OpenVMS Alpha V7.0 through V7.1. This kit addresses the following problems: Problems Addressed in X25ALP_E03B011: Corrections made to X25$ACCESS.EXE: o IO$_ACCESS and IO$M_REDIRECT adds unwanted facilities data, called and calling address fields, causing call to clear with bad data. o For GAP connections posts additional reads when CLR_EXP or data messages are received to allow subsequent CLR messages to be read. NSP links remain after application exit. User application was not receiving all incoming call termination management information so call could not be considered terminated by the user application. o OSI Transport initiates data transmission after X.25 call clearing has been initiated. o Stale connection-id in VCRP causes panic, trying to free memory a second time. o The root of the problem was that a double deallocation of memory was occurring when facilities data was included for clearing connections which use the X25$ACCESS port to OSI Transport. The problems appeared during both the CLEAR and CLRC operations. There are additional symptoms, causing errors as a result of: - timer queue entries becoming corrupted, - VCRP double deallocation when pool checking was enabled, or - clear or clear confirm messages with facilities data from Routeabout Routers. Corrections made to X25$ZSDRIVER.EXE: o Crash in ZSDRIVER when line not in use, apparently from sufficient noise on the line to cause a data overrun. Corrections made to X25$ACCESS.EXE and X25$ZWDRIVER.EXE: o Sufficient amounts of data of a "fast" system, such as an AlphaServer 4100, caused data transmission to cease. The ZWDRIVER was needlessly consuming large amounts CPU time on AlphaServer 4000 family systems. For PBXDP cards with greater than 2 ports, the modem control signals for each of ports 0, 2, 4 and 6, was based solely on the state of port 0, and likewise, the modem control signals for ports 1, 3, 5 and 7 was base on port 1. The modem control signal DTR state was being destroyed after reading from the register on the PBXDP that controls DTR. Corrections made to X25$ZSDRIVER.EXE and X25$ZWDRIVER.EXE: o When using internal clocking, attempts to set the clock speed too high can cause a system crash with arithmetic exception - integer divide by 0. The driver assumed a transmit underrun could only happen while it still had a transmit frame in progress and it would panic. Corrections made to X25$MEL.EXE: o "NCL SHOW X25 PROTOCOL DTE" counters are negative or incorrect when used in conjunction with the SNAP command modifier. Corrections made to X25$L2.EXE: o When connected to a RouteAbout, X.25 thought the RouteAbout had a receive window of 0 and consequently could not receive frames. Therefore, X,25 would not send any response to the X.25 RESTART packet from the RouteAbout. o A panic occurred during X25 shutdown when LLC2 is used over FDDI, due to the premature deallocation of the VCIB used for communication between LLC2 and the FDDI driver. o Under certain circumstances, the response to an RR was lost from the remote system, and the software would send out two I frames of data with the same sequence number, followed by a rejection of the RR after the lost RR message. Corrections made to X25$KERNEL_RTL.EXE: o The "NCL NODE SHOW LINK" failed on remote node. Corrections made to X25$ACCESS.EXE and X25$NWDRIVER.EXE: o The problem occurred when a DTE on a gateway port was dropped and an Alpha application using PVC did not get notified of the restart from the gateway. An insufficient number of reads were being issued to process the network management commands (NOCOMM, RESET, RESTART) along with the incoming data frames. Problems Addressed in X25ALP_E02B011: o Stop ZWDRIVER needlessly consuming large amounts CPU time on AlphaServer 4000 family systems. o On PBXDP boards with more than 2 ports, correctly report the state of the modem control signals of ports above the first two. (The previous driver incorrectly reported the state of modem control signals for port 0 as the state of the modem control signals for each of ports 0, 2, 4 and 6 AND reported the state of the modem control signals for port 1 as the state of the modem control signals for ports 1, 3, 5 and 7.) o Ensure the state of the modem control signal DTR always is preserved across modifications to the register which controls DTR. Previously the board read the port register and inadvertently changed bit settings when doing so. The change corrects this situation for all ports on the PBXDP synchronous communications card. INSTALLATION NOTES: The images in this kit will not take effect until the system is rebooted. If there are other nodes in the VMScluster, they must also be rebooted in order to make use of the new image(s).

This patch can be found at any of these sites:

Colorado Site
Georgia Site

Files on this server are as follows:


privacy and legal statement