Getting Handle of Job Controller

[bmsq]

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.

[ray.wurlod]

Once you have the controller name use DSAttach() to establish a handle to it. Don't forget to DSDetach() once you're done with it.

[chulett]

I'm writing some custom Job Control and I need to be able to get the handle of a job's 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.

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.

[ray.wurlod]

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.

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)

[bmsq]

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!

[kduke]

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.

[bmsq]

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!