Hello All,
Is there any way to find out how many users are connected to the DataStage server and what all jobs are they editing?
Thanks,
Siddharth
Number of users connected to DataStage Server
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 20
- Joined: Thu Nov 27, 2003 3:45 am
- Location: New Delhi, India
Hi
Not sure of any direct method, however try exploring the options in the DS Director..Job..CleanUp Resource;
Select the Show all process radio button; then for each process in the upper pane, you will get a list of processes in the lower pane.
Info like Jobnames, windows machine names is also displayed
Do check it out..
Latesh
Not sure of any direct method, however try exploring the options in the DS Director..Job..CleanUp Resource;
Select the Show all process radio button; then for each process in the upper pane, you will get a list of processes in the lower pane.
Info like Jobnames, windows machine names is also displayed
Do check it out..
Latesh
-
- Premium Member
- Posts: 385
- Joined: Tue Oct 07, 2003 4:55 am
-
- Premium Member
- Posts: 224
- Joined: Tue Sep 24, 2002 7:32 am
- Location: Denver, CO USA
This is only true for DataStage Server on Windows. On UNIX, you need to go to the directory defined on "/.dshome", and run "bin/uvsh".ds_developer wrote:Telnet to the server and login to a project.
Do a search on this forum for further information on "uvsh", particularly those discussing unlocking jobs. This is a powerful and potentially dangerous tool -- if in doubt, ask an expert first.
-T.J.
Developer of DataStage Parallel Engine (Orchestrate).
-
- Participant
- Posts: 20
- Joined: Thu Nov 27, 2003 3:45 am
- Location: New Delhi, India
Hello All,
Thanks to all of you for putting in your valuable inputs. The situation is something like this.
I have the DataStage server on a Solaris box and DataStage clients are on the Windows Platform. So whenever I telnet into the server it automatically asks me to log into the Sun OS first. That means I cannot telnet the DataStage services directly.
1. Is there any way to telnet into the DataStage services directly?
2. My aim is not to unlock jobs. But to find out which user is editing what job? This is not something the Director can give, because the Director can give me only the runtime information and not otherwise.
Thanks,
Siddharth
Thanks to all of you for putting in your valuable inputs. The situation is something like this.
I have the DataStage server on a Solaris box and DataStage clients are on the Windows Platform. So whenever I telnet into the server it automatically asks me to log into the Sun OS first. That means I cannot telnet the DataStage services directly.
1. Is there any way to telnet into the DataStage services directly?
2. My aim is not to unlock jobs. But to find out which user is editing what job? This is not something the Director can give, because the Director can give me only the runtime information and not otherwise.
Thanks,
Siddharth
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
1. Yes. You can telnet to the machine on which the DataStage server is running. If it's Windows, you will already be in the DataStage environment because dstelnet is the listening service (unless you've changed the defaults). If it's UNIX change directory to where the DataStage Engine is installed (this location is recorded in the hidden file /.dshome however this strategy may change in a near future release), then invoke uvsh after executing the dsenv script to set environment variables.
But see below. You may not have to invoke uvsh. If you do invoke uvsh, the prompt changes to ">", and the command to quit this environment is any of "Q", "QUIT", "LO", "LOGOUT" or "OFF".
2. The LIST.READU command will identify which client is editing which job, though indirectly. Each connected client will have an entry the record id of which begins and ends with the "!" character and contains the project name and the string "ADMIN". This entry merely signals to the Administrator tools that clients are connected (and therefore that exclusive access is impossible). However it does identify the user number and pid of the connected client.
If a client is editing a job or routine (which is not necessarily the case), then another entry in the LIST.READU report will have the name of that job or routine as the recordid. By matching the user numbers of the two entries you can identify the pid of the client.
If necessary you can then use operating system utilities such as netstat to get the IP address of that client.
The LIST.READU command can be invoked from the operating system (as list_readu) without invoking uvsh. For example:
Yet another alternative is to use the DataStage Administrator client's Command window to execute the LIST.READU command.
Code: Select all
cd `cat /.dshome` # note use of back-quotes
. ./dsenv
bin/uvsh
2. The LIST.READU command will identify which client is editing which job, though indirectly. Each connected client will have an entry the record id of which begins and ends with the "!" character and contains the project name and the string "ADMIN". This entry merely signals to the Administrator tools that clients are connected (and therefore that exclusive access is impossible). However it does identify the user number and pid of the connected client.
If a client is editing a job or routine (which is not necessarily the case), then another entry in the LIST.READU report will have the name of that job or routine as the recordid. By matching the user numbers of the two entries you can identify the pid of the client.
If necessary you can then use operating system utilities such as netstat to get the IP address of that client.
The LIST.READU command can be invoked from the operating system (as list_readu) without invoking uvsh. For example:
Code: Select all
cd `cat /.dshome`
. ./dsenv
bin/list_readu
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.