Informing the IBM Community

DSPIFSLCK and the profile that would not delete


DSPIFSLCK and the profile that would not delete

Mixing a little of promoting useful utilities with my frustration when I can’t get something to work.

To set the scene, I’ve been trying to remove an old developer profile from one of our production machines. For whatever reason every time I try to delete it I get a very unhelpful error message CPF9071.

Cause . . . . . : User identifier *N *N cannot be deleted from the system
distribution directory or changed to a remote user because a system resource
required to complete this request is in use.
Recovery . . . : Have the user sign off the system, and then try the
request again later.

Now as you might already have guessed my user isn’t signed on, I’ve also done a scan of active jobs and can’t find any system processes he was attached to (perhaps a stray SQL/FTP job doing the rounds?) I’ve also done a DSPLOG to confirm there’s no batch jobs being submitted under the profile either.

WRKOBJOWN comes up with a blank and not even an “owns objects not in a library”, I tried restarting MSF with *CLEAR on the off chance there was a message stuck but no. Also tried a suggested IBM solution to no avail.

At my wits end I wondered if perhaps there could be an IFS object checked out by the user, that would explain it not appearing on my previous checks. Unfortunately there are over 500,000 objects on this particular IFS (and that’s excluding certain IBM folders) so needle in a haystack comes to mind.

Enter some frantic googling later and a lot of references to a tool called DSPIFSLCK which sounded just the trick. Unfortunately if you go looking for this you will find a lot of dead links, it seems to have been originally posted to a site that’s no longer active and a lot of people referencing back to it.

Not one to be easily dissuaded from my goal I eventually found a working version of the source in an archived discussion on the Scott Klement site. This also reports on whether the object is checked out and by who which is perfect for my needs.

It’s a nice little tool in front of an API to report on IFS object locks (as you might’ve guessed from the name!) As a side note this’ll be really useful next time the customer complains that they can’t import a spreadsheet from the IFS because someone has it open in excel, finger shall be duly pointed at the culprit.

The main disadvantage for my use is again I don’t fancy calling it 500,000 times let alone dealing with the spool files that would generate. Swapping out the printfile for an output file is a good start as I can just build a single list rather than trawling through spool files.

Luckily the customer makes use of the IFSTOOLS library that you all may be familiar with from the IBM API examples meaning I already have a list of every object from the last run that’ll help with organising my program calls. So now a quick batch job to loop the output and run the command for each one, then writing the results to an output file. With fingers crossed wander off for an hour or so and see what happens….

I wish I could tell you the above worked, but as interesting as it’s been to find the utility and adapt it I’m afraid my stubborn account will not go. Maybe someone in the comments has a trick up their sleeve?

The fact that it’s the directory entry causing me headaches makes me suspect I’m dealing with a DLO issue but the customer in question has some aversion to IPLs and so I doubt I’ll get to run a RCLDLO command any time soon let alone a RCLSTG. Join me next month when we discuss the mysterious power problems my customer had that just happened to give me an opening 🙂

For now going back to the IBM page I’ve moved the directory entry onto another profile so I can delete the developer, problem duly kicked into the long grass.


How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.