Tony after Ken:

>> "Does the COBOL compiler provide for the proper reading
>> of TurboIMAGE datasets through the use of COBOL verbs
>> such as OPEN, READ, WRITE and CLOSE?"
> >> The answer to this question is - no. You must use the DB* Intrinsics.
>
> And like many others, I've long lamented this fact. The image
> intrinsics map SO BEAUTIFULLY onto the COBOL syntax:

> Maybe if we ever get back to doing front-end compiler work for
> the HP3000 we could explore this again? I know it's not
> standard, but WHAT a competitive advantage it could be.....

Tony, sounds like you want high-level, high-performance access
to TurboIMAGE without having to deal with all the intrinsic details.
I've got a news flash for you:  It's already been done:  It's called
Native Mode Transact/iX...  Anything you can do in COBOL you
should be able to do in Transact.....  usually with only ~ 10 - 40
percent of the code....        :-)

But (before anybody jumps on me):  Yes, I know:  Nobody is
learning Transact in school anymore, and the user base is small...
:-(

Then Wirt added:

> Standards aren't all they're cracked up to be. ......  They "level
> the playing field" by bringing a uniform mediocrity to whatever
> they standardize.  .....

Yup.  Several years ago I think it was Alfredo who said that
disparate systems should be able to COMMUNICATE via
standard protocols.  The 3000 can do that, without joining the
masses of back-end "uniform mediocrity".

> I personally prefer to program in BASIC as an upper level
> control/sequencing structure and a macroassembler as a
> means to generate high-efficiency code.

But if you used Transact/iX, you wouldn't have to do a lot of
your own "macroassembling".....  And you wouldn't be stuck
with that seriously limiting "feature" of BASIC:  The two-
character maximum for variable names.  For simple systems
(and perhaps for products like QueryCalc, where the author
probably has many thousands of lines of code essentially
memorized), BASIC might be O.K.  But for end-user apps with
many tens or hundreds of thousands of lines of code, being
restricted to two-character variable names is a BIG drawback:
The code becomes very hard to follow for anyone but the author
(and sometimes even the author, I'll bet), without extensive and
pervasive variable cross-reference tables (which are themselves
a major pain)...   my $0.02...    :-)

...  And now that HP is going to enhance Transact/iX to fully
support Image intrinsic B-Trees, along with that the language
will gain the ability to use *all* IMAGE and TPI modes....

Anyway, I'm with Stan:   Filet mignon forever....

Ken Sletten