Hi all,
I'm writing some custom Job Control and I need to be able to get the handle of a job's controller. Sounds easy right? Using the GetJobInfo to get the name of the Controller works as advertised, but I also need the controller's instance id so that I can attach to the correct instance of the job.
I've gone through the documentation but can't find any way around this problem. Is this a gap in the DS API? Or is there another way which I can get the controller's handle.
Getting Handle of Job Controller
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Re: Getting Handle of Job Controller
I'm curious... why do you think you need that? What are you planning on doing with it? There's no handle you can access unless you establish one, so returning the name of the controlling job seems perfectly reasonable to me. Some times it helps tremendously when, rather than stating a specific "need", let us know what your goal is, what you are trying to achieve. Many times people are taking the wrong fork in the road, it's getting dark and they're about to be eaten by a Grue. We can be the Bringers of Light when that happens.bmsq wrote:I'm writing some custom Job Control and I need to be able to get the handle of a job's controller.
And what do you mean by "the controller's instance id"? If the controlling job is a multi-instance job, the invocation id will be part of the job name, if that's what you mean by instance id.
-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:
We have one particularly useful pair of routines here that can log a message or a warning in the controller's job log.
We use the former to capture gross elapsed timing of a job that is run in a loop to process data for different time periods. That way there's a nice adjacent summary in the job sequence's log.
We use the former to capture gross elapsed timing of a job that is run in a loop to process data for different time periods. That way there's a nice adjacent summary in the job sequence's log.
Code: Select all
FUNCTION LogMessageToController(Message)
* Log informational message in controller's job log.
* Do nothing if there is no controller.
$IFNDEF JOBCONTROL.H
$INCLUDE DSINCLUDE JOBCONTROL.H
$ENDIF
RoutineName = "LogMessageToController"
ControllerList = DSGetJobInfo(DSJ.ME, DSJ.JOBCONTROLLER)
ControllerJobName = Field(ControllerList, ".", 1, 1)
If Len(ControllerJobName)
Then
hController = DSAttachJob(ControllerJobName, DSJ.ERRNONE)
ErrCode = DSLogEvent(hController, DSJ.LOGINFO, (Message))
ErrCode = DSDetachJob(hController)
End
Ans = 0
RETURN(Ans)
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.
Thanks for your responses guys.
There are two reasons why I'm trying to get the controller handle. The first is some simple info/warn messages which I want to pass to the controller. The API provides a built in log to controller function but this is only for info messages, not warnings.
Ray's code provides the sort of thing I'm after, but the controller I'm trying to log to is normally one of a set of Multi-instance jobs. I'm guessing that the code provided will log to the non-instanced job rather than the specific instance actually in control.
The second was needed for a convoluted solution I had for another problem. The REAL problem I'm trying to solve is how to add check-pointing within some job control I'm writing. As far as I'm aware, sequences are just auto generated server jobs. Since Ray has previously suggested using sequences as a prototype tool and copying the Job Control to a server job as the basis for Custom Job Control, I though I'd try to use the built in sequence check pointing functions. Unfortunately, this fails terribly when the Server Job aborts because you can't restart it like a sequence. Instead you need to reset which wipes out the checkpoints. Is there any way to make use of the built in checkpoint system or will I need to roll my own using some form of persistent storage like a file or DB?
Thanks in advance!
There are two reasons why I'm trying to get the controller handle. The first is some simple info/warn messages which I want to pass to the controller. The API provides a built in log to controller function but this is only for info messages, not warnings.
Ray's code provides the sort of thing I'm after, but the controller I'm trying to log to is normally one of a set of Multi-instance jobs. I'm guessing that the code provided will log to the non-instanced job rather than the specific instance actually in control.
The second was needed for a convoluted solution I had for another problem. The REAL problem I'm trying to solve is how to add check-pointing within some job control I'm writing. As far as I'm aware, sequences are just auto generated server jobs. Since Ray has previously suggested using sequences as a prototype tool and copying the Job Control to a server job as the basis for Custom Job Control, I though I'd try to use the built in sequence check pointing functions. Unfortunately, this fails terribly when the Server Job aborts because you can't restart it like a sequence. Instead you need to reset which wipes out the checkpoints. Is there any way to make use of the built in checkpoint system or will I need to roll my own using some form of persistent storage like a file or DB?
Thanks in advance!
Rolling your own is complicated. You need to store when a job finishes successfully either in a table, sequential file or maybe a hashed file. You need to compare this last completion to the start of the current run even if this run has been stopped. If you run once a day then you can compare to today. At some point all your jobs should finish successfully. If you cross midnight then this logic may break. You will need something more complex.
Restartable job sequences is always difficult and needs to be very accurate. Rerunnig some jobs can cause errors in the targets.
Restartable job sequences is always difficult and needs to be very accurate. Rerunnig some jobs can cause errors in the targets.
Mamu Kim
Hi all,
I found a rather sneaky work around that will allow me to use the built in checkpoint routines with custom job control.
As stated in my previous post, you can use the DSCheckpoint* routines (as used by restartable sequences) in Custom Job Control/Batch job. Unfortunately I've found this to be quite useless because when your batch job fails, it will appear as "Aborted" which means you need to reset it before you can run it again. But when you do this all your checkpoints are cleared out which makes the DSCheckpoint functions useless for anything but sequences (which automatically appear as "Aborted/Restartable").
My work around for this is to write your job control as a DS Basic routine and then create a restartable sequence which only calls your routine. By doing this, you are effectively adding your job control to the sequence which allows you to do everything you would normally do in the Batch job while being able to use the Checkpoint functions for restart ability.
It's not the cleanest solution, but it is ALOT quicker then rolling your own checkpoint system like I thought I might need to do.
I hope this can help someone else in the future!
I found a rather sneaky work around that will allow me to use the built in checkpoint routines with custom job control.
As stated in my previous post, you can use the DSCheckpoint* routines (as used by restartable sequences) in Custom Job Control/Batch job. Unfortunately I've found this to be quite useless because when your batch job fails, it will appear as "Aborted" which means you need to reset it before you can run it again. But when you do this all your checkpoints are cleared out which makes the DSCheckpoint functions useless for anything but sequences (which automatically appear as "Aborted/Restartable").
My work around for this is to write your job control as a DS Basic routine and then create a restartable sequence which only calls your routine. By doing this, you are effectively adding your job control to the sequence which allows you to do everything you would normally do in the Batch job while being able to use the Checkpoint functions for restart ability.
It's not the cleanest solution, but it is ALOT quicker then rolling your own checkpoint system like I thought I might need to do.
I hope this can help someone else in the future!