DSXchange

From where are you invoking the external script - if from the Sequence then you will have the invocation ID as you are passing it to the job being called; if from the job itself you can use the variable "DSJobInvocationId"

cnu - I give up! As mentioned many times before, a date or timestamp column has no format and does NOT need conversion. The only time you have a format is when this column is converted to a display or other format!
Why don't you just try it?

The Date and Time value are not stored in any "format" at all, the format is a display-only attribute.

What have you actually tried so far? Oracle DATEs contain time information, if you read this as a timestamp and declare your output as timestamp as well this could work.

You are not getting this error, but getting this warning message. It suggests that you increase the soft limit, but doesn't prevent any processing.

What are the datatypes for lnk_Sort_Op.NTWK_ROW_BGN_DT and lnk_Sort_Op.NTWK_ROW_END_DT? If they are not timestamp dataypes then perhaps you are performing an implicit conversion and one of these two values does indeed contain invalid data at runtime.

There is no need for a conversion if your datatype is DATE, the display format isn't relevant in this case, just the contents.

Add "COL.SPACES 1" to limit the spaces between columns to 1 instead of the default 3.

Vince - interesting note. We have had a couple of XML patches on Solaris as well as AIX and each time I had to go and manually replace the xmli.so and xmlo.so libraries! Since the OP went across releases I discounted that possible error and assumed that entrypoints had changed.

I'm not sure what you mean by "design patterns", could you detail what exactly you are looking for?

This might have happened if an admistrative lock was taken and not released (this could happen if the process aborts). Do you have the DataStage deadlock daemon running? If not, it would make sense to start it in order to see if it takes care of that lock. If that doesn't work, then I can think of 2...

Then try doing one - it looks like you still have UNIX paths in there.

What system condition is triggering the coredump? Also, do you have "dbx" installed, this will let you look at the stack of the core (among other functions) with which you might be able to track the cause.

Do you have a "$INCLUDE DSINCLUDE JOBCONTROL.H" in the code? The DSJS.CRASHED value is declared in that file.

If you have checked the APT_CONFIG file syntax and it is correct, then most likely your DS Server isn't sufficiently powerful or not configured with enough memory to deal with all the PX processes. Try a smaller APT_CONFIG file configuration and see if that fixed the problem.

In 99% of all cases the answer is "yes".