Re: Do I have a looping issue?
[...]
I'm sure you'll agree that products should be allowed to issue whatever messages they feel might be helpful to the user. Yes?
Well, sort of. The user should generally be able to tailor messages, typically by severity. I've seen plenty of complaints about all kinds of software that there are too many messages being issued, or they go to the wrong place, etc.
There's even a recent thread on IBM-MAIN about an instance of this. ?
[...] But given that this particular feature has been a part of Hercules for over 20 years now and, as far as I know, this one specific particular version of MVS is the *only* one (that I am aware of) that seems to trigger these particular unwanted messages that you are complaining so loudly about [...]
This program check on a CS may well be unique as a routine thing, but I'm not at all sure it's a bug. As has been mentioned, it's a fundamental part of the MVS integrity design that the normal approach to validating a storage address passed from an unprivileged caller to a privileged one is to adopt the key of the caller before referencing the storage. If the address is not accessible by the caller then a program check will result. This is a fault in (or an attempt to compromise system integrity by) the unauthorized caller - not a fault in the OS. In the case at hand, it seems that an privileged MVS routine is doing this validation a different way, but either way would result in a program check in privileged MVS code.
In fact, I feel the fact that the messages are being issued PROVES their usefulness! Their very issuance has brought to light what some feel is a serious shortcoming (or dare I say, bug) in MVS! Had the messages that you are currently complaining so loudly about NOT been issued, that fact would never have come to light.
I really don't see that it's a bug. Maybe a less than ideal implementation, but who's to judge that? ?
> It is never a good thing to see illegitimate program check messages
> from your OS on the console.
Then fix your operating system to not cause illegitimate program checks!? ;-)
It's most certainly not an "illegitimate" program check!
That there's a problem in the operating system in question that should probably be fixed? :)
No.
Tony H.
|
Re: virtual memory and overlays
On Sat 29 Oct 2022 at 17:15:24 +0200, Bernd Oppolzer via groups.io wrote: from the rest of the compilation or by separating the compiler passes from
each other ...
if there are multiple passes). There are definitely different phases, but in how far they are actually run sequentially (like actual passes), I don't know. At least current gccs have an option to dump out the intermediate data structures after each phase: -fdump-tree-all. In theory those passes might be run sequentially. But I suspect that the fact that a representation of the whole source program file is kept in memory at once will be an unavoidable problem, with only 16 MB of address space to work with. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFH falu.nl@rhialto
|
Re: virtual memory and overlays
Is there anyone from that era who still knows how this is done, can tell us
whether it would be possible, and can advise on what to do?
I had a quick look, and it appears there is support in config.h for generating the pre-processor as a separate module. I may try doing this if I get a moment.
best regards,
¸é±ð²Ô¨¦.
Dave
|
Re: Do I have a looping issue?
Gregg Levine wrote: Aaron, ideally the things that the OSTAILOR instructions
are properly documented, they are indeed Fish? Yes, OSTAILOR is definitely documented: * PGMTRACE is not however. It's mentioned, but it's technically not documented. But then, I'm not sure it really needs to be either. I think simply mentioning it in this particular case should be good enough. It is also not documented anywhere what *specific* program interrupts are filtered by default for each OSTAILOR setting either, but it's easy enough to determine that for oneself, as my earlier post illustrated: * /g/h390-vm/message/4474The other problem is that how many of us are even aware of them?
Me? I am not. That's hardly surprising. In my experience most users *rarely* take the time to read through a product's available documentation to familiarize themselves with it. They usually go straight to trying to use it and then ask for help when they have problems/questions. Problems/questions that are quite typically already answered/addressed in the documentation, had they bothered to take the time to read it. It's sad, really. :( -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Re: Do I have a looping issue?
Aaron Finerman wrote: Fish wrote:
Aaron Finerman wrote:
Hercules should not be in the business of reporting program
checks. Why not? What is your reasoning? Hercules is a hardware emulator, not an operating system. So your claim is that hardware emulators shouldn't (or should not be allowed to) issue helpful messages? The fact that Hercules is a hardware emulator carries no weight in the argument. Hercules is a PRODUCT. I'm sure you'll agree that products should be allowed to issue whatever messages they feel might be helpful to the user. Yes? And the fact that in this particular case YOU personally feel that the messages that Hercules is currently issuing are unhelpful to YOU (and therefore are not interested in seeing them) is immaterial IMO. Others may well feel differently. Which is why we have a configuration options the user can set to their liking. If you personally don't wish to see such messages, then feel free to configure your Hercules with OSTAILOR QUIET. According to the architecture, hardware's responsibility
is to store ILC and interrupt code, and swap psws. Which Hercules certainly does. Operating system would do the rest and if necessary produce
any messages. Again, does this mean hardware emulators are not allowed (or should not) issue helpful messages of their own as well? You don't see any program check messages on the z15 or zPDT consoles
(or any other real hardware). Immaterial. Hercules is not a z15 or zPDT. Hercules is Hercules. It should only report on a disabled wait condition, which
it does. Again, why?
In my days when the hardware loaded a disabled wait, an alarm
went off in the machine room to notify the operators that the
system went down. Nowadays I hear the status goes red on your
HMC connected web browser. So, reporting on a disabled wait is
always a good idea.
I meant why should Hercules ONLY report disabled waits and not ALSO unexpected program interrupts. :) I think it's obvious Hercules should report disabled waits. OSTAILOR is a useless option and should default to QUIET. Why?
Again, back to this being an OS responsibility. Most operating
systems display interrupt information or provide exits to let
the application handle the program check.
Personally, I like to know who actually benefits from this feature?
The Hercules user, obviously. (Well, Hercules users other than YOU that is.) It's obvious that YOU certainly don't feel benefitted by them. But I'm sure there exists a non-zero subset of Hercules users out there who do however. Now, are there enough of them to justify NOT changing OSTAILOR's default to QUIET? I don't know. Unknown. But given that this particular feature has been a part of Hercules for over 20 years now and, as far as I know, this one specific particular version of MVS is the *only* one (that I am aware of) that seems to trigger these particular unwanted messages that you are complaining so loudly about, fails IMHO to justify suddenly changing the default OSTAILOR to QUIET. In fact, I feel the fact that the messages are being issued PROVES their usefulness! Their very issuance has brought to light what some feel is a serious shortcoming (or dare I say, bug) in MVS! Had the messages that you are currently complaining so loudly about NOT been issued, that fact would never have come to light. It is never a good thing to see illegitimate program check messages
from your OS on the console. Then fix your operating system to not cause illegitimate program checks! ;-) You are correct that if one were writing an OS this may come handy,
but anyone who is doing this would know when you get an interrupt,
the first thing you do is to save your registers and the old psw
is already stored. So what is Hercules telling you that you don't
know? That there's a problem in the operating system in question that should probably be fixed? :) -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Re: virtual memory and overlays
I don't have a solution to this problem, obviously, but I would like to ask some questions to understand the problem better.
With respect to this: "where it first compiled cRexx on VM/370, now it does not" ...
does the storage problem depend on the size or complexity of the source code being compiled?
That is: does gcc on VM refuse to start, or does the error occur later during compilation?
If, for example, gcc compiles simple programs and does not compile complex programs,
the error could come from the non-availability of dynamic (free) storage used to store
compiler lists, used to store variable names, attributes, offsets etc.
If this was the case, then - of course - a reduction in module size by using overlay techniques would help ...
or by issuing dynamic loads (and deletes) of compiler components which are not used together
at the same time (but at different times during compilation, maybe by separating the preprocessor
from the rest of the compilation or by separating the compiler passes from each other ...
if there are multiple passes).
AFAIK, the gcc compiler for VM is a simple port of gcc from other platforms, but nothing has been
done to cope with the special requirements of the 16 MB restriction; gcc consists of one large
load module where all calls are simple static calls (using V constants).
I could imagine a much better solution, but improving this requires a deep knowledge of the
overall gcc structure and a decision, which parts of gcc could maybe be transformed into
seperately loadable "phases". If the gcc compiler does not have parts that run sort of
separately from the rest and can be separated using LOAD / DELETE or LINK macros,
then IMO all bets are off.
Of course: gcc is written in C, but anyway:
even C functions can be loaded (and removed) dynamically using the MVS macros mentioned above;
I've done this in the past using IBMs C with C function pointers (by writing ASSEMBLER functions
cload() and cdelete() usable from C, returning C function pointers). This is possible.
But the hard part IMO is:
to identify the parts of gcc where such a change makes sense
and where it would help to reduce the overall gcc load module size.
A function which is cload()ed from the rest of gcc must be linked together with all of its needed subfunctions,
and in the best case it should not need subfunctions used in the rest of gcc ... otherwise the needed
space for these subfunctions will double.
That is:
all the functions of gcc must be separated in several different sets of functions, which are complete
(that is, don't need functions from another set) AND the different sets can be cload()ed step be step
from a main section at different times. If this is accomplished, then the overall size used will be
only the size of the largest set plus the size of the main section (and not the sum of all sections,
as today).
I don't know if this is possible. It is probably needed to analyse all the function calls first.
HTH, kind regards
Bernd
Am 28.10.2022 um 17:51 schrieb rvjansen@...:
toggle quoted message
Show quoted text
Just a wild question here with regard to the compiler we need to use for cREXX.
The gcc compiler ported to VM/370 suffers address space size problems (so I have heard from reliable sources) and even has led to the ¡®380¡¯ version of Hercules to be able to be compiled (so I have read). A larger language like PL/I does not have these problems however, and when I read up about its history, this seems to be due to the fact that it has a lot of ¡®phases¡¯ that could be implemented in overlays, something the linkage editor/loader could handle in the pre-virtual memory days (and following IBM¡¯s reputation for preserving compatibility, probably still can).
This has led to the anecdote that one IBM lab was toiling at phases and overlays to fit PL/I in even the smallest of S/360 machines, while the other team was putting the finishing touches on virtual memory. Should they have talked to each other, a lot of work could have been avoided.
Now gcc is a lot bigger than anything from that era, and we have problems - where it first compiled cRexx on VM/370, now it does not. My speculation is that if we went in the opposite route than the historic development went, and we packaged this compiler in overlays, we could lessen its memory footprint.
Is there anyone from that era who still knows how this is done, can tell us whether it would be possible, and can advise on what to do?
best regards,
¸é±ð²Ô¨¦.
|
Re: #VMCE #rexx EE goes XEDIT - compiling a wish list
#VMCE
#rexx
On Fri, Oct 28, 2022 at 02:00 AM, Mark A. Stevens wrote:
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?
Quote from page 348:
System Product Editor Interface to Access Files in Storage
CMS uses the SUBCOM facility to allow a number of CMS commands to use an
XEDIT interface to access files in storage. Applications can read or write specific
records without having to go to disk or use the program stack to transfer the data
to or from XEDIT. This improves performance.
This interface is used internally by CMS for processing the FILELIST, HELP,
PEEK, and SENDFILE commands. The interface is invoked by specifying the
XEDIT option on the LISTFILE or NAMEFIND commands. This option may
only be specified from the XEDIT environment.
When using this interface from an application program, only the extended Parame-
ter List can be used, and the high-order byte of of Register 1 must contain X'02' to
indicate SUBCOM is being used.
The application can invoke this interface via SVC 202 or via a BALR instruction.
Because XEDIT is a nucleus-resident routine, other nucleus-resident routines can
branch directly to it while routines that do not resides in the nucleus use SVC link-
age. When using an SVC 202, register 1 must point to the FSCB where the name
of the routine being invoked is the first token. [...]
348 VM/SP System Programmer's Guide
|
Re: #VMCE #rexx EE goes XEDIT - compiling a wish list
#VMCE
#rexx
The bREXX bug with literals in the parse template does not break running editor macros in general. If anybody knows of a XEDIT macro where this bug would change behaviour, I'd like to see it. I am sure there is always a way to program around this bug and I am confident to say this because of my experience on VM/SP 1+2.
Martin
|
Re: Adding disks found in DMKRIO and CPEREP error
Hello Mark,
Thank you for the link to the earlier message.? As for the 3270:
: Now start the 3270 emulator.
: Feel free to replace this with your preferred terminal emulation program.
cd WC3270
start wc3270.exe -keymap 3270 -title "VM Login" Model5.wc3270
Bertram Moshier / WB8ERT
On Fri, Oct 28, 2022 at 11:27 PM Mark A. Stevens via <marXtevens= [email protected]> wrote: 2) How do I copy and paste text from a 3270 screen to email without having it look so crappy.? Any thoughts?? Yeah, copy line by line, but ...
What 3270 emulator, on what OS, please?
?... Mark S.
|
Re: Adding disks found in DMKRIO and CPEREP error
2) How do I copy and paste text from a 3270 screen to email without having it look so crappy.? Any thoughts?? Yeah, copy line by line, but ...
What 3270 emulator, on what OS, please? ?... Mark S.
|
Re: Adding disks found in DMKRIO and CPEREP error
On Fri, Oct 28, 2022 at 12:21 PM, Bertram Moshier wrote:
Can someone help me create the 3350 and 3380 drives on the Herc system?? I'm not sure of the command.? (If someone already answered this question, I apologize for mising it.)? The drives are:
Rene gave an example in the following e-mail. I remembered reading it, and found it by searching via groups.io. /g/h390-vm/message/2601I Hope This Helps ?... Mark
|
Re: #VMCE #rexx EE goes XEDIT - compiling a wish list
#VMCE
#rexx
On Fri, Oct 28, 2022 at 07:19 PM, Mike Gro?mann wrote:
what do you mean by:
?
??BREXX still has a problem with parsing its command line, so that will be a challenge, in and of itself.¡°
?
The error in the parse statement or any other issue?
BREXX in MVS 3.8j , and in VM/370 does not handle literals when you use PARSE ARG, or ARG. The problem was discussed in earlier e-mails: Rexx PARSE on VM/SP 5 behaves different from BRexx on VM/370 CE V1M1R1.1. /g/h390-vm/message/3843Possible bug in BREXX parse instruction /g/h390-vm/message/3736and issues have been opened in the following GitHub projects. PARSE errors when literal patterns used #8 BREXX PARSE errors with literals in the template #61 I Hope This Helps ?... Mark S.
|
Re: Do I have a looping issue?
Hello!
<Me wearing a worn looking wide brimmed hat that's also worn by Indy
Jones and a long scarf with special color patterns>
Aaron, ideally the things that the OSTAILOR instructions are properly
documented, they are indeed Fish? The other problem is that how many
of us are even aware of them? Me? I am not.
<Now not wearing those.>
Be careful Fish, there's a crab looking for you.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."
toggle quoted message
Show quoted text
On Fri, Oct 28, 2022 at 10:01 PM Aaron Finerman <arfinerman@...> wrote:
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. :)
|
Re: Do I have a looping issue?
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, 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.? :)
>
|
Re: Do I have a looping issue?
Fish wrote:
> Hercules should not be in the business of reporting program
> checks.
>>>Why not? What is your reasoning?
Hercules is a hardware emulator, not an operating system. According to the architecture, hardware's responsibility?is to store ILC and interrupt code, and swap psws. Operating system would do the rest and if necessary produce any messages.? You don't see any program check messages on the z15 or zPDT consoles (or any other real hardware).?
> It should only report on a disabled wait condition, which > it does. >>>Again, why?
In my days when the hardware loaded a disabled wait, an alarm went off in the machine room to notify the operators that the system went down. Nowadays I hear the status goes red on your HMC connected web browser. So, reporting on a disabled wait is always a good?idea.
> OSTAILOR is a useless option and should default to QUIET.
>>>Why?
Again, back to this being an OS responsibility. Most operating systems display interrupt information or provide exits?to let the?application?handle the program check.? ? Personally, I like to know who actually benefits from this feature ? It is never a good thing to see illegitimate program check messages from your OS on the console. You are correct that if one were writing?an?OS this may come handy, But anyone who is doing this would know when you get an interrupt, the first thing you do is to save your registers and the old psw is already stored. So what is Hercules telling you that you don't know ?
Best regards, ??
? ?
Aaron Finerman wrote:
> Hercules should not be in the business of reporting program
> checks.
Why not? What is your reasoning?
> It should only report on a disabled wait condition, which
> it does.
Again, why?
> OSTAILOR is a useless option and should default to QUIET.
Why?
> If an application program checks, the underlying OS produces
> the appropriate messages.
Not always, but yes, I'll concede the point.
> If an OS program checks, it either produces a dump, or loads
> a disabled wait with memory intact for problem determination
> or a standalone dump.
Usually, yes. I would agree.
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?
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.? :)
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
Re: #VMCE #rexx EE goes XEDIT - compiling a wish list
#VMCE
#rexx
Hey Mark,
what do you mean by:
??BREXX still has a problem with parsing its command line, so that will be a challenge, in and of itself.¡°
The error in the parse statement or any other issue?
Mike Mark A. Stevens via <marXtevens= [email protected]> schrieb am Do. 27. Okt. 2022 um 20:00:
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.
-- Von Gmail Mobile gesendet
|
Re: Do I have a looping issue?
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. :)
|
Re: Do I have a looping issue?
Joe, thank you for the explanation of WHY. ?While I worked many years as a systems programmer on MVS ?I was never an internals guy. ?My specialty was "networking" and related subsystems. ?Pretty much all of them.
Yes, I see now how this is a perfectly normal thing for MVS to do. ?The recommendation to change the instruction from CS to something else would seem to be an improved implementation. ?I can see why this is happening so frequently, too.
Again, thanks Joe, Harold
toggle quoted message
Show quoted text
On Fri, 2022-10-28 at 17:22 -0500, Joe Monk wrote: "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 AreasA 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
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).
>
|
Re: Do I have a looping issue?
"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 AreasA 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
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).
>
|
Re: Do I have a looping issue?
Aaron Finerman wrote: Hercules should not be in the business of reporting program
checks. Why not? What is your reasoning? It should only report on a disabled wait condition, which
it does. Again, why? OSTAILOR is a useless option and should default to QUIET. Why? If an application program checks, the underlying OS produces
the appropriate messages. Not always, but yes, I'll concede the point. If an OS program checks, it either produces a dump, or loads
a disabled wait with memory intact for problem determination
or a standalone dump. Usually, yes. I would agree. 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? 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. :) -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Martin Scheffler
Mark A. Stevens
Mike Gro?mann