If EQUALS is in effect, then DFSORT will always preserve the original order of records with the same key value. If EQUALS is not in effect, then it is possible for the sequence of records with the same key value to vary. One reason this can vary is due to the amount of memory available on the system since that can impact which sort technique is used. If an incore sort is done, it's likely (but not definite) that records with the same key may retain their original sequence. If work files are used (be they memory object, Hiperspace or disk sortwk), then records with the same key value might get dispersed to different work files and in the output phase be merged in a different sequence. Since DFSORT adapts to available resources, it is not surprising to see this variance. The whole reason we have the EQUALS parameter, is for situations where maintaining the original sequence is required.
Have a nice day, Dave Betten z/OS Performance Specialist Cloud and Systems Performance IBM Corporation email: [email protected] IBM Mainframe Discussion List <[email protected]> wrote on 10/25/2018 02:37:24 PM: > From: Jesse 1 Robinson <[email protected]> > To: [email protected] > Date: 10/25/2018 02:38 PM > Subject: Re: SORT not behaving consistently > Sent by: IBM Mainframe Discussion List <[email protected]> > > I for one find this discrepancy highly disturbing unless it can be > tracked down to an unintended difference in SORT options. Like it or > not, a program should give consistent results on every execution > wherever it's run. Whether it matters to the user in this particular > case is not germane. It should matter to all of us. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > [email protected] > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected] > ] On Behalf Of Beesley, Paul > Sent: Thursday, October 25, 2018 11:29 AM > To: [email protected] > Subject: (External):Re: SORT not behaving consistently > > My thought exactly. Apparently it does... which, as Charles Mills > correctly says, the rest of the fields should be part of the sort > key or they should use EQUALS. > > Regards and thanks > Paul > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Cameron Conacher > Sent: Thursday, October 25, 2018 5:37 PM > To: [email protected] > Subject: Re: SORT not behaving consistently > > So are you saying that the order of records with identical keys is > different machine to machine? > Does that matter? > > Sent from my iPhone > > > On Oct 25, 2018, at 12:23 PM, Beesley, Paul <[email protected]> wrote: > > > > Hi > > > > Have been asked to investigate reasons for an identical DFSORT > behaving differently on 2 machines. > > We are transitioning a service which is currently on a zEC12 to a > z14 machine, and the disks are currently HP9500, moving to IBM DS8886. > > When they run sort of multi-thousand records on the old machine, > and then running the identical sort against identical data on the > new setup, they get several records in a different order. > > Seems they are sorting on the first 21 characters or so, and it is > doing that fine, but the order of the records beyond that is a bit > random, whereas on the new system they are in the same order as the input. > > On the new system it's almost like EQUALS is coded, but it's not. > > Hope that makes sense. > > Any ideas what would cause this (repeatable) difference in the > outcome ... faster machine? Faster disks? > > Paul > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
