Command Line Job Unlock Option

sudhirmah · Post by **sudhirmah** » Wed Mar 23, 2005 7:28 am

One of the most wanted option is to provide "dsjob -unlock jobname" kind of option. ofcourse with some restriction that only owner or dsadm or root can unlock the job.

thanks
SAM

kduke · Post by **kduke** » Wed Mar 23, 2005 7:46 am

This is probably doable. I have VB program which I can run any TCL command with. It is part of DwNav. It runs standalone though. I post with my version of DataStageBackup.bat. It does a UNLOCK READULOCK in the UV account before it exports all the projects. This is a dangerous command if you do not understand the issues. Ask Ray. I could post the VB code maybe or someone could write a BASIC program to figure out how to unlock one job.

ray.wurlod · Post by **ray.wurlod** » Wed Mar 23, 2005 10:42 pm

Nothing to stop you modifying, or creating your own, dsjob command. The API is documented (Server Job Developer's Guide and Parallel Job Developer's Guide).

I think it would need a whole lot more checking to be safe than just who is executing it. Maybe only allow locks held by defunct processes to be released without query. After all, these locks exist for a reason!

The deadlock daemon can be used to release locks held by defunct processes. If you're the administrator, you can start it in manual mode.

T42 · Post by **T42** » Fri Mar 25, 2005 9:57 pm

Plus just killing your process is far easier. Just find the dead process and do a kill -14. Never a kill -9. EVER!

99.99% of the time, it solves the deadlock problem for me.

ray.wurlod · Post by **ray.wurlod** » Sat Mar 26, 2005 12:01 am

Make sure you always kill child processes before parent processes!

(I'm still uneasy about kill, even kill -14, and prefer UNLOCK.)

T42 · Post by **T42** » Sun Mar 27, 2005 11:59 am

Actually, in my experience with Tru64 and AIX (unsure about other OSes), kill -14 have been very successful in telling DataStage, "Hey, clean up your stuff then close down." Just killing the "dscs" process (the parent process for DataStage client session) will unlock the jobs for me.

In the rare case it fails (usually when someone does a kill -9 and not admit to it), using the UNLOCK script will work well to clean everything up.

I know how dangerous kill can be (especially kill -9), but I have found DataStage to be robust enough to handle this behavior these days for the two OS I am using. It also comes in handy when you are without dsadm access needed, and do not want to bother your administrator.

roy · Post by **roy** » Sun Mar 27, 2005 4:12 pm

Hi,
doesn't anybody use the cleaup resources via director and DS.TOOLS anymore?

sudhirmah · Post by **sudhirmah** » Sun Mar 27, 2005 10:35 pm

After looking at the process id using cleanup resources. and after killing the pid using kill -9 <pid>, it does not work, it still says job is being accessed by another user. Once in issue the command "list_readu | grep RU | grep -v :" the process is still there

ray.wurlod · Post by **ray.wurlod** » Mon Mar 28, 2005 12:32 am

Chances are that you haven't chosen the correct process initially. See my earlier post about child and parent processes. It's not as easy as using WMDs. You have to be very selective.

T42 · Post by **T42** » Wed Mar 30, 2005 10:27 pm

sudhirmah wrote:kill -9 <pid>

There's your problem RIGHT THERE!

Read my instructions very carefully.

DO NOT USE -9. DO NOT USE -9.

USE -14!

You killed DataStage using a very hard-core Operating System kill -- where everything's destroyed without mercy. This is a last resort action.

Kill -14 will tell DataStage, "Hey, please quit." DataStage have a specific internal routine that would listen to that kill request. Once it receive that kill request, it would go, "Okay, let me unlock the jobs that are locked, clean up the project VOC stuff, and a few other minor stuff, then I'll leave."

Within a few seconds, that should happens, and your locked jobs will be unlocked by magic.