Jim Mulder wrote:
z890, z990, and z9 machines have a 2-level TLB. Nothing
lower than OS/390 2.10 will run reliably on a machine with a 2-level
TLB because lower releases than 2.10 do not do some of the necessary
TLB purges. I have heard some speculation that you might be able to
get around this by running an older MVS under VM, with the following
VM trace:
#CP TRACE IPTE RUN NOTERM
Of course, this would cause some performance degradation, since VM would
intercepting and simulating every IPTE for this virtual machine. I don't
know of anyone who has tried this. It was just some hall talk with
a VM developer.
There may be other issues that would prevent an older MVS from running
on a modern machine, such as missing support for a larger storage
increment
size. The storage increment size might also be avoided under VM if the
virtual machine does not have too much real storage defined - I think
VM simulates the increment size but I wouldn't swear to that.
And there may be other issues that I am not remembering. The bottom
line is that you won't find anyone who knows for sure. The only way
you could find out is to try it.
And as others have pointed out, if by "old, old" you mean
pre-MVS/XA, you can most definitely forget that. Support for
pre-XA architecture was dropped by the 9672 G4 machines
(9672-Rx5).
IPTE (as well as ISTE and ISTO) selective invalidate instruction(s) were part of
original 370 virtual memory architecture. However, the 370/165 engineers had
scheduling problem with retrofitting virtual memory hardware to 165. They
proposed
that they could shave six months on the hardware schedule if they could drop the
selective invalidate instructions, r/o segment protect and some other features
from the 370 architecture. at the architecture review board meetings ... the
svs/mvs people said they saw no problem since they weren't ever planning on
doing
selective invalidate anyway ... that periodic use of PTLB (purge "all" table
lookaside
buffer) would be more than sufficient for any of their planned use of virtual
memory).
As a result, all of that got dropped from the original release of virtual memory
hardware for 370 ... and the 370 models that had already implemented the full
370
architecture had to be retrofitted to only have the 370/165 subset
implementation.
In the morph of cp67 cms to vm370 cms (besides the name change from cambridge
monitor
system to conversational monitor system) ... there was big change to use 370
r/o segment
protection. when the r/o segment protect feature got dropped from the
architecture
(as part of helping the 370/165 engineers make up six month schedule) ... it had
significant long term effects on the whole way that vm370 had to go about
supporting
shared segment protection.
In those days ... the architecture group had converted the architecture "red
book"
to cms script .... and were using conditional script controls when printing either
the full architecture book or the subset that appeared as the principle of operations.
slight overlap with this thread:
http://www.garlic.com/~lynn/2007d.html#29 old tapes
http://www.garlic.com/~lynn/2007d.html#31 old tapes
Very early on, there was joint project between Endicott and the science center
to
modify cp67 to support 370 "virtual memory" virtual machines ... including all
the
features in the full, original 370 virtual memory architecture. This was in
regular
production use a year before the first 370 engineering machine with virtual
memory
support appeared (370/145) ... and long before any 370/165 machine with virtual
memory support was available. misc. past posts mentioning the subject:
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a
page fault ?
http://www.garlic.com/~lynn/2001c.html#7 LINUS for S/390
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/2002n.html#10 Coherent TLBs
http://www.garlic.com/~lynn/2002n.html#23 Tweaking old computers?
http://www.garlic.com/~lynn/2003g.html#19 Multiple layers of virtual address
translation
http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment
protection hack
http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded
http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the
line
http://www.garlic.com/~lynn/2005h.html#10 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#39 A second look at memory access
alignment
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/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
http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks
http://www.garlic.com/~lynn/2006s.html#61 Is the teaching of non-reentrant
HLASM coding practices ever defensible?
http://www.garlic.com/~lynn/2006t.html#1 Is the teaching of non-reentrant HLASM
coding practices ever
http://www.garlic.com/~lynn/2006u.html#60 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006y.html#26 moving on
----------------------------------------------------------------------
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
