On 30 Aug 2013 16:13:59 -0700, in bit.listserv.ibm-main you wrote: >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.
Are the SYNCSORT manuals for both z/OS and UNIX available online? Since I am retired, I'm not working for a customer but I am still interested in how it works and what features are available. Clark Morris > ><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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
