[email protected] (Jon Perryman) writes: > 2. It is the only tool where we can easilyt segregate interactive > versus long running programs. This allows WLM give more resources to > interactive users because they are personally waiting. Sysprog's > encourage it's use by setting WLM such that a user get's less than > batch priority when they use to many resources.
re: http://www.garlic.com/~lynn/2013n.html#16 z/OS is antique WAS: Aging Sysprogs = Aging Farmers http://www.garlic.com/~lynn/2013n.html#17 z/OS is antique WAS: Aging Sysprogs = Aging Farmers http://www.garlic.com/~lynn/2013n.html#18 z/OS is antique WAS: Aging Sysprogs = Aging Farmers http://www.garlic.com/~lynn/2013n.html#19 z/OS is antique WAS: Aging Sysprogs = Aging Farmers as an undergraduate in the 60s, I did dynamic adaptive resource manager for cp67 ... which was picked up and released as part of the product. A default policy was "fair share" resources ... nobody got more resources than anybody else ... regardless of interactive or background/batch characteristics ... default policy gave interactive more timely resources ... but not more resources. some past posts http://www.garlic.com/~lynn/subtopic.html#fairshare in the simplification morph from cp67 to vm370, the dynamic adaptive code was dropped ... however customers would continue to advocate in share to bring it back. I went to the science center ... some past posts http://www.garlic.com/~lynn/subtopic.html#545tech and continued to work on cp67 and then did port to vm370 http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 one of my hobbies in IBM was producing, distributing & supporting production systems for large number of internal datacenters ... including the internal IBM world-wide sales&marketing HONE systems ... some past posts http://www.garlic.com/~lynn/subtopic.html#hone this was also during the Future System period ... when 370 efforts were being shutdown ... but I continued with 360/370 and not exactly career enhancing ... critized what they were doing ... some past posts http://www.garlic.com/~lynn/submain.html#futuresys when Future System finally imploded, the mad rush to get products back into the 370 pipeline contributed to decision to pickup a lot of stuff I had been doing (and was running widely inside the company) and release it to customers. Back in the 60s, various litigation contributed to the 23Jun1969 "unbundling" decision that started to charge for software, se services, etc ... some past posts http://www.garlic.com/~lynn/submain.html#unbundle however, they managed to make the case that kernel software should still be free. With the lack of products during the future system period and clone processors getting market foothold ... a decision was made to start charging for kernel software ... and the decision was made to make my scheduler a separate kernel component and the guinea pig for starting to charge for kernel software (as a result I got to spend a lot of time with the business and legal people about policies for kernel software charging). later with the big explosion in online & interactive vm/4300 machines ... both with customers and internally ... the company made a decision that vm/cms was the strategic interactive offering. It was then that the TSO product manager asked me if I would port my dynamic adaptive resource manager to MVS ... hoping that I could help fix the really horrible TSO human factor characteristics ... old email reference: http://www.garlic.com/~lynn/2006b.html#email800310 as I've mentioned periodically ... I declined the offer ... in part because there was enormous number of other MVS issues (not just scheduling) that affected its poor interactive characteristics. as an aside, one of the problems I had (re)releasing my dynamic adaptive resource manager ... was somebody from Armonk (with past history in POK MVS) non-concurred with approval for the release because it didn't have a lot of manual tuning knobs (because that was state-of-the-art at the time with MVS having enormous number of manual tuning knobs). I tried to explain that dynamic adaptive eliminated the necessity for all those manual tuning knobs ... since it was repeatedly calculating them dynamically adjusting for configuration and workload. I finally created a "joke" ... I put in manual tuning knobs ... and described the algorithms, code in detail as well as shipping source code. The "joke" was that the dynamic adaptive code had more degrees of freedom than the manual tuning knobs ... so any knob choice could be compensated for by the dynamic code. All the code was also packaged in a source module I named "STP" (after the television commercials about the "racer's edge"). -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
