Re: Acucobol interface - Mailing list pgsql-hackers

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?

> >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?

> >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 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.  Take a look at:

http://sourceforge.net/projects/xdb/
http://www.unixodbc.org/



>
>
> Roberto Fichera.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html