OW Scheduler

[frown] Hello, I'm struggling with the following issue. We will give the user the possibility to submit a certain job that in its turn will submit a number of other jobs. However, the first job can be launched by the user at 09.00 am, but should only be executed after 10.00 pm. So there is no regularity in when the first submit is made, but if it is executed than the next jobs can only be executed after 10.00 pm. Can this be accomplished by using P91300 (Schedule Jobs) or does anybody know any workarounds for this problem ? Many thanks.

Han Soemantri OW XE Update 6 SP. 19.1

Does the first submit use different data selection or processing options each time. That is, does the user specify the data selection or change processing options each time it is run, or is it always using the exact same data selection and processing options?

If your answer is that the same data selection and processing options ARE used, then you CAN use the Scheduler to start the job (with the caveat that all these jobs can run on the server -- there are a few odd UBE's that must run locally).

After re-reading your post, if you're asking if the scheduler can be used to control just the "next jobs", I don't think it can do that if they are launched by the first job.

So it depends on exactly what your question was. Perhaps you can clarify this point.

Don, your second remark is exactly what we want to accomplish. The first job can be launched whenever the user wants. Then we want to "stall" the job until after 10.00 pm and only after that point the next jobs need to be activated. I think my guess was right, OW Scheduler is not the way to go...but are there any alternatives to get what we want ? By the way, indeed PO values and Data Selection should be unchanged and all jobs will run on the server.

Han Soemantri.

Han,

Would you consider modifying the first job so that it doesn't launch the next jobs, and then just schedule the next jobs with OW Scheduler?

Don, I'm not sure if I understand your question.If we schedule the next jobs how do we link them to the original submit ? But to answer your question: All options are open.

Regards,

The way to do this on the AS400 is to submit this to a jobq that is held and then use the scheduler to release this at 10 and hold it say at 8.
I am not sure if the other platforms will allow this form of queue manipulation

Hi Han,

We have had similar situations to deal with and have looked at different solutions. I describe simply, two of these below for you....

1. Set a rule in the first UBE that it will wait until 10.00pm and then will launch the next jobs at that time. The potential problem here is the queue will have an open job on it all of the day and this may be no good in your environment. We used this for a job that must launch UBEs regularly through out the day but based on other actions going on around the system.

2. The second option, which I think will work for you, is to use the OW Scheduler and create a scheduled job for the second (third, fourth etc) UBE. Set this up as inactive and to run at 10.01pm once only on the appropriate server, queue etc. In the first UBE, when it is happy to launch the second UBE you issue an update to the scheduler master file setting the active status to 01 and setting the date and for the next run to the current date for your job. You must then call the scheuling routine to force the job to become scheduled to run. At 10.01pm the scheduler will launch your job. In your second UBE, when it first launches, update the scheduled job table again setting the status back to inactive and again running the scheduler routine to stop the job being scheduled anymore.

I think this option will work well for you as you then have the control in your scheduler but the user can run their job at any time. We have used this before and it works well for us.

A sample of the bit of code is shown below:

...
0011 VA rpt_VA_StartTime = "220000"
...
0016 //
0017 // Convert Start Time to Scheduler format
0018 //
0019 Get UTC Time
VA rpt_VA_SchedulerStartTime <- mnUTCTime
SL DateToday -> jdDate
VA rpt_VA_StartTime -> mnTime
"L" -> cUTC_Local
UNDEFINED -> szTimeZone
UNDEFINED -> cDaylightSavings
UNDEFINED -> szDaylightSavingsRuleName
...
0021 Get Audit Information
VA rpt_UserId <- szUserName
VA rpt_UpdatedDate <- jdDate
VA rpt_TimeOfDay <- mnTime
VA rpt_Machine <- szWorkstation_UserId
0022 VA rpt_ProgramId = "************"
0023 If BC Scheduled End ANSI C UTC Time (F91300) is not equal to <Zero>
0024 F91300.Update
BC Scheduled Job Name = TK Scheduled Job Name
VA rpt_VA_SchedulerStartTime -> TK Scheduled Start ANSI C UTC Time
VA rpt_VA_SchedulerEndTime -> TK Scheduled End ANSI C UTC Time
VA rpt_UserId -> TK User ID
VA rpt_ProgramId -> TK Program ID
VA rpt_Machine -> TK Work Station ID
VA rpt_UpdatedDate -> TK Date Updated
VA rpt_TimeOfDay -> TK Time - Last Updated
...
0029 //
0030 // Add schedule entries to scheduler for changes made
0031 //
0032 Determine and add F91320 Records for Job
BC Scheduled Job Name -> szScheduledJobName
VA rpt_VA_SchedulerStartTime -> mnSchedulerStartTime
BC Recurrenc Type -> szRecurrenceType
BC Time Zone List -> szTimeZones
BC Adjust local time for daylight savings -> cDaylightSavings
BC Scheduled Minutes -> mnScheduledMinutes
BC Scheduled Hours -> mnScheduledHours
BC Scheduled Days -> mnScheduleDays
BC Scheduled Weeks -> mnScheduledWeeks
BC Scheduled Month -> mnScheduledMonth
BC Day -> cScheduledDay
BC Weekday -> cWeekday
BC Weekend -> cWeekend
BC Monday -> cMonday
BC Tuesday -> cTuesday
BC Wednesday -> cWednesday
BC Thursday -> cThursday
BC Friday -> cFriday
BC Saturday -> cSaturday
BC Sunday -> cSunday
BC Company -> szCompany
BC Number Of Job Occurences -> mnMaxScheduledRecords
VA rpt_VA_SchedulerEndTime -> mnSchedulerEndTime
BC Daylight Savings Rule Name -> szDaylightSavingsRuleName
0039 End If
...


Andrew

Hi Andrew, thanks for the reply. After reading your post I think this can be the solution we were looking for. Actually we were figuring out a way to update F91300 but without any results so far. We will try to implement a similar set-up as you described and I will certainly keep you informed about the status. Best regards.

Han,
Since your platform is AS400 Peter's advice is a simple way to achieve your aim. Submitting your job to a queue (Let's call it Queue A) that is held until a time is one way. A simple CL program can release Queue A at a the required time - and it can also submit a job to Queue A at a low job queue priority to hold the queue again once all jobs on it have been processed. If you also want to ensure that the individual 'child' jobs are completed before any other job comes from Queue A, then you can achieve this by having multiple job queues. The child jobs get submitted to Queue B which is processed before anything on Queue A. The individual queues could also be put into their own subsytem on the AS400 so that they weren't tripping up or being tripped up by any of your normal batch processes.

Hi Andrew. After testing this set-up I have still a few questions. What did you use as Recurrence Type and Number of Occurences to pass in the BSFN "Determine and Add F91320 Records for Job". After I reschedule my job to a new launch time and date, the launching status always comes in status 25 (Error: Could Not Submit Job). I think it has something to do with the Recurrence Type, but I'm not sure. Any help would be greatly appreciated. Thx.

Hi Han -Andrews not around at the moment but I worked on the implementation of this idea should be able to help.

Regarding your question, we use the F91300 Recurrence Type and Number of occurences to pass to the BSFN.
These are the fixed attributes for the job so there is no need to change them.

What values do you have written to the F91300 and F91320 tables for the new scheduled job? If there is a problem with the values passed to BSFN they should be evident.

Let me know how u get on.

Cheers

Dave Barber

Dave, regarding my previous questions. It turned out that there was a problem with the environment we used to test our scheduler entries in. We solved this and now the set-up is working just fine. Thanks again for the advise. We use it for only one program right now, but we're planning on using it for other stuff as well. Regards.