Restarting a job with the same parameters
Moderators: chulett, rschirm, roy
-
- Premium Member
- Posts: 252
- Joined: Mon Sep 19, 2005 10:28 pm
- Location: Melbourne, Australia
- Contact:
Restarting a job with the same parameters
We're using the standard checkpoint functionality to make our job sequences restartable. The only problem is that when you restart the top-level sequence, it asks for the parameters to be re-entered.
I want an easy foolproof way to restart any restartable job seq using the same parameters as when it failed.
My guess is that it is technically possible. If you know the DS database structure of the logs, you could write a routine that accepted a job name as input, found the latest job log for the job, sucked the parameters last used out of the log, and executed the job.
Problem is, this would take me a week and it's outside the scope of my job. ie. It's a nice-to-have, and we all know what happens to them.
What I'm hoping is that someone more talented than me has already done it, and is just dying to share their code. I am confident enough with BASIC that I reckon I could tweak anything similar to my requirements.
Thanks in advance...
I want an easy foolproof way to restart any restartable job seq using the same parameters as when it failed.
My guess is that it is technically possible. If you know the DS database structure of the logs, you could write a routine that accepted a job name as input, found the latest job log for the job, sucked the parameters last used out of the log, and executed the job.
Problem is, this would take me a week and it's outside the scope of my job. ie. It's a nice-to-have, and we all know what happens to them.
What I'm hoping is that someone more talented than me has already done it, and is just dying to share their code. I am confident enough with BASIC that I reckon I could tweak anything similar to my requirements.
Thanks in advance...
Ross Leishman
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The parameters last used are in the log "job started" entry for the previous run. Before the job starts they're also in the RT_STATUSxxx table for the job. Possibly easier to retrieve from there.
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: 252
- Joined: Mon Sep 19, 2005 10:28 pm
- Location: Melbourne, Australia
- Contact:
Thanks guys.
Kim, I found the EtlGetRowCountsFromLog job in EtlStats. I can see how I would go about grabbing params from there.
Ray, I looked at RT_STATUSnnnn and didn't think it would help that much, but then I opened the file for a restartable job, and lo-and-behold we have a CHECKPOINT row. Looks like just the thing.
So, I choose one of these methods to grab my param names and values, then its just a matter of DSAttachJob to create a job handle, DSSetParam to set my params, then DSRunJob to kick it off.
Is that about it? Any pitfalls to watch out for?
Kim, I found the EtlGetRowCountsFromLog job in EtlStats. I can see how I would go about grabbing params from there.
Ray, I looked at RT_STATUSnnnn and didn't think it would help that much, but then I opened the file for a restartable job, and lo-and-behold we have a CHECKPOINT row. Looks like just the thing.
So, I choose one of these methods to grab my param names and values, then its just a matter of DSAttachJob to create a job handle, DSSetParam to set my params, then DSRunJob to kick it off.
Is that about it? Any pitfalls to watch out for?
Ross Leishman
No pitfalls unless you have encrypted values in there; I'm not sure that they will re-parse.
<a href=http://www.worldcommunitygrid.org/team/ ... TZ9H4CGVP1 target="WCGWin">
</a>
</a>
-
- Premium Member
- Posts: 252
- Joined: Mon Sep 19, 2005 10:28 pm
- Location: Melbourne, Australia
- Contact:
Followup: For anyone interested, I wrote the following routine called "RestartJob" that is no less nasty than it is cheap. It takes a single argument: pJobName - the name of the Job/JobSeq to restart.
It does the following:
- Finds the job
- Finds the previous settings of parameters
- Sets parameters to their previous settings, ignoring encrypted params and those with default of $PROJDEF.
- Calls UtilityRunJob to launch the job.
It does NOT:
- Handle encrypted parameters with any value other than $PROJDEF
- Handle non-$PROJDEF values for params with default $PROJDEF.
- Handle errors of any kind. eg. If your job is not in status Finished or Aborted/Restartable, then brace yourself.
Anyway, it works for my purposes.
It does the following:
- Finds the job
- Finds the previous settings of parameters
- Sets parameters to their previous settings, ignoring encrypted params and those with default of $PROJDEF.
- Calls UtilityRunJob to launch the job.
It does NOT:
- Handle encrypted parameters with any value other than $PROJDEF
- Handle non-$PROJDEF values for params with default $PROJDEF.
- Handle errors of any kind. eg. If your job is not in status Finished or Aborted/Restartable, then brace yourself.
Anyway, it works for my purposes.
Code: Select all
$INCLUDE DSINCLUDE JOBCONTROL.H
Deffun UtilityRunJob(A1, A2, A3, A4) Calling "DSX.UTILITYRUNJOB"
Equate RoutineName To 'RestartJob'
lJobHandle = DSAttachJob(pJobName, DSJ.ERRFATAL)
lParamList = DSGetJobInfo (lJobHandle, DSJ.PARAMLIST)
lParamCount = Dcount(lParamList,',')
lParamSet = ""
For lParamNum = 1 to lParamCount
lParamName = Field(lParamList, ',', lParamNum)
If DSGetParamInfo(lJobHandle, lParamName, DSJ.PARAMTYPE) <> 1 Then
If DSGetParamInfo(lJobHandle, lParamName, DSJ.PARAMDEFAULT) <> "$PROJDEF" Then
lParamValue = DSGetParamInfo(lJobHandle, lParamName, DSJ.PARAMVALUE)
lParamSet := "|" : lParamName : "=" : lParamValue
End
End
Next lParamNum
lParamSet = lParamSet[2,1000]
lErrCode = DSDetachJob(lJobHandle)
Ans = UtilityRunJob(pJobName, lParamSet, 0, 0)
Ross Leishman
-
- Premium Member
- Posts: 252
- Joined: Mon Sep 19, 2005 10:28 pm
- Location: Melbourne, Australia
- Contact:
I've had no reason to handle the encrypted params - the only ones I use are always $PROJDEF - no exceptions - ever.
In testing the script I noticed that the value returned by DSGetParamInfo() for encrypted params was not the value you see in the DSParams file. It was just 2 or 3 chars of rubbish (rather than 20 or so chars of rubbish)
If DSGetParamInfo() can't be made to return the correct encrypted value, then I think you're stuffed, because I don't believe the correct encrypted value is in the logs either.
In testing the script I noticed that the value returned by DSGetParamInfo() for encrypted params was not the value you see in the DSParams file. It was just 2 or 3 chars of rubbish (rather than 20 or so chars of rubbish)
If DSGetParamInfo() can't be made to return the correct encrypted value, then I think you're stuffed, because I don't believe the correct encrypted value is in the logs either.
Ross Leishman
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Have you actually tested with an encrypted parameter?
That aside, if DSGetParamInfo(hJob, paramname, DSJ.PARAMVALUE) and DSSetParam(hJob, paramname, paramvalue) can handle encrypted parameters, then it ought to be possible to create another routine - somewhat a clone of UtilityRunJob - to run the job collecting the encrypted value by other means.
That aside, if DSGetParamInfo(hJob, paramname, DSJ.PARAMVALUE) and DSSetParam(hJob, paramname, paramvalue) can handle encrypted parameters, then it ought to be possible to create another routine - somewhat a clone of UtilityRunJob - to run the job collecting the encrypted value by other means.
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.
We know you didn't need it, but others would. Tons of peoples, like my current client, started on a version that didn't support $PROJDEF so didn't have the luxury of your 'no exceptions' rule.rleishman wrote:I've had no reason to handle the encrypted params - the only ones I use are always $PROJDEF - no exceptions - ever.
When I get some time, I figured I would just try it with encrypted passwords and see if it works as is. You never know. As noted, DSGetParamInfo can handle them and if that rubbish is the right rubbish... all will be golden. Stay tuned.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
FYI:
Code: Select all
JobControl (fatal error from DSGetParamInfo): Job control fatal error (-16)
(DSGetParamInfo) Cannot get the Default or Designed Default of an encrypted parameter for any job except the current job.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact: