[email protected] (Vernooij, CP - KLM , SPLXM) writes: > I still remember the early 80's, on a 3031/3033 or so I think, when > IBM decided to sell memory in 1MB units only. We needed 0.5 MB > expansion for the next year and my manager was very angry with IBM > about the unnecessary waste of money because of this new policy. So 1 > MB was a substantial investment at that time.
303x (along with 3081) was q&d projects kicked off after FS imploded. http://www.garlic.com/~lynn/submain.html#futuresys 3031 was 158 engine with just 370 microcode and the integrated channel microcode moved to a 2nd 158 engine called "channel director"; 3032 was 168-3 with new covers and configured to work with external "channel director", 3033 was 168-3 logic remapped to chips that were 20% faster (also had more circuits per chip, some late logic rework to increase use of onchip logic, increased 3033 to 1.5times 168-3). MVS in 3033 timeframe was increasingly enormous bloat ... but the amount of system real storage approaching 16mbyte and amount of virtual address space approaching 16mbyte (even with each application getting its own 16mbyte virtual address space, MVS requirement was approaching 16mbyte). to address the real storage bloat, a hack was done to have >16mbyte real storage even tho 370 didn't support >16mbyte real storage addressing. IDALs introduced with 370 was 32bit field for i/o transfer addresses, it was leveraged for doing i/o to real addresses >16mbyte. The 370 page table entry was 16bits, 12bit page number, 2 defined bits, and 2 undefined bits. The 2 undefined bits were co-opted to prefix the page number forming 14bit page number (allowing to generate up to 64mbyte addressing). While instruction addressing was still 24bit/16mbyte, virtual addresses could be translated into 26bit/64mbyte real addresses. OS/360 heritage has enormously ingrained pointer passing API paradigm. With everything in single same address (OS/360 real storage and VS2/SVS) that wasn't a problem. Moving to VS2/MVS with different 16mbyte virtual address space for each application represented enormous problem/opportunity. It started out with image of the MVS kernel taking up half of each 16mbyte application virtual address space (8mbyte, with application and kernel in same virtual address space can use pointer passing API for kernel calls to access application parameters). That left the problem of various MVS subsystems that moved into their own separate virtual address space. To address applications calling subsystem, the common segment area (1mbyte CSA) was defined in each virtual address space for parameters used in subsystem calls (leaving 7mbytes for applications). However as systems size grew (with 3033), CSA size had to grow (proportional to both number subsystems and concurrently executing applications) ... becoming common system area (multiple one mbyte segments). Later in 3033 time-frame, CSA was 5-6mbytes at many customers (leaving 2-3mbytes address space for applications), threatening to become 8mbytes (leaving nothing for applications). all the problems contributed to the attack of the vm/4341s ... a cluster of vm/4341s had more aggregate processing than 3033 at lower cost, lower environmental and floor space. Also 4341 channels were faster & more efficient than the 303x channel director (158 engine running integrated channel microcode). I've mentioned before that the head of POK trying to fight off the Endicott 4341s, got the corporate allocation of a critical 4341 manufacturing component cut in half. Places like LLNL were doing benchmarks looking for 70 4341s for datacenter compute farm ... the leading edge of cluster supercomputers. Large corporations were also ordering hundreds of 4341s at a time, placing them out in departmental areas ... the leading edge of the distributed computing tsunami. some old email http://www.garlic.com/~lynn/lhwemail.html#4341 MVS was locked out of the exploding distributed computing market. The 3380 was high-end CKD DASD ... however the only mid-range disks were FBA (3310 & 3370) appropriate for placing out in departmental areas (non-datacenter environment, converted departmental supply & conference rooms). Eventually they did come out with 3375 (CKD simulated on 3370) to try and provide MVS an entry into this market. However, MVS system tended to require 10-30 people for care&feeding ... which scaled poorly to hundreds of distributed departmental computers (IPL and run with little or no human intervention). -- 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
