Force a calling job to abort based on the child job's status

Post questions here relative to DataStage Server Edition for such areas as Server job design, DS Basic, Routines, Job Sequences, etc.

Moderators: chulett, rschirm, roy

Post Reply
I_Server_Whale
Premium Member
Premium Member
Posts: 1255
Joined: Wed Feb 02, 2005 11:54 am
Location: United States of America

Force a calling job to abort based on the child job's status

Post by I_Server_Whale »

Hello all,

Not sure if this has been already asked. But I couldn't find anything useful in my search. And my BASIC skills have become rusty. :(

Environment:

IS 8.1, Windows Server 2003

There are 3 Server jobs, Job A, Job B and Job C. And there are two user-defined server routines, R1 and R2 which are coded to call Job B or Job C when used.

Job A, Job B and Job C have similar designs. An ODBC stage followed by a transformer which is in turn followed by a sequential file stage.

As per business requirements, When Job A is kicked off, Routine R1 is called in Job A's transformer, Routine R1 in turn calls Job B. So, now that Job B is kicked off, the transformer in Job B calls Routine R2 which in turn calls Job C. This is like a waterfall design, where Job A Kicks off both Job B and Job C in a serial fashion. Job A finishes after the runs of Job B and Job C are completed regardless of the status of Job B and C. Not sure why it was designed this way. Seems like it was designed by a very experienced DS person.

The problem:

When Job C aborts, this status is not reflected in the parent and grandparent jobs (Jobs A and B). Jobs A and B still show up as finished.

The Question:

How do I make the status of Job C to be reflected in Job A and Job B? If Job C aborts, then I need Jobs A and B to abort as well instead of showing up as "Finished".

Job A, Job B and Job C are multi-instance jobs.

Any inputs or thoughts are greatly appreciated.

Cheers,
I.
Anything that won't sell, I don't want to invent. Its sale is proof of utility, and utility is success.
Author: Thomas A. Edison 1847-1931, American Inventor, Entrepreneur, Founder of GE
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Any reason not to use a hierarchy of sequences, where it would be a lot easier to handle failure detection?

To continue with your current approach you need to emplace a method of aborting the caller (which is anathema to me). One way would be to constrain the first output of the Transformer stage based on the routine's return value, and put a row limit of 1 on that output link. Another way would be to have the routine set a value in a user-available system variable, such as @USER.RETURN.CODE, and have an after-stage subroutine in the Transformer stage check for that.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
ArndW
Participant
Posts: 16318
Joined: Tue Nov 16, 2004 9:08 am
Location: Germany
Contact:

Post by ArndW »

You can issue a DSStopJob(DSGetJobInfo(DSJ.ME,DSJ.JOBCONTROLLER)) call, this will issue a stop request to the parent job when only one parent exists; with more parents (a calling b calling c) you would need to parse the result of DSGetJobInfo(DSJ.ME,DSJ.JOBCONTROLLER) to get all the jobs.

This is only necessary if the jobs are called without the calling processes waiting for the jobs to finish, this would seen by calls to DSWaitForJob() in the original code. If there are called to DSWaitFor() then you can use the return codes from the job to set the return code of the current call.
Post Reply