I mean the second, using the COBOL SORT verb to invoke the SORT from within the program. And I tend to agree with you. Just looking for reasons other than the ones I have thought of to refute the claim that was made.
Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Shmuel Metz (Seymour J.) Sent: Monday, November 25, 2013 11:30 AM To: [email protected] Subject: Re: Has anyone measured CPU savings using external SORT's vs internal (COBOL) SORT's? In <985915eee6984740ae93f8495c624c6c231f711...@jscpcwexmaa1.bsg.ad.adp.com>, on 11/25/2013 at 10:43 AM, "Farley, Peter x23353" <[email protected]> said: >It has been suggested to management here that there could be >potentially significant CPU savings from re-engineering application >programs such that any SORT's are done in a separate step, so that >a program with a single internal SORT would be broken up into a >pre-SORT process followed by an external SORT of the massaged data >followed by a post-process of the SORTed data. By "internal sort" do you mean a sort programmed in COBOL, or do you mean invoking the sort utility from within the COBOL program? If the latter, why would separate job steps be more efficient? For that matter, why wouldn't it be less efficient? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
