Cannot get exclusive access to executible file for job

travissolt · Post by **travissolt** » Mon Mar 05, 2007 9:55 am

While working on a job it got locked up. We located the locked job and removed the lock. We were then able to open it in designer but are unable to compile (we get an executable file not available job may be being monitored error). We then tried to delete the job in the designer but we get the Cannot get exclusive access to the executable file for the job error. What other option do we have to delete this job??

kcbland · Post by **kcbland** » Mon Mar 05, 2007 10:07 am

You don't need to delete the job. You still have a lock, just not on the job itself. Your lock is on a supporting file, either a RT_STATUSnnnn, RT_CONFIGnnnn, or RT_LOGnnnn. You need to identify the internal job storage number, then look in the lock table for one of these three. Use the UNLOCK USER userno ALL syntax. As root or dsadm do the following:

Code: Select all

$ cd `cat /.dshome`
$ . ./dsenv
$ bin/dssh
> LOGTO yourproject
> CT DS_JOBS yourjobname
{look at line numbered 5 to get the job number}
> LOGTO UV
> LIST.READU
{find the lock listed for your job number, then look at the USERNO column}
> UNLOCK USER userno ALL
> LIST.READU
{ make sure lock is released}
> QUIT

chulett · Post by **chulett** » Mon Mar 05, 2007 10:08 am

Why delete it? It sounds like it may still be running - have you grep'd for any current 'phantom' processes on your server and looked for this job?

Code: Select all

ps -ef |grep phantom |grep -v grep

Your other option is the Cleanup Resources tool in the Director. You may need to know the internal job number as it won't always be listed by job name there. Show all and just scroll through it...

Code: Select all

SELECT JOBNO FROM DS_JOBS WHERE NAME = 'jobname';

Take the number shown and also look for any object with that number in it -

RT_LOGnnn
RT_CONFIGnnn

Etc. These would need to be logged out or released.

talsimad · Post by **talsimad** » Mon Mar 05, 2007 10:09 am

you need to log into datastage administrator using dsadm user, then you have to get the path to the universe folder:
execute the command "whence uv" to get the path -->$folder
then excute the commande MKDIR $folder
and finaly excute the command UNLOCK ALL
it will unlock all the ressources on your UNIVERSE DATABASE

best regards

kcbland · Post by **kcbland** » Mon Mar 05, 2007 10:11 am

talsimad wrote:and finaly excute the command UNLOCK ALL
it will unlock all the ressources on your UNIVERSE DATABASE

This would be a very bad idea. You affect all locks on all projects for all users.

chulett · Post by **chulett** » Mon Mar 05, 2007 10:11 am

Umm... no.

travissolt · Post by **travissolt** » Mon Mar 05, 2007 11:00 am

You don't need to delete the job. You still have a lock, just not on the job itself. Your lock is on a supporting file, either a RT_STATUSnnnn, RT_CONFIGnnnn, or RT_LOGnnnn. You need to identify the internal job storage number, then look in the lock table for one of these three. Use the UNLOCK USER userno ALL syntax. As root or dsadm do the following:

Code:
$ cd `cat /.dshome`
$ . ./dsenv
$ bin/dssh
> LOGTO yourproject
> CT DS_JOBS yourjobname
{look at line numbered 5 to get the job number}
> LOGTO UV
> LIST.READU
{find the lock listed for your job number, then look at the USERNO column}
> UNLOCK USER userno ALL
> LIST.READU
{ make sure lock is released}
> QUIT

_________________
Kenneth Bland

I tried this but it does not find the job. The job locked up before we had a chance to run anything (lastweek)so I know it is not running. I did find this in the list.readu... notice that the PID/loginid are empty.

Device Innode netnode usernum lmode pid loginid job
655374 153521 0 64606 30 RL RT_CONFIG64

kcbland · Post by **kcbland** » Mon Mar 05, 2007 11:42 am

Yes and I told you the EXACT syntax to use. You must use the case sensitive exact spelling of your job name to get the job number. Of course the RT_CONFIG does not have a PID, it's not a job process. That's why I told you to use the UNLOCK command with the USERNO value. It always will be able to release locks, whether it's a job process, routine, table definition, status record, or whatever, because there's always a USERNO associated with a lock.

travissolt · Post by **travissolt** » Mon Mar 05, 2007 12:12 pm

>unlock 64606 USERNO all
Insufficient privileges to perform lock maintenance.

I guess I need to will get with the admin and see if this works for him.
Thanks

kcbland · Post by **kcbland** » Mon Mar 05, 2007 12:27 pm

kcbland wrote:As root or dsadm do the following:

travissolt · Post by **travissolt** » Tue Mar 06, 2007 8:43 am

Our dsadm removed the locks from the RT_ folders using the process described above. Thanks for your help.