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