How to set a recurring execution of an object inside of a job schedule object

[Anon Anon]

Hi All,

I'm trying to set up a schedule of a bunch of jobs such that each of them recurs at different points during the day.

I know this sounds dumb, but the Job scheduler, for me, is the best way to keep track of a bunch of different objects. That way if our client crashes or something of that nature, then I wouldn't have to go searching for all of the jobs that should be running at that specific time. I could just run the scheduler and it would run the jobs when they needed to be run.

I was thinking it would be good if I could set each of the execution parameters for the tasks loaded into the scheduler but that doesn't seem possible exactly. Like I can set each one to run at specific different times and set it to run every day but not so that it recurs every 5 minutes.

With an Event, I have to set it so all of the jobs run at the same interval which isn't ideal, either.

If I'm not being clear (which I'm really not sure I am), let me know but if anyone has a good idea of how to do this, it would be much appreciated

[Anon Anon]

Well, for me at least, it is a bit unclear.   

Are you trying to place all regularly scheduled tasks in one or more Schedule objects and have the needed execution parameters passed to the task as it executes?  If so, what type of parameters are needed; dates or other values?  And if there are some other value what is their source and are they static or changing?

I think if you provide some specific examples of you detail requirements then some potential approaches might be offered up.

[Pete Wirfs]

Just because UC4 can do it, doesn't always mean it should.  It is a bad solution design when it demands the batch scheduler run a batch program so frequently that it simulates near-real-time service.  This is not the best use of your batch scheduling system.

At this datacenter we push back and tell them that if they need their process to run more frequently than once every 30 minutes, then they really need a better design.   To some designers, expecting UC4 to do this process is a convenient short cut by making it your design problem instead of their design problem.

To run an application every 30 minutes, we only need to create 48 schedule entries.  (We have several like this.)

One solution I like is to have the application invoke CALLAPI to tell UC4 exactly when the job needs to be executed.  Another viable solution is to have them build their own web service to handle the iterative processing that needs to take place.

[Anon Anon]

Well, I agree that just because you can that does not mean that you should.

We have a significant number of Events that execute during the day to activate tasks.  The Events themselves are placed on the Schedule and some execute continuously and others during certain periods.  Some of the Events are simply Timed and others are waiting of a File(s).  A few Event's have intervals of 1 minute but most are 5 minutes or greater.

Our view is that it is far easier for us to manage a Event single task on a Schedule rather than, in Pete's example, 48 tasks.  Given our environment we would have easily more than 1,000 tasks on a Schedule just to handle this recurring work.   In lots of instances, usually for exceptions, we will stop/quit the Event while the issues are resolved.  I cannot imagine trying to perform this same level of control via modifying the Schedule's tasks.

Also we have avoided web services or other methods for our traditional batch processing since we believe that it is advantageous to have a single point of automation (and, unfortunately possible failure) and its associated visibility.  This also includes all of the control, reporting, notification, etc. that UC4 provides.

[Anon Anon]

Hmm, let me try to clear it up a bit then. The problem I'm currently having is that there is a job which is supposed to run every 5 minutes, I have set an event so that it does this. The job itself should only take 60 seconds or so but very occasionally it will take more than 5 minutes to complete.

Once this happens, the event seemingly tries to start the next job but that causes the original job to fail and the next job to fail. We have gotten around this by making the interval longer but that's not really the solution we want.

With a recurring execution, you can set it so that it will wait until the first job finishes before starting the next job, which is great and what we want. However, the event is in a scheduler with other objects (so that we can keep track of all of them in case the system goes down and need to restart all the objects). My idea was to change the event into a recurring execution so that it won't cause that issue where it crashes and it waits until the job is finished, but I can't seem to make it so that the job will hold the parameters set when I select recurring execution. Oh, also, I failed to mention that in the attributes panel of the job, I would select that it can only run 1 task in parallel else it waits for it to finish. Hmm, that might actually solve my problem, if I set the event running with this job and specify in the job that it can only run one at a time or else it has to wait, then it shouldn't start up the job again until it's finished the first time.

[Anon Anon]

I think I understand a bit better now.

If it were me, I would modify the Event's ! Process (Interval tab) to check the state/status of the task it's about to activate.  If it is, for example, currently active then don't perform the ACTIVATE_UC_OBJECT.

The following Script functions  may be of use:

SYS_ACTIVE_COUNT
GET_UC_OBJECT_NR
GET_UC_OBJECT_STATUS
GET_STATISTIC_DETAIL

[ScottSilvester606020]

I'm very late to this discussion but this script we add to all of our events to avoid collisions may come in handy for anyone reading this thread in the future.

 

:SET &FLAG='N'
:WHILE &FLAG <> 'Y'
:    IF SYS_STATE_ACTIVE(JOBP.SFTP.FILE.TRANSFERS) = 'N'
:       SET &ACTOBJ = ACTIVATE_UC_OBJECT(JOBP.SFTP.FILE.TRANSFERS)
:       SET &FLAG='Y'
:    ELSE
:       WAIT 60
:    ENDIF
:ENDWHILE

[Pete Wirfs]

I use "run 1 task in parallel" for jobs that would collide with themselves.  If you have more than one job that you don't want colliding, then use a SYNC object.

[Anon Anon]

For this kind of task we usually do not use the Tasks running parallel attribute.  For us, we often actually want the interval skipped and to not activate the task.  Using this attribute results in a Status code of 1822, FAULT_ALREADY_RUNNING - task is already running.  This "intentional" failure then shows up in various Service Level reports that we then have to address as to why this particular failure occurred.  In addition using this technique, we can if desired, add notification logic to the Event's ! Process to start various kinds of escalation since the activated task is not running at the scheduled interval.

[Legacy User]

I created a VARA object, the VARA contains the information object-to-activate & timeframe when to activate it (10:00-12:00). The EVNT_TIME object reads the vara in the !Process and iterates trough the VARA entries using PREP_PROCESS_VAR. If the current time is inbetween the specified timeframe, it checks using SYS_ACTIVE_COUNT with ANY_ALIVE parameter, whether the object is still active. If so, it continues without doing anything, if not, it ACTIVATE_UC_OBJECT without the WAIT parameter. This simulates a crontab - however as Pete said, if your organisation is listening to your guidance, try to advice them :-). Note that all objects recorded in the VARA need to have the same periodicity. I don't know how this behaves if you record lots of object into the VARA, mine has only about 20 entries.

[Jim Griffith]

I have all 3 of your solutions running in my system..ha. I have one that uses a vara to keep track if a set of processes are active or not. We have an include object in some that checks to see if an instance of that process is already active and if it is, it kills the new execution. AND I have some that use the attributes. If you don't care about the "FAULT_OTHER" failure, then i would use the parallel setting in the Attributes tab. That will be the easiest. The if you do care about that, the vara method looks cleaner because you can have the !Process tab look at the flag in the vara and just not submit the process if the flag shows there's already one running. 

Good luck!