I don't think, in this case, it is the user causing the problem at all. The
user didn't define their storage allocation, and in practice can't do that
at all. So the user didn't set up the situation which caused the integrity
issue, the system administrator did.
The system administrator is in control of the CP Directory, and as such,
decisions are left to him. The system doesn't question what he does, within
the definition of the syntax, semantics and limitations of the directory
entries and commands. If you want to define a large virtual machine, should
the system question your authority?
The system could check the memory and page space against each directory
entry as the binary directory is built, but this would add time to the
directory build, and does not account for the situation of planning to add
more page space before logging in the new directory entry. Maybe a warning
of "User xxxx exceeds paging space" could have averted this situation, but
again, each user would have to be checked against the running system. It
shouldn't keep you from creating the entry, just let you know that there
might be an issue if you actually use it.
To my mind, if this requires addressing, it should be in the DIRECTXA
command, so as to help the system administrator in avoiding aiming the gun
at his toes.
--
Robert P. Nix Mayo Foundation .~.
RO-OE-5-55 200 First Street SW /V\
507-284-0844 Rochester, MN 55905 /( )\
----- ^^-^^
"In theory, theory and practice are the same, but
in practice, theory and practice are different."
On 9/15/09 3:44 PM, "Alan Altmark" <alan_altm...@us.ibm.com> wrote:
> On Tuesday, 09/15/2009 at 03:27 EDT, Steve Marak <sama...@gizmoworks.com>
> wrote:
>> I agree with that ("the guest cannot be allowed to harm CP") but has
> that
>> actually been formally - or even informally - accepted by the Powers
> That
>> Be?
>
> Yes, it is in the Statement of System Integrity in the General Information
> Manual.
>
>> I ask because I still remember, as though it were yesterday, opening a
>> security/integrity APAR against VM back in the mid-1980's because any
>> class G user could knock CP down by defining a shared and a nonshared
>> device on the same virtual control unit, and being told that that was
> NOT
>> a security or integrity issue, and that no fix would be forthcoming.
>
> Under "today's" rules, that would be an Integrity problem.
>
> o If a class G (only) user can repeatedly or with malice of forethought
> hang or abend CP, it WILL be classified as an integrity problem (denial of
> service).
>
> o If a class G user happens to do something that triggers an abend or hang
> due to a "system malfunction", it will NOT be classified as an integrity
> problem.
>
> o If the system abends or hangs because it is overloaded (memory, CPU), it
> will NOT be classified as an integrity problem.
>
> o Just because it isn't an integrity problem doesn't mean it isn't a
> defect.
>
> Alan Altmark
> z/VM Development
> IBM Endicott
