|
From: David E. <de...@us...> - 2005-05-20 21:45:26
|
Roger While wrote: > Is that the "libtoolized" version ? No it's the 1.04 version plus the 'isbuild' (isbuild.c) bug fix from your "libtoolized" version. BTW, I think the 'isbuild' bug is caused by an invalid block number access which starts with block #3. The current solution works, but the underling problem (invalid address ?) needs to be identified and fixed. > Anyway, shoot over the code and I'll diff it up with my version and > then push to CVS. I have been holding off on updating the VBISAM CVS > to see if Trevor had time to pick up on a couple of requests. I will e-mail you a copy. There isn't very many differences. Just some hacks which try to substitute some UN*X features (user id's, file locks, file attributes) which Win32 does not support or has a different implementation. Is there any place where the source code can be uploaded to users to test it ? > (As it is C-ISAM conform and so has it's lacking) I think that C-ISAM compatibility is important but not critical. And this is only because C-ISAM, lacking any formally defined standard (1, 2), has become the industry standard. > Total key length is restricted to 120 bytes. I could not verify this information. But I think it is dependent on what type of record and if compression is used. Even if the maximum key length is 120 bytes, most applications COBOL will not need to exceed limit. > Maximum number of key parts is 8. According to the docs: Unlimited keys per table - Late breaking news: Decided to limit key count to 32 for now, will make it dynamic in the future. Up to 32 parts per key. Index depth <= 65535 levels (Highly unlikely that > 4 or 5 levels would ever exist!) My interpretation of this is that the number of key segments may be limited (up to32 parts per key), the number of keys (index depth <= 65535 levels) is not very limited. > There is no facility to specify own key comparison routine. > Using manual locking, there is no way to lock a record on insert. I could not verify this information using the documentation. However, I did notice some comments on one of the source files, which now I can't find, indicating a way to use your own comparison routine. > Note : This is still not ready for use by Cobol I agree that further tests and development will be required. I've written a couple of C test program which mimics a simple COBOL application. One program creates a primary key (no dups) and a secondary key (with duplicates), and then performs a sequential read using the primary key. Another program, sets a starting point and then performs a sequential read using the secondary key. So far, my tests indicate that even in it's current state, VBISAM could be used to support indexed files. So the question is: Is VBISAM a better option than the current method using BDB ? In my view the answer is YES. 1) ISAM Category: Data Management [DM] Support for programs using the indexed sequential file access method. http://www.opengroup.org/public/prods/dmm4.htm 2) D010 Indexed Sequential Access Method (ISAM) 8/90 http://www.opengroup.org/public/pubs/catalog/d010.htm (Publication is no longer available) |