gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[open-cobol-list] Re: VBISAM Win32 port (2)


From: David Essex
Subject: [open-cobol-list] Re: VBISAM Win32 port (2)
Date: Fri May 20 14:47:23 2005
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722

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)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]