Re: DLTUSRPRF Fails

[CRPence <CRPbottle@xxxxxxxxx>]

On 10 Jun 2013 16:47, Sam_L wrote:
> I had a profile I could not delete today, no matter what I tried.
> No object, no locks.
>
> There was thread on this back in June, 2007 and the resolution was
> to use:
>    DLTUSRPRF USRPRF(xxx) OWNOBJOPT(*CHGOWN yyy)
>
> Yep, it works. But the new owner (yyy) did not inherit any objects.
> I guess I will see what happens if we ever need to delete yyy.

  Hopefully the choice of a system UsrPrf like QUSER [or any user 
already assigned many objects] was not the "yyy" in the above 
"resolution", as was the case in that thread:
http://archive.midrange.com/midrange-l/200706/threads.html#00886
Subject: DLTUSRPRF fails with CPF22BF-User profile not deleted.
http://archive.midrange.com/midrange-l/200706/msg00916.html

  If the "new owner" was a new user profile with effectively no owned 
or authorized objects, then learning what was the problematic object 
should be easy; i.e. if the object ownership was changed to that new 
user, then what that object was that could not be deleted when using 
OWNOBJOPT(*DLT) should since be tracked to the new user.  The DMPOBJ of 
the "yyy" user should help to identify what the object was that gave 
rise to the error CPF22BF; i.e. assuming that same error, as the old 
thread, and there were no "previously listed messages in the job log" 
that already had answered that question.  I see in that thread I had a 
similar response, and a mention also of using RCLOBJOWN feature on the 
new owner user profile, in case the condition identifies an object can 
be resolved by that action; i.e. the user owns an object that was not in 
a context [aka library].
http://archive.midrange.com/midrange-l/200706/msg00925.html