I believe the switch was made before the app went into production, so CPU comparisons would have been speculative. The master file was ISAM because it was too early in mainframe evolution to take advantage of VSAM support in COBOL.
Years later at another shop I investigated converting an ISAM application to VSAM, a remarkable trick to hugely improve performance with no programming changes. The app was run on contract for an outside governmental entity. I still shake my head at the outcome. VSAM conversion was nixed by my management because--as the contract was written--we would have collected less revenue from the owner in view of huge performance gains. Wow. . . 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 Clark Morris Sent: Friday, October 26, 2018 11:14 AM To: [email protected] Subject: (External):Application change for ISAM effects wasRe: SORT not behaving consistently [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
