No wonder they didn't break. On Mon, Dec 21, 2015 at 6:27 AM, Tony Thigpen <[email protected]> wrote: >> Endicott did something similar for e-architecture (4331 & 4341) >> tailoredfor vs1&dos. > > The 4300 did not come out of Endicott. It was developed in Germany, in the > same lab that developes DOS/VSE. > > Tony Thigpen > > > Anne & Lynn Wheeler wrote on 12/21/2015 03:05 AM: >> >> [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. >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
