[Top][All Lists]

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

Re: [GnuCOBOL-Dev] GnuCOBOL file description

From: Ron Norman
Subject: Re: [GnuCOBOL-Dev] GnuCOBOL file description
Date: Mon, 17 Jun 2019 14:20:33 -0400

I think a simple text file is much easier to handle with minimal overhead and no portability issues and likely much less code and faster.
There is no need for any locking for this.

On Mon, Jun 17, 2019 at 1:23 PM James K. Lowden <address@hidden> wrote:
On Sun, 16 Jun 2019 14:48:46 -0400
Ron Norman <address@hidden> wrote:

> Pleas review the attached document about having GnuCOBOL write/read
> data file descriptions using a separate text file in the same
> directory as the data file.

While I applaud the goal, I suggest we consider a different design. 

Instead of a per-file textual description littering the file namespace,
why not a centralized, machine-readable description? 

I would propose a SQLite database in /var/gnucobol/files (where the
name of the database is "files").  The location could be overridden by
an environment variable.  Advantages:

1.  Simple to interrogate.

2.  No parsing or serialization.

3.  Can enforce rules.

4.  File namespace remains clean.

5.  User cannot accidently delete/munge the metadata.

6.  Could also be used to enforce locking.

SQLite is in the public domain.  Its on-disk format hasn't changed
since 2006.  It's simple to write the proposed cob_{read,write}_dict
modules in terms of SQLite.  While it's easy to write them in C, it
might be more interesting to develop them in Cobol; it would be an
opportunity to integrate SQLite with GnuCOBOL. 

As an example of the kinds of features a SQLite implementation could
bring, there could be a table of the names of file conversion

        create table conversions (
                input text not NULL,
                output text not NULL,
                subroutine text not NULL,
                primary key(input, output),
                foreign key (input) references (,
                foreign key (output) references (

The conversions table could inform the user (or programmer) of available
conversions, and could be used by the programmer to select the
conversion routine dynamically.  It can also display potential
conversions not currently supported. 

If the idea is intriguing, I could sketch out a design and queries to
support the functionality. If adopted, I could write the initial C
version of the read/write routines. 

After the merge, of course.  :-/ 


Ron Norman

reply via email to

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