DSXchange

There is also a C-callable variant of the DSGetJobInfo() function that you can incorporate in your own parallel routines.

It's a DataStage BASIC function so the only place you could use it in a parallel job is embedded in an before-job or after-job subroutine, or in a routine invoked from a BASIC Transformer stage.

You can use it far more widely in job sequences and server jobs, but that was not your question.

No. You need to standardize the format of the timestamp string first, then apply a format string that matches your standardized format.

Or write your own routine or BuildOp.

You have missed probably THE most important questions, if it's a review of an existing implementation. These are two. 1. Are the end-users' requirements being met and, if not, why not and how could they be? 2. Are the key performance indicators of the ETL being met (usually these are expressed in te...

You have missed probably THE most important questions, if it's a review of an existing implementation. These are two. 1. Are the end-users' requirements being met and, if not, why not and how could they be? 2. Are the key performance indicators of the ETL being met (usually these are expressed in te...

Please answer my questions about your Transformer stage job. Help us to help you. An extra question, then. What are the row counts when you use an Aggregator stage - inputs and outputs to that stage? Can you please post the job design in each case? But use Code tags (which gives fixed-width typeface...

Even that may not help. Relying on CPU as the metric of performance in an I/O intensive job is probably missing the point. The process spends time waiting for I/O operations to complete - while it is waiting it can not consume CPU so the CPU goes off and services other processes or, if there is none...

Welcome aboard. This is, of course, a huge topic. Many of us here have the experience you mention, often more than once. IBM has a specific methodology that they use, called ITERATIONS, which begins with fundamental questions like "is the enterprise ready for a data warehouse?". You might do well to...

Assuming, of course, that you are not bound by a non-disclosure agreement of some kind.

I would be very surprised if you weren't.

The server Sort stage is notorious for not being the quickest sort utility around. It was "thrown in" to the product to check a box in marketing requirements, and somehow never got tweaked after that. We generally prefer to sort using a UNIX sort where possible. (Note that the same is not true in pa...

The "purest" DataStage approach would be to create a job sequence that reads from the control table (using a DataStage job), stores those values somewhere (maybe in user variables) and proceeds on that basis. From time to time it may be necessary to run other minor jobs to update and even to re-read...

How many output rows, how many input rows?

You probably need to constrain the output to pass only those rows that are complete.

Take a look at the actual rows being output.

As someone with some experience as a DBA, as well as being somewhat knowledgable about DataStage, I flinch every time I see UNLOCK being given immediately as the "solution" for every lock-related problem. The locks are there for a reason, people. Take some time to study what is being locked, and why...

Try finding more meaningful Subject line.

You can also pick them up using DataStage macros (such as DSJobStartTimestamp) or equivalent DataStage API functions (such as DSGetJobInfo() function), both of which are available in expressions in job sequences.