DSXchange

It is possible to use a before job subroutine which can pickup values from a file and assign them to a job parameter. Unfortunately no, as at that point it is 'too late' - the parameter values have already been assigned. It would have to be truly before, in a separate step, to try something like th...

Don't recall exactly, somewhere in the "RT" job hashed files. The answer is out in the forums, I do believe, so a search may turn it up.

Search the forums for 64BIT_FILES, the concerns with that approach have been mentioned here several times. Basically, the concern is that ALL hashed files will be created as 64bit going forward, every single one everywhere from what I understand.

What are you trying to accomplish with this constraint? If it is simply to check the success/failure of the lookup, that should work but the 'more proper' solution would be the NOTFOUND link variable.

The short answer is no, especially (and emphatically) for the 'series of jobs' question. The slightly less shorter answer is yes (in a single job) if you can manage to do all of your work in a single target database stage. It is still controlled at the individual link level but everything would be a...

Ahhh... the gauntlet has been thrown.

I believe all that is understood by the OP, but they seem to be looking for some way to not need to add/override the value in every job that needs it. Is that correct?

Hmmm... I don't believe there is any way for an environment variable to have its default value set to another environment variable. Be happy to be proven wrong, however.

Perhaps this is something that judicious use of Parameter Sets would help with? Don't ask me how, just wondering.

xinhuang66 wrote:Is it possible that there are some process in the job itself cause the lock ?

Nope. It really is as simple as already posted. And the rules for a direct path versus a conventional load are different.

Ah... Wurlod Humor.

FNUXI.

So, is the belief that these are coming from the normal operation of DataStage and I'll need to monitor and nuke these on a regular basis? Or these are rogue interlopers that deserve nothing more than shooting first and asking questions later?

I guess in principal that I agree, seeing as how I never use it, prefering other mechanisms to 'join' or merge files.

That smells odd enough it's probably a bug. Open a case with your official Support provider and let us know what you find out.

About the only real 'gotcha' I can think of off the top of my head is the need to use a field separator when cat'ing everything together for the CRC32 function. A silly example that should easily make the point: Two fields to check, Field1 has a value of "123" and Field2 has a value of "456". Cat'd ...

CRC32 works well for that. Unless you have a very small number of columns to compare, it's relatively painless to hash up the CRC value for all the fields in the existing rows and compare that to what comes in from your source. A miss in the lookup = new, while a hit where the CRC value is different...