DSXchange

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.

I stopped and restarted DS with no change. Still won't run jobs.

Are the dsadm passwords stored somewhere else? Earlier I could not log Administrator into the box. I called IT support, I can now telnet in as dsadm but I cannot log into dsadm with Administrator.

User Name/Password is incorrect 80011

dsadm cannot log into any DS client tool. But I can telnet in.

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.

How can I verify the rpc is running?

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.

The client is Windows but the server is Unix. Sorry for the confusion.

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?

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.

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.

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.

Problem solved on that. Our illustrious IT staff has moved DS to a link while doing maintenance and not replaced the directory.