 |
Current Release Information
The currently shipping version of C-Index/II is Release 5.0c.
Release 5.0c
Release 5.0c is a maintenance update for Release 5.0b. The only significant bug fixed related to reading of cross-platform files on Unix systems, which could cause a memory access violation with some compiler settings.
Release 5.0b
Release 5.0b is a maintenance update for Release 5.0. Compilers directly supported by this release are:
Win32 (Windows NT, Windows 98, and Windows 95) DLL
Visual C++ 5.x
Unix Generic System V
ANSI or K&R
Macintosh
MPW C
Example ports which are not tested or supported in this release include:
MSDOS
Microsoft C 8.0
Borland C/C++ 3.1/4.x
MetaWare HighC 3.0
PharLap/Borland 3.1
Microsoft Windows 3.x DLL compiled using Borland C
Borland C/C++ 3.1
Borland C/C++ 4.0
Microsoft Windows 3.x DLL compiled using Visual C
Visual C 1.5
Win32 (Windows NT and Windows 95) Library
Visual C++ 1.1
Visual C++ 2.0
Borland 4.x 32 Bit
OS/2 2.x
Borland C/C++
Windows NT
Microsoft Visual C++ 4.x Library
Microsoft Visual C++ 4.x, Win32 DLL
Borland 4.x 32 bit compiler
Borland 5.x 32 bit compiler
VAX/VMS
Vax C Compiler
IBM 370
IBM C
Release 5.0
C-Index/II Release 5.0 was a major feature enhancement update which replaced Release 4.2b. It included fundamental performance improvements and many useful new features.
ReadShare
The new ReadShare feature has been added to improve performance of multi-user access. When multiple processes are reading from a file, they all have access to the file simultaneously. Without ReadShare, only one process has access to the file when reading or writing. With ReadShare, C-Index/II is able to read from the file without locking out other processes, provided that no write operation is pending. Since most applications spend the majority of time reading from a file, this can have dramatic improvement in access times.
SpeedRead
A new performance feature has been added called "SpeedRead". When SpeedRead is turned on, C-Index/II will try to satisfy any read operations from information that is already in the local virtual memory disk buffers, without performing any file locks or checking if the file has been changed on the server. If the entire read operation cannot be processed from disk buffers, it will retry using the usual method that verifies the status of the buffers, locks the file for reading, and updates the buffers in memory as required.
SpeedRead improves the performance of the read functions in Release 4.2b (cnext, cprev, cgetcur, cfind, and dseq). Although the main benefit of SpeedRead is for multi-user applications, it will improve the performance of single-user file access as well. An example of the single-user performance improvement can be shown using the testman manual test utility in EXCL mode. With 10,000 entries of 10 bytes each, cnext with SpeedRead turned on is three times faster than cnext with SpeedRead turned off. Alternatively, cnextrep and cnextrep2 are nine times faster than cnext with SpeedRead turned off.
Additional Performance Enhancements
Performance improvements have been made in other areas. For example, random key searches are faster, and file access is faster when DENYWRITE share mode is used for opening the file.
New Relative Key Position Functions
Two new functions have been added for handling relative key position. The cigetrel function returns a value indicating the relative position of the current key in an index. The cisetrel will set the current key position to a key which matches the relative key position specified. These functions can be used together to manage scroll bar elevators in GUI based applications. It can also be used for showing relative completion of tasks that traverse an index, such as printing of reports.
New cnextrep2 Function
A new fast next function has been added: cnextrep2. It is identical to cnextrep with two exceptions. In cnextrep2, any C-Index/II function (except cnextrep2 itself, which is not reentrant) can be called from within the callback function. For example, a multi-key record referenced by a key passed to the callback could be deleted from within the callback by calling ddelete. The only other difference is that cnextrep2 passes the current key value to the callback before doing a next operation. This allows the application to position to a starting key value and have the callback process all of the keys involved, including the first one. Both of these changes will simplify typical uses compared with the cnextrep function. See test7 for examples of how cnextrep2 can be used.
New dcheck Function
A new function has been added for checking the integrity of the multi-key data records. Calling the dcheck() function will validate that all records have the correct corresponding keys pointing to the record and conversely, all keys point to the correct record. This is an important addition to the PowerFail Protection feature for use with the bcheck function in multi-key applications.
Deleting Fields in Datalist
Normally, a datalist cannot be modified after it has been used to add records to the C-Index/II file. A new feature in Release 5.0 makes it possible to mark fields in the datalist as deleted. Deleted fields are not included in records added or updated. When a record is updated the system also determines if the deleted field of the existing record was included in an index. If so, the key value in that index is deleted.
There are a number of applications for deleting an existing field. The most obvious is to remove fields from use when they are not needed in the application. This could be used in combination with the psp field checkflg. By setting psp->checkflg to FALSE, C-Index/II will not verify that the datalist is the same as when the record was written to disk. That way new fields can be added to the end of the datalist with old fields being removed from the records by marking them as deleted.
Another use is to allow more flexibility in how a record is indexed. First, create several fields as segmented key fields and reserve them for future use by marking them as deleted. At the time of calling dadd or dupdate the application can turn on and off the segmented key fields depending on the nature of the record, allowing a record from a single datalist to be indexed differently depending on its content. Since segmented key fields are virtual fields, this changing of the datalist does not affect dread. On dupdate your application can set the pattern of deleted segmented key fields to reflect any changes in the nature of the record.
|
