开云体育

I finally got back to email.? Thanks everyone for clarifying the
culprit, MVS!? I got that.? I do admit that once every two decades can
be considered rare.

I understand why the CS is being used.? But WHY, MVS is doing this
memory writability check still seems to be a mystery.? Something must
trigger MVS to use it.? I guess once every 20 years its probably not
worth figuring out the underlying condition.

Thanks for the clarification, everyone.

Harold

On Fri, 2022-10-28 at 14:13 -0700, Fish Fish wrote:
> Harold Grovesteen wrote:
>
> > 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.
>
> It's not VM that's doing it: it's MVS (i.e. the VM guest).
>
> CS is an unprivileged instruction, so when MVS executes it, it causes
> a program check (which Hercules then logs).
>
>
> > Does it make sense to add protection exceptions to the VM
> > OSTAILOR setting rather than setting it manually?
>
> No. Because Protection Exceptions should NOT normally be occurring.
> It's not an exception that is considered "routine" (expected) in a
> normal operating environment (which are the only type of exceptions
> that OSTAILOR is designed to filter).
>
>
> > One would expect that if this is a "normal" situation with VM/370
>
> MVS. (Not VM)
>
>
> > that the VM setting
>
> MVS setting. :)
>
>
> > would turn this report off.
>
> Correct! Which is precisely WHY it's *not* turned off! Because it's
> NOT considered "normal/expected"! It's *unusual*. It's not something
> that regularly (routinely) happens in a normally functioning
> operating system.
>
>
> > (Obviously it is reported when OSTAILOR is not being
> > used.)
>
> Or even when OSTAILOR *is* used, which was what I tried to make
> clear. That's why if MVS 3.8j is being run either natively -OR- under
> VM, you (currently!) need to add a "PGMTRACE -04" statement to your
> Hercules configuration file if you want to suppress their being
> reported by Hercules.
>
>
> > 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.
>
> Actually it's not the first time. As Dave pointed out in his reply it
> was actually mentioned over 19 years ago too:
>
>? ?
>
>
>
> > (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.
>
> Because Hercules does not consider such exceptions to be "routine"
> (ordinary/expected) in a *normally* (properly!) functioning operating
> system! Hercules considers such exceptions to be "unusual" and "out
> of the ordinary" and usually indicative of a programming error. Thus,
> by default, it does NOT filter them out and reports them instead.
>
>
> > (This sort of gets back to why VM/370
>
> MVS!
>
>
> > 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.
>
> I think the thing that is unique that is going on here is the
> distributers/maintainers of the MVS 3.8j and VM systems ship their
> product with OSTAILOR QUIET purposely enabled in order to prevent
> this very issue. It only popped up this time because Jim Snellen
> reported seeing the messages in his log file because he obviously
> WASN'T using the stock Hercules configuration file that comes shipped
> with the normal MVS/VM distributions, and was instead using a
> Hercules configuration file that he constructed himself (probably via
> my HercGUI, which specifically mentions using NULL or QUIET is *not*
> recommended).
>