DSXchange

Left that extra bit for you, Ray.

The full path to the script, yes.

No perhaps about it.

Interesting... seems more of a workaround than a true resolution to me, as it doesn't seem like it should be doing that in the first place. Anywho, glad you got it sorted!

Same "command", slightly modified.
You'll get a little extra stuff without excluding 'root records' and the like but that's close enough. Seriously, was that all that hard to derive from the other examples?

As noted, you can certainly turn that option on, the silly thing is that (again as noted) it only skips the header in the first file, they get read in as data with all of the other files. That's what Ray means by "compatible". Another option - if your file metadata doesn't match the header...

Well... Oracle Enterprise Linux (OEL) is Oracle's Linux distribution. OEL is based on Red Hat Enterprise Linux and is "100% binary compatible with Red Hat".

What 8.x version is this?

Yes, that's exactly what I meant.

Six years later?

Has the 8.x version opened up the email body in the notification stage such that it can support parameters or variable data of any kind? Last I knew, if you wanted data in the body you had to write a routine to call DSSendMail() rather than use the Notification Activity stage.

I don't believe so, I think all you can do is dump the data and then use your search mechanism of choice, like grep for instance.

You would only do that if you knew the job was not actually running.

So, are you saying that the log file noted in the message - /datastage/SAMPLE/Scratch/ora.1261684.765173.6.log - either doesn't exist or is empty? I don't see anything "as the log says" or "following log entry shows" that proves that to me.

Record terminators, like a line-feed in the middle of your data.

I already did and since it was only four words I've opened my post.