Shmuel Metz , Seymour J. wrote:
What did they use for a test machine before the 3081 was available?
There was a micro-order on the 3168 that was highly suggestive.
re:
http://www.garlic.com/~lynn/2006m.html#25 Mainframe Limericks
refers to posting
http://www.garlic.com/~lynn/2006m.html#21 The very first text editor
refers to abbreviated quote from Melinda's history paper at:
http://www.princeton.edu/~melinda
the following is a little more detail from that referenced extract
(regarding 16 percent went to work for DEC):
Boston and its suburbs provided other opportunities that didn't require
the VM developers to move away from the bright lights and disrupt the
lives of their families. By the end of 1976, sixteen percent of the
former Burlington personnel were working for DEC. Forty-seven percent
had found IBM positions that didn't require them to move to
Poughkeepsie. To make matters worse, several of the most knowledgeable
CP people who did go to Poughkeepsie, including Dick Newson and Per
Jonas, were put into a separate group whose purpose was to build a tool
that could be used for the development of MVS/XA. Pete Tallman, of
VMA fame, also joined what came to be known as the ``VM Tool'' project
as soon as it moved to Poughkeepsie. Starting with VM/370 Release 3,
PLC 06, the VM Tool group began building a fast, stripped-down CP that
would create XA virtual machines on a real 370 so that the MVS
developers could test MVS/XA.
... snip ...
something similar happened with os/360 operating system virtual memory
development ... the earlier os2/vs2 svs prototype work with MVT
incorporating some of the cp67 virtual address space support was done on
360/67 ... and then moved to "virtual 370s" and much later "real 370s".
370 was originally announced w/o virtual memory support and 360
operating systems ran with very little changes.
however, one of the early uses of the internal network technology
http://www.garlic.com/~lynn/subnetwork.html#internalnet
was joint development project between the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
and endicott to modify cp67 (running on 360/67) to provide 370 virtual
machines (including support for 370 virtual memory architecture that had
hardware tables different than what was defined for 360/67).
the initial set of updates were the "cp67-h" changes to a standard cp67
kernel that added 370 virtual machine option (to existing 360 & 360/67
virtual machine options). then there were a set of "cp67-i" changes (on
top of the "cp67-h" changes) that change the kernel to run on 370 hardware.
now because 370 virtual memory support hadn't been announced, it was
being treated as super corporate secret. complicated the matters was
that the science center cp67 system was also providing service to
various non-employee students (and others) at various educational
institutions in the boston area. so typical operation was
360/67 hardware
standard "cp67-l" system running on 360/67 hardware providing 360 VMs
"cp67-h" running in 360 virtual machine providing 360 & 370 VMs
"cp67-i" running in 370 virtual machine providing 370 VMs
CMS running in 370 virtual machine
as a countermeasure to accidental leakage about 370 virtual memory to
the public.
cp67-h & cp67-i were in regular use a year before the very first
engineering 370 with hardware virtual memory was reading for testing (a
engineering 370/145 in endicott). in fact, booting cp67-i on the
engineering 370/145 was one of the first tests of the virtual memory
hardware support. as it turned out, the first boot failed. a little more
examination showed that the hardware had reversed the op-codes in a
couple of the new B2xx instructions ... while cp67-i had it correct. the
cp67-i kernel was patched to correspond to the (wrong) hardware
implementation and then booted succesfully.
there was a different problem leading up to 370 virtual memory
announcement. pok engineers had to design virtual memory hardware
retro-fit for 370/155 and 370/165 machines. they were falling something
like six months behind. finally there was an escalation meeting in POK,
where the 165 engineers said that if they could eliminate some of the
new features defined for 370 virtual memory they could pickup six months
... and allow 370 virtual memory to be announced six months earlier.
there was a decision to drop the additional features ... and other
models that had already done their implementations had to drop the
features.
one of the features dropped was shared segment protection (different
than the 360 storage key protection). cms had been reworked to take
advantage of the feature (i.e. different virtual address spaces could
share the same physical pages in real memory and enforce storage
alteration protection). as a result, cms had to revert to a real gludge
using 360 storage key protect for different virtual address spaces
sharing the same physical pages.
a few old posts mentioning cp67-h and cp67-i work supporting 370 virtual
memory.
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and
System/390 - do we need it?
http://www.garlic.com/~lynn/2004b.html#31 determining memory size
http://www.garlic.com/~lynn/2004h.html#27 Vintage computers are better
than modern crap !
http://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005c.html#59 intel's Vanderpool and
virtualization in general
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#18 Exceptions at basic block
boundaries
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
http://www.garlic.com/~lynn/2005p.html#27 What ever happened to Tandem
and NonStop OS ?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion -
DISAPPOINTMENT
http://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers
a few old posts mentioning the 165 schedule delays resulting in dropping
370 virtual memory features in order to catchup.
http://www.garlic.com/~lynn/2000f.html#35 Why IBM use 31 bit addressing
not 32 bit?
http://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re:
Parity - why even or odd)
http://www.garlic.com/~lynn/2002m.html#2 Handling variable page sizes?
http://www.garlic.com/~lynn/2002m.html#68 Tweaking old computers?
http://www.garlic.com/~lynn/2002n.html#10 Coherent TLBs
http://www.garlic.com/~lynn/2002n.html#23 Tweaking old computers?
http://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#20 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2005.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#62 The mid-seventies SHARE survey
http://www.garlic.com/~lynn/2005c.html#18 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs.
Microcoded
http://www.garlic.com/~lynn/2005e.html#57 System/360; Hardwired vs.
Microcoded
http://www.garlic.com/~lynn/2005e.html#59 System/360; Hardwired vs.
Microcoded
http://www.garlic.com/~lynn/2005f.html#1 System/360; Hardwired vs.
Microcoded
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs
above the line
http://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block
boundaries
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2006.html#13 VM maclib reference
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006e.html#5 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006i.html#4 Mainframe vs. xSeries
http://www.garlic.com/~lynn/2006i.html#9 Hadware Support for Protection
Bits: what does it really mean?
http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation
in S/370
http://www.garlic.com/~lynn/2006j.html#5 virtual memory
http://www.garlic.com/~lynn/2006j.html#41 virtual memory
http://www.garlic.com/~lynn/2006l.html#22 Virtual Virtualizers
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
