DSXchange

... and yet the topic is marked as Resolved. Is it?

What OS? If it's truly not there, I would think a call to your support provider would be in order.

Could you please post your resolution to this problem? It will help future searchers if you close out this issue such that people can see both the problem and the solution.

Do an exact search for "normalize" for quite a number of discussions on the subject. For example: viewtopic.php?t=121718

Exactly - when they show up in logs still wrapped in hash/pound signs like that, that means it has no idea they are Job Parameters and hasn't done the substitution. Sometimes you've copied a stage from another job and forgotten to add the parameters it requires, or you've typed the parameter name in...

Granted, but it equates to true in Oracle, regardless of however much that irks you. All Hail Larry the Great!

If you can get a tape drive on the DataStage server that reads them, I'd wager you can open the device as a fixed-width Sequential file and read them directly.

For that approach you'd need to leave the data type in the job as Varchar so DataStage doesn't try to monkey with it before it goes to Oracle.

Access the Mainframe tape drives directly from your UNIX server? I sincerely doubt that can be done with any tool but don't know for certain. I would assume you'll need to get them dumped to files by the MF folks and then process them in DataStage once they're moved to your UNIX server.

Record Delimiter is what goes at the end of the record. Final Delimiter is what (if anything) goes after the final field but before the Record Delimiter. That's my understanding, anywho.

Have you read the Parallel Job Developer's Guide section on that? Sequential File Stage / Input Link Format / Record level section, lovely little picture and all there.

Sounds like that could be an issue, but I have no clue. Perhaps someone with Solaris experience will pipe up, otherwise open a case with your official support provider.

I always use Timestamp for DATE fields in my jobs. Regardless, you need to match the format mask in the SQL, so "DD-MON-YY" (with no zero time) for your current SQL. Or change it to Timestamp.

It's trying to validate minimum values... do those exist in the Solaris kernel?

Then the next question is what does your sql look like? Generated sql for a DATE field would use a TO_DATE(YourField,'YYYY-MM-DD HH24:MI:SS') to convert it properly, hence the suggestion.