DSXchange

Did you also set ORLogging = 0? The logs are not purged immediately after making the setting change, but only upon the next run, so it might take some time for the logs to be pruned down to size after specifying purge settings. The size really is quite large. Do you have QS or any other add-ons in u...

I wouldn't try cleaning up space directly in XMETA unless I was certain what I was doing. Perhaps you could set a project purge for x-job runs or x-days; this will go a long way in keeping XMETA smaller (another option would be to switch logging back to the hashed files).

Please post the complete error messages, since the snippet that you posted doesn't help to narrow down the possible cause.

The question here is why aren't the datasets being deleted. You need to look at the log file of the run before the one which shows all the warnings.
Once you have found the cause and cannot avoid it, then an option would be to deprecate the warning to an informational message in the job log handler.

I just put together a quickie job, Row Generator with 2 timestamp colums and put them through a filter without any errors or warnings.
If you add $OSH_PRINT_SCHEMAS to your job and look at the actual schemas going into your filter stage are they actually timestamp?

No, recompilation won't change anything. What is odd is that this warning should only occur once (or do you have more than 50 DataSets in the job?). If you go to the directory you will see files named "...ds.being_deleted", if no jobs are runnig then you can manually do an "orchadmin ...

DataStage will always try to be backwards compatible. DataStage is over 10 years old now and not a single stage has been "retired"; so I wouldn't worry about the stage disappearing on you. What will happen is that the older stages might become deprecated over time and that new functionalit...

I've seen this message (only on windows) several times, but it seems to be caused by a previous run having aborted and is only a warning message and does not prevent the job from running.

There was something niggling at me when I made my post but I ignored it - but now you reminded me of the FABS() function. Thanks.

The ksh script you are calling returns with a stderr status that is non-zero ("1" in this case) and thus DataStage is assuming that it has errors.
You can use a conditional trigger for the value of "1" as an output link for a successful job call.

According to the Parallel Job Developer's Guide the result of the ABS() is a dfloat, but generally the ABS() function is an integer one. I tested it here (on Windows 8.1) and the ABS(-1.5) returns 1 on a dfloat. Either the documentation or the ABS() function is wrong. I wonder which IBM will correct...

What column is the table partitioned on? That would be the column number 0 referred to in the error message.

There should be more error messages in the log which point to the Oracle loader log files - and the errors should be detailed there.

This looks very similar to a thread from a couple of days ago where a DB2 table was declared as partitioned in the job when it really wasn't. Could this also be the case here? Is your DB2 partitioned? If yes, have you declared the column as nullable?

Which program is giving you this error?

The default port is 9080 for the client programs, i.e. "Machine:9080" as the Domain, then userid, password as defined and the projects should appear in the dropdown list.