The Pankian Metaphor 3134

part of the issue was that many of the participants involved in dropping much of the dynamic adaptive capability in the cp67 to vm370 morph ... went on to become part of the vmtools effort in pok.

there had been a strategic decision that vm370 would be stabilized and there would be no new releases. furthermore, nearly all of the group was required in pok in support of the mvs-xa development effort ... they were needed to build an internal only XA-based virtual machine capability needed by the mvs-xa development organization. this activity to retarget the vm370 development group to a purely internal mission in support of mvx-xa development ... somewhat coincided with compebreastive corporate forces trying to continue vm370 and help obtain decision allowing me to (re-)release the dynamic adaptive stuff (as the resource manager).

the vmtool effort had very similar static tuning paradigm as the initial vm370 implementation (in part because there was much less variety in workload and configuration ... for purely supporting mvs-xa development).

misc past references to decision to retargeting the vm370 development group to the vmtool mission purely in support of internal mvs-xa development

in part because of customer demand ... some amount vm370 support and development effort continued ... even with much of the original vm370 development group having been retargeted to internal mvs-xa development support. in part because of the continued customer virtual machine demand; there was a decision to repackage vmtools as a customer product as vm-xa ... initially for 3081 running in 370-xa mode. this moved to 3090 ... where pr-sm had been implemented. pr-sm implementation was somewhat in response to hypervisor that had been done by amdahl. misc. past posts mentioning pr-sm and amdahl hypervisor:

as part of continued development of vm-xa offering as customer product, three different compebreastive scheduling product proposals emerged. at one point i observed that all the resources spent on resolution and escalation meetings (regarding the three compebreastive scheduler implementation proposals) was significantly larger than needed to actual implement all three compebreastive solutions and perform extensive benchmark comparisons.

while all of that was going on ... i had observed that system configurations had changed from being significantly real storage and-or processor constrained to being significantly i-o constrained. i did quite a bit of work significantly enhancing the resource manager to improve its ability in i-o constrained environment ... but that never shipped in product. at one point i characterized the transformation as relabreastive system disk performance had declined by a factor of 10 times over a period of years (i.e. other resources increased by a factor of 50, but disks only improved by a factor of five ... or less). i've made past references to the anecdote about the disk division adversely reacting to my observation and buttigning the divisions performance and modeling group to refute the statement. they subsequently came back and reported that i had actually understated the change.

--