I'm not sure about this, but if you don't care who gets authorization for VSWITCH, then just automate the process for everyone.
For example, when ever you update the directory and DIRECTXA it. Have a little REXX program also kick off to scan all "USER " cards, take the second word on that statement and do a GRANT for that user. If you use DIRMAINT, do a "DIRM GET USER DIRECTORY" after updating and execute the same REXX routine. Also, execute the routine as part of AUTOLOG1 to reissue the grants at IPL time. My point is that it is an easy enough workaround. And would be much quicker than getting IBM to channel resources into a request that is needed by few (or 1) licenses. In my case, I do grants for vswitch for 20 machines at a time. Right now, I'm done for LINUX6X and LINUX7X machines. (I'm only up to LINUX69 which is a test DB2 Connect Server Edition machine). But then, I also do the Linux installs, and I'm prompted for vswitch authorization by my documentation. Just like the CREATE DIRECTORY in SFS, the GRANT AUTH in SFS for the install software, updating the user direct, etc. All just a part of the initial machine configuration. I agree that one less step is one less step to forget/mess up....but that's what we get paid for. <G> Tom Duerbusch THD Consulting >>> RPN01 <nix.rob...@mayo.edu> 4/21/2009 12:58 PM >>> The problem is that not everyone wants to purchase an external security manager simply to get this feature. We have no need for an ESM, as, if one of our four users get out of line, we can just walk over to their cube and whack them with a board. I'm not buying an ESM to un-secure a single entity in an already closed box. That makes no sense at all. No humans use the box directly, and we grant the vSwitch to just short of every virtual machine that uses the box. To have to go through the grant process, no matter if it is in the CP directory, in System Config, or in Autolog1, for every new machine that gets created, and to open the door for human error by forgetting to grant this resource, which needs to be available for everyone on the system, seems at best to be an oversight on IBM's part. ESMs are not the solution to this problem. Sorry. -- 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 4/17/09 12:20 AM, "Alan Altmark" <alan_altm...@us.ibm.com> wrote: > On Thursday, 04/16/2009 at 04:15 EDT, Marcy Cortes > <marcy.d.cor...@wellsfargo.com> wrote: > >> Apparently its *someone*'s requirement, but I agree, and optional open >> Vswitch would be handy indeed. > > I should probably get the requirement answered "Available". As Rob > mentioned, your ESM is capable of doing this. With RACF, RALTER VMLAN > SYSTEM.VSWITCH1 UACC(READ). > > I have no plan (or much willingness) to spend money to duplicate in CP > what can be done with an ESM. > > Alan Altmark > z/VM Development > IBM Endicott > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
