Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!hc!whitfill
From: whitfill@hc.DSPO.GOV (Jim Whitfill)
Newsgroups: comp.os.vms
Subject: Re: Continuous batch jobs
Message-ID: <14276@hc.DSPO.GOV>
Date: 9 Apr 88 16:29:18 GMT
References: <880405103235.000003D4071@naif.JPL.NASA.GOV>
Organization: Los Alamos National Laboratory
Lines: 39

in article <880405103235.000003D4071@naif.JPL.NASA.GOV>, PJS@NAIF.JPL.NASA.GOV (Peter Scott) says:
> 
> We have a realtime communication interface setup here that we are
> interfacing a data reduction system to, and the guy doing it says he
> wants to do it via a batch job that never terminates (until the system
> goes down) because detached processes are too much work to set up.  Not
> having much experience with them myself, it sounded reasonable to me, but
> then I got to thinking that I'd never seen anyone run a continuous batch
> job (deliberately), and that maybe there would be problems with that that
> few people know about.  Anyone got any information we should know?
> 
> Peter Scott   (pjs%grouch@jpl-mil.jpl.nasa.gov)

We have many continuous batch jobs on our systems. We have no trouble with
them. What we have are jobs that cycle every n minutes, hours, etc.

All we do is the following:

$ BEGIN:

code to execute

$ WAIT 00:05:00
$ GOTO BEGIN

This runs faster than resubmitting the batch job every 5 minutes, i.e., 
the job runs and then as its last statement does a SUBMIT/AFTER="+-00:05".

The disadvantage is that it occupies memory and a balance set slot continuously.

                   =======================================
                               Jim A. Whitfill
                    Los Alamos National Laboratory (LANL)
                            Group MEE-10, MS J580
                             Los Alamos, NM 87545
                                (505) 667-9282

                 (ARPAnet ==> whitfill%meediv.xnet@lanl.gov)
                   =======================================