hi All
I am trying to run a job from another job using a sub-routine.
i created a job BasicTrial
SeqFile-->Transformer---->seqFile
In the Transformer i called a subroutine BasicTrial("JobName") In my case it looked like BasicTrial("AcctCustSeqTrial")
My Job AcctCustSeqTrial is compiled and in runnable state
The code for my Subroutine BasicTrial("JobName"):
--------------------------------------------------------------
$IFNDEF JOBCONTROL.H
$INCLUDE DSINCLUDE JOBCONTROL.H
$ENDIF
jobHandle = DSAttachJob(JobName, DSJ.ERRFATAL)
Ans = DSRunJob(jobHandle,DSJ.RUNNORMAL)
--------------------------------------------------------------
My Main job is getting Aborted with a fatal error saying:
BasicTrial..Transformer_1 (fatal error from DSRunJob): Job control fatal error (-2)
(DSRunJob) Job AcctCustSeqCreation is not in a runnable state
The Documentation claimed that the handle will automatically get detached so i modified my code as below
-------------------------------------------------------------------
$IFNDEF JOBCONTROL.H
$INCLUDE DSINCLUDE JOBCONTROL.H
$ENDIF
jobHandle = DSAttachJob(JobName, DSJ.ERRFATAL)
ErrMode1 = DSRunJob(jobHandle,DSJ.RUNNORMAL)
ErrHandle = DSDetachJob(jobHandle)
jobHandle1 = DSAttachJob(JobName,DSJ.ERRNONE)
Ans = DSGetJobInfo(jobHandle1,DSJ.JOBSTATUS)
-------------------------------------------------------------------------
Now the Job is running forever
Can anyone please tell me how i should go about achieving my objective
P.S The above code i modifed the last line as
Ans = DSGetJobInfo(jobHandle1,DSJ.JOBNAME)
it again got aborted
Thanks for the responses in advance
Thanks and Regards
Pavan
Problems in running a job using subroutines
Moderators: chulett, rschirm, roy
-
- Premium Member
- Posts: 133
- Joined: Tue Nov 23, 2004 11:24 pm
- Location: India
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
"is not in a runnable state" is an error message that suggests that your job was not eligible to be run. Your assertion that the job is in a runnable state is therefore questionable.
The only possible states in which a job is eligible to run are "Finished OK", "Finished (see log)", "Validated OK", "Validated (see log)", "Has been reset" and "Compiled".
Your code suggests that you are not checking the job status prior to invoking DSRunJob.
You can do this explicitly, or you can use DSResetJob. This is the (undocumented) function invoked in Job Sequences when you choose "reset if required, then run" as the Execution Action of a Job Activity.
Finally, do not believe the statement about automatic detaching of job handles. It's true most of the time. Better safe than sorry; always detach the job when you're done with it. However, you don't need to do that immediately the job has finished; it's quite OK to get the job's exit status and perform any other interrogations before detaching the job.
The only possible states in which a job is eligible to run are "Finished OK", "Finished (see log)", "Validated OK", "Validated (see log)", "Has been reset" and "Compiled".
Your code suggests that you are not checking the job status prior to invoking DSRunJob.
You can do this explicitly, or you can use DSResetJob. This is the (undocumented) function invoked in Job Sequences when you choose "reset if required, then run" as the Execution Action of a Job Activity.
Finally, do not believe the statement about automatic detaching of job handles. It's true most of the time. Better safe than sorry; always detach the job when you're done with it. However, you don't need to do that immediately the job has finished; it's quite OK to get the job's exit status and perform any other interrogations before detaching the job.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
I would think it could be related to not waiting for the job to complete after issuing the DSRunJob. If it is still running from the invocation made by the first row through the job when the second row comes around, the job will not be in a 'runnable state' - because it is still running.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Premium Member
- Posts: 133
- Joined: Tue Nov 23, 2004 11:24 pm
- Location: India
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Well, you're re-inventing the wheel by wanting to run job B for each row processed by job A.
Look in the Routines branch (sdk\Utility category) at the routine called UtilityRunJob, which does exactly what you're trying to achieve.
Look in the Routines branch (sdk\Utility category) at the routine called UtilityRunJob, which does exactly what you're trying to achieve.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Premium Member
- Posts: 133
- Joined: Tue Nov 23, 2004 11:24 pm
- Location: India