DSXchange

Do you have an English language specification of what you are trying to accomplish, that you could share with us?

There's usually another way, but we don't want to waste time suggesting things that aren't what's needed.

Most of what is generated by DataStage parallel jobs is not object code, but Orchestrate shell (osh) script. Transformer stages and BuildOps have to go through a process of generating C++ source, then compiling and linking it, and obviously these have to be stored somewhere. It's probably inadvisabl...

Theoretically the answer is yes. With RCP enabled, the default behaviour of Read mode is the same as SELECT * FROM tablename; - that is, all columns are selected. In practice this can result in far more data having to be transferred from the database server to DataStage than is really warranted.

When is the interview?

And we have ethical objections to supplying answers to interview questions.

The typical problem with DataStage design, we find, is usually between the keyboard and the chair.

Yes, probably. Why do you need to know?

Search is your friend. Do you think you were the first to ask about slowly changing dimensions?

Your scenario will not apply in an integer sequence which is what I specified.

Sign up for premium membership (for less than $1 per week) and help us fund the website. Then you will be able to read all of the premium posters' responses and save lots of development time. You will also get access to other nice things as well.

How many other jobs were running at the time? What other work was the machine doing at the time (for example is there also a database server)? And so on. It's overloaded - doesn't matter where the load comes from.

The hashed file is typically created without an @SELECT phrase from a Hashed File stage; the @SELECT phrase is, however, created if the hashed file is created from a UV stage because, in the latter case, there is expectation that SQL will be used to access the hashed file. Now we await the outcome o...

... and can not be tuned any higher.

Prove to me that you can not obtain uniqueness with fewer than 70 columns. This is a ridiculous amount! The most I've ever seen in very many years in database technology is nine. Sheesh!

Try to work out exactly what's happening.

There's no End to the On Error clause of your ReadSeq statement. Therefore your routine is syntactically incorrect and will not compile.

Your later question is unrelated to the compile error and therefore deserves a separate thread. You are not allowed to hijack even your own threads here.

Why we are getting each and everytime diff issues instead if we are running the same Job and without changing the logic. Because other things, such as resource availability, change over time. Documenting such restrictions/requirements is part of the overall skill set of the experienced DataStage pr...