DSXchange

I think the root of the problem you are having is terminology. There are many different types of date representations that are all collectively called "Julian Date". Most are an integer number starting at some arbitrary point in time set to day 0 and each successive day adds 1 to this value. The dat...

DSGuru2B, you can solve this type of problem by using stage variables. The first stage variable is called SeqNo and have the derivation "IF (In.NumberColumn=LastNumberColumn) THEN SeqNo+1 ELSE 1" and the second is called LastNumberColumn and is derived with "In.NumberColumn". This depends on your so...

Try looking for "parameters" and "read", there are some threads on this subject including this one . You have 2 basic choices depending upon where you would prefer to do the computations - in UNIX you can get the values from the flat file and then use the dsjob command to call up the DataStage jobs ...

Kaps, I did a search of "filter" and "truncate" and didn't come up with any matches, so I don't know what you read and where you read it - what is the actual problem you are getting with filter? The filter does nothing more than call an OS command, so there isn't much that can go wrong there - this ...

I compared runs on our system (which hasn't been rebooted in 27 days) and couldn't see a difference in reported times for jobs that ran before the DST switch, but for those that have run after I get the same 1 hour difference in displayed times. Normally calls to DATE() and TIME() go through to the ...

Naah, no problem there; I still enjoy playing with "stuff" like that even though I let my membership to the cryptographer's association lapse

The actual column name is linked to a column position number for hashed files. When you enter this in the columns screen the number gets incremented by 1 each new column, if you later change the column ordering around on the graphical canvas the original position number remains as originally entered...

bapajju,

yes, once your job is finished you can get the information for specific rows per link using the DataStage function DSGetLinkInfo(). This can be done in an after-job subroutine or even from a completely different job.

The order of hashed file columns is dependent on factors other than the displayed name; if you manually entered your column metadata for the hashed file and perhaps later inserted columns or changed the order then you will have a mismatch. Please "save" the column metadata in your input column list ...

srini

please use the features of this forum before posting such a broad question. I would recommend you look at the excellent FAQ article and then doing some experimentation with that information and then posting any remaining questions here.

Craig, you can download the GCI manual from IBM's web pages but I think the effort isn't worth it - if you can get the IBM/Ascential polynomial then you you can find some Java source (I found several references in Google) and plug it in there for use outside of DS. I think that's the minimum amount ...

My guess is that you have rcp enabled and are dropping this column somewhere between source and target. The solution is to turn off RCP or put in a modify stage that explicitly drop the column.

Looks like you need to bind in the Java call to DataStage. If you need performance you'll need to use the GCI [have you played around with it before {it's not inherently complex, just tricky}?] or if performance isn't important then you can just do shell script call.

Salil, There's nothing left out in Oracle stage properties. Well, I have to disagree with you. If I write a PX job and create an output Oracle enterprise stage and enter all the properties except the table name I get ( surprise ) the same error message that you do at compile time. Is this a coincide...

I don't know why they used this type of construct with a GOTO; it could just as easily have been programmed as: