Chuck, I was assuming the OP was talking about a non-system *USRPRF,
because I would surmise that changing the ownership of system-owned
objects would be an extremely dangerous thing to undertake.

Trevor Briggs
Lincare, Inc.
(727) 431-1246

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, March 26, 2014 1:14 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: QDFTOWN changing objects to a new owner

On 26-Mar-2014 09:53 -0700, Briggs, Trevor (TBriggs2) wrote:
You could always do a DLTUSRPRF with *CHGOWN and then re-create the
user profile when you're done.

While certainly an option for a non-system *USRPRF, is that an option

for a system user profile? I seem to recall [and I verified on v5r3
that still,] the DLTUSRPRF command had the "system" user profile names
hard-coded against which to test the specified USRPRF() specification
for which the effect would be CPD2205 "User profile cannot be deleted."
F/QCAIFLD with additional details suggesting "This user profile is
required by the system and cannot be deleted."

If that checking within the command was since removed, then...

As a /system/ user profile, would the request to DLTUSRPRF QDFTOWN
OWNOBJOPT(*CHGOWN NewOwnName) fail immediately [per the msg CPD2205 as
was the case in the past, but as a result of the CPP vs the command
definition objects parameter checking], or would the request enable the
effect of the CHGOBJOWN\CHGOWN processing, and then fail only to effect
the actual user profile deletion?

Related ...

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page