Gavin corrects my assumption.

>Ken elbows:
>>And you do always have to handle all the routine details of
>>IMAGE intrinsics....

> Less so than other languages.

I somewhat sheepishly admit that it's been so many years
since I have even looked at IMAGE access from BASIC that
I have only the vaguest recollection of the details....  Well,
there's still the short variable name problem.  One out of two
ain't bad ??  .. Or maybe I can go for 1.4 out of two ??...  I'll
settle for that....

> So BASIC actually has much BETTER Image support than
> most other 3GL languages.  Transact, Java, and most 4GLish
> languages generally provide the same or better functionality.
> The Java Image interface(s) should be particularly nice to
> program with.

If Java can end up combining the ease and flexibility of IMAGE
access from Transact/iX with the network access power of C++
in one well-structured and "well-behaved" language, then we've
really got something:  One programming *and* debugging
environment to go from client GUI to IMAGE I/O;  wall-to-wall,
as it were...

Not being able to do the last above with one "system" is one
of the inefficiencies we still have to deal with here at NUWC:
Transact/iX is superb at IMAGE I/O, but reasonably lousy
for event-driven client I/O on the net. C/iX and C++ do the net,
but from what little I've picked up doing direct IMAGE I/O with
C can be, shall we say, tedious.

Even with the "probably coming soon" and very valuable
Transact enhancement to allow import of externally generated
database and file ID's, doing effective end-to-end debugging
from the client front end all the way through to IMAGE is still
somewhat of a problem....

Ken Sletten