I have to agree... It's one thing to restrict a COUPLE command that's initiated by the user. It's another to restrict a directory statement that only the sysprog can put in the directory.

a) It makes the sysprog (frequently an MVSer who does VM on the side) now have to update two places (3 if they remember to update CF2) to connect to a Vswitch.

b) It's really tantamount to requiring correct passwords on the LINK statement in the directory. Or requiring a LINKOK statement for every LINK...

Almost every new VM/Linux site asks me "Why?"

My two cents: Allow the directory NICDEFs without a GRANT. Keep the grant requirement for COUPLEs...

Lee

Phil Smith III wrote:
Alan Altmark <[EMAIL PROTECTED]> wrote:
On Tuesday, 10/24/2006 at 01:33 MST, "Schuh, Richard" <[EMAIL PROTECTED]> wrote:
Is there some reason that having a "NICDEF 500 TYPE QDIO LAN SYSTEM VMTEST" in the directory does not authorize the user for that switch?

4. Consider the LINK command in the directory. Without an ESM, it confers permission. With an ESM, it does not. Do we continue that same weird model? Or do we just bite the bullet and separate authorization from configuration?

Yes, I'd argue that you do, for reasons of usability.  The current approach 
makes VM harder for non-VMers to adopt, and is thus bad for the platform.

Besides, systems without ESMs are different beasts than systems with ESMs, so they operate 
differently.  The added complexity of having to do a *second* step rather than putting things 
in the directory where &deity intended reminds me of the arcane kinds of things you have 
to do in some other OSes just to get stuff to work, and doesn't "feel" VMish to 
this gray-haired pismire.

It's hard enough to get customers to update the directory properly without 
having to *also* have them add an arcane command somewhere else (like SYSTEM 
CONFIG!) that they're (correctly) afraid to mess with!

...phsiii


--

Lee Stewart, Senior SE
Sirius Enterprise Systems Group
Phone: (303) 798-2954
Fax: (720) 228-2321
[EMAIL PROTECTED]
www.siriuscom.com

Reply via email to