Richard,
I saw Bob Bolch's not about the undocumented command. We've never
needed to use it, because VM:Secure has a list of userids and ACI groups
in VMXRPI CONFIG that have special powers when VM:Secure is down. That,
and the fact that passwords are stored in the directory, have given us
all the capability that we've needed when VM:Secure is down.
Dennis O'Brien
I miss the old Star [Jones], who said "talk to the hand", and the hand
was covered with powdered sugar. -- Bill Maher
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Schuh, Richard
Sent: Thursday, March 22, 2007 09:19
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] Building NonRACF CP Module
I heartily concur. It would be nice if VM:Secure had the same
capability.
Regards,
Richard Schuh
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Bill Munson
Sent: Thursday, March 22, 2007 7:41 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Building NonRACF CP Module
COOL - what a great feature!
munson
Alan Altmark wrote:
> On Thursday, 03/22/2007 at 08:54 EST, Sebastian Welton
<[EMAIL PROTECTED]>
> wrote:
>> I've had to do this where RACF was shared with MVS systems. If the
MVS
>> systems went down then VM was pretty much stuffed so we then just
needed
> to
>> IPL with the alternate CPLOAD module. Naturally no RACF was available
> but
>> the way VM is built its pretty much secure for the average user. In
fact
>> googling showed a posting from me about this:
>>
>>
http://listserv.uark.edu/scripts/wa.exe?A2=ind9711&L=ibmvm&T=0&P=34282
>
> If anyone cares, you can CP SEND RACFVM SETRACF INACTIVE. This will
cause
> the CP-resident RACF code to begin to defer all requests back to CP,
as
> though RACF is not present, including LOGON. You don't have to
deactivate
> any classes or change any permissions. No auditing is performed.
>
> RACF will, however, prompt the OPERATOR for confirmation. A SETRACF
> ACTIVE will start the wheels turning again and the OPERATOR will be
> informed (but not prompted).
>
> Alan Altmark
> z/VM Development
> IBM Endicott
>
