DSXchange

Hi,
While trying to open a job, It gives a message

"Job accessed by another user".

The job was left open and then connection to datastage was lost.

When I look in Director

I see PID# for this job.
When I try to release resoure/logout, the PID# is still there in Director.

Any clues.

Ketfos

Search this site for "unlock"... what's also important is to release the locks (the bottom half of the screen instead of the top half you're using now).

Ogmios

Ketfos,
Execute on the Admin client window, if you have the Admin rights. Else ask your Admin to do it. Alternatively you can unlock it by Inode number after getting the Inode numbers for the jobs locked.

dsrules

You can release from Director only if you have Admin rights....the other option is once u get the PID you can Kill that Process from Unix.

Regards

Hi,
The PID# asscoiated in the Director screen fro this job does not exist on the UNIX side.


Ketfos

This can be a pain, but its worth understanding what is going on

DataStage maintains a list of locks on all universe files that are used in the system , including runtime files such as RT_CONFIGxx and designtime files such as DS_JOBS (this lock I guess is record level)

When a user opens a job in designer a lock is taken and if the client crashes , datastage still holds the lock on the releveant record/file.

The admin fluff will only tell you the PID of the thread that WAS holding the lock - if the rug is pulled out from under it (or the thread is killed) it has no way of getting a signal to say its had its lock released. and hence still reports the last PID

Anyway - solutions

Always try to use the DS.TOOLS approach first
Be wary of killing PIDs as this can leave unassociated locks

if all else fails you need to identify and release the lock as follows

cd $DSHOME
bin/list_readu EVERY

this will brng out a list of the lines

Active Record Locks:
Device.... Inode.... Netnode Userno Lmode Pid Login Id Item-ID.............

2621441 8928 0 65455 16 RU 12422 dsadm 4 2621442 258124 0 65455 19 RU 12422 dsadm DummyJob.

from this we can see that dsadm is locking DummyJob on inode 65455

to unlock drop to UV shell
bin/uvsh
and type

UNLOCK INODE 65455 ALL

or

UNLOCK USER 12322 ALL

which should release the locked job record

I WOULD SUGGEST YOU CHECK SOME OTHER POSTINGS AS TO THIS ISSUE AS THIS IS WHAT I DO AND I AM MORE OF A COWBOY THAN THE LATE GREAT JOHN WAYNE

A clean method can be to locate any dsapi using 'ps -ef | grep dsapi'.

Ask other users to log out before doing any unlock activity.

To identify whether DataStage is being locked or hash a timewait in unix level, you can check 'netstat -na | grep 31538'.

If it says TIME_WAIT, you can wait for about 30 mins and retry.