Page 1 of 1

Use of the following commands

Posted: Wed Apr 27, 2005 1:28 am
by vinodlakshmanan
Hi,
I was browsing through the $DSHOME/bin directory and found a few DataStage executables. I am wary to try them out before knowing actually what they do. Can someone please explain the significance of the following commands:
dspipe, dsapi_server, dsapi_slave, dsdlockd, dslictool, dsrpcd, dstskup

Posted: Wed Apr 27, 2005 1:51 am
by ArndW
You are correct not to try them out; they are, for the most part, not functional when called at the user level and you certainly don't need to utilize any of them. If you really wish to know how the underlying DS (or UniVerse) system functions, you can start by downloading and reading the documentation found at IBM UniVerse Documentation, the UniVerse System Description guide would make a good starting point.

Posted: Wed Apr 27, 2005 5:27 am
by ray.wurlod
You won't, of course, find any information about the ds... executables in UniVerse documentation, though there are uv... equivalents for some of them.

dsrpcd is the DataStage RPC daemon, that listens for connection requests from DataStage clients and instantiates the dscs (DataStage common server) for each.

dsapi_server is the executable for the dscs (this mapping can be seen in the dsprcservices file). Each connected DataStage client has one instance of dsapi_server as its "agent process", that maintains the connection from the server end (for example monitoring the inactivity timeout).

When some work needs to be done on behalf of the connected client, dsapi_server forks a dsapi_slave process to do that work.

dsdlockd is the deadlock daemon, which can be configured to run or not to run, in dsdlockd.config file. It's primary task is to check for deadlocks (which are rare) in the DataStage repository database, but it also has a secondary task of cleaning up after defunct processes.

dspipe is a fairly self-explanatory name; it is an executable that manages named pipes for DataStage (for example, creating and deleting them in a manner appropriate for the operating system).

All the above is from memory, since I don't currently have access to a DataStage machine. I can't remember, however, what dstskup does. :oops:

Posted: Wed Apr 27, 2005 7:17 am
by ArndW
After such an exhaustive post by Ray, the least I could do is post what the dstskup does - but I can't read it on my UNIX box (only root can), it doesn't exist on Windoze and I can't find reference to it in the system... Now my curiousity is piqued as well.

Posted: Wed Apr 27, 2005 7:28 am
by chulett
ArndW wrote:After such an exhaustive post by Ray
Affectionately known here as a 'Full Wurlod'. :wink:

Posted: Wed Apr 27, 2005 7:36 am
by ArndW
Craig,

I though international treaties had forbidden unsanctioned use of the full-Wurlod; and that even the Half-Wurlod could be lethal when improperly used and interpreted :) I wish I had root access to see what's inside that insidious dstskup program - it's rather small.. perhaps a script...

Posted: Thu Apr 28, 2005 11:30 pm
by vinodlakshmanan
Another query actually... why do we have to restart the DataStage server after re-indexing or cleaning up projects? Will there be any serious impact if we do not restart the server?

Posted: Fri Apr 29, 2005 7:35 am
by chulett
I don't recall having to do that. :?

Posted: Fri Apr 29, 2005 7:35 am
by ray.wurlod
There is no need to restart DataStage after cleaning up a project or reindexing. Where did you obtain this assertion?

It is, however, necessary to restart DataStage if you make changes to the configuration parameters in the uvconfig file. It's also necessary to restart DataStage so that it picks up any changes you might make in the dsenv script (UNIX-based servers only).

Posted: Wed May 04, 2005 11:56 pm
by vinodlakshmanan
Well, I find ppl working with me doing it, so I asked. Thanks for the info.