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

Reply via email to