Sorts today are designed to minimize elapsed time, at least Syncsort's MFX sort, is by default. As with EQUALS there are ways to tell the sorts what to prioritize on, TIME, EXCPS, MEMORY.
In making optimization decisions, we tend to go by the rule of, you can buy more CPU or memory or DASD, but you can't buy more time. Many, most?, shops have production windows that have grown smaller, thus the effort that is made to minimize time. [AD] We do all the optimization with an eye out for what else is running in the system. We don't want to start a sort and give it so many resources that it negatively effects the rest of the processes running on a system. Using the Global Sort Optimizer, we track what the usual resources available are for the expected duration of a sort and prevent that sort that starts at 7:50AM, and is going to run for an hour, from taking all the resources that your online systems need that start up at 8:00AM. Syncsort provides sorting technology to many other vendors including IBM (DB2Sort), BMC (BMCSORT), and others. Chris Blaicher Technical Architect Syncsort, Inc. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Jesse 1 Robinson Sent: Friday, October 26, 2018 12:46 PM To: [email protected] Subject: Re: SORT not behaving consistently My first job in IT had me working on a fairly new application that was designed around an ISAM master file. Shortly before going live, it was discovered that the data center billed application business units for I/O but not for memory usage. So a quick change was instituted to read the entire ISAM file into virtual storage at startup and process it there. I don't know what the savings amounted to, but it was certainly an example of nudging people in an unexpected--and probably unwanted--direction. . . 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 Cameron Conacher Sent: Friday, October 26, 2018 9:01 AM To: [email protected] Subject: (External):Re: SORT not behaving consistently About a hundred years ago I ran into a similar sort issue. Parallel runs in our pre-production environment did not have sequence matched sort outputs. I chased several threads. EQUALS made things match but there is a cost. Apparently it was related to sort work DASD. Knowing I could make it right with EQUALS was good enough. It was the only way to guarantee a sequence of records with matching sort keys. Since I considered the final matching key sequence random I just did not care enough to use EQUALS to force a matching sequence. Sent from my iPhone > On Oct 26, 2018, at 11:35 AM, Seymour J Metz <[email protected]> wrote: > > Be careful what you measure; people will optimize in ways that you didn't > anticipate and don't want. What affects perfolrmance is the working set, and > a large region is not synonymous with a large working set. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List <[email protected]> on > behalf of Paul Gilmartin > <[email protected]> > Sent: Thursday, October 25, 2018 5:06 PM > To: [email protected] > Subject: Re: SORT not behaving consistently > >> On Thu, 25 Oct 2018 20:36:58 +0000, Jesse 1 Robinson wrote: >> >> OK, I'm simmering down. Here's my concern: I own the SORT product; I own the >> CEC; I own the DASD. If I change any of those things and the user's output >> differs, then I'm on the spot to explain why. The explanation may not be >> difficult, but if a user presses with 'why didn't you tell us this would >> happen', I'm on the defensive for an outcome I can't control or even >> anticipate. I don't like being on the defensive. You don't score points on >> defense even if you survive to battle another day. OK, I'm done. >> > I was once a user of a site that had a chargeback policy and tried > (desperately) to make the charge for any job repeatable, regardless of > background system load, to avoid "Why didn't you tell us this would > happen?" Impossible. For example, who pays for paging I/O? If you > don't charge for it, you're motivating prodigal REGION use. They > seemed to have the misguided idea that making the formula complicated > enough would make it repeatable. > > -- gil ---------------------------------------------------------------------- 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
