PJS@NAIF.JPL.NASA.GOV (Peter Scott) (04/06/88)
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)
whitfill@hc.DSPO.GOV (Jim Whitfill) (04/09/88)
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) =======================================
srghamo@grv.dsir.govt.nz (04/15/88)
In article <880405103235.000003D4071@naif.JPL.NASA.GOV>, PJS@NAIF.JPL.NASA.GOV (Peter Scott) writes: > 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. Actually, what he wants IS a detached job but one that LOOKs like a batch job. The problem with a continuous batch job is that it requires a queue to live in and is susceptible to nasty things like STOP/QUEUE/MANAGER. Create a command procedure, as for a batch job, then, issue the command RUN /DETACH ... SYS$SYSTEM:LOGINOUT /INPUT=commandfilename /OUTPUT=logfilename Andrew Ollivier, Department of Scientific and Industrial Research, New Zealand SRGHAMO@GRV.DSIR.GOVT.NZ