DSXchange

Sorry about the redundant posts. Our Firewall had an issue and I kept hitting the 'submit' button

We just had the exact same error today! After a bit of searching, I found our issue was related to not having enough disk space. Our ABAP extract was writing to a sequential file, but the device was out of free disk space. I cleaned up a few large files and re-ran with success. Just something to che...

We just had the exact same error today! After a bit of searching, I found our issue was related to not having enough disk space. Our ABAP extract was writing to a sequential file, but the device was out of free disk space. I cleaned up a few large files and re-ran with success. Just something to che...

We just had the exact same error today! After a bit of searching, I found our issue was related to not having enough disk space. Our ABAP extract was writing to a sequential file, but the device was out of free disk space. I cleaned up a few large files and re-ran with success. Just something to che...

The way I accomplished this was to write a unix script that invokes dsjob. With dsjob you can give it a parameter to dump the summary log entries or the detail entries. Here is a piece of my script:

dsjob -jobinfo $2 $1 > $logs_dir/$1_$my_date.log

As an FYI, IBM stated that the Before Telnet Command does not return or check for commands that fail.

Thanks for the response Ray.
I can definitely do that, but do you know if a "Before Command' ever returns a non-zero return code or will cause the job to abort?

Yes, I specifically check the error codes and have code that forces the script to return a 99 if there is an error. I have tested this functionality and ensured it is returning a non-zero return code.

I have a server job that includes an FTP stage to retrieve a file to the DataStage server. Before it ftp's this file we have a 'Before Telnet Command' execute a unix shell script to sort the file before the ftp. Our issue is that occasionally the shell script fails due to lack of space or the file n...

Ok, so where is the 'book' on 'used properly'? If you provide the functionality to call a script through a Telnet Before Command and there are 'got ya' things you shouldnt do, then a responsible software company would outline those. I've seen nothing in any manual that says NOT to do what this contr...

That's what I'll probably end up doing. Things like this are what frustrates me about DataStage. Not to mention the fact, that I also tested my unix script by having it do an exit 99 to see if the datastage job would abort...it didn't.

That's what I tried to explain previously. The datastage log above says it ran just fine, but there is NO unix shell script log at all.

The command always works from the command line and sporatically works from the Telnet Before Command. As for not using the ExecSH before job subroutine, this was developed by a IBM contractor and I inherited the support/maintenance, so I cannot answer why they did what they did. I had the same thoug...

I currently have a server job that contains an ftp stage. Within this ftp stage I use the "Telnet Before Command" to execute a unix shell script before it performs the file ftp. Inside this unix shell script I create a log file that contains everything the script has completed. When this s...

I just recently worked with DataStage support on an issue I was having much like this. What it turned out to be was a job level setting. IBM advised me at that in the Job Parameters option to look on the performance tab. Once there they had me un-check the 'use poject defaults' and select the 'enabl...