So are you saying that what Lee and I both did to shoot our systems should APAR'able? Or should it be a requirement? Or is it going to be a "your gun, your foot" answer?
Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." -----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Tuesday, September 15, 2009 1:45 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] VM lockup due to storage typo 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
