Re: Do I have a looping issue?
Joe Monk wrote:
> Tony Harminc wrote:
[...]
> > I really don't see that it's a bug. Maybe a less than ideal
> > implementation, but who's to judge that?
>
> Well, when it was implemented it was the only way!
>
>? ? ?MODULE NAME? ? ? = IEAVEVAL
>? ? ?CSECT NAME? ? ? ?= IEAVEVAL
>? ? ?DESCRIPTIVE NAME = VALIDITY CHECK
>? ? ?COPYRIGHT? ? ? ? = N/A
>? ? ?STATUS? ? ? ? ? ?= VS2-RELEASE2
[ In passing, a line like the above STATUS = is often enough not updated to show later changes. But I take the point.]
> As we can see, it was implemented in OS/VS2 release 2. Long
> before MVS 3.8J and the TPROT instruction...
Yes, I can see that, and I can certainly understand it as well. As you say Joe, at the time, it was the *only* way it could be done, and thus cannot *technically* be classified (considered) as a bug. I agree 100% with that.
But I personally think it's quite telling that IBM did eventually "fix" (change) that particular routine to properly use the 'TPROT' instruction instead in their later versions of MVS up to and including the latest version of z/OS (which doesn't exhibit the problem).
If using 'CS' instead of 'TPROT' isn't (wasn't / shouldn't be considered) a bug, then why did they feel the need to "fix" (change) it in later versions? Why didn't they simply leave well enough alone? After all, if it ain't broke, don't fix it! Right?
Almost certainly TPROT has much better performance than CS. There is no need to serialize, or even to reference the storage in question, thus avoiding cache issues etc. If the instruction is available then why not use it if the address in question is translatable (i.e. not paged out or otherwise unavailable)? ?
If the version of MVS that's being used (3.8j) was only being run on the same/similar hardware that it originally ran on where the 'TPROT' instruction wasn't available, then it makes sense leaving it alone, as-is. But it's not. It's being run on "newer hardware" (Hercules) where the 'TPROT' instruction *is* available, thereby rendering what WAS "the proper/only way to do it" into "the improper way to do it for the hardware we're ALWAYS going to be running on".
I still say it's something that should be fixed.
Keep in mind that while TPROT appeared in the late edition(s?) of the S/370 POO, in practice it was never in most of the workhorse machines like the /168 or 3033 that actually ran MVS. And the whole notion of checking for the presence of an architectural feature on the fly and setting a flag somewhere was certainly not common in MVS if it existed at all. There was no STSI etc, and while of course it could be tried and the PIC 1 caught, I don't know of any case where that was implemented.
I'll gladly retract my "bug" claim, but I'm NOT going to change my stance regarding it being something that SHOULD (IMHO) be fixed (changed).
Changed where - in current hobbyist versions of MVS 3.8? If so, let's implement the check for TPROT so we don't break 3.8 for other hardware or emulators. In any case I'm still not clear on what instruction(s) replace entirely the need for the CS. TPROT alone is not sufficient - is whatever is needed in any version of Hercules?
Tony H.
|
Re: Do I have a looping issue?
toggle quoted message
Show quoted text
On Sun, Oct 30, 2022 at 10:56 AM Tony Harminc < tharminc@...> wrote: In z/OS they no longer use TPROT. There is a service now that does the check.
Joe
That seems kind of muddled. IEAVEVAL *is* a service that does the check, using TPROT or CS as appropriate. Do you mean there is an *instruction* now that does the same check? If so, I'm not aware of any such - can you say what it is?
Tony H.
|
Re: Do I have a looping issue?
In z/OS they no longer use TPROT. There is a service now that does the check.
Joe
That seems kind of muddled. IEAVEVAL *is* a service that does the check, using TPROT or CS as appropriate. Do you mean there is an *instruction* now that does the same check? If so, I'm not aware of any such - can you say what it is?
Tony H.
|
Re: virtual memory and overlays
Hi Harold,
Thank you for the very detailed explanation. I think is probably best to move this to the cRexx list seeing that there is work to do working to the solution. I¡¯ll invite you off-list and I promise to keep this list up to date with summarized results - if any.
¸é±ð²Ô¨¦.
toggle quoted message
Show quoted text
On 30 Oct 2022, at 10:37, Harold Grovesteen <h.grovsteen@...> wrote:
?The situation with 16M of memory and GCC compilations is a known
consideration. I am not current with this topic although I was very
much aware of what transpired due to the 16M constraint when it was
discovered. If anyone has more current information that would alter
anything I say below please chime in.
Ignore if this entire topic is not of interest to you. My response is
a bit long, and I apologize, but this is not a small topic.
Harold Grovesteen
On Sat, 2022-10-29 at 17:15 +0200, Bernd Oppolzer via groups.io wrote:
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. The issues related to compilation with GCC surrounds the size of the
module being compiled. This was first discovered when trying to
compile GCC with GCC. Prior to this point GCC (actually the i370
target of GCC) was compiled on a PC but output mainframe assembler.
The assembler modules were moved to a Hercules running operating
system where it was assembled and linked. Whether only one GCC module
triggered this situation I do not know. After all, once the first
module was encountered, it was pretty much of a show stopper for GCC
compiling GCC on Hercules.
I would look at what has changed since compilation of cRexx on VM/370
worked vs. now that it does not. Did cRexx change? Did the VM/370
environment change (reducing available memory in the virtual machine)?
Rather than looking for a GCC resolution, looking at cRexx might be the
better approach. Refactoring any cRexx module which can not be
compiled into two smaller modules would probably work. I know nothing
about cRexx source code, so how difficult that might be is unclear to
me. Maybe cRexx is one huge module. This is do not know.
As far as I know, getting past the compilation process should be
sufficient. Although, obviously, at some point source code module
structure changes will not work.
One possible solution is to return to use of i370 on a PC. cRexx could
be compiled on the PC and the assembly modules assembled and linked on
VM/370. Assuming it still exists, how to acquire the version of gcc
i370 that actually runs on a PC I have no idea. Whether there has been
any code generation changes that would make the output incompatible
with what gcc on VM/370 generates, I have no idea either. Or changes
with the C-library used by GCC, no clue. But that is a possible path.
All of the techniques listed below for GCC would also work for cRexx
and that is where I would suggest efforts be applied, not GCC.
The "fix GCC" or "compile on a PC" paths introduce a lot more unknowns
and variables than working with cRexx. Obviously, there might be
reasons for not touching cRexx, but something has to be touched if it
is to be compiled.
My bet, if cRexx has not been touched, either GCC in the version of VM
being used is different or the VM itself is different and that is where
the change occurred. The original poster, Rene, would know what might
have changed in his environment. If there was any, I did not see why
cRexx was being compiled.
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).
Whether GCC of this vintage is one large module (which I doubt very
much) or not, I do not know. The reason I say that is because the
discussion at the time suggested one module tripped this constraint.
A solution though was found. Increase the amount of available memory.
This was the solution chosen by the original developers behind the GCC
porting to MVS and VM. The solution involved allowing a S/370
operating system to run with 31-bit addressing. This was the inception
of the S/380 version of Hercules and alterations that allowed GCC (or
any other application) to use the increased memory. That group has now
split off entirely from Hercules. At this point, I ceased tracking
what they are doing.
I know the underlying Hercules address-mode change was never included
in Hercules. Whether the current versions in use on Hercules of MVS
and VM/370 include the required changes I do not know. Someone closer
to those operating systems might know the status. I think there were
separate versions of MVS and VM that had changes that used the Hercules
31-bit address mode in S/370, that is, a MVS/380 and a VM/380.
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.
Nobody was willing to tackle this problem with the i370 version of gcc.
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@...:
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?
A bigger issue would be someone with the experience and understanding
of how GCC functions to do this work. That is where the rub is. A
number of people here have probably done overlay work. It is the
knowledge of C plus compiler design that is the real challenge for this
group.
For the rare occurrences that require more than 16M to compile C code,
the "compile on a PC" approach would be recommended by me. Of course
getting access to the i370 GCC compiler that runs on a PC is the
challenge. Someone who still works with the "380" team may be able to
ascertain that.
As someone who has actually implemented an assembler, no where near as
complicated as a compiler, this is not trivial.
And I would certainly not touch it at all if C was a requirement.
best regards,
¸é±ð²Ô¨¦.
|
Re: Do I have a looping issue?
Harold,
"Hercules is NOT a hardware emulator. ?...? So, the argument that because hardware worked a certain way dictates how Hercules should operate does not conform to Hercules design objective."
I think you misunderstand the argument.
The argument is not that Hercules should work a certain way because hardware worked a certain way. After all, if that were the case, how would you disable registers 0-7 to emulate a 360/20?
The argument is that the hardware is an implementation of the architecture. If the hardware therefore, doesnt?report the error on the system console, as an implementation?of the architecture, then why does Hercules? So the argument is that the architecture doesnt?report the error on the console, and therefore the hardware, as an implementation of the architecture, doesn't either.
Joe
Hercules is NOT a hardware emulator.? Hercules emulates three different ARCHITECTURES.? Yes, those architectures have been implemented by hardware from multiple hardware vendors.? So, the argument that because hardware worked a certain way dictates how Hercules should operate does not conform to Hercules design objective.
Harold Grovesteen
On Fri, 2022-10-28 at 21:33 -0400, Aaron Finerman wrote: 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.? :)
|
Re: virtual memory and overlays
The situation with 16M of memory and GCC compilations is a known consideration. I am not current with this topic although I was very much aware of what transpired due to the 16M constraint when it was discovered. If anyone has more current information that would alter anything I say below please chime in. Ignore if this entire topic is not of interest to you. My response is a bit long, and I apologize, but this is not a small topic. Harold Grovesteen On Sat, 2022-10-29 at 17:15 +0200, Bernd Oppolzer via groups.io wrote: 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. The issues related to compilation with GCC surrounds the size of the module being compiled. This was first discovered when trying to compile GCC with GCC. Prior to this point GCC (actually the i370 target of GCC) was compiled on a PC but output mainframe assembler. The assembler modules were moved to a Hercules running operating system where it was assembled and linked. Whether only one GCC module triggered this situation I do not know. After all, once the first module was encountered, it was pretty much of a show stopper for GCC compiling GCC on Hercules. I would look at what has changed since compilation of cRexx on VM/370 worked vs. now that it does not. Did cRexx change? Did the VM/370 environment change (reducing available memory in the virtual machine)? Rather than looking for a GCC resolution, looking at cRexx might be the better approach. Refactoring any cRexx module which can not be compiled into two smaller modules would probably work. I know nothing about cRexx source code, so how difficult that might be is unclear to me. Maybe cRexx is one huge module. This is do not know. As far as I know, getting past the compilation process should be sufficient. Although, obviously, at some point source code module structure changes will not work. One possible solution is to return to use of i370 on a PC. cRexx could be compiled on the PC and the assembly modules assembled and linked on VM/370. Assuming it still exists, how to acquire the version of gcc i370 that actually runs on a PC I have no idea. Whether there has been any code generation changes that would make the output incompatible with what gcc on VM/370 generates, I have no idea either. Or changes with the C-library used by GCC, no clue. But that is a possible path. All of the techniques listed below for GCC would also work for cRexx and that is where I would suggest efforts be applied, not GCC. The "fix GCC" or "compile on a PC" paths introduce a lot more unknowns and variables than working with cRexx. Obviously, there might be reasons for not touching cRexx, but something has to be touched if it is to be compiled. My bet, if cRexx has not been touched, either GCC in the version of VM being used is different or the VM itself is different and that is where the change occurred. The original poster, Rene, would know what might have changed in his environment. If there was any, I did not see why cRexx was being compiled.
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).
Whether GCC of this vintage is one large module (which I doubt very much) or not, I do not know. The reason I say that is because the discussion at the time suggested one module tripped this constraint. A solution though was found. Increase the amount of available memory. This was the solution chosen by the original developers behind the GCC porting to MVS and VM. The solution involved allowing a S/370 operating system to run with 31-bit addressing. This was the inception of the S/380 version of Hercules and alterations that allowed GCC (or any other application) to use the increased memory. That group has now split off entirely from Hercules. At this point, I ceased tracking what they are doing. I know the underlying Hercules address-mode change was never included in Hercules. Whether the current versions in use on Hercules of MVS and VM/370 include the required changes I do not know. Someone closer to those operating systems might know the status. I think there were separate versions of MVS and VM that had changes that used the Hercules 31-bit address mode in S/370, that is, a MVS/380 and a VM/380.
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.
Nobody was willing to tackle this problem with the i370 version of gcc.
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@...:
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?
A bigger issue would be someone with the experience and understanding of how GCC functions to do this work. That is where the rub is. A number of people here have probably done overlay work. It is the knowledge of C plus compiler design that is the real challenge for this group. For the rare occurrences that require more than 16M to compile C code, the "compile on a PC" approach would be recommended by me. Of course getting access to the i370 GCC compiler that runs on a PC is the challenge. Someone who still works with the "380" team may be able to ascertain that. As someone who has actually implemented an assembler, no where near as complicated as a compiler, this is not trivial. And I would certainly not touch it at all if C was a requirement.
best regards,
¸é±ð²Ô¨¦.
|
Re: Do I have a looping issue?
On Sat, 2022-10-29 at 23:52 -0500, Doug Harvey wrote:
I don't know how many instructions there are, or when new
instructions were added, but it would be pretty cool if (say)
Hercules could be started to run with the 01-May-1980 CPU instruction
set, 01-July-1990 CPU instruction set, etc.
Hercules was never designed to operate that way. As the architectures expanded over the years, Hercules maintains the current level of the architecture. For S/370 that means Hercules emulates the LAST Principles of Operation manual for S/370. As Fish said, Never! Admittedly there are some challenges with the latest architecture, but we are well past those considerations for S/370. Harold Grovesteen
doug
On Oct 29, 2022, at 11:28 PM, Fish Fish <david.b.trout@...>
wrote:
Joe Monk wrote:
Tony Harminc wrote: [...]
I really don't see that it's a bug. Maybe a less than ideal
implementation, but who's to judge that? Well, when it was implemented it was the only way!
MODULE NAME = IEAVEVAL
CSECT NAME = IEAVEVAL
DESCRIPTIVE NAME = VALIDITY CHECK
COPYRIGHT = N/A
STATUS = VS2-RELEASE2
As we can see, it was implemented in OS/VS2 release 2. Long
before MVS 3.8J and the TPROT instruction...
Yes, I can see that, and I can certainly understand it as well. As
you say Joe, at the time, it was the *only* way it could be done,
and thus cannot *technically* be classified (considered) as a bug.
I agree 100% with that.
But I personally think it's quite telling that IBM did eventually
"fix" (change) that particular routine to properly use the 'TPROT'
instruction instead in their later versions of MVS up to and
including the latest version of z/OS (which doesn't exhibit the
problem).
If using 'CS' instead of 'TPROT' isn't (wasn't / shouldn't be
considered) a bug, then why did they feel the need to "fix"
(change) it in later versions? Why didn't they simply leave well
enough alone? After all, if it ain't broke, don't fix it! Right?
If the version of MVS that's being used (3.8j) was only being run
on the same/similar hardware that it originally ran on where the
'TPROT' instruction wasn't available, then it makes sense leaving
it alone, as-is. But it's not. It's being run on "newer hardware"
(Hercules) where the 'TPROT' instruction *is* available, thereby
rendering what WAS "the proper/only way to do it" into "the
improper way to do it for the hardware we're ALWAYS going to be
running on".
I still say it's something that should be fixed.
I'll gladly retract my "bug" claim, but I'm NOT going to change my
stance regarding it being something that SHOULD (IMHO) be fixed
(changed).
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
Re: Do I have a looping issue?
Hercules is NOT a hardware emulator. ?Hercules emulates three different ARCHITECTURES. ?Yes, those architectures have been implemented by hardware from multiple hardware vendors. ?So, the argument that because hardware worked a certain way dictates how Hercules should operate does not conform to Hercules design objective.
Harold Grovesteen
toggle quoted message
Show quoted text
On Fri, 2022-10-28 at 21:33 -0400, Aaron Finerman wrote: 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.? :)
|
Re: #VMCE #rexx EE goes XEDIT - compiling a wish list
#VMCE
#rexx
On Sun, Oct 30, 2022 at 12:33 PM, Bertram Moshier wrote:
Please add to the wishlist:? Accept * for the drive letter (e.g. EE DMKSYS ASSEMBLE *).
This should be acceptable, XEDIT on z/VM 6.4 behaves this way. LCM+L's VM/SP 5 is down atm.
It would also be nice to have a SYNONYM list for filetypes (e.g. ASM for ASSEMBLE).
This might be a typical task for the profile when EE will be able to run REXX-powered macros. Here an example for XEDIT on z/VM 6.4 : ?PROFILE? XEDIT??? A1? V 255? Trunc=255 Size=17 Line=0 Col=1 Alt=0??? ?
====>???????????????????????????????????????????????????????????????? ?
????? |...+....1....+....2....+....3....+....4....+....5....+....6....+
????????????????????????????????????????????????????????????????????? ?
??? 0 * * * Top of File * * *???????????????????????????????????????? ?
??? 1 /* REXX */????????????????????????????????????????????????????? ?
??? 2 parse arg fn ft next??????????????????????????????????????????? ?
??? 3???????????????????????????????????????????????????????????????? ?
??? 4 fn = strip(fn)????????????????????????????????????????????????? ?
??? 5 upper fn??????????????????????????????????????????????????????? ?
??? 6 if abbrev("ASSEMBLE",ft,1) then "LOAD" fn "ASSEMBLE"??????????? ?
??? 7 if abbrev("ASM"???? ,ft,3) then "LOAD" fn "ASSEMBLE"??????????? ?
??? 8 if abbrev("XEDIT"?? ,ft,1) then "LOAD" fn "XEDIT"?????????????? ?
??? 9???????????????????????????????????????????????????????????????? ?
?? 10 /* all other commands AFTER "LOAD" */?????????????????????????? ?
?? 11 "set case m i"????????????????????????????????????????????????? ?
?? 12 "set prefix nulls left"???????????????????????????????????????? ?
?? 13 "set number on"???????????????????????????????????????????????? ?
?? 14 "set cmdline top"?????????????????????????????????????????????? ?
?? 15 "set scale on 3"??????????????????????????????????????????????? ?
?? 16 "set msgline on 3 20 overlay"?????????????????????????????????? ?
?? 17 "set curline on 5"????????????????????????????????????????????? ?
?? 18 * * * End of File * * *???????????????????????????????????????? ?
??????????????????????????????????????????????????????????????????????
|
Re: Do I have a looping issue?
In z/OS they no longer use TPROT. There is a service now that does the check.
Joe
"But I personally think it's quite telling that IBM did eventually "fix" (change) that particular routine to properly use the 'TPROT' instruction instead in their later versions of MVS up to and including the latest version of z/OS (which doesn't exhibit the problem)."
Au contraire, mon ami poissonneux!
They "changed" it to TRY to use a TPROT first ... but if the TPROT would cause either a paging or translation exception, they still used compare and swap...
"If the TPROT instruction condition code indicates that a page or segment translation exception was encountered, the following processing?is?done: A recovery routine (FRR)?is?established to intercept any program checks The protection key?is?switched to the selected input protection key A compare and swap instruction?is?used to validate the storage area."
Joe
Joe Monk wrote:
> Tony Harminc wrote:
[...]
> > I really don't see that it's a bug. Maybe a less than ideal
> > implementation, but who's to judge that?
>
> Well, when it was implemented it was the only way!
>
>? ? ?MODULE NAME? ? ? = IEAVEVAL
>? ? ?CSECT NAME? ? ? ?= IEAVEVAL
>? ? ?DESCRIPTIVE NAME = VALIDITY CHECK
>? ? ?COPYRIGHT? ? ? ? = N/A
>? ? ?STATUS? ? ? ? ? ?= VS2-RELEASE2
>
> As we can see, it was implemented in OS/VS2 release 2. Long
> before MVS 3.8J and the TPROT instruction...
Yes, I can see that, and I can certainly understand it as well. As you say Joe, at the time, it was the *only* way it could be done, and thus cannot *technically* be classified (considered) as a bug. I agree 100% with that.
But I personally think it's quite telling that IBM did eventually "fix" (change) that particular routine to properly use the 'TPROT' instruction instead in their later versions of MVS up to and including the latest version of z/OS (which doesn't exhibit the problem).
If using 'CS' instead of 'TPROT' isn't (wasn't / shouldn't be considered) a bug, then why did they feel the need to "fix" (change) it in later versions? Why didn't they simply leave well enough alone? After all, if it ain't broke, don't fix it! Right?
If the version of MVS that's being used (3.8j) was only being run on the same/similar hardware that it originally ran on where the 'TPROT' instruction wasn't available, then it makes sense leaving it alone, as-is. But it's not. It's being run on "newer hardware" (Hercules) where the 'TPROT' instruction *is* available, thereby rendering what WAS "the proper/only way to do it" into "the improper way to do it for the hardware we're ALWAYS going to be running on".
I still say it's something that should be fixed.
I'll gladly retract my "bug" claim, but I'm NOT going to change my stance regarding it being something that SHOULD (IMHO) be fixed (changed).
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
Re: #VMCE #rexx EE goes XEDIT - compiling a wish list
#VMCE
#rexx
Hello,
Please add to the wishlist:? Accept * for the drive letter (e.g. EE DMKSYS ASSEMBLE *).
It would also be nice to have a SYNONYM list for filetypes (e.g. ASM for ASSEMBLE).
Thank you for asking for wish list items.
Bertram / WB8ERT
|
Re: Do I have a looping issue?
"But I personally think it's quite telling that IBM did eventually "fix" (change) that particular routine to properly use the 'TPROT' instruction instead in their later versions of MVS up to and including the latest version of z/OS (which doesn't exhibit the problem)."
Au contraire, mon ami poissonneux!
They "changed" it to TRY to use a TPROT first ... but if the TPROT would cause either a paging or translation exception, they still used compare and swap...
"If the TPROT instruction condition code indicates that a page or segment translation exception was encountered, the following processing?is?done: A recovery routine (FRR)?is?established to intercept any program checks The protection key?is?switched to the selected input protection key A compare and swap instruction?is?used to validate the storage area."
Joe
Joe Monk wrote:
> Tony Harminc wrote:
[...]
> > I really don't see that it's a bug. Maybe a less than ideal
> > implementation, but who's to judge that?
>
> Well, when it was implemented it was the only way!
>
>? ? ?MODULE NAME? ? ? = IEAVEVAL
>? ? ?CSECT NAME? ? ? ?= IEAVEVAL
>? ? ?DESCRIPTIVE NAME = VALIDITY CHECK
>? ? ?COPYRIGHT? ? ? ? = N/A
>? ? ?STATUS? ? ? ? ? ?= VS2-RELEASE2
>
> As we can see, it was implemented in OS/VS2 release 2. Long
> before MVS 3.8J and the TPROT instruction...
Yes, I can see that, and I can certainly understand it as well. As you say Joe, at the time, it was the *only* way it could be done, and thus cannot *technically* be classified (considered) as a bug. I agree 100% with that.
But I personally think it's quite telling that IBM did eventually "fix" (change) that particular routine to properly use the 'TPROT' instruction instead in their later versions of MVS up to and including the latest version of z/OS (which doesn't exhibit the problem).
If using 'CS' instead of 'TPROT' isn't (wasn't / shouldn't be considered) a bug, then why did they feel the need to "fix" (change) it in later versions? Why didn't they simply leave well enough alone? After all, if it ain't broke, don't fix it! Right?
If the version of MVS that's being used (3.8j) was only being run on the same/similar hardware that it originally ran on where the 'TPROT' instruction wasn't available, then it makes sense leaving it alone, as-is. But it's not. It's being run on "newer hardware" (Hercules) where the 'TPROT' instruction *is* available, thereby rendering what WAS "the proper/only way to do it" into "the improper way to do it for the hardware we're ALWAYS going to be running on".
I still say it's something that should be fixed.
I'll gladly retract my "bug" claim, but I'm NOT going to change my stance regarding it being something that SHOULD (IMHO) be fixed (changed).
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
Re: #VMCE #rexx EE goes XEDIT - compiling a wish list
#VMCE
#rexx
On Thu, Oct 27, 2022 at 05:45 PM, Martin Scheffler wrote:
What do I need for "EE goes XEDIT" ?
- from C call an assembler routine to establish a CMS SUBCOM evironment "XEDIT"
- an assembler routine which receives subcommand calls and calls the C part of the editor
- an assembler routine using EXECCOMM to share REXX variables, EXTRACT needs this
Some progress ... EE is seeing subcommands via bREXX and sets return code 4711?? () :
File: CLOSE??? EXEC???? A1???????????? ?
?====> cms close?????????????????????? ?
?File written: CLOSE EXEC A1?????????? ?
??? 0 * * * Top of File * * *????????? ?
??? 1 /* REXX */?????????????????????? ?
??? 2 trace i????????????????????????? ?
??? 3 address "CMS" "IDENTIFY"???????? ?
??? 4 say rc?????????????????????????? ?
??? 5 address "JUNK" "IDENTIFY"??????? ?
??? 6 say rc?????????????????????????? ?
??? 7 address "XEDIT" "IDENTIFY"?????? ?
??? 8 say rc?????????????????????????? ?
??? 9 say "Hit ENTER to continue ..."? ?
?? 10 parse pull?????????????????????? ?
?? 12 exit rc????????????????????????? ?
?? 12 * * * End of File * * *????????? ?
?????????????????????????????????????? ?
???? 3 *-* address "CMS" "IDENTIFY"???????????????????????????????? ?
?????? >>>?? "CMS"????????????????????????????????????????????????? ?
?????? >L>?? "IDENTIFY"???????????????????????????????????????????? ?
MECAFF?? AT VM370CE? VIA RSCS???? 07:42:45 10/30/22 GMT???? SUNDAY? ?
???? 4 *-* say rc?????????????????????????????????????????????????? ?
?????? >V>?? "0"??????????????????????????????????????????????????? ?
0?????????????????????????????????????????????????????????????????? ?
???? 5 *-* address "JUNK" "IDENTIFY"??????????????????????????????? ?
?????? >>>?? "JUNK"???????????????????????????????????????????????? ?
?????? >L>?? "IDENTIFY"???????????????????????????????????????????? ?
???? 6 *-* say rc?????????????????????????????????????????????????? ?
?????? >V>?? "-3"?????????????????????????????????????????????????? ?
-3????????????????????????????????????????????????????????????????? ?
???? 7 *-* address "XEDIT" "IDENTIFY"?????????????????????????????? ?
?????? >>>?? "XEDIT"??????????????????????????????????????????????? ?
?????? >L>?? "IDENTIFY"???????????????????????????????????????????? ?
???? 8 *-* say rc?????????????????????????????????????????????????? ?
?????? >V>?? "4711"???????????????????????????????????????????????? ?
4711??????????????????????????????????????????????????????????????? ?
???? 9 *-* say "Hit ENTER to continue ..."????????????????????????? ?
?????? >L>?? "Hit ENTER to continue ..."??????????????????????????? ?
Hit ENTER to continue ...?????????????????????????????????????????? ?
??? 10 *-* parse pull?????????????????????????????????????????????? ?
?????????????????????????????????????????????????????????????????????
|
Re: Do I have a looping issue?
Doug Harvey wrote: Very much a newcomer here but have been following this discussion
with interest, and appreciate both sides of the discussion, but I
don't think the program should be updated.
If it WAS, and tomorrow (somehow) you stumbled across an old 1980's
era mainframe in a barn, HA! In your dreams! :) you should be able to install and run MVS 3.8j on it.
If this program were updated to use the TPROT instruction,
that wouldn't work. Sure it would! As long as you did the update *correctly* (sensibly) of course. Check for the existence of the 'TPROT' instruction at startup (IPL) and set a flag somewhere that IEAVEVAL can then easily check. If the flag is on ('TPROT' is available), do it the newer, better, *preferred* way. Otherwise fall back to doing it the older less efficient 'CS' way. I don't know how many instructions there are, or when new
instructions were added, but it would be pretty cool if (say)
Hercules could be started to run with the 01-May-1980 CPU
instruction set, 01-July-1990 CPU instruction set, etc. That would be an administrative nightmare and something that would almost *certainly* NEVER happen. (That of course is a prediction based on my years as a Hercules developer, and NOT a promise. Stranger things have happened. But seriously, I *strongly* doubt it will EVER happen.) -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Re: Do I have a looping issue?
Very much a newcomer here but have been following this discussion with interest, and appreciate both sides of the discussion, but I don't think the program should be updated.
If it WAS, and tomorrow (somehow) you stumbled across an old 1980's era mainframe in a barn, you should be able to install and run MVS 3.8j on it. If this program were updated to use the TPROT instruction, that wouldn't work.
I don't know how many instructions there are, or when new instructions were added, but it would be pretty cool if (say) Hercules could be started to run with the 01-May-1980 CPU instruction set, 01-July-1990 CPU instruction set, etc.
doug
toggle quoted message
Show quoted text
On Oct 29, 2022, at 11:28 PM, Fish Fish <david.b.trout@...> wrote:
Joe Monk wrote:
Tony Harminc wrote: [...]
I really don't see that it's a bug. Maybe a less than ideal
implementation, but who's to judge that? Well, when it was implemented it was the only way!
MODULE NAME = IEAVEVAL
CSECT NAME = IEAVEVAL
DESCRIPTIVE NAME = VALIDITY CHECK
COPYRIGHT = N/A
STATUS = VS2-RELEASE2
As we can see, it was implemented in OS/VS2 release 2. Long
before MVS 3.8J and the TPROT instruction...
Yes, I can see that, and I can certainly understand it as well. As you say Joe, at the time, it was the *only* way it could be done, and thus cannot *technically* be classified (considered) as a bug. I agree 100% with that.
But I personally think it's quite telling that IBM did eventually "fix" (change) that particular routine to properly use the 'TPROT' instruction instead in their later versions of MVS up to and including the latest version of z/OS (which doesn't exhibit the problem).
If using 'CS' instead of 'TPROT' isn't (wasn't / shouldn't be considered) a bug, then why did they feel the need to "fix" (change) it in later versions? Why didn't they simply leave well enough alone? After all, if it ain't broke, don't fix it! Right?
If the version of MVS that's being used (3.8j) was only being run on the same/similar hardware that it originally ran on where the 'TPROT' instruction wasn't available, then it makes sense leaving it alone, as-is. But it's not. It's being run on "newer hardware" (Hercules) where the 'TPROT' instruction *is* available, thereby rendering what WAS "the proper/only way to do it" into "the improper way to do it for the hardware we're ALWAYS going to be running on".
I still say it's something that should be fixed.
I'll gladly retract my "bug" claim, but I'm NOT going to change my stance regarding it being something that SHOULD (IMHO) be fixed (changed).
--
"Fish" (David B. Trout)
Software Development Laboratories
mail: fish@...
|
Re: Do I have a looping issue?
Joe Monk wrote: Tony Harminc wrote: [...] I really don't see that it's a bug. Maybe a less than ideal
implementation, but who's to judge that? Well, when it was implemented it was the only way!
MODULE NAME = IEAVEVAL
CSECT NAME = IEAVEVAL
DESCRIPTIVE NAME = VALIDITY CHECK
COPYRIGHT = N/A
STATUS = VS2-RELEASE2
As we can see, it was implemented in OS/VS2 release 2. Long
before MVS 3.8J and the TPROT instruction...
Yes, I can see that, and I can certainly understand it as well. As you say Joe, at the time, it was the *only* way it could be done, and thus cannot *technically* be classified (considered) as a bug. I agree 100% with that. But I personally think it's quite telling that IBM did eventually "fix" (change) that particular routine to properly use the 'TPROT' instruction instead in their later versions of MVS up to and including the latest version of z/OS (which doesn't exhibit the problem). If using 'CS' instead of 'TPROT' isn't (wasn't / shouldn't be considered) a bug, then why did they feel the need to "fix" (change) it in later versions? Why didn't they simply leave well enough alone? After all, if it ain't broke, don't fix it! Right? If the version of MVS that's being used (3.8j) was only being run on the same/similar hardware that it originally ran on where the 'TPROT' instruction wasn't available, then it makes sense leaving it alone, as-is. But it's not. It's being run on "newer hardware" (Hercules) where the 'TPROT' instruction *is* available, thereby rendering what WAS "the proper/only way to do it" into "the improper way to do it for the hardware we're ALWAYS going to be running on". I still say it's something that should be fixed. I'll gladly retract my "bug" claim, but I'm NOT going to change my stance regarding it being something that SHOULD (IMHO) be fixed (changed). -- "Fish" (David B. Trout) Software Development Laboratories mail: fish@...
|
Re: Do I have a looping issue?
"I really don't see that it's a bug. Maybe a less than ideal implementation, but who's to judge that?"
Well, when it was implemented it was the only way!?
*01* ?MODULE NAME= ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?00150002
* ? ? ? ? ? ? IEAVEVAL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?00200002
*02* ? ? ?CSECT NAME= ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00210002
* ? ? ? ? ? ? IEAVEVAL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?00220002
*01* ?DESCRIPTIVE NAME= ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00250002
* ? ? ? ? ? ? ? ? ?VALIDITY CHECK ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00300002
*01* ?COPYRIGHT= ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?00350002
* ? ? ? ? ? N/A ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00400002
*01* ?STATUS= ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 00450002
* ? ? ? ?VS2-RELEASE2 ? ??
As we can see, it was implemented in OS/VS2 release 2. Long before MVS 3.8J and the TPROT instruction...
Joe
On Sat, Oct 29, 2022 at 8:30 PM Tony Harminc < tharminc@...> wrote: [...]
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: 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
|
Martin Scheffler