On Thursday, 11/08/2007 at 10:27 EST, "Huegel, Thomas" <[EMAIL PROTECTED]> wrote: > Although I do think that sometimes they get a little case of 'If it ain't > broke, don't fix it' syndrome.
I suppose that creeps in from time to time, but living in the middle of it, I can tell you that it really comes down to business decisions. We have things that are broken and things that are not. When faced with both, we choose to fix the broken things. I wish we could do both. > The conversation here, I think, is to improve the SHUTDOWN process with more > standardization and control. > Although it may be perfectly OK to FORCE RSCS or TCPIP I'd prefer not to allow > anyone except a very select few, to be able to FORCE VSE or zOS. Then don't. Use the SVM-style interactions mentioned yesterday (?) to broker potentially devastating commands. Or maybe you want additional ESM controls on such commands? Keep those cards and letters (i.e. Official Requirements) coming... > I think there were some very good ideas presented here and they shouldn't be > just brushed away. Indeed. Shops have choices: - Buy products - Use shareware - Build it yourself - Contract someone else to build it for you - Submit requirements to a vendor of an existing product - Go without Each has a cost and a benefit and every shop has to decide on its own priorities and policies, not to mention how much it is willing to spend. > Will RACF ever become a nocharge option??? No. There are legal impediments since competing solutions are available. Note that even though z/OS includes RACF in the base price, there is a credit available if you "snap out" RACF. We would have to do the same thing for z/VM and, at the end of the day, you end up with 3 choices (!): - Use nothing - Use RACF - Use another product All we would change is the "default" - the choice still has to be made. So spending money on repackaging the system a la z/OS wouldn't change anything. Not really. Alan Altmark z/VM Development IBM Endicott
