DSXchange

You haven't told what you have set the file type to, so it is impossible to recommend changing it. The cacheing/buffering attributes won't make a performance difference in this case. If you have a dynamice file, let the job run to completion, then check the modulus of the file and reset the MINIMUM....

I'm not at a DS system right now to check, but could you see if the computation would work if you do it on integers and not real numbers? Then you could remove the decimals in the string and subsequently put them back into the result via division

A startup time of 15-20 minutes is quite long. It probably includes the time required for the lookups used (be they lookup stages to databases or to PX files) to be loaded to memory. The actual startup times for the processes to load (which increases as the number of nodes and stages goes up) will b...

And what does the Oracle error log file contain? That will tell you exactly what happened.

If the file is in a directory that is remotely mounted, for instance through NFS, then you can use the wait for file activity. If it is not mounted, then you could just use the ftp or rcp to try to copy the file to the local machine, then repeat the wait loop if you get an error code of file-not-fou...

I figured that with an original question like that in this forum, I could afford to misinterpret his question so that the answer would be easy.

Wow - a double whammy. Perhaps one of the least informative subject lines ever used in DSXChange coupled with a posting in the wrong forum.

Try right-mouse click on the stage variable, then choose 'delete'

The most common method is to use the DS/BASIC function call DSGetProjectInfo(DSJ.PROJECTNAME) in a server job (or job sequence, or even in the before/after of a parallel job.

Those functions won't work in Server, as already stated. If your string date format is the same as the default date format of your Oracle instance then you don't need any conversion at all. What stage are you using to write to Oracle?

But if "0010" gets truncated to 3 character it would be "001", hence the initial result.

I agree with Craig, they must have some reason for deciding to dispense with the builtin parallelism of the enterprise stage. Do you have a partitioned DB2 database?

My guess is that it takes the minimum definition of the 2 varchar inputs and uses that for the join. If you change your 2nd sequential file first column to varchar(3) your join is correct.

Sounds like there might be a bug when DataStage creates the load file and doesn't inherit the explicit column definitions into this file. You should take it up with your support provider.

If Auto-purge is set to 10 days and you only have 5 days of logs then someone probably manually purged the log. 1. if by "back end" you mean UNIX the answer is no, the logs are in hashef files and can only be viewed within DataStage. 2. No, when logs are purged their contents are irretrievably delet...

No, you cannot do a range lookup from a sequential or DataSet file in PX 7. You can use the same method you used in server jobs in PX - write to an SQL-capable source and use that in your lookup stage.