DSXchange

Hi,
I have a job where a shell script is executed at end of job. The job works perfectly on one server but fails on the other server.
But when I run the shell script individually on other server it works perfectly.

Can anyone let me know what could be wrong with the job?

Check how arguments are passed to the script on each system.

What's the error you are getting exactly so that we can advise what's the root caue.
My wild guess is the directory path may exist in one server and not in another.
Make sure everything is perfect.

Whn the script fails in DataStage, I just go into the Director and copy the command from the log and paste it on command line, and everything works.

But same command fails from within DataStage on one server but passes on other server.

You've given us absolutely no information to work with, just "it works here" and "doesn't work there". Help us help you, post the actual error that you are getting, please. Unedited.

Here you go:


DataStage Log from server where command executes correctly

/apps/Ascential/DataStage/Projects/Scripts/ftp_to_nt.sh uaxxx21 /apps/Ascential/DataStage/Projects/Target/ p.txt "10.xx.xx.xxx" H_Files/Directory p.txt ascii
Reply=0
Output from command ====>


DataStage Log from server where command execution fails

/apps/Ascential/DataStage/Projects/Scripts/ftp_to_nt.sh uaxxx31 /apps/Ascential/DataStage/Projects/Target/ p.txt "10.xx.xx.xxx" H_Files/Directory p.txt ascii
Reply=1
Output from command ====>

If the above command is copied into command line of server uaxxx31, it executes perfectly

Telnet to your server as the same ID that executes the DataStage job, and then test the ftp script. Just a wild guess if you're using default credential mapping, then you could be testing with a personal ID but not the mapped ID, like dsadm. Depending on what your script does, it may be looking for hidden files in the dsadm home directory that don't exist there, but do exist in your personal home directory. If that doesn't help, then please show what's inside the script.

The FTP script executes perfectly when I log in as dsadm and run the script in Telnet.

But when I run the job as dsadm it fails, I added some more logging and this what I see this in the log:

Name (10.xx.xx.xxx:dsadm): User ascii cannot log in.
Login failed.

It is taking ascii as the user login id in DataStage job , but the same command in Telnet works perfectly.

I'm thinking that when I run in DataStage the profile is not being read correctly, any other ideas?

I don't think DataStage will ever read your profile. Any required environment variables belong in the dsenv file. If it's dependent on that, then compare your servers' dsenv files. Changes there require a restart of the DataStage server process.

Why could it be taking the ascii command as the user ID? I would double check your job and script across servers, but it could be related to your profile too. Are you able to run the script from telnet under a different user account, perhaps one with a default profile?

Could it be that you are in the wrong default directory?

When you open a command sequencer your default directory is your project dir.

Hop to that path on the command line and try your same command.

The ENV settings in a command sequencer are also a factor. Those are modified by your dsenv settings, and also your COLUMNS setting based upon the window size when you bounced your engine last.

add some debug statements to your ftp script.
echo $ENV > /tmp/my_ftp_env_settings.txt

stuff like that.
Also turn on verbose on your ftp so that you get more debug info.

Checked dsenv file across servers they are identical.
Checked scripts, they too are identical.

Currently only dsadm is setup on the box (it is a new box)

So script runs fine under dsadm in telnet but still failing in Datastage.

Any other ideas to try out?

What user ID do your DataStage jobs run under?

Logged in as dsadm in Director and executed job.

That doesn't mean your job runs under that ID. Use ExecSH as a before-job subroutine and execute the id command to determine the actual user.

Another thing to check: I ran into a similar problem but with FTPS when using the FTP Enterprise stage to call the ftp -s command on AIX. It turned out that the HOME environment variable, as found in the detail job log, was pointed to the ID that we had used to sudo to root to run the server install with, many months before. In that case, I had installed certificates under /home/dsadm, because jobs were executed under the dsasdm uer. The FTP Enterprise stage only worked after I put the certificates into the other user's home directory (the one that $HOME pointed to by default). I could have changed HOME to point to /home/dsadm to make it work also.