[email protected] (Joel C. Ewing) writes: > No (about the "free", not about the "dead for decades"), DOS/VS was the > last really free base (last version Release 34?). Perhaps technically > DOS/VSE was "free", as there didn't appear to be a monthly licensing > charge for DOS/VSE itself (Computerworld, April 30, 1979, p4), but in > the practical sense a production DOS/VSE system was definitely not free > as there were monthly support charges for DOS/VSE and separate monthly > licensing plus support charges for must-have VSE add-on components like > VSE/Power and others. DOS/VSE came out with the IBM 4331 & 4341 > processors in 1979 and supported running in both S/370 mode or the > ECPS:VSE mode supported by the 4300 processor family.
various legal actions resulted in 23June1969 unbundling announcement where (application) software & other stuff started to be charged for (however they made the case the kernel software should still be free). some past posts http://www.garlic.com/~lynn/submain.html#unbundle during future system effort 370 efforts were being killed off (lack of 370 products there era is credited with clone processors market foothold). after future system failed ... past posts http://www.garlic.com/~lynn/submain.html#futuresys there was mad rush to get stuff back into 370 product pipeline. POK kick off 3033 (168 logic mapped to faster chips) and 3081/XA in parallel ... reference http://www.jfsowa.com/computer/memo125.htm XA had a lot of extensions tailored for MVS. Endicott did something similar for e-architecture (4331 & 4341) tailored for vs1&dos. In large part a single virtual address space supported as part of the hardware architecture. Rather than having segment & page tables ... there were two new instructions that told the machine what virtual address was at what real address ... and invalidated the virtual address. However there was an enormous explosion in vm/4300 sales (before announce, 4341s were referred to a "E4") ... which required multiple virtual address space ... which met that large number of 4300s ran in 370 mode rather than e-mode. Note that POK had convinced corporate to kill off the vm370 product and move all the development people to POK as part of MVS/XA development (including excuse that MVS/XA would ship on time, if they couldn't get the additional resources). Endicott manage to save the vm370 product mission, but had to reconstitute a development group from scratch. some old 4300 related email http://www.garlic.com/~lynn/lhwemail.html#43xx Note that VS1 and VM/370 "ECPS" was different than e-machine architecture. It originated with the 138/148 (virgil/tully) ... where selected high use kernel/system instructions paths were implemented in microcode. The low & mid-range machine were vertical microcode machines with an avg of 10 native instructions per 370 instruction (somewhat analogous to mainframe emulators that run on Intel platforms). Kernel instruction paths tended to get 10:1 performance improvement when moved to microcode. I did the initial study and effort for the VM/370 ECPS ... old post with results for selecting pathlengths to be moved to microcode (I was told, that I needed to select the 6kbytes of highest executed kernel, which turned out to account of 80% of vm/370 kernel execution) http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist trivia ... the methodology for selecting the VS1 paths wasn't nearly so rigorous. other trivia ... major motivation for Future System product was as countermeasure to clone controllers ... but the (failed) Future System effort contributed significantly to the rise of the clone processors. The threat of clone processors resulted in decision to transition to charging for system/kernel software. I continued to work on 370 stuff all during the FS period ... even periodically ridiculing FS stuff ... which wasn't exactly career enhancing. Also one of my hobbies was developing&supporting advanced enhanced operating systems for internal datacenters ... some old email http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 In any case, the mad rush to get stuff back into 370 product pipeline contributed to decision to pick up various of my stuff and ship it in products for customers. One part of that stuff (dynamic adaptive resource manager) was selected to be guinea pig for starting to charge for system/kernel software ... and I had to spend some amount of time with lawyers & business types going over policies for system/kernel software charging. even more trivia: when 3033 looked at doing something similar to ECPS ... it didn't work out as well. 3033 was horizontal microcode machine that had been optimized so it was executing nearly one 370 instruction per machine cycle. Directly dropping system/kernel 370 pathlengths into microcode could even result in running slower than the original 370. -- 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
