Re: Re: Acucobol interface
От | Roberto Fichera |
---|---|
Тема | Re: Re: Acucobol interface |
Дата | |
Msg-id | 5.1.0.14.2.20010607150846.03409d10@mail.tekno-soft.it обсуждение исходный текст |
Ответ на | Re: Acucobol interface (mlw <markw@mohawksoft.com>) |
Список | pgsql-hackers |
At 08.03 07/06/01 -0400, mlw wrote: >Roberto Fichera wrote: > > > > Hi All, > > > > I'm developing (currently in pre-alfa stage) a Acucobol interface for the > > Postgresql. > > The Acucobol runtime have a generic FS API interface that handle the work > > with the > > record oriented files, defining the open, close, read, write and so on low > > level function I can > > extend the runtime to talk with any file and database. > > > > My current work translate each Acucobol FS command in a relative Postgresql > > query and > > the returned tuple will be translated in a record oriented view. > > After some performance tests I've notice that this path have much overhead > > and because > > this I was thinking to redesign the interface. > > > > My first think was to bypass the SQL translation and use the Postgresql low > > level routines. > > I need to see the tables as record oriented archive, so I can scan > > sequentially (forward and > > backward) each record, lock/unlock it, insert and delete it and start to > > read the records with > > a match of a specific key. > > > > Does anyone know where can I start to search/read/learn/study some > > document/code of the > > Postgresql low level routines ? > > > > If need some detail, please ask ;-)! > > > > Thanks in advance. > > > > Roberto Fichera. > >What you are looking for is a very powerful database back-end, as Tom Lane >suggests, something like Berkeley DB might do, but then what you want is a SQL >interface over that. I've already evaluated the Berkeley DB interface, and surely it's a good interface, it maybe superior of the current Acucobol proprietary format when the archive is very large (several Gb). >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. >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. >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 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. Roberto Fichera.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Stephan SzaboДата:
Сообщение: Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards