Re: DLTUSRPRF fails with CPF22BF-User profile not deleted.

[Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx]

the thing that gets my attention is this:
> Ownership of object QFPACFG in QTEMP type *USRSPC changed.

what QTEMP? rob's?  then how does MARKP own the object?

Thanks,
Tommy Holden




CRPence <crp@xxxxxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/19/2007 03:26 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
midrange-l@xxxxxxxxxxxx
cc

Subject
Re: DLTUSRPRF fails with CPF22BF-User profile not deleted.






   DLTUSRPRF msgCPDA0B2 RC1 ;; For some [apparent] preventives for that 
condition, see: MA33733 &  SE25293
   Since RC1 [reason code/condition 1"] indicates a lock is held, then a 
PwrDwn/IPL sequence is a valid suggestion for probable resolution to 
avoiding the lock conflict impacting the delete request.  Although 
either party could have suggested pursuing doc collections in an attempt 
to determine the origin of the problem versus simply getting past the 
problem; in this case, to determine the object, the lock, the holder of 
the lock, and possible origin for the lock being left when presumably it 
should have been dropped.
   A DMPOBJ MARKP *USRPRF as initial doc collection would have generated 
information that describes what the user owned, for which the delete of 
that object was being prevented.  Now that QUSER is the owner, there 
will be many more objects to pore over from a dump, so yes, the idea of 
having created a temp/special user to transfer ownership would have been 
a better choice... Oh well.
   I do not know if the RCLOBJOWN would resolve it, but after an IPL 
into restricted, it may be worth trying that on QUSER and then checking 
the reclaim directory -- or the object may just get deleted, as in the 
second APAR noted it was 'pending destroy' anyhow.  That APAR also 
indicated that "IPL and RCLSTG made no difference."  However I wonder if 
they were attempted in that order.  Since the problem in that APAR was a 
lock held in another thread, presumably if RCLSTG [perhaps SELECT(*DIR)] 
could not resolve, it was due to not having IPLed first, to ensure the 
lock was gone first.?  Given any of that applies.... The confusing part 
is that the APAR describes the problem of a lock being left on the user 
profile, not the object which was not linked.

Regards, Chuck
-- All comments provided "as is" with no warranties of any kind 
whatsoever and may not represent positions, strategies, nor views of my 
employer

rob@xxxxxxxxx wrote:
> What would *CHGOWN do that *DLT couldn't?
>
> Gosh darned if that didn't do it though!!!
>
> DLTUSRPRF USRPRF(MARKP) OWNOBJOPT(*CHGOWN QUSER) 
> 0 user permissions changed. 
> 0 changes made to distribution lists. 
> User MARKP, User ID *N *N removed. 
> Ownership of object QFPACFG in QTEMP type *USRSPC changed. 
> Object MARKP in QSYS type *USRPRF deleted. 
> Job 496501/ROB/QHXHDLTU submitted to job queue QUSRNOMAX in library 
QSYS.
> Dang.  If I had it to do over again, I'd have created a special user 
> profile and transferred ownership to that just to find what object it 
> would have been.
>
> Rob Berendt