[Top][All Lists]

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

[open-cobol-list] Re: [Tiny-cobol-users] ISAM replacement

From: Bernard Giroud
Subject: [open-cobol-list] Re: [Tiny-cobol-users] ISAM replacement
Date: Tue Nov 9 09:51:04 2004

>From what I looked so far:

1) Yes, multiple keys with multiple segments with/without duplicates.
2) It emulates/is compatible with C-ISAM: so data in the .dat file and
indexes in the .idx file.
3) Yes, see 2 above.

Bernard Giroud
Credit Lyonnais (Suisse) SA
----- Original Message -----
From: "David Essex" <address@hidden>
To: "tiny-cobol-users" <address@hidden>
Sent: Tuesday, November 09, 2004 6:22 PM
Subject: Re: [Tiny-cobol-users] ISAM replacement

BTW, does any one know if VBISAM supports the following:

- Multiple keys with duplicates.
- Is the data and index stored in a single or different files.
- Can multiple keys indexes be stored in a single file.

Giroud, Bernard wrote:

> David Essex a écrit :
>> Andrew Cameron wrote:
>> ...
>> > The best way to do it would probably be a switch for the
>> > configure script so you Could choose to use either the old
>> > DB backend or the New VBISAM backend.
>> Modifications to the 'configure script' should not be a problem.
>> However removing BDB will not be easy for the following reasons.
>> First, all types of file IO in the TC RTL use BDB.
> You mean: Indexed, Relative and Sort. But not Sequential nor Line
> sequential.
> And you can always implement a relative file by an indexed one with
> keys.

Actually all file types use the BDB structures.

So even if VBISAM where used just for INDEXED file types, the current
RTL sources would have to be decoupled from BDB.

>> The RTL can be
>> changed to optionally use BDB for only INDEXED file types. However this
>> is not a small change thus will require some work.
>> Second, getting TC to work with VBISAM, for INDEXED file types, will
>> require an addition to the RTL. Again this will require some work.
>> Third, BDB is used for the SORT statement to sort files. I do not think
>> that VBISAM provides a SORT facility. Even if it did it would require
>> some work on the RTL.
> BDB is used implicitly: the additions in the file are arranged in sorted >
> and then it is read again sequentially by the order of the keys. So, any
> ISAM method will work in this case.

If that is true, what is the advantage in duplicating the code just to
use VBISAM instead of BDB ?

> BTW, the sort should really be implemented by a sort, not an indexed
> file method.

I agree, but AFAIK no LGPL SORT utility exists.

>> Perhaps the best solution is not to think of VBISAM as a complete BDB
>> substitute, but as a optional substitute for INDEXED files.
>> > One thing to note when you add an extension try to get it to work
>> > Under all the current platforms supported by TC.
>> VBISAM is supposed to be OS independent, but it appears to have been
>> developed on UN*X. So until it can be compiled and run on Win32 without
>> a POSIX layer (using MinGW), I don not think it can be considered a
>> serious contender for BDB.
> I agree this might be a problem.
>> Anyway, my 2 cent worth.

This e-mail contains confidential information or information belonging 
to the Credit Lyonnais Group entity sending it and is intended solely 
for the addressees. Any views expressed in this message are those of 
the individual sender and its contents do not constitute a commitment 
by Credit Lyonnais unless confirmed by letter or fax. The unauthorised 
disclosure, use, dissemination or copying (either whole or partial) of 
this e-mail, or any information it contains, is prohibited. E-mails are 
susceptible to alteration and their integrity cannot be guaranteed.
Internet communications are not secured and therefore Credit Lyonnais 
shall not be liable for this e-mail if modified or falsified. If you 
are not the intended recipient of this e-mail, please delete it 
immediately from your system and notify the sender of the wrong 
delivery and the mail deletion.

reply via email to

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