On Sat, 5 Mar 2022 at 19:48, Charles Mills wrote:
>
> I guess I am unclear on the sequence of events involved. Serious question,
> not an argument:
>
> I have an ordinary problem state program that attempts to access storage
> that it does not have access to. Obviously a S0C4 is the result. Let's
There really isone. If you're authorized, TPROT will help, but there are three
problems:
1. It requires Supervisor mode.
2. I requires that you be in the correct addressing environment.
3. It gives a condition code three with no useful information if
the data are paged out.
--
Shmuel
How would you handle CC 3 from TPROT? Does z/VSE have a facility to request a
page-in without treating an invalid virtual address as an error?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List
Yes, and they will report it if TPROT gives cc=3.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Jeremy Schwartz
It is not obvious that there will be an S0C4. ESPIE can intercept codes related
to various types of protection.
The general sequence of events is
1. You get a program check. The Supervisor determines that it needs to page
something in.
2. Upon redispatch, you attempt to use the data
3.
I guess I am unclear on the sequence of events involved. Serious question,
not an argument:
I have an ordinary problem state program that attempts to access storage
that it does not have access to. Obviously a S0C4 is the result. Let's say
the address is a valid virtual address (but the storage
z/VSE and running on the callers TCB (for several z/VSE related reasons).
Tony Thigpen
Seymour J Metz wrote on 3/5/22 19:35:
As a subsystem, you should have your own recovery environment, so what you do
won't interfere with the caller's error recovery. Using a recovery routine,
whether to
As a subsystem, you should have your own recovery environment, so what you do
won't interfere with the caller's error recovery. Using a recovery routine,
whether to handle a program check or to handle the ABEND from an unhandled
program check, has two advantages:
1. It works when the data
Using an ESPIE will avoid an ABEND, as will the appropriate use of move with
key.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Keven Hall [k...@k3n.us]
Sent:
> How does the hardware not know the answer to that question?
Because the hardware only knows about pages assigned to pages; it knows nothing
about what has been paged out, as was previously noted.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
> only the OS knows the answer to this question
Am I suffering from some mental block? How does the hardware not know the
answer to that question? If an instruction can cause a S0C4, why could an
instruction not answer this question? The hardware "knows" about virtual
addresses.
Also FWIW, I
> Store with Caller's PSW Key
There are the various "move with specified key" instructions.
Best practice for writing a PC routine requires that you make use of those
or equivalent services.
> But would such a facility be useful to an intruder
I don't think it would provide any information
There’s no way to avoid an ABEND unless you use FRR, ARR,ESTAE etc. or unless
your thread of execution has some explicit or implicit lock on the virtual
storage.
There’s no “safe “ instruction that serves you purpose.
The archives are replete with discussions on this topic IIRC
Regards,
On Mar 5, 2022, at 15:11:41, Tony Thigpen wrote:
>
> Since I support software that is called by any number of users, I would like
> to validate that they provided valid parms. As a called subsystem, I can't be
> messing with the callers error handling routines that may already be handling
>
My thoughts.
Since I support software that is called by any number of users, I would
like to validate that they provided valid parms. As a called subsystem,
I can't be messing with the callers error handling routines that may
already be handling SOC4s. I don't want to know if it's 'in
To paraphrase the Great and Powerful Oz, "Pay no attention to that man behind
the macro."
I had made a bunch of clean-up to this macro, renaming operands to be more
meaningful, and mistakenly sent out a partially-updated copy. A fully-updated
copy is attached. I cleaned up the MEXIT and
On Mar 5, 2022, at 05:44:41, João Reginato wrote:
>
> Which is the best instruction to test if a virtual address is still valid to
> avoid an unexpected S0C4?
>
How is that information useful?
Is its usefulness diminished by "an unexpected S0C4"?
--
gil
The long-displacement facility has been part of the z/OS architecture level set
since z/OS 2.1 (including the "high performance" variant).
Mark B wrote:
If you need to test a facility bit in the range of 0-31 then use the list of
bits stored by the STORE FACILITY LIST instruction, which should
Just curious would the following macros work better as a replacement for TPROT
in the requested case?
IARBRVER, IARBRVEA, and IARBRVKA
Regards,
Jeremy Schwartz
From: IBM Mainframe Assembler List on behalf
of Philippe Leite
Sent: Saturday, March 5, 2022 9:28
Hi Dan. I believe you have run into a couple of glitches in the
z390 assembler.
There is another issue with your WIF macro. The line:
LAY ,-1(,)
references variable symbol "" which is not defined.
The HLASM Language Reference states:
: Use the MEND statement to indicate the end of a
On Sat, 5 Mar 2022 09:44:41 -0300 João Reginato wrote:
:>Which is the best instruction to test if a virtual address is still valid to
:>avoid an unexpected S0C4?
There have been multiple answers regarding a technique. I would question the
business case for this.
The obvious case is a higher
Several years ago at SHARE, I did a presentation on various requests for new
architecture. Such an instruction to determine accessibility was at the top of
the list. So, I dragged out an architecture instruction template and designed
one on the spot: Given a base register, index register, and
And I would say that ESTAE is "heavy" and is not the best choice if you expect
the S0C4 with some frequency, but ESPIE is "light" and intended for this sort
of thing.
I remember there was some sort of VSE -- DOS/360 when I was using it --
equivalent. STXIT?
Charles
-Original
On 3/5/2022 7:28 AM, Philippe Leite wrote:
You can use TPROT for this purpose but it's a privileged instruction.
Not only is it privileged, but it does not do what the OP has asked for.
He is not concerned only about storage that happens to be paged in, he
wants the answer for storage that
Also, the question is somewhat unanswerable without knowing the environment.
z/OS? VSE? CMS?
Non-privileged program?
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Charles Mills
Sent: Saturday, March 5, 2022 7:40 AM
I think VSMLOC may do the job for you.
But all it can tell you is that the storage is allocated at the time of the
VSMLOC, not what it might be a microsecond later when you access it.
THE BEST thing is to set up an ESPIE and recover from any S0C4. ESPIE is
lightweight. This is exactly what it is
You can use TPROT for this purpose but it's a privileged instruction.
Regards,
Philippe Leite
LAB Services - IBM
Em sáb., 5 de mar. de 2022 09:45, João Reginato
escreveu:
> Hi
>
> Which is the best instruction to test if a virtual address is still valid
> to
> avoid an unexpected S0C4?
>
>
>
Hi
Which is the best instruction to test if a virtual address is still valid to
avoid an unexpected S0C4?
TIA
João
>> IHAFACL
uops - I spoke too soon
Am 04.03.22 um 19:44 schrieb Philippe Leite:
Macro IHAFACL
Regards,
Philippe Leite
LAB Services - IBM
and for the VSE people around
z/VSE stores facility indications beginning at V=R location 200 (C8 hex), so
you don't have to issue these instructions yourself.)
and to IBM people supporting this:
wouldn't it be nice to have a copy book such that you can simply code:
TM
30 matches
Mail list logo
