DSXchange

ray.wurlod wrote:FORGET re-compile. It is not necessary!

You can reset the job from dsjob.
You can even test whether it needs to be reset (Aborted = 3).

After resetting, the job status will be 21 (has been reset).
Then you can run the job normally.

No need to re-compile.

Are you listening?

I have used the following command :

dsjob - reset will only reset the job. You need to run the job after resetting the job.

Job status 3 means that the job is not in a runnable state (and must be reset).

Job status 1, 2 or 21 mean that the job is in a runnable state (and need not be reset).

Job status 0 means that the job is running, and can not therefore successfully process a run request.

There are other status values, but these cover the gamut of normal operation.

As noted, you should first check the job status using dsjob to determine if it needs to be reset. Then only if it needs to be reset, reset it as shown. Lastly, actually run the job.

This is bog standard 'dsjob wrapper script' stuff.

The other code I have seen regularly is 255. It seems to mean "something is horribly wrong" Resetting is required.

For sequencers a reset is optional when the status is 3. If you want checkpoint restartability then you should not reset before running when the status is 3 since the job will restart from the beginning. You have reset the checkpoints.

ray.wurlod wrote:Job status 3 means that the job is not in a runnable state (and must be reset).

Job status 1, 2 or 21 mean that the job is in a runnable state (and need not be reset).

Job status 0 means that the job is running, and can not therefore successfully process a run request.

There are other status values, but these cover the gamut of normal operation.

I have tested it by designing a simple job which reads from a file then there is a sort stage to sort it and then the output is written in the output file. Then I incorporated an extra column in the output file which has no mapping in the sort stage. Then i run the job from the designer and as expected the job gets aborted . Then i remove that extra column and save the job and the job should run now. Then i reset the job with the following command :
In the director the status of the job is RESET. Then i run the following command:
Then the job is getting aborted with the same error as in the previous case , but if i compile the job and then run it from dsjob then it is running ok. Is it necessary to compile the job so the changes get reflected.Please look into it and for the RESET command the status code is 0.

that sounds like a bug. If you RESET the job from the director, does the dsjob -run still fail? Also, will it fail after a RESET if run from the director?

Arnd,

Pravin's job failed because he ran the job without compiling the changes he had made. Is this not correct?

Am i missing something?

balajisr, you are right. ARRGG!!! I missed that part of his description. The job, after saving changes, has a status of not compiled and therefore cannot run.

ArndW wrote:balajisr, you are right. ARRGG!!! I missed that part of his description. The job, after saving changes, has a status of not compiled and therefore cannot run.

Then my previous assertion that job needs to be compiled from the designer after it gets aborted before running it by dsjob command or if the job gets aborted for the absence of any input file which was getting created in the previous job , bcoz the previous job failed then RESET option might work, if there is any design related issues then the job needs to be compiled after making the necessary changes to make it executable.

Re-compile is only required if you have changed the job design.

If you have not changed the job design, you do not need to re-compile. Reset is sufficient if the job has aborted and its design is not changed.