Even better! Thanks Alan. Do the link after the release, and remember to tell racfvm to link it again (mr) before reaccessing it. When a switch does occur, RACF will want to rewrite the file. -- Mike Harding z/VM System Support
mhard...@us.ibm.com mike.b.hard...@kp.org mikehard...@mindless.com (925) 926-3179 (w) (925) 457-9183 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> wrote on 12/04/2009 11:06:42 AM: > From: Alan Altmark/Endicott/i...@ibmus > To: IBMVM@LISTSERV.UARK.EDU > Date: 12/04/2009 11:07 AM > Subject: Re: Automate z/VM RACF SMF process to z/OS > Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> > > On Friday, 12/04/2009 at 01:34 EST, Michael Harding/Oakland/i...@ibmus > wrote: > > What I'd do (gingerly) is to set myself temporarily as racfvm's secuser, > do a > > "send racfvm release a", then "send racfvm q disk" to see that the > release > > worked. Then link racfvm's 191 MW and access it, make your change and > > release/detach it, Finally, "send racfvm access 191 a" and "send racfvm > q disk" > > to verify, then reset racfvm's secuser. > > (cough) Unfortunately, gingerly tiptoeing through the cow-filled pasture > doesn't stop you from stepping in it. :-) > > send racfvm link * 191 191 rr > and then link to the disk MR, please. > > There is no gun-to-your-head-save-the-planet reason to disobey General > Order #2: "Never use link mode MW on a CMS minidisk". > > Alan Altmark > z/VM Development > IBM Endicott
