Next: Changes in V4.3
Up: CHANGES AND NEW FEATURES
Previous: Changes in V4.1
The following describes the most significant changes which occurred in HDS
between versions V4.1 and V4.2 (not the current version).
- 1.
- Support for the VAX/VMS operating system has been discontinued
at this version of HDS and all references to VMS usage have been
dropped from this document.
A VAX/VMS implementation of HDS V4.1 remains in operation and
continues to be supported by Starlink on a "care and maintenance"
basis, but as a separate entity. This means that the following and
future additions to HDS will not be applied to the VAX/VMS
version. Users of HDS on VAX/VMS should refer to the documentation
that accompanies it for information, and not to this document.
- 2.
- The OSF1 (Digital UNIX) implementation of HDS now supports file
mapping. This should improve the performance of those applications
that can take advantage of it.
- 3.
- HDS now allows container files that are marked for deletion to
be re-opened for use, so long as they have not yet been closed (and
therefore deleted). This facility was found to be necessary to support
foreign data file access in the NDF library (SSN/20).
- 4.
- Due to the introduction of various new POSIX facilities on OSF1
(Digital UNIX) and associated compiler flags, some untested code was
being compiled and used on this platform. The result was that file
specifications containing "wild-carding" characters could not be
used and the HDS_WILD routine did not function
correctly in recent un-tested distributions of HDS for OSF1. These
problems have now been fixed.
- 5.
- A bug has been fixed which meant that the
HDS_WILD routine would not function correctly if
it was the first HDS routine to be called in an HDS application. A
call to HDS_START would prevent this problem
occurring, but is now no longer necessary.
- 6.
- A bug has been fixed which could result in objects accessed for
modification using file mapping to be written back to their container
files using a write call (instead of unmapping the file) if the
`MAP' tuning parameter was changed between calls to
DAT_MAP (or equivalent) and
DAT_ANNUL (or equivalent). This problem did not
occur if DAT_UNMAP was called to unmap the data
explicitly. Surprisingly, this erroneous behaviour almost always gave
the correct result, but could very occasionally result in a core dump.
- 7.
- A bug has been fixed that could corrupt data in the immediate
neighbourhood of a primitive object slice whose value was
updated. This could only happen in rare circumstances and was normally
limited to slices no more than 32 bytes in length.
- 8.
- Certain error messages that are often the result of an attempt
to access a corrupt HDS container file have been modified to
explicitly give the affected file name.
- 9.
- The HDS makefile has been extensively revised. Amongst other
things, this is to permit automatic distribution via the
Starlink Software Store on the World Wide Web.
- 10.
- This document (SUN/92) has been revised and is now available in
both Latex and hypertext (HTML) forms.
- 11.
- The HDS implementations on SunOS and Ultrix systems have been
superceded by Solaris and OSF1 implementations respectively (the
latter now being called Digital UNIX). The code to support these (and
other) earlier implementations of HDS has been retained, and may be of
use to those wishing to port HDS back to these platforms. However, it
is no longer supported on these systems by Starlink and has not
recently been built or tested on them. An Open VMS implementation of
HDS running on Dec Alpha workstations is also known to exist, but is
not supported by Starlink.
Further information about old or unsupported implementations of HDS
may be obtained by contacting Starlink Software Support
(ussc@star.rl.ac.uk).
Next: Changes in V4.3
Up: CHANGES AND NEW FEATURES
Previous: Changes in V4.1
HDS Hierarchical Data System
Starlink User Note 92
R.F. Warren-Smith & M.D. Lawden
23rd February 1999
E-mail:rfws@star.rl.ac.uk
Copyright (C) 1999 Central Laboratory of the Research Councils