Right...
On Fri, Jan 31, 2020 at 12:51 PM -0600, "Seymour J Metz" <[email protected]> wrote:
Well, if you write your own OS in order to give all applications access to real
storage, then the OS is part of your code. I don't know about z/TPF or z/VSE,
but certainly neither z/OS nor z/VM gives an unprivileged user that sort of
access.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Assembler List on behalf of Keven
Sent: Thursday, January 30, 2020 6:07 PM
To: [email protected]
Subject: Re: Does S0C5 still exist ?
I believe it’s completely possible for Problem State code to raise a
Program Interrupt with code 5 in z/Architecture but not under z/OS.In AR ASC
mode an ALET can identify a Real-space designator that results in access to
real storage . z/OS (along with VM, VSE etc.) requires authorization to use
such ALETs but one could fashion an OS or stand-alone utility that allowed
non-authorized access to real storage.
On Thu, Jan 30, 2020 at 4:34 PM -0600, "Steve Smith" wrote:
I created a better one, based on LURA, and tests fine. You don't get an
exotic PSW, but this will abend with a S0C5, with no risk to the system:
IEFS0C5 START 0
IEFS0C5 RMODE ANY
IEFS0C5 AMODE 64
MODESET MODE=SUP
LLIHH 2,X'DEAD'
LURA 1,2
BR 14
END
... it will not get to the BR 14, so it's superfluous.
APF authorization is required. IF there's a way to incur a S0C5 in problem
state, I don't know it.
sas
On Thu, Jan 30, 2020 at 3:51 PM MELVYN MALTZ <
[email protected]> wrote:
> Hi Steve,
>
> You're the only person to actually meet my request...thankyou
> I would much appreciate the code used, I tried B and MVI to your address
> in
> A/RMODE 31 but I get S0C4
>
> Melvyn.
