Scheduling Utility

Scheduling Utility

Post by Sam Hanse » Tue, 14 Apr 1998 04:00:00



IT Manager new to PICK. Running on RS6000. Anyone know of a good (and
hopefully inexpensive) scheduling utility to run processes/jobs/reports
in background. Would like to be able to set date/time for processes to
run.

Sam Hansen
IT Manager
Pacific North Equipment
(253) 872-3513
Kent, WA



 
 
 

Scheduling Utility

Post by Ken Walli » Wed, 15 Apr 1998 04:00:00


Personally I've never found anything wrong with "at", though I know it has
limitations - more of a timed execution manager than a batch queue
processor.  "at" is a standard part of AIX and other UNIXes and I've always
seen job scheduling as an OS function, not a DBMS or application one.

Of course, the particular PICK flavour you have may not easily let you use
the OS functions to schedule jobs and then you'll have to get hold of
somebody's PICK BASIC scheduling program and train people to use that
instead of teaching them reuseable skills like shell and perl scripting.


> IT Manager new to PICK. Running on RS6000. Anyone know of a good (and
> hopefully inexpensive) scheduling utility to run processes/jobs/reports
> in background. Would like to be able to set date/time for processes to
> run.

> Sam Hansen
> IT Manager
> Pacific North Equipment
> (253) 872-3513
> Kent, WA




--
Ken Wallis

Empower Data Solutions Pty Limited, ACN 079 955 196

Envision, enable, enhance... empower

 
 
 

Scheduling Utility

Post by Mark Green » Wed, 15 Apr 1998 04:00:00



> IT Manager new to PICK. Running on RS6000. Anyone know of a good (and
> hopefully inexpensive) scheduling utility to run processes/jobs/reports
> in background. Would like to be able to set date/time for processes to
> run.

> Sam Hansen
> IT Manager
> Pacific North Equipment
> (253) 872-3513
> Kent, WA




If you are running Universe, you can use XtraCom. You can find out more
at their web site:

http://199.45.123.2:80/xtracom/

We have been using it for almost a year now, and have had no problems
with it.
--
Mark Greene            
The above opinions are mine, not my employer's.
greenemj AT hlthsrc DOT com

 
 
 

Scheduling Utility

Post by Dave » Wed, 15 Apr 1998 04:00:00


We use cron - a lot - if there's a limit we've never hit it (HPUX 10.20). At
last count we had 50 scheduled jobs via our cron tab. Some occur regularly
throughout the day, others run nightly and still others are weekly, monthly
or even yearly occurrences. Every one runs as a phantom so no license is
used.

On our NT4.0 server we use the same technique but use the AT function. No
sign of a limit there either.

cron is a great tool and if you have Unix it's already paid for.

 
 
 

Scheduling Utility

Post by Michael Talbot-Wils » Thu, 16 Apr 1998 04:00:00



>> IT Manager new to PICK. Running on RS6000. Anyone know of a good (and
>> hopefully inexpensive) scheduling utility to run processes/jobs/reports
>> in background. Would like to be able to set date/time for processes to
>> run.

If you are doing it in AIX (i.e. they are Unix processes etc.) use cron.

If you want to do it within PICK (at least Advanced Pick and D3), I
don't think there is any equivalent general utility, so you have to
write a small program to start the main program at the right time.
You can have a different little program for each service or you can
aim for something more elaborate and general.  

You need Basic programs that sleep and restart (i.e. run in an infinite
loop and use the SLEEP statement).  The sleep may be for a length of
time or until a time of day. On waking, this program runs the program
that does whatever you want.

You can have the program wake up early each day (sleep till 23:59:59
then sleep two seconds).  When it wakes it can look at the date and see
what day of the week it is and decide whether to sleep for another day.

Such programs need to be started with 'ZHS' so that they run as
phantoms, i.e. in the background.  Typically they will be started by
USER-COLDSTART.  See your system's documentation on Z and phantoms.

--Mike

 
 
 

Scheduling Utility

Post by CWNoa » Fri, 17 Apr 1998 04:00:00


One caution on using SLEEP if you are running UniVerse - PORT.STATUS will wake
up any sleeping process. It will think it's wake up time has arrived, no matter
what time it really is.

This one was a bear to diagnose!

Regards,
Charlie




>>> IT Manager new to PICK. Running on RS6000. Anyone know of a >>> good (and

hopefully inexpensive) scheduling utility to run >>> >>> processes/jobs/reports
in background. Would like to be able to >>> set date/time for processes to run.
Quote:

>If you are doing it in AIX (i.e. they are Unix processes etc.) use cron.

>If you want to do it within PICK (at least Advanced Pick and D3), I
>don't think there is any equivalent general utility, so you have to
>write a small program to start the main program at the right time.
>You can have a different little program for each service or you can
>aim for something more elaborate and general.  

>You need Basic programs that sleep and restart (i.e. run in an infinite
>loop and use the SLEEP statement).  The sleep may be for a length >of time or

until a time of day. On waking, this program runs the >program that does
whatever you want.
Quote:

>You can have the program wake up early each day (sleep till >23:59:59 then

sleep two seconds).  When it wakes it can look at the >date and see what day of
the week it is and decide whether to sleep >for another day.

Quote:

>Such programs need to be started with 'ZHS' so that they run as
>phantoms, i.e. in the background.  Typically they will be started by
>USER-COLDSTART.  See your system's documentation on Z and >phantoms.

>--Mike


IS Director
Affiliated Acceptance Corp
3101 Mercier, Ste 407
Kansas City, MO 64111
 
 
 

Scheduling Utility

Post by Ian McGow » Fri, 17 Apr 1998 04:00:00


cron is probably running anyway and takes _much_ less cpu resources
than a phantom.  if you're going to do some kind of scheduling
of a bunch of things, one way to do it is to fire off a phantom
every hour or every day (from a cron job) that runs any scheduled
jobs and then terminates.  also has the advantage that if your
basic scheduler has bugs, it at least gets a fresh start on a
regular basis :-)

: It's interesting you should say that.  I've been told that 'cron' is far
: more efficient then a phantom.  It seems most others use 'cron' when they
: can.  I wonder if they know the answer to this.
: Of course, unix people informed me of this after looking at the use of
: system resources between a 'cron' and a phantom.


: > Cron is not the way to go. I have written and used a pick basic program
: > uses phantom ports to accomplish the same thing with less overhead.
: >
: > > The problem with using cron is that it has a limit as to how many jobs
: > > cron'ed.  I have a basic program that uses a parameter file to schedule
: > > processing jobs.  You cron the one program then it runs and kicks off
: > > rest.  It can start jobs running or it can setup PHANTOMS to run later.
: > > is if your system can handle PHANTOM.  We are running UniData but I
--


 
 
 

Scheduling Utility

Post by Mark Green » Fri, 17 Apr 1998 04:00:00



> Gordon:

> It's interesting you should say that.  I've been told that 'cron' is far
> more efficient then a phantom.  It seems most others use 'cron' when they
> can.  I wonder if they know the answer to this.

Like most things in life, the real answer is "it depends".  If the cron
process is doing a mostly unix based function (grep, find, etc.) then
yes, this is better than launching a Pick phantom to shell out to unix.
On the otherhand, if the cron is exec'ing a new pick process to run a
pick program, then the resources used are the same as doing the phantom
from the pick environment--generally speaking. This probably varies from
D3 to Universe to Unidata, etc.

> Of course, unix people informed me of this after looking at the use of
> system resources between a 'cron' and a phantom.

> Bill


> > Cron is not the way to go. I have written and used a pick basic program
> that
> > uses phantom ports to accomplish the same thing with less overhead.



> > > Sam,

> > > The problem with using cron is that it has a limit as to how many jobs
> can be
> > > cron'ed.  I have a basic program that uses a parameter file to schedule
> batch
> > > processing jobs.  You cron the one program then it runs and kicks off
> the
> > > rest.  It can start jobs running or it can setup PHANTOMS to run later.
>  That
> > > is if your system can handle PHANTOM.  We are running UniData but I
> think the
> > > code is generic enough for PICK.  Send me an email and I'll forward it
> to you
> > > if you are interested.

> > > Gordon

> > > BTW: I can't charge anything for it as I think I got it from an idea in
> a
> > > magazine somewhere.  In other words, free.



> > > > IT Manager new to PICK. Running on RS6000. Anyone know of a good (and
> > > > hopefully inexpensive) scheduling utility to run
> processes/jobs/reports
> > > > in background. Would like to be able to set date/time for processes
> to
> > > > run.

> > > > Sam Hansen
> > > > IT Manager
> > > > Pacific North Equipment
> > > > (253) 872-3513
> > > > Kent, WA




--
Mark Greene            
The above opinions are mine, not my employer's.
greenemj AT hlthsrc DOT com
 
 
 

Scheduling Utility

Post by Dave » Fri, 17 Apr 1998 04:00:00


Is the amount of overhead really the issue? Either mode would have the
overhead of spawning a subprocess and starting (insert your flavor of pick
here). And the overhead of the scheduling mechanism can't be substantial.
(Assuming that it was written with some sanity.) Our cron daemon has used
just 3:43 of cpu time since we rebooted on March 21st.

IMHO the real question is why would we write a program that  already exists?
Does it lack functionality? Does it crash regularly? Is it an immense drain
on system resources? Does it fail to do the job?!

Not that I'm complaining; but, if cron could do one more thing for me it
would recognize the work day of the month. For instance, to assure that it
runs on the third work day. I've needed to schedule a proc to run on the 1st
through 5th and placed a mechanism in the proc that aborts unless it's the
third work day. Then again this could be a gap in my understanding of cron.

Have Fun.


>> Gordon:

>> It's interesting you should say that.  I've been told that 'cron' is far
>> more efficient then a phantom.  It seems most others use 'cron' when they
>> can.  I wonder if they know the answer to this.