DSXchange

Clean up resouces option of DataStage Director :

The clean up resources option does not show process_id of any job at the Server reagrdless of whether it is locked or not.

DS.TOOLS utility:
By using this utility also we are not able to logout any job which has been locked. This utility is also unable to get process_id of any job at the Server.

Can someone please tell if there is any setting to be done at server side for the above two options to work

Did you select the "Show All" option at the bottom of the screen?

Locks for a process only show when a process is selected.

There's no setting to be done on the server, though you probably do need to be connected using a user ID that has administrative privileges. Depending on how you installed DataStage, this could be dsadm or root.

The "error" you describe can occur when you have selected a job that has no active stages (for example a Job Sequence, or a job that simply connects two passive stages). Under some circumstances, it can also occur if the job is simply not running (therefore there are no processes).

Yes i had selected the Show All button but still it did not return any process_id.

User dsadm is having administrative privileges for DataStage and not Unix Server.

I am getting this error for all kind of jobs.

Hi

We are also faced same kind of problem. What I did directly used UNIX and then killed the process using process id. From director you can able to see the job process id. Really if you got any idea please share with us.

If you have killed the process from UNIX, you won't get the process id. There will be only one entry named unavilable. If you want to release these kind of locks, you have to use unlock command. The syntax is

UNLOCK [NODE node [USER user.number
[FILE pathname [DEVICE device.number [INODE i.node.number
[GROUP group.address [RECORD record.ID
{FILELOCK GROUPLOCK READULOCK READLLOCK
ALL

Hope it helps.

Arun

mandyli wrote:Hi

We are also faced same kind of problem. What I did directly used UNIX and then killed the process using process id. From director you can able to see the job process id. Really if you got any idea please share with us.

My idea is:
Don't kill processes at UNIX level.

There is a child, parent, grandparent relationship between the processes that are involved in running a job, and between the processes involved in supporting a connected client.

If you don't shut these down gracefully, they will leave orphaned locks hanging around (which the deadlock daemon could clean up eventually). This is particularly true with SIGKILL (-9), which is a signal that a process can not ignore and which gives no grace time for shut down.

If you don't shut them down in the correct sequence you will create orphans; you may even create zombies. Talk to your UNIX administrator about the desirability of creating zombies, but wear a flak jacket when doing so!

Learn patience. If you want something to shut down, ask nicely (for example a stop request or a signal that gives grace time). Understand that sometimes, because a process has been put to sleep, it does not get any CPU cycles with which to process your signal. Learn which process does what; learn how to send harmless signals (for example kill 0 pid merely asks "are you there?") to determine whether a process is capable of processing signals. And be prepared to wait for some minutes; the instant death caused by kill -9 may be gratifying, but causes you a lot more work than does a clean shutdown.

This problem has been resolved. this problem was due to incorrect permissions settings.

Following correct settings were done to solve the problem:
-rwsr-x--x 1 root dstage 1519616 Nov 13 2003 dsdlockd
-rwsr-x--x 1 root dstage 1499136 Nov 13 2003 dslictool
-rwsr-x--x 1 root dstage 3678208 Nov 13 2003 dstskup
-rwsr-x--x 1 root dstage 1519616 Nov 13 2003 list_readu
-rwsr-x--x 1 root dstage 1486848 Nov 13 2003 upduvtrans
-rwsr-x--x 1 root dstage 53248 Nov 13 2003 uv
-rwsr-x--x 2 root dstage 3796992 Nov 13 2003 uvbackup
-rwsr-x--x 1 root dstage 49152 Nov 13 2003 uvdls
-rwsr-x--x 2 root dstage 3796992 Nov 13 2003 uvrestore
-rwsr-x--x 1 root dstage 16384 Nov 13 2003 uvsetacc

Settings for all the above was found to be incorrect. dsadm was the owner instead of root and also permissions were incorrect.
]

pravesh_kushwaha wrote:This problem has been resolved. this problem was due to incorrect permissions settings.

Following correct settings were done to solve the problem:
-rwsr-x--x 1 root dstage 1519616 Nov 13 2003 dsdlockd
-rwsr-x--x 1 root dstage 1499136 Nov 13 2003 dslictool
-rwsr-x--x 1 root dstage 3678208 Nov 13 2003 dstskup
-rwsr-x--x 1 root dstage 1519616 Nov 13 2003 list_readu
-rwsr-x--x 1 root dstage 1486848 Nov 13 2003 upduvtrans
-rwsr-x--x 1 root dstage 53248 Nov 13 2003 uv
-rwsr-x--x 2 root dstage 3796992 Nov 13 2003 uvbackup
-rwsr-x--x 1 root dstage 49152 Nov 13 2003 uvdls
-rwsr-x--x 2 root dstage 3796992 Nov 13 2003 uvrestore
-rwsr-x--x 1 root dstage 16384 Nov 13 2003 uvsetacc

Settings for all the above was found to be incorrect. dsadm was the owner instead of root and also permissions were incorrect.
]

hi all,
i've also faced the same problem but am using 7.5.1 server edition. And i've changed as above and its working fine now. Could any one tell whether it is advisable or not?

And how the owner name and the permissions for aforementioned files have been changed? Is it due to any data stage set p problem?