SEARCH CONTACT US SUPPORT SERVICES PRODUCTS STORE
United States    
COMPAQ STORE | PRODUCTS | SERVICES | SUPPORT | CONTACT US | SEARCH
gears
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
.
} DOS
.
} OpenVMS
.
} Security
.
} Tru64 Unix
.
} Ultrix 32
.
} Windows
.
} Windows NT
.
connection tools
.
} nameserver lookup
.
} traceroute
.
} ping
OpenVMS AXPLIBO02_061 Alpha V6.1 LIBOTS ECO Summary

Copyright (c) Digital Equipment Corporation 1994, 1995. All rights reserved. OP/SYS: OpenVMS Alpha COMPONENTS: LIBOTS SOURCE: Digital Equipment Corporation ECO INFORMATION: ECO Kit Name: AXPLIBO02_061 ECO Kits Superseded by This ECO Kit: AXPLIBO01_061 ECO Kit Approximate Size: 670 Blocks Kit Applies To: OpenVMS Alpha V6.1, V6.1-1H1, V6.1-1H2 System Reboot Necessary: Yes ECO KIT SUMMARY: An ECO kit exists for LIBOTS on OpenVMS Alpha V6.1 through V6.1-1H2. This kit addresses the following problems: Problems addressed in the AXPLIBO02_061 kit: o Using the compiler switch /GRANULARITY=BYTE will cause the wrong bits to be fetched. This could result in user programs that cause data corruption. o Small X-Floats in T-Float denorm range were being incorrectly converted to zero. o T-Float denorms converted to X-Float were incorrect by a factor of 2. NOTE: The X-Float datatype is a new datatype supported by OpenVMS Alpha starting with OpenVMS Alpha V6.1. It is a 128 bit IEEE floating point datatype that is implemented in software, specifically LIBOTS. X-Float is represented as a REAL*16 in Fortran. Problems addressed in the AXPLIBO01_061 kit: o The LIBOTS routine OTS$INSV_VOL can write values to the wrong address and corrupt data. The LIBOTS INSV/EXTV corruption can be seen if a volatile longword doesn't start on a byte-boundary. This can seen in languages like C and Pascal when dealing with poorly aligned data. For Pascal, you can see it with a record like: type r = packed record f1 : boolean; f2 : integer; end; For C, you can see it with a record like: #pragma nomember_alignment struct r { unsigned f1 : 1; unsigned f2 : 32; }; Given a Pascal user's tendency to use the PACKED keyword, the problem is more likely to occur in Pascal rather than C. C users would have to go out of their way to use a 32-bit bitfield which is not very common. This problem can also be seen from BLISS and possibly Ada. INSTALLATION NOTES: In order for the corrections in this kit to take effect, the system must be rebooted. If the system is a member of a VMScluster, the entire cluster should 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:

axplibo02_061_libots.README
axplibo02_061.CHKSUM
axplibo02_061.a-dcx_axpexe

privacy and legal statement