DSXchange

The answer to the original question is "probably".

Since no-one seems to have an answer, why not research the three methods yourself and share your results?

Don't forget to document the hardware and software configuration and the volume of data processed (and make sure that this is enough to generate statistically meaningful results).

That's exactly what the DIGITS transform does.
It's an easier-to-remember name, which is one of the reasons for having Transforms.

Objects used by DataStage clients to communicate with the server are exposed by an ActiveX control. If an OLE Automation error occurs, it ceases to be possible to use the current connections; you need to open new instances of the clients. DSR_JOB is one of a number of "helper subroutines" on the ser...

Resetting the job will sometimes add an event to the job log with a subject like "from previous run...", which may also contain useful diagnostic information.

Without line terminators this is tricky. I'd be inclined to pre-process the file in a before-job subroutine, pretty much along the lines I indicated, but using ReadBlk to read 540 bytes, then 540 bytes, then 3 bytes, then as many "record" sized chunks as necessary. And the ASCII function to covert t...

ALL writes to a hashed file are destructive overwrites, whether from one source or many. If the key being written already exists on the hashed file, then that row is replaced entirely with the columns of the new row. If this is what you want to happen then, yes, it is "safe". A hashed file behaves l...

The ORABULK stage produces the control and data files for sqlldr. It does not have any implicit capability to invoke sqlldr. Most of the other bulk loader stage types do have this capability, but the ORABULK stage does not. It is for this reason that you need to use ExecSH (or ExecDOS if on Windows)...

Another possibility is that you read the sequential file as if it contains just one column. You can process that column with DataStage's ASCII() function in a Transformer stage's stage variable, which should yield the ASCII equivalent. You can then decompose the row using substring and vertical pivo...

Use the monitor, or show performance statistics in Designer, or the "active stage finishing" event in the job log, to tell us how many rows were read from the hashed file stage. Also tell us whether there were any selection criteria used in the hashed file stage, if there were any constraints in a f...

Essentially, my recommendation was because it's a decided nuisance to have to reset jobs. I prefer that the controlling job can retain control, report anything that needs to be reported can be reported, and perhaps even other tasks executed to remedy a situation that might otherwise have generated a...

What you are seeing in DataStage is the number of rows written to the data file for sqlldr. The ORABULK stage creates the control and data files. It does not, however, run sqlldr to get these rows into Oracle. You can invoke sqlldr from the After-Stage Subroutine section of the ORABULK stage. Choose...

It's most likely to mean that someone, somehow, has added an out of sequence key. It's not something that can happen accidentally. Check with your colleagues.
Otherwise, search the forum on how to reset the sequence.

Welcome aboard! If you're writing your own job control code, to determine the prior status of a job you: attach the job (DSAttachJob) determine it's previous status (DSGetJobInfo) There are 12 possible statuses of a job, constants for which are defined in JOBCONTROL.H in the DSINCLUDE directory. Sea...

Still wasting apostrophes, I see!