Have we actually determined WHY these protection exceptions are
occurring, albeit apparently legitimately with VM/370? If so I missed
understanding that. Yes, I got that CS is being used to test
writability to a location. But WHY is VM doing THAT? This is the part
I missed.
Does it make sense to add protection exceptions to the VM OSTAILOR
setting rather then setting it manually? One would expect that if this
is a "normal" situation with VM/370 that the VM setting would turn this
report off. (Obviously it is reported when OSTAILOR is not being
used.)
What mystifies me is why after years of people using VM/370 and MVS as
guest that this is the first time this apparently legitimate situation
has arisen. (I get it that obviously without OSTAILOR the report would
happen.) But why protection exceptions IN THIS CASE must be manually
turned off is what confuses me. (This sort of gets back to why VM/370
is testing location writability.) That would still suggest that there
is something unique going on here that others have not encountered. Or
maybe they were all smart enough to know to manually turn off reporting
of protection exceptions.
Harold Grovesteen
toggle quoted message
Show quoted text
On Thu, 2022-10-27 at 09:21 -0700, Fish Fish wrote:
Dave Wade wrote:
[...]
So its pointless looking at the PSW Hercules reports to
see the Machine State that MVS believes it has created.
What is reported is the fake VM has created¡
Correct. Due to the way VM works its magic, the PSWs that the real
hardware (i.e. Hercules) uses (dispatches?) -- which is always what
VM itself uses (dispatches, since its ultimately in control of (what
it thinks is) the real hardware) -- is never what the VM guest (i.e.
MVS in this case) thinks is (or sees as) ITS "real" PSW. What MVS
always "sees" is what it THINKS is a "real" PSW, but it's actually a
virtualized PSW that VM fakes (emulates) for it.
The PSWs that VM *itself* uses however (and thus what Hercules
reports on the HMC), are the actual real hardware PSW that VM used to
dispatch its VM guest with.
So in the context of our original discussion, the PSWs that Hercules
was reporting were the REAL hardware PSWs that VM itself dispatched
its MVS guest with.
Which, as explained, were causing REAL (bona-fide) Protection
Exception program interrupts.
MVS might not have been "seeing" any Protection Exception program
interrupts, I don't know (I'm guessing it probably wasn't; I'm
guessing that VM was intercepting them and dealing with them itself),
but the Protection Exception program interrupts WERE actually
occurring on the real hardware.
On real hardware (i.e. on real IBM machines), these Protection
Exceptions were actually occurring, but were not being "reported"
(displayed) anywhere that the machine operator/user could see. But
they were certainly happening!
On Hercules however, as a courtesy (i.e. in order to be helpful),
whenever certain "unexpected" program interrupts occur, it DOES
report them. It DOES display them.
And Hercules was reporting all of these many Protection Exception
program interrupts that were occurring because its OSTAILOR setting
(or more technically, its "pgmtrace" setting(*)) was telling Hercules
that they SHOULD be reported (displayed).
You won't "see" them on real IBM hardware (because IBM hardware
doesn't bother to "report" them), but you *WILL* see them on
Hercules!
As long as your OSTAILOR (i.e. pgmtrace(*)) says to do so of course.
I hope that all makes sense now.
---------------------
(*) The "OSTAILOR" configuration file statement is just a more
convenient (more compact) way of specifying a long series of
"PGMTRACE" commands that define WHICH program interrupts should be
reported and which ones SHOULDN'T be reported. Code 11 program
interrupts for example (Page Faults) occur all the time and are thus
largely uninteresting to the Hercules user, so they're typically
marked to not be reported. (All of our predefined OSTAILOR setting
specify a pgmtrace value with code 11 marked as "don't report".)
OTHER program interrupts however (such as Protection Exceptions,
Addressing Exceptions, Specification Exceptions, OPERATION
EXCEPTIONS(!), etc) are marked as "DON'T filter!" (i.e. "Please
report!"), since they almost always indicative of a serious
programming error.
And USUALLY (not always, but *usually*) the Hercules user who is
running Hercules wants to know whether their software is operating
correctly or messing up. So Hercules helpfully reports such
occurrences -- according to what it was told to report (which is
controlled via its PGMTRACE setting of which the OSTAILOR statement
is simply a more convenient way of specifying).
Hope that helps!
