And if we do not discuss the way things should be vs. the way they are, there will never be any progress. We will always be mired in the past and become, dare I say it, dinosaurs. Even T-Rex was only around for about 3 million years - a very short time in geological terms (the Cretaceous Period, the one in which T-Rex lived, lasted about 80 million years).
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark > Sent: Monday, March 09, 2009 8:24 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Using LBYONLY > > On Friday, 03/06/2009 at 03:31 EST, Bob Bolch > <b...@zenoroad.com> wrote: > > It?s perfectly fine to discuss the way things ?should be? > ?vs- the way > things > > ?are?, but when a design is more than 20 years old, as in this case, > then the > > way it works now is, by definition, the way it should be. > Making some > changes > > is just too painful. > > I think that we must continually assess the somewhat, uh, > "arcane" nature of VM commands. By default, I believe that > the ability for UserX to bring UserY onto the system should > not be restricted by the particular mechanism used, even > though you should be able to exert control over a particular > mechanism if desired. > > A good example is communications. Should I have to protect > MSG, WNG, MSGNOH, SMSG, COUPLE, NICDEF, IUCV, VMCF, ADRSPACE > PERMIT, shared R/W DCSS, and shared mdisk separately? I > don't like that. It's a never-ending quest to discover what > new interfaces have been added, and it is a terribly large > hammer to swing to enable mandatory access controls in your ESM. > > I much prefer to be able to protect an activity rather than a > command or interface, but we are stuck with history for the nonce. > > Alan Altmark > z/VM Development > IBM Endicott >
