Re: Re: Acucobol interface - Mailing list pgsql-hackers

At 15.38 07/06/01 -0400, mlw wrote:

>Roberto Fichera wrote:
>
> >
> > >I am reticent to admit that I have done a little COBOL and the 
> interface for
> > >data paradigms is very good for a dBase like package. If you can live
> > >without a
> > >client/server interface ala Postgres, and can live with a file based 
> access
> > >methodology, then what you want is doable.
> >
> > The main problem is that we want see our data as relational database
> > and we want continue to use the current programs. Currently we have
> > some customer that have their company archive large around 50Gb.
>
>In what format is this data?

It's a VISION format, a proprietary variant of a B*Tree format.

> > >I'm not aware what platform you wish to run your program, I am assuming
> > >Windows. The old dBase format is currently being used under the name 
> "xbase."
> > >There are many libraries that conform to this file format and offer the
> > >type of
> > >access which you wish to have. On top of that, there are ODBC drivers 
> (in UNIX
> > >and Windows, btw) for these xBase files.
> >
> > Acucobol runtime, currently is present in around 650 different platform
> > (HW/SW)
> > so we can run the same programs in different environment. We use Linux
> > and WNT/W2K as server and W9x/WME as client. Use the xBase format
> > isn't a good choice when we have a several Gb of data, this is why I'm
> > thinking
> > to the PostgreSQL. The current Acucobol's "flat file" isn't adequate to 
> manage
> > such large files, we need a way to see that files as relational DB.
>
>Just out of curiosity, why is the xbase format not a good choice?

Because the DBF format didn't perform well on a large archive of serveral 
million
records. It's don't reuse the deleted records, have a limitation of 255 
fields and
the char() field can be max 255 char in length and the max record size is 4k.

> > >You write acucobol extensions using some generic xbase access layer, 
> and use
> > >the ODBC xbase driver for applications like Access and Excel.
> > >
> > >You'll have to sort out all the issues like concurrent access, and 
> stuff like
> > >that, but it should come pretty close to what you want to do.
>
>I think you are missing the point. A good xbase library will allow you to 
>perform
>"joins" on data across tables. It doesn't have a SQL syntax, but that does not
>mean you can't code that way.
>
>Also, ODBC drivers for xbase use SQL format queries.

I know.

> > I have already done some work. I've implemented an extension of the generic
> > Acucobol FS layer that talk with a PostgreSQL. This lowlevel layer
> > translate each
> > FS primitive in a query. The acucobol's record is translated in attribute
> > (and vice versa)
> > using a XFD file (eXtended Fields Description) which describe each record's
> > field and
> > that is cached in memory. This file is generated by the acucobol compiler
> > for each used file.
> > With this informations I'm able to perform a complete query to the
> > PostgreSQL, the
> > returned tuples will be translated in the expected "flat record" and
> > finally returned to the
> > runtime for its work.
> >
> > I know, the cobol use a different philosophy than a relational DB but this
> > my work
> > show that this two different world could talk. Also, I know the difficulty
> > of the major lowlevel
> > integration. I need some doc/indication/files-to-read of PostgreSQL
> > lowlevel routines
> > to see if this different world could have a major integration bypassing the
> > "overhead" of
> > the query accessing directly to the DB.
>
>I think, strongly, you are going down the wrong track.

Could be ;-)! But I want try to do some work before abandon this
solution.

>Take a look at:
>
>http://sourceforge.net/projects/xdb/

I've take a look on it, and I'd the confirm of the aspected limitations. 
Another
problem of this library is that we can't perform concurrent locks with other
applications different than xdb library. So it's unusable for me.

>http://www.unixodbc.org/

I know it, it's good link!


Roberto Fichera.