I can't support DIRECTXA as the sole examination. Paging volumes can be
added at any time. DIRECTXA only gets a change to look when it is run.
If this even needs to be addressed (hence, this thoughtful thread), IMHO
comparing the min and max virtual machine memory specification would be
better done when the virtual machine is being built during
logon/autolog/xautolog.
OTOH, it would not hurt to have DIRECTXA provide that early warning so
that when one finally does attempt to create the virtual machine, any
typos might already have been displayed and corrected when DIRECTXA
provided an early warning. It's just plain embarrassing for an existing
virtual machine to cause a problem because the sysprog made a wild (or
uninformed) keystroke while editing the directory source ... another
source of sysprog "collateral damage".
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
RPN01 <nix.rob...@mayo.edu>
Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
09/16/2009 08:13 AM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
To
IBMVM@LISTSERV.UARK.EDU
cc
Subject
Re: VM lockup due to storage typo
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
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if this
message has been addressed to you in error, please immediately alert the sender
by reply e-mail and then delete this message, including any attachments. Any
dissemination, distribution or other use of the contents of this message by
anyone other than the intended recipient is strictly prohibited. All messages
sent to and from this e-mail address may be monitored as permitted by
applicable law and regulations to ensure compliance with our internal policies
and to protect our business. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
