Re: Possible to stop SORT before EOF?
Posted: Thu Feb 17, 2011 9:08 am
Hello,
Please pay closer attention - it is more important to reply with information that fits the dialog rather than with personal preference. . . For many people/places, Easytrieve is their "go to" tool. Often a very good choice. But every coding opportunity is not a nail, so always using the hammer is not always the best (or even a good) solution.
Of course this is batch - rather silly to even consider "a few million records" in an online process (though i've had a few clients that were unhappy with the results when they did). Easytrieve will use more cpu because it is interpreted - most of the time. Of course i've only seen a few hundred thousand Easytrieve modules/jobs across more than 100 different data centers (been a "migrant data worker" for over 30 years - usually with multiple concurrent clients) . . . Once upon a time a couple of my clients ran some timing tests and determined that unless the data volume was "huge", the cost of the compile outweighed the cost of the interpreted run. Keep in mind that these were not little quick & dirty programs, but rather code that ran into the several thousand lines.
Please confine replies to the part of the forum where the topic is posted. If someone is interested in some other solution, they usually ask for their topic to be relocated.
Please pay closer attention - it is more important to reply with information that fits the dialog rather than with personal preference. . . For many people/places, Easytrieve is their "go to" tool. Often a very good choice. But every coding opportunity is not a nail, so always using the hammer is not always the best (or even a good) solution.
Of course this is batch - rather silly to even consider "a few million records" in an online process (though i've had a few clients that were unhappy with the results when they did). Easytrieve will use more cpu because it is interpreted - most of the time. Of course i've only seen a few hundred thousand Easytrieve modules/jobs across more than 100 different data centers (been a "migrant data worker" for over 30 years - usually with multiple concurrent clients) . . . Once upon a time a couple of my clients ran some timing tests and determined that unless the data volume was "huge", the cost of the compile outweighed the cost of the interpreted run. Keep in mind that these were not little quick & dirty programs, but rather code that ran into the several thousand lines.
Sort performance is not part of this consideration. The main cpu use in an Easytrieve process is used working on the data within the Easytrieve code - and it really is quite expensive.Previous post was commenting on good performance of Syncsort. Easytrieve Plus will use Syncsort (or whatever is installed).
Yup, i've clients who insisted that everythng to be promoted to Production had to be written in the Chosen Language. Others only need written permission to use a particular tool (like Easytrieve or whatever) rather than the Chosen Language.the production department wanted to order us to write every program possible in Easytrieve rather than COBOL
Please confine replies to the part of the forum where the topic is posted. If someone is interested in some other solution, they usually ask for their topic to be relocated.