DSXchange

chulett wrote:If you really need a mixture, then the "type 2 columns" would need to come out into a child table.

As mentioned in my first post. Just a little shorter.

We have a 32 cpu machine that has been partitioned. DataStage runs under a 4 cpu partition because we have a 4 cpu license. However, when the jobs are run we get warnings in the job logs about violation of the number of cpu's. It seems DataStage does a 'system' scan instead of a partition scan. So....

Yup!

http://www.dsxchange.com/viewtopic.php? ... put+line+0

http://www.dsxchange.com/viewtopic.php? ... put+line+0

http://www.dsxchange.com/viewtopic.php? ... put+line+0

http://www.dsxchange.com/viewtopic.php? ... put+line+0

http://www.dsxchange.com/viewtopic.php? ... put+line+0

http://www.dsxchange.com/viewtopic.php? ... put+line+0

Plus four or five more.

Not if it includes effective date ranges for the changes, that's indicative of a type 2. A type 3 is, in a way, just a stack of tracked fields of a fixed number with values pushed down the line as a change is detected. Eventually, changes 'fall off' the end and are lost. I suppose you could do some ...

Or you can trust in Ray's mind reading ability.

You might want to elaborate on that just a wee bit.

It's not suppose to matter... just trying to get as much information as possible about the problem. Ok, so just a problem viewing ODBC data. Do both people (the 'working' one and the 'non-working' ones) use the same logon information to your ODBC database or do they each have their own? It would pro...

A dimension is of one type, not some odd combination of types. So, to keep history you would need it to be a Type 2 and thus keep history on all columns.

If you really need a mixture, then the "type 2 columns" would need to come out into a child table.

View what kind of data? From where? Is this one user the same user that created the jobs?

ps. Don't mark the post as a UNIX OS post if your server runs on Windows. It confuses things.

Ah, so the mention of "PI/Open" flavor is related to Prime Information? That does go back aways.

So just changing the INCLUDE to yours would fix it right up?

Get rid of the 'cd' part and you should be fine:

"fullpath/XXXX.ksh #InputFile# #InputPath# #ArchivePath#"

Assuming 'fullpath' starts from root - i.e. with a forward slash.

1) Sure - just enclose it in hash signs like 'normal'.

2) The name of your script. Actually, the full path to your script. Followed by the appropriate argument list.

charles.craig@physiciansm wrote:"I joined the team and was met with ignorance and apathy." Well, what are you going to do about it? "I don't know and I don't care."

Sorry for the wrong answer, at least (as you said) I got you pointed in the right direction.

Use "dsjob -paraminfo" instead.

Ah, deja-vu all over again.