Aborting Job

[lbegley]

I am responsible for the DataStage server (not a developer).
If, for what ever reason, a developer decides to abort (cancel, stop) a job that is running. 'What is the most efficient way to abort a running job, close the Window? stop it via Director? or ?"
We seem to have uvsh.exe processes hanging around and we need to periocically release the locks on these jobs after a job has been aborted.


Thanks in advance.

[kduke]

They should always stop it in Director. It is the proper way. It may not stop it the fastest.

A job runs as a separate process in the background. The Director is the proper tool to start and stop these jobs.

Designer has a separate connection to the DataStage engine. If you have a job displayed then there should always be a lock unless it is a read only job. If the network connection gets broken then these locks are not released. Closing Designer should release these locks unless you get an End Now button.

[chulett]

'What is the most efficient way to abort a running job, close the Window? stop it via Director? or ?"

Kim has already addressed the Director issue and the proper way to stop a job. I just wanted to address the 'close the Window' comment. I'm assuming 'the window' refers to having a job open in Designer while it is running, and the answer is 'no'.

Closing it will release the locks on the design as Kim mentions, but has no bearing on the running state of the job. It will continue as its merry way, regardless whether or not someone has it open in the Designer.

Of course there are other, less 'proper' ways to get jobs stopped and sometimes you may need to fall back on them. Database issues may make a job 'unstoppable' through normal means and require a DBA to kill the process, which the job will definitely notice. You may also end up having to kill processes from your operating system. However, this is the exception to the rule and the Director should be your first recourse for stopping jobs.

[roy]

Hi,
IMHO,
having a job stoped as mentioned via director, being the safest way also does not garantee a safe end to running processes.
so in case you already have defunct processes, you need to check what is going on.
if you have an active DB connection you can use DBA personel to kill the session as mentioned.
if you don't have DB connection you could try cleanup resoures via director (if you checked the DS Administrator option for enable job administration in director) to log the process out (might still leave locks in the ds epository).
if that fails there is always to good old ds.tools for handling locks (and logging out processes) which should be available mostly to the person/s incharge of the DS administration (usually one that is part of the sysadmins onsite) ds.tools will let you (usually when logged in as dsadm or equivalent user) logout a process, clear locks held by a process and such things, in a simple but orderly mannor.

I often here of people using kill -9 to stop a process which by definition lucks giving the process a chance to free locks, resources and such; when and if it gets to a kill scenario I start with -15, -13, -11 and only if all fails got to -9; again I'm against kill to stop jobs in the first place!!! simply since no repository lock release is certain.

IHTH,

[throbinson]

For a real time job that uses the MQ Series Stage as input, Director WILL stop the job however it will ALWAYS leave a DSD.StageRun phantom orphan process running in the HP-UX 11.11 environment. We NEVER stop a real time MQ job via Director. We have other jobs that stop the jobs via the MsgType MQ stage functionality.