We all know that they are not M$ and we are glad they aren't. Regards, Richard Schuh
> -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Huegel, Thomas > Sent: Tuesday, September 15, 2009 2:18 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: VM lockup due to storage typo > > I would think that IBM would be scurring to fix what is > obviously a problem. > After all they are not Microsoft... > > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Schuh, Richard > Sent: Tuesday, September 15, 2009 4:13 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: VM lockup due to storage typo > > Seems to me that he said it was either an integrity problem > or a defect. > I would think that either would me meat for the APAR grinder. > > Regards, > Richard Schuh > > > > > -----Original Message----- > > From: The IBM z/VM Operating System > > [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes > > Sent: Tuesday, September 15, 2009 1:50 PM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Re: VM lockup due to storage typo > > > > 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 > > >
