dick scherrer wrote:Which has nothing to do with anything in this topic as far as i can see . . .
Previous post was commenting on good performance of Syncsort. Easytrieve Plus will use Syncsort (or whatever is installed).
dick scherrer wrote:Easytrieve uses far more cpu because it is nearly always interpreted rather than executed.
In batch? Where you're likely to be using Syncsort? Hey, I suppose there may be some online Easytrieve Plus, I don't know, but if you are running it in batch, it is compiled - or to put it another way, I'd like to see your PARM statement to "interpret" it.
I once used a product called EZ/KEY from Pansophic which was a "development environment" for Easytrieve Plus. Sure flattened the CPU if you tried to do a SYNTAX check.
I've never seen any performance problems with Easytrieve Plus. At one site, to get authorisation to use it in production, we had to "race" against equivalent COBOL programs. On seeing the results, the production department wanted to order us to write every program possible in Easytrieve rather than COBOL. We didn't do it that way, we used whichever we thought was most appropriate, but we certainly never worried about performance.
We also generated Easytrieve record layouts from the Data Dictionary, so same as the COBOL. Then, when you do your sort, in Easytrieve Plus, using Syncsort, in the Easytrieve you are referring to data names, not offsets in the file (never had to worry about those 4 bytes on a variable-length record). Then even the business analysts could read the sorts.
If anyone has performance problems with Easytrieve Plus, and happens to be reading this Syncsort forum, and wants them looked at, stick a question in the Easytrieve forum.