<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