<In response to Ken's response to Steve and I>

The point I was making was that I only have to maintain 200 lines of
COBOL code.
The contents of the COPY statements are static and do not change when
they are
used by any number of programs. I don't know about Transact object
efficiencies but
I have had to rewrite several 4GL programs(not Transact) in COBOL or C
or Pascal to gain object efficiency when that 4th GL object was used in
a heavy production environment frequently. The main objective in using
COBOL(or C or Pascal) with such organizational techniques is to gain a
balance between maintainability/control and a minimally sized efficient
object.


In that regard......fiat lux......||*(


Eric Sand



        Eric after Steve:

        <<  Be carefull not to malign COBOL. With the organizational
        techiniques I've been using for 15+ years I can access any
        Image DB with 2 COPYLIB references in the Data Division and
        one COPYLIB reference in the PROCEDURE Division for each
        Image function with a corresponding PERFORM. Using this
        technique with other "encapsulation" concepts I've generated
        2000+ lines of COBOL code with 200 lines of source. >>

        I'm sure what you say above is completely valid.... BUT:  You
        still end up with 2000+ lines of COBOL code in the end product.
        That's not the case with Transact/iX:  The small amount of code
        you start with is what you end up with....    :-)

        > Don't forget, spaghetti code can be written in any
language.....!

        Always.....

        Ken Sletten