Peter, John's initial guess was pretty much on target. You first sort is going to do much more work than the second one. You might ask why since it is sorting on fewer key bytes?
The answer is they share the first 3 bytes, which might not seem like much, but it at least groups the data. Let's assume it is a department code, or a country code, it doesn't matter, all of each group are together. Without seeing the specific job output it is tough to give specifics because the size of the records and the size of the keys as a percentage of the record length and the amount of memory all factor into how we process data. (Was that enough of a disclaimer???) Anyway, if all we have to do is do minor re-arrangements on the second pass, then the CPU used is much less. One other thing, all modern sorts re-order and sometimes convert the records so that the keys to be sorted can be processed with a single CLC instruction. Therefore the first sort had to do that conversion on input and then convert it back to the original format on output. The second sort didn't have to do any of that conversion. If you want a fuller explanation, you need to send me offline all the sort messages for both steps. Or, you can call our support folks at 201-930-8260. Actually, I am supposed to refer you there first, but I like to talk to real users directly sometimes. <Advertisement> On our web site at: http://www.syncsort.com/en/Data-Integration/Solutions/Mainframe-Solutions/zIIP-Offload-for-Copy We have information on a new product, MFX ZPCopy. It can significantly reduce CPU cycles used for copy operations. If you are interested, please contact the support people at 201-930-8260. <End-Avertisment> Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: Friday, August 30, 2013 5:22 PM To: [email protected] Subject: Re: Peculiar CPU behavior of SYNCSORT? You're right, the sort orders are not the same. For the CPU example I gave below, the first sort uses these parameters: $ORTPARM: CORE=MAX SYSIN: SORT FIELDS=(1,3,CH,A,17,7,CH,A) The second one gets these: $ORTPARM: CORE=MAX SYSIN: SORT FIELDS=(1,24,CH,A) The application in question is not one I am intimately familiar with so I can't say offhand whether that first sort is very disruptive of the original order or not. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Charles Mills Sent: Friday, August 30, 2013 6:10 PM To: [email protected] Subject: Re: Peculiar CPU behavior of SYNCSORT? Are the keys the same? Is there a difference in how out-of-order each file is going into the sort? > There is no difference in the parameters given via PARM and/or SYSIN Must be a different sort key, right? Or what's the point? Is each sort sequence the same? If you sort a file into a particular sequence, make some fairly slight changes, and then sort it again into the same sequence -- the second sort is going to use a heck of a lot less resources. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Farley, Peter x23353 Sent: Friday, August 30, 2013 3:00 PM To: [email protected] Subject: Peculiar CPU behavior of SYNCSORT? While analyzing high CPU consuming jobs we came across a peculiar behavior of SYNCSORT. Certain SYNCSORT steps in some of the jobs are *regularly* (not just occasionally) taking much more time than some of the other SYNCSORT steps in the same jobs with same amount of data. For example, in one job a file is sorted in certain order and after enrichment by an application program is sorted back into the original order. The first SYNCSORT takes 96 seconds of CPU time while the second SYNCSORT takes only 8 seconds. There is no difference in the parameters given via PARM and/or SYSIN. This kind of processing is done multiple times in many application jobs, so if there is anything we could do to reduce the time taken by the first SYNCSORT we would be very interested in doing whatever it takes. Can anyone suggest why there should be such a disparity in observed CPU timings for SYNCSORT? Or what SYNCSORT parameters might be worth investigating to reduce the initial SYNCSORT CPU time? TIA for any helping to cure my ignorance. Peter Example SYNCSORT CPU timings DATE : 08/15/2013 STEP NAME RECORD COUNT CPU TIME SORT10 6547982 01 MIN 28.64 SEC SORT20 6547981 05.35 SEC DATE : 08/16/2013 STEP NAME RECORD COUNT CPU TIME SORT10 6551104 01 MIN 36.83 SEC SORT20 6551103 08.02 SEC -- 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 ATTENTION: ----- The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
