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
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----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?
midrange.com
