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
Job accessed by another user
Moderators: chulett, rschirm, roy
Re: Job accessed by another user
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
Ogmios
In theory there's no difference between theory and practice. In practice there is.
Ketfos,
Executeon 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
Execute
Code: Select all
Unlock All
dsrules
______________________________________
"Everytime I close the door on reality, it comes in through the windows." - Jennifer Yane
"Everytime I close the door on reality, it comes in through the windows." - Jennifer Yane
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
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
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
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.
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.