DSXchange

I'm not really sure what you mean by the 'menu bar' but there are things that can disappear from the Designer that can be tricky to get back. Sometimes you can go into the Registry Editor and get things back that way, but I've generally found the easiest way is to simply reinstall the client. Missin...

And? Like I said, gotta do it in a routine.

Perhaps I should have said "It's the only way to use multiple lines of code or certain functions'. I'm sure Ray will be along later tonight to give us all the gory details of the Whys and the Wherefors.

No, you had it right at first - it must be done in a Routine. That is the only way to use multiple lines of 'code'.

Hmm... don't recall any posts mentioning any. There was at least one person who posted that they had used it and everything went just fine, from what I recall.

While you could continue to use the OCI8 stage to talk to Oracle 9i, you would need to leave a copy of the 8i client on the server and continue to point to it via your dsenv file. In the long run, you are much better off transitioning to the OCI9 stage. When you migrate, you'll need to update dsenv ...

Iconv is giving you an error on dates like that, you just aren't seeing it. Check out the online help for the Status function. It (among other things) allows you to check the success or failure of a date conversion, and the online help shows you how to do that.

Your 'simple job' is doing 45 million ODBC lookups over the course of its run. All this one at a time and over the network, unless your lookup sources are co-resident with the DataStage server.

Much better idea to bring this data into hash files and do the lookups locally against the hashes.

You fix it by not writing records to a hash file with null keys, which is typically what generates this error. Add a constraint to either not send records with null keys to the hash or transform them to some sort of 'default' value. FYI, DataStage jobs typically have three exit statuses: Ran OK - st...

I think you are going to need to adjust your 'sort' command. Since you don't specify a delimiting character, 'space' is used by default to count the fields. It looks to me what you are getting is a sort where it is considering all three of your fields as one long field, especially with the inclusio...

This change is mentioned in the readme. They renamed the 'OCI9' plugin stage back to the more generic 'OCI' plugin as it now supports Oracle 9i and 10g. The upgrade automagically swaps all of your stages in existing jobs for you.

I think this is a consequence of how record viewing is 'broken' in 7.x, where it tries to show you every field on the screen at once even if it needs to make each field a fraction of an inch wide to do so.

This has been fixed in the 7.5 release.

What "file stages" are you referring to that allow you to suppress fundamental data type mismatch warnings like this?

Technically, everything under the covers is a string in DataStage and also a Sequential file has nothing but Char data in it. Can't say why exactly it doesn't like your date format off the top of my head, but if you define it as a Char(10) you won't have problems. How much confidence do you have in ...

Only way to "turn them off" is to ensure they don't occur. Looks like you have an "empty" field that is being moved into a Long datatype and it doesn't like that. Can you check for and transform that to something else before the Sort stage, like to a NULL or a Zero perhaps?

Straight out of the online help for System Variables:

@TIME The internal time when the program started.

If you want the system time, you need to switch to the Time() function.