Help!!! We have 8 DS servers who are not showing this problem. On the problem server, I have multiple users who can log in. Any user can create schedule, edit job or run job. DSADMIN has access to schedule, edit and run as well.
Lately the scheduling has been flaky. DS claims it tried to run the job but the job didn't run or log anything. I tried running the job manually and it does nothing...no log entry. I can reset the job and get a log entry by clearing the status file, but the job will not run scheduled or manual.
DS Refuses to run job or run scheduled job.
Moderators: chulett, rschirm, roy
DS Refuses to run job or run scheduled job.
Last edited by Triton46 on Wed Nov 10, 2004 7:45 am, edited 1 time in total.
-
ray.wurlod
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
DataStage does not have its own passwords. It relies upon operating system authentication. The only exception is on Windows, where the user id and password for running scheduled jobs may be stored.
None of this affects what you're trying to do.
The first thing you have to do is to verify that the DataStage RPC service is running. If it is not, you will have to diagnose why, perhaps try to start it with debugging options.
Next thing to try is "variations on a theme". For example, if the users on the troublesome machines were created as domain users, they will need to log in as domainname\userid rather than just userid. Try all of domainname\userid, machinename\userid and just userid for the user name.
That you can telnet to this machine is a red herring; the DataStage telnet service is an entirely separate service. Clients connect via the RPC mechanism, not the telnet mechanism.
None of this affects what you're trying to do.
The first thing you have to do is to verify that the DataStage RPC service is running. If it is not, you will have to diagnose why, perhaps try to start it with debugging options.
Next thing to try is "variations on a theme". For example, if the users on the troublesome machines were created as domain users, they will need to log in as domainname\userid rather than just userid. Try all of domainname\userid, machinename\userid and just userid for the user name.
That you can telnet to this machine is a red herring; the DataStage telnet service is an entirely separate service. Clients connect via the RPC mechanism, not the telnet mechanism.
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.
You need to have access to the server. Under the control panel should be a big A for Ascential icon. Click on that to see the services. Alternatively, you could find the Services icon and look for the engine that way.
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
On UNIX, grep for 'dsrpcd'.
However, I'm a little confused.
You said that jobs won't run but can be reset (something along those lines), which would imply that you can connect to the server in question. Then you say that 'dsadm' can't log in via any client tools to the server. The question about dsrpcd is moot if you can log in at all... is it only the 'dsadm' user that can't log in? What error do you get? Are you sure you know the password for it on that server?
However, I'm a little confused.
You said that jobs won't run but can be reset (something along those lines), which would imply that you can connect to the server in question. Then you say that 'dsadm' can't log in via any client tools to the server. The question about dsrpcd is moot if you can log in at all... is it only the 'dsadm' user that can't log in? What error do you get? Are you sure you know the password for it on that server?-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
There are two problems (I probably am mixing the two, hopefully they are the same problem)
Server is located in London. Two instances DEV and PROD
On Prod I can login as DSADMIN but I cannot run jobs as DSADMIN. DSADM cannot login at all with DS client. I can telnet in to the box as both.
On DEV, I can login as DSADMIN and can run jobs. DSADM cannot login at all with DS client. I can telnet in to the box as both.
Server is located in London. Two instances DEV and PROD
On Prod I can login as DSADMIN but I cannot run jobs as DSADMIN. DSADM cannot login at all with DS client. I can telnet in to the box as both.
On DEV, I can login as DSADMIN and can run jobs. DSADM cannot login at all with DS client. I can telnet in to the box as both.
This is odd. The login issue has been resolved: To recap:
I could telnet into the box with DSADM but could not open any DS client tool with DSADM. The box only had a local user for DSADM. The IT support recreated a DSADM account for DSADM and I was able to log into DS client tools with DSADM.
Weirder. The IT support person removed the NIS account and I still have access to DS tools with DSADM. The box goes down on Sat for maintenance so we'll see if that is true on Monday.
Other problem:
I still cannot run or refresh jobs on one of our boxes. The others work fine.
I could telnet into the box with DSADM but could not open any DS client tool with DSADM. The box only had a local user for DSADM. The IT support recreated a DSADM account for DSADM and I was able to log into DS client tools with DSADM.
Weirder. The IT support person removed the NIS account and I still have access to DS tools with DSADM. The box goes down on Sat for maintenance so we'll see if that is true on Monday.
Other problem:
I still cannot run or refresh jobs on one of our boxes. The others work fine.
For the non-running of jobs check the crontab file on UNIX. As the user you run your jobs with do:
You should be able to recognize your jobs. If they are in there (assuming you run them in "every"... style) cron will run them. Then have your system admins check the cron log files to see whether they actually see the job starting.
What we had in one case was that because of changes in one of the DataStage configuration files the DataStage phantoms would core dump, but this should be detectable from the cron log files.
Ogmios.
Code: Select all
crontab -l
What we had in one case was that because of changes in one of the DataStage configuration files the DataStage phantoms would core dump, but this should be detectable from the cron log files.
Ogmios.
In theory there's no difference between theory and practice. In practice there is.