[Default] On 26 Oct 2018 09:45:46 -0700, in bit.listserv.ibm-main [email protected] (Jesse 1 Robinson) wrote:
>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. > What did the change do to CPU time and overall run time? Clark Morris >. >. >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
