DSXchange

DataStage was first developed without multiple instances and invocation IDs. These were added later, but there is only one job and only one job log, all entries from the job run and in the instances run are in the same log (which is why you are seeing the 2 instances shown as part of the main job); ...

No, the dataset stage does not have that option. You would need to put a stage right after the read. I know that a Transform stage with the constraint "@INROWNUM < 2000" (in a 1-node configuration) would work, but there should be some other more efficient way that I can't think of right now.

I'd take it step by step. Clear the log (in the director, from the main job, not one of the invocations). Recompile the job. Now your logs are clear and the job status will be compiled; at least until it is executed without an invocation. Run your sequences and when the state of the main job changes...

I don't know of a way to get this from the command line. The DataStage API function DSGetParamInfo will get you the default values (the link goes to the IBM page for the BASIC call, but there is also a c++ call available).

You need to create the columns in a stage such as the modify stage (preferred) or a transform stage; the copy stage won't do this for you, as you've discovered.

Could it be that some spaces have been removed from your post? Do you want to blank-pad your strings to 4 characters?

Although I'm not sure what your problem is, the /Temp directory is always installed in the windows home directory; you need to do a lot of work, including editing several registry entries, in order to move that temp elsewhere.

Are you using the Multi-client manager tool to switch versions?

With Transaction size of 0 everything is grouped as one transaction, and the database has to take care of making a before-image for each and every record that you are deleting, then a copy of each and every record you are inserting. Once those two actions have been performed it starts doing actual c...

I haven't done failovers on SQL-Server, but doesn't the failover database inherit the database name and other attributes, making a failover almost transparent to the database users and not requiring multiple settings?

I couldn't think of an example yesterday, but have a good one today - In the database I have columns defined as SQL-Server type "timestamp2" with 7 digits of microsecond precision, but DataStage only allows 6 digits. With the setting of schema reconciliation set to default, my job aborts. ...

While Craig and many others here can get you started, why not download the free ETLStats from Kim Duke's website which should cover the functionality you need?

That would be cool if it worked If you have two lookups after one another in a job then DataStage might combine those operators automatically, and putting those two lookups after each other on the designer makes the job logic a lot easier to understand.

What Chandra has suggested is a way to avoid seeing the error. It is much better to fix the problem and avoid the overhead associated with doing an unnecessary cast/conversion. There is a reason that the default for this setting is "OFF" and this is a good example of why; namely the settin...

There is no built-in program or functionality to archive logfiles. That having been said, the log files are standard hashed files which can easily be read from DataStage server jobs, or you have the ability to output the log files to stdout from your command line and can redirect them to a flat file...

try with bigint, as in my first post.