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
midrange.com
