Re: DLTUSRPRF Fails

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