DSXchange

StringToDate(ip.date,"%yyyy-%mm-%dd") specifies that the input string is in YYYY-MM-DD format. This is not how you originally represented the problem. What you probably need is something of the form DateToString(StringToDate(ip.date,"%mm/%dd/%yy"), "%yyyy-%mm-%dd")

That's not the same as your response of "delete all the existing data in the existing file" to which I responded.

I agree with Arnd on method for your newly-stated requirement. You will need an intermediate file - perhaps rename the source file before proceeding.

Why did you purchase DataStage?

DataStage can do all that (see my earlier post). If you want to write your own routines, you've wasted a lot of money on DataStage.

To reiterate: use a server job, not a server routine.

It might even be one of those one in a million chances (remember that one in a million chances always come up - Terry Pratchett) where the application was executing a NAP (or similar) and was interrupted by its parent sending an "are you there?" (kill 0) signal.

The functionality you require is available as the "overwrite existing file" property of an input link to a Sequential File stage.

Don't use a routine. You're only reinventing the wheel and making your DataStage application more difficult for others to maintain.

It's not that easy to find UniVerse, and they've had that for some time. The main issue there was some marketing genius's decision to group all database software under "DB2".

And, once you've found UniVerse, you need to take great care not to be redirected onto DB2 pages.

That's because I don't think this particular piece of information will change in the next release.

At worst, the table name DS_JOBOBJECTS will lose its underscore and case sensitivity, and some of its multi-valued fields will be normalized into child tables.

Consider setting up the FTP as a shell script invoked from an after-stage or after-job subroutine. Within that routine you can make your success tests to decide whether to invoke the script. The table name can be supplied (possibly as a job parameter) through the Input Value field when invoking the ...

Double click on the result cell in the Test grid - see if anything got logged. Add debugging statements to your routine to report progress using DSLogInfo() - re-test and check results as above. Add ON ERROR and LOCKED clauses to OPENSEQ to handle these possibilities. Add a CLOSESEQ statement before...

Nothing was (has been) changed in DataStage, right? And it worked fine before "they" rebuilt the UNIX system, right? The conclusion seems obvious to me.

1. The Director has a Print option under the Project menu. Use this when in Schedule view.

2. In a CMD shell, type AT to get a list of entries on the AT queue.

Depending on what the stored procedure does you may be able to call it from an ODBC stage (or more than one).

What's different between the QA machine and the one where the problem is manifesting?

Check out the IsValid function. You may need to specify that your date format is different from your project's default.

The warning is warning you - because you need to know - that you are trying to shoehorn a potentially large value (a dfloat) into a small receptacle (an int32). That's the "range" part of the warning. The largest int32 is 2^31-1. The largest dfloat is substantially larger than that! Further, if the ...