DataStage scheduler problem

[EJRoufs]

We are using DataStage v 7.1 for Windows Server.

We have some jobs using SQL Server tables. When we schedule them to run, they blow up, because when the Scheduler runs them, it does not have the valid userid/password needed to access the tables. I found a spot in the DataStage Administrator where we could put a userid and password for the Scheduler (it appears, anyways). When I put the valid userid/password in here, though, the job does not even run at all when it is scheduled to run. Any ideas what the problem might be?

Thanks for any info. :>

[Sainath.Srinivasan]

Did you check the permissions for that user?

[EJRoufs]

Did you check the permissions for that user?

What kind of permissions are you referring to? That user has permission to the SQL Server table. If I actually log on and just run the job, it works just fine. It's when the scheduler tries to run it that nothing happens.

[ArndW]

The userid/password you enter in this location is to tell the scheduler which userid/password to run under and isn't related to the database connection at all.

You should put your database User and Password information into job parameters; and either use the default values at runtime (by not explicitly setting them) or to pass the parameter value information via the command line at runtime.

[EJRoufs]

The userid/password you enter in this location is to tell the scheduler which userid/password to run under and isn't related to the database connection at all.

You should put your database User and Password information into job parameters; and either use the default values at runtime (by not explicitly setting them) or to pass the parameter value information via the command line at runtime.

I'm not following exactly. Where would I pass them "to"? There is a userid/password that is hard-coded into the ODBC stage I am using. But because of how the ODBC driver is set up, it does not "use" that userid/password. It uses the userid/password that the person logs onto DataStage with. Which doesn't happen when the job is scheduled to run, though.

[ArndW]

Eric,

OK, I jumped the gun and thought that you were getting IDs mixed up. In that case, the User/Password that you enter in scheduling the job should be that which runs it, just as you did (correctly) state in your original post. So if the job isn't even getting started then either you have a type in the uid/pwd or something else, like 3rd party security software, is blocking access.

You can check this by writing you own little dummy "at" backgroun job to do something trivial like "ls >> c:\xxx.txt" and see if you can get that working.

[EJRoufs]

Eric,

OK, I jumped the gun and thought that you were getting IDs mixed up. In that case, the User/Password that you enter in scheduling the job should be that which runs it, just as you did (correctly) state in your original post. So if the job isn't even getting started then either you have a type in the uid/pwd or something else, like 3rd party security software, is blocking access.

You can check this by writing you own little dummy "at" backgroun job to do something trivial like "ls >> c:\xxx.txt" and see if you can get that working.

Ahhh.... so I have to schedule it with the same ID that I run it with? Maybe that's the problem. I have an ID: "tsitpc1" that is used to run the job. That ID has access to the SQL Server tables. However, THAT ID doesn not have authority to schedule jobs. I have another ID: "eroufs" that has authority to schedule jobs, but THAT ID does not have access to "run" the jobs. ;> That sounds like that's going to be a problem, huh?

[ArndW]

Yes, I think you've identified the cause.

But in my windows scheduler I can choose any user to execute the command as, so I am not sure if you can't change your system's access rights around to allow the DS-userid to also be fired off from AT