DSXchange

I've seen that OCI message in a couple of different situations. One would be when handling CLOB fields and others of that ilk. You basically define them as very large varchars in DataStage and they work 'fine' as long as the contents fit in the size you've declared. Once they don't, the 'truncated d...

Haven't really used it all that much, but I would think that - assuming you define the field properly - the CFF stage would handle the COMP-3 conversion for you automagically. There are other reasons you want to make sure it is correctly defined as otherwise it may get 'converted' from EBCDIC to ASC...

Thanks mate for the reminder!

No worries, Kim, it's probably another of those 'Windows Server only' things like uvwalk.

Keep in mind, however, that some of the reasons that the OP is looking for - like phantom errors or timeouts - can only be 'captured' after the job has finished and that by farming the logs.

Adds a whole 'nuther wrinkle. One that we've discussed ad nauseum, granted, but a wrinkle none the less.

I've found the NOTFOUND variable to be unreliable when used with anything other than a hashed file lookup. Stick with the old fashioned way when using database stages - check one of the key fields for a null value to indicate failure.

Those kind of 'records' are hard to skip gracefully. Better to not generate them. I think there is a /B switch you can use... check the help by issuing copy /? from a command prompt.

Or try 'type' as Roy suggested instead.

Interesting. I had the issue on a 6.x system running on Tru64 with everything scheduled via cron. Haven't seen it yet here with 7.0.1 on HP/UX but (now that I think about it) may have more to do with the fact that we do very little scheduling via cron, practically all is done with Control-M. Haven't...

The error message basically means you have created a 'closed loop' job stream - you need to resolve that before the job will compile or even think about running.

Make sure there is a separate beginning and end to your job, that one doesn't point back to the other.

The setting at the Project level only applies to new jobs created after the change was put into place. You have a couple of options. You can create a routine to take a value and update all existing jobs with that value - but that implies a good knowledge of the inner workings of things DataStage. So...

Lotsa changes from 6.x to 7.5.1... well worth the upgrade. IMHO.

You might want to post the details of your 'before stage subroutine to copy files'. Does the EOF (^Z?) exist in your source files or is it being introduced in the concatenation process?

I think you need to look at the FileInfo function, not Status.

FileInfo (etc) is documented in the BASIC reference manual.

For Windows and emailing attachments, you should look at 'blat'.

I never had to do anything special. It didn't run one day and then did the next with no intervention on my part.

Only saw it two or three times total.