If OSTAILOR was meant to help in OS development (which I agree it could come handy) it would be perfected by addition of
EXT+ SVC+ PGM+ MCH+ commands to allow for tracing of all or selective codes.
Best regards,


On Fri, Oct 28, 2022 at 7:04 PM Harold Grovesteen <h.grovsteen@...> wrote:

On Fri, 2022-10-28 at 15:09 -0700, Fish Fish wrote:

Aaron Finerman wrote:

OSTAILOR is a useless option and should default to QUIET.

From the purpose of someone who only runs a mature operating system, I
can understand this perspective. However,...

But why can't Hercules issue a message as well? I mean, I can
certainly envision a situation where a programmer might be writing
code that has some type of program interrupt interception/handling
routine (STXIT I believe it's called? I'm not an MVS person!) to deal
with, say, a page fault or a data exception or even an operation
exception, but which is incorrectly coded to not expect a protection
exception.

Then too there is the case of stand-alone programs or a someone
writing (developing) their own operating system too, and would
appreciate being informed whenever something "unexpected" happens.
Have you considered that?

Absolutely agree 100%! I am aware of activities by individuals in all
of these areas. And can well understand when Hercules was being
debugged, the usefulness of seeing all program interruptions until
Hercules itself was reasonably well debugged. And then the "tailoring"
made sense.

OSTAILOR support (with its current default(*)) has been a part of
Hercules ever since version 1.61 release back in May 2000. And for
good reason IMO: it helps keep the Hercules user (which in most all
cases (but admittedly not necessarily every case) is a single
user/person) informed about the internal goings on inside that
amazing virtual mainframe sitting on their desk and running the
operating system and software of their choosing.

I'm seriously doubting our current OSTAILOR handling is *ever* going
to change in that regard.

HOWEVER...

Having said that, what I *can* envision is *maybe* (*possibly*)
adding a *new* OSTAILOR setting specifically designed for MVS 3.8j. A
new "OSTAILOR MVS38J" perhaps. Or maybe just "OSTAILOR MVS". Or maybe
"MVSNOPROT" or something. THAT I think might have a better chance of
being accepted by the other developers and the rest of the community.

But defaulting OSTAILOR to QUIET? Nope. Ain't gonna ever happen.
(That's a prediction by the way, not a promise.)

Just my 2 cents.

Mine too. :)

On Thu, Oct 27, 2022 at 01:36 PM, Martin Scheffler wrote:

CMS HELP was based on XEDIT since VM/SP 1.
FILELIST arrived with VM/SP 2, EXEC 2 was used ( still EXEC 2 on LCM+L's VM/SP 5 but (compiled) REXX on z/VM 6.4).

REXX arrived with VM/SP 3, XEDIT received EXTRACT, Prefix Macro Support, Selective Line Editing (see ).

I think as a minimum we should approach VM/SP 3 XEDIT compatibility.

Martin

I think SP3 compatibility would be a good start. BREXX still has a problem with parsing its command line, so that will be a challenge, in and of itself. Would support of EXEC2 be present, until BREXX is fixed?

I don't know where XEDIT lives in memory, when invoked. Does putting it, or part of it in a DisContiguous Saved Segment (DCSS) hurt or help? Was it in the CMS DCSS since SP 1?

?... Mark S.

"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."

"User-Supplied Addresses for User Storage Areas

A potential integrity exposure exists whenever a routine having a system protection key (key 0-7) accepts a user-supplied address of an area to which a store or fetch is to be done.?If?the system routine does not adequately validate the user-supplied address to ensure that it is the address of an area accessible to the user for storing and fetch data, an integrity violation can occur when the system-key routine:

Stores?into?(overlays) system code?or data (for?example, in the nucleus?or the?system?queue area), or into another?user's code?or?data.

Moves?data?from a?fetch-protected?area?that?is?not?accessible?to the user (for?example, fetch-protected?portion of?the?common?service areas)?to an area that?is accessible?to the?user.

The?elimination?of?this?problem?requires?that?system-key routines always verify?that?the entire?area to be?stored into,?or?fetched from, is accessible?(for?storing?or?fetching)?to the?user in question.?The?primary validation technique is?the?generally established?MVS convention that?system-key routines?obtain the protection?key?of the user before?accessing?the?user-specified?area of?storage.?For?example,?MVS data management SVC?routines (which generally execute in key?5)?assume the user's key?before?modifying a?data control?block?(DCB) or an I/O block (lOB)."

So now you know the WHY.

Page SUP-336 of this book explains the HOW:?

Joe

On Fri, Oct 28, 2022 at 4:38 PM Harold Grovesteen <h.grovsteen@...> wrote:

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).
>

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).