Jim asks:
> Are there
> strong reasons to just use Eloquence as a DBM and develop in
> another language, presumably using an ODBC driver to access the
> data?

Eloquence works just like Image in that there is a library of DBOPEN,
DBFIND, DBGET, etc. routines that you can link into any standard compiled
language.  This Eloquence client library is also capable of talking to
databases which physically reside on other servers.  So the only reason to
use an ODBC driver is if you have a client tool that only supports ODBC or
it's otherwise more convenient for some reason.

I would expect most people porting 3GL code to Unix using Eloquence would
use this TurboImage compatible client library and so would see a development
environment that works just as MPE and TurboImage do.

John adds:

> From our brief acquaintance testing eloquence, the dbms access seems
> very good, excepting the already mentioned lack of partial lists of
> fields to be read/written/updated. i.e., only @ item lists are supported
> so far.

Once again this is *only* a restriction for Eloquence's own Business Basic
compatible language, since the original design of Eloquence did not require
item lists.  If you're programming in C, COBOL, or most other languages,
then what you get is a 100% Image compatible interface that fully supports
item lists.

At the moment the only variance from 100% perfect compatibility (that I can
think of offhand) is that Eloquence will let you update data without a
covering DBLOCK in place (it will generate a temporary one internally) so if
you have code that relies on failing in this situation then you might have a
problem, but as far as I know all non-privileged Image applications really
ought to find that Eloquence *is* Image as far as they can tell.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *