re: http://www.garlic.com/~lynn/2009j.html#67 DCSS
Some of the other stuff in CSC/VM was released in my resource manager (which appeared with vm370 release 3 plc9) the 23jun69 unbundling announcement started charging for (application) software and se services (but they managed to make the case that kernel software should still be free). some posts mentioning unbundling http://www.garlic.com/~lynn/submain.html#unbundle When I was undergraduate ... I had added tty/ascii terminal support to cp67 ... and tried to make the 2702 do something it couldn't quite do. that somewhat was motivation behind the univ. starting a project for a clone controller using interdata/3 ... discussed some in this recent post http://www.garlic.com/~lynn/2009j.html#60 A Complete History Of Mainframe Computing four of us got written up being responsible for clone controller business. some posts mentioning clone controller http://www.garlic.com/~lynn/subtopic.html#360pcm The clone controller business has been attributed as the motivation for the FS project. http://www.ecole.org/Crisis_and_change_1995_1.htm quote from above: IBM tried to react by launching a major project called the 'Future System' (FS) in the early 1970's. The idea was to get so far ahead that the competition would never be able to keep up, and to have such a high level of integration that it would be impossible for competitors to follow a compatible niche strategy. However, the project failed because the objectives were too ambitious for the available technology. Many of the ideas that were developed were nevertheless adapted for later generations. Once IBM had acknowledged this failure, it launched its 'box strategy', which called for competitiveness with all the different types of compatible sub-systems. But this proved to be difficult because of IBM's cost structure and its R&D spending, and the strategy only resulted in a partial narrowing of the price gap between IBM and its rivals. ... snip ... old post with somebody taking FS quotes from Fergus&Morris book on IBM http://www.garlic.com/~lynn/2001f.html#33 IBM's "VM for the PC" c.1984?? Now allowing 370 product pipelines dry up is claimed to have given the clone processors foothold in the market ... and success of the clone processors is major motivation to decide to start (also) charging for kernel software. My resource manager got chosen to be the guinea pig for kernel software charging ... and as a result ... I had to spend some amount of time with the business people & lawyers on policies regarding software charging. another mad rush to get products back into the 370 product pipeline was the 303x stuff ... recent discussion http://www.garlic.com/~lynn/2009j.html#59 A Complete History Of Mainframe Computing basically after FS was killed, work on 3081 was started but that was going to take 6-7 yrs ... and they needed something on much shorter cycle ... so 3031 was repackaged 370/158, 3032 was repackaged 370/168, and 3033 started out as 168 wiring diagram remapped to newer chips that were 20% faster. Now one of the things that were in the page-mapped filesystem stuff was location independence support. Carefully crafted executable code could be loaded at any virtual location in any virtual address space. The same "shared" object could appear at different virtual addresses in different virtual address spaces. Operating systems that had been designed for paged-mapped operations had support for this as a matter of course ... including IBM's TSS/360. CMS inherited a lot of its structure, compilers and other features from os/360 ... which had a real-storage orientation. OS/360 Relocatable address constants ... were relocated at "load" time ... and while executing were tied to a specific address. This nominally prevented having the same shared object appearing simultaneously in multiple virtual address spaces at different addresses. The 370 issue was that with only 256 64kbyte segments (in 16mbyte virtual address space) ... there would be great difficulty in finding unique locations for every application that might be available at a large location. Any single user wouldn't necessarily require more than 16mbytes ... but might require an arbitrary combination of applications available at the installation. To support shared "fixed" address applications which might be used in arbitrary combination... a unique location had to be chosen for ever application ... but the total possible aggregate size of all available applications exceeded 16mbytes. Lots of past posts mentioning difficulty of modifying code so it would be location independent while executing (in addition to having to modify it for executing in a R/O protected shared segment) http://www.garlic.com/~lynn/submain.html#adcon
