Eric continues the thread: >The point I was making was that I only have to maintain >200 lines of COBOL code. Yes, I understand; that is a real benefit... >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.... With Transact you end up with "pure" NMPRG files and NMXL XL's. So with well-written code, for practical purposes performance of NM Transact/iX should be as good as well- written COBOL or C or PASCAL (notice I did not say exactly the same; there may be small variations). And since Transact is a fully-procedural language, you should be able (on the 3000, going against TurboIMAGE) to do anything in Transact that you can do in COBOL.... Plus with Trandebug/iX we have a good host-based debugging environment. The one big weakness Transact still has is being able to easily deal with the network / sockets / client-server I/O. That's why network server programs are best written in "C"; then those programs can call Transact/iX modules to implement business rules and do the IMAGE I/O. Note that the "Open Transact" enhancement currently being looked at by the RAPID Lab will make that a lot easier. ... O.K., Duane: I'll save you the trouble of jumping on the above opening I just gave you: Yes, I know QWEBS is written entirely in COBOL; and obviously that deals extensively with the net. It's not necessarily impossible in Transact either, I guess; but dealing with variable-length, event driven input from a client can be difficult; "C" is a lot better at that (so I'm told by people who are "C" gurus; I'm not). And, yes, with some other 4GL systems performance (or, rather, the lack thereof) can definitely be a problem.... But not with Transact/iX... Ken Sletten