DSXchange

No... something else is different. Operating system version, patch levels of O/S or DataStage, database client version, something. What database are we talking about here?

So... this is new behaviour after migrating the job to the 8.x version? Are you on 8.0 or 8.1 and are you current on your patches / fixpacks?

Sorry, never been on a Windows server.

Support?

I think you can change the default settings and create hash files in the hash stage as 64 bit. its in the uvconfig. Whoa there! Make sure you understand what exactly this option does if you change that value in uvconfig - every single hashed file created in the project after that will become a 64bi...

Meaning... you have to handle the 12 to 24 hour conversion manually in PX?

Umm... I don't recall the 7.x version of Oracle having any kind of a TIMESTAMP column.

Ernie will probably do a much better job, but some short answers: 1. It used to be a charged option but I don't think it is any more, could be wrong however. Yes, you'd have to license the Agent as that needs to be running to 'RTI Enable' a multi-instance job. 2. That's all in the docs and in the in...

Stop and think about it for a moment. Maybe even try it. The code I gave you does exactly that. And now that I know the this and that:

Which is exactly what I gave you does. How will checking the first three characters of "INT1" or "INT2" for "INT" fail?

Use the substring operators to check to see if the first three characters = "INT". For example:

No, there's no 'architectural' difference at all. It's just that the addition of the Invocation ID to the job's name at runtime results in a unique job name allowing multiple invocations of the 'base' job name to run.

That's because you are sitting in the Engine directory rather than a Project. Add a step "2.5" where you cd to the Project directory you want to check. Note you could also try adding a "LOGTO <ProjectName>" command to the beginning of the commands you run in Step 3.

You only need to do the resize once as long as all you do is 'clear' the hashed file between runs. If you set the option to delete and recreate it, it will start off life as a 32bit hashed file again and you'll be back to square one.

Your "hashedfilepath" must be the complete path to the hashed file, including its name. Did you do so? It would look something like: SETFILE /a/b/c/Fred Fred OVERWRITING Where 'Fred' is the actual hashed file name. Note the second name can be anything, think of it like an alias for the has...

For a BASIC routine you need to check the SEEK function. After you open the file, you can use SEEK with the appropriate option (2?) to move to the end of the file and then start writing.