DSXchange

They're stored the DSParams file (along with a lot of other stuff) in the project directory on the server. It's probably easiest to print them from there, particularly if you've put them all in the User-Defined category.

You can not expect to write one row in parallel execution. @INROWNUM is calculated on each processing node. Constrain the job to execute in sequential mode - or in a single node node pool - irrespective of the number of nodes in the configuration file.

Are you specifically able to open job CopyOfTCIJBBKORFO ?

If you have multi-valued fields in your dynamic array SUM() will only total the values into fields. Prefer SUMMATION() in this case.

All DataStage background processes (phantoms) redirect stdout and stderr to a file in the &PH& directory. The "phantom warning" message is generated if there is any "unexpected output" therein. Yes, you can use PRINT, but please don't assert without proof that DSLogInfo() is expensive. It is...

Once you have solved it, please mark this thread as resolved.

There is a third possibility; if the hashed file was created using a UV stage, then it must be dropped with a DROP TABLE command executed at TCL.

No. But you could build the two into a single stored procedure.

SDKSequences is a hashed file, not a UNIX file. YOU corrupted it by editing with a UNIX tool. Therefore you have lost all sequence information that any job in your project may have had. Gone forever (unless you can restore SDKSequences from backup media, but even then the sequences it contains will ...

ArijitS wrote:I want to design a job with infinite loop.

Why? Are you being paid by the hour?

This is a silly requirement as stated. Please post your real requirement, as Craig asked you to do.

Analysis 1: A hash file is a tool for shaping a block of hash.

Analysis 2: There is no such thing as a hash file in DataStage.

There is no failover capability of this kind in DataStage server. This is partly because there is a lot of stuff in shared memory, which is lost if the conditions that require failover occur.

You would have to update the control record //JOB.STARTED.NO also.

I'd still push back on the requirement. Schedule the one second or so per day that the job can stop to have its log purged properly.

Welcome aboard.

You have given ONE command for each. There are other ways. The original request was for the commands (plural). Would you like to document the others, or join me in encouraging the OP to research?

The comment at the end of your export file claims that there are no components in the job itself. Can you please open the job in Designer and see whether there are any stages in it?

Have you tried to and, if so, with what result? What does the manual or on-line help suggest?