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 ALPLIBR08_071 Alpha V7.1 - V7.1-1H2 LIBRTL ECO Summary

TITLE: OpenVMS ALPLIBR08_071 Alpha V7.1 - V7.1-1H2 LIBRTL ECO Summary Modification Date: 04-DEC-98 Modification Type: Updated Kit: Supersedes ALPLIBR07_071 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: DIGITAL OpenVMS Alpha COMPONENTS: LIBRTL.EXE LIBRTL_INSTRUMENTED.EXE SOURCE: Compaq Computer Corporation ECO INFORMATION: ECO Kit Name: ALPLIBR08_071 ECO Kits Superseded by This ECO Kit: ALPLIBR07_071 ALPLIBR06_071 ALPLIBR05_071 ALPLIBR04_071 ALPLIBR03_071 ALPLIBR02_071 ALPLIBR01_071 ECO Kit Approximate Size: 4806 Blocks Kit Applies To: OpenVMS Alpha V7.1, V7.1-1H1, V7.1-1H2 System and Cluster Reboot Necessary: Yes Rolling Reboot Supported? Yes Installation Rating: 3 - To be installed on all systems running the listed versions of OpenVMS which are experiencing the problems described. 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 LIBRTL on OpenVMS Alpha V7.1 through V7.1-1H2. This kit addresses the following problems: Problems addressed in ALPLIBR08_071: o For OpenVMS V7.0, the run-time library (LIBRTL) routine OTS$CVT_TU_L (convert text unsigned to long) was made 64-bit address aware and quadword conversions were added. This resulted in a `signed' overflow check being performed in the `unsigned' case. Consequently, some conversions were reported as overflow errors when they were in fact good. o For OpenVMS V7.0, the run-time library (LIBRTL) routine STR$ADD (string add) was made 64-bit address aware to support 64-bit string descriptors. This resulted in one of the `input' parameters being overwritten with an intermediate value. The documentation lists this parameter as read-only. o For the FORTRAN Run-time Library (RTL), ensure that a large enough buffer is allocated, if the size the user requested buffer is bigger than the current intermediate buffer. o The run-time library (RTL) routine LIB$GETDVI failed fo CLASS_VS (varying string) descriptors. Varying strings were most often found in PASCAL language programs. Problems addressed in ALPLIBR07_071: o The string copy routine STR$COPY_R_R8 accepts a source length argument in a register. This should be interpreted as an unsigned word, the upper portion of the register being masked off. o LIB$VM_MALLOC (used by C RTL routine "malloc") obtains memory using $EXPREG. In the case where $EXPREG fails to return enough memory to satisfy a given request, such "leftover" memory is placed on a LIB$VM_MALLOC free list. This tends to occur when a process has reached all its virtual address space limit, or for some reason asks for an exceptionally large memory allocation. The problem is that this "leftover" memory is probably the last memory available to the process, and interferes with any "last ditch" attempts to recover. Another scenario is where a task can be performed in 2 ways, one of which involves using a large amount of memory. This can result in LIB$VM_MALLOC grabbing a large amount of virtual memory and putting it on its free list. Problems Addressed in ALPLIBR06_071: o The wrong length was returned in the resultant-length field from LIB$GET_FOREIGN in the case that the input string was truncated. LIB$GET_FOREIGN was returning the original length of the string instead of the truncated length. o LIB$CONVERT_DATE_STRING handles 2-digit years from input by selecting the current century as the default to use for the century portion of the date. This behavior may not be desirable for many customers since 00 would be interpreted as 1900 (and then as 2000 on 1/1/2000). Unfortunately, it has been documented since V6.0 and therefore we could not see changing the Y format without disrupting customers who expect this behavior. Problems Addressed in ALPLIBR05_071: o Please see the problem description in the ALPLIBR03_071 documentation below. The problem described was not totally resolved by the ALPLIBR03_071 remedial kit. This kit fixes the problem. Problems Addressed in ALPLIBR04_071: o A "not valid type" error occurred as a result of a change in LIBRTL. Problems Addressed in ALPLIBR03_071: o The LIB$CVT_DX_DX routine will return an access violation status when called from BASIC with a zero length source string. This may potentially happen with other languages as well. This only occurs for NBDS to NBDS conversions. There is an additional problem in NBDS to NBDS conversions, where the length returned does not account for extra spaces on the end of the string (excluding space padding). Problems Addressed in ALPLIBR02_071: o Memory leak in repeated calls to lib$init_date_time_context and lib$free_date_time_context causes memory to be exhausted. Problems Addressed in ALPLIBR01_071: o When using the ACCOUNTING utility to format and display accounting records, certain record types display erroneous values for elapsed time and processor time. o X-FLOAT numbers are not rounding correctly when doing formatted I/O from Pascal. o A hang will occur when LIB$FIND_IMAGE_SYMBOL is called recursively. This manifested itself in a C++ program where the recursive call to LIB$FIND_IMAGE_SYMBOL occurred because of its use in a constructor. 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). If it is not possible or convenient to reboot the entire cluster at this time, a rolling re-boot may be performed. During installation you may see the following message: %INSTALL-E-NODELSHRADR, unable to delete image with shareable address data -INSTALL-I-PLSREBOOT, please reboot to install a new version of this image This is not a cause for concern. It simply means that LIBRTL.EXE was installed as a resident image, which is the standard configuration for OpenVMS Alpha systems. The new image will not take effect until the system is rebooted.



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

alplibr08_071.README
alplibr08_071.CHKSUM
alplibr08_071.CVRLET_TXT
alplibr08_071.a-dcx_axpexe

privacy and legal statement