Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!genrad!decvax!ucbvax!arc.CDN!perkins
From: perkins@arc.CDN (Ernie Perkins)
Newsgroups: comp.os.vms
Subject: run myprog/topcpu=?  Clarification
Message-ID: <161*perkins@arc.cdn>
Date: Fri, 16-Oct-87 20:22:56 EDT
Article-I.D.: arc.161*perkins
Posted: Fri Oct 16 20:22:56 1987
Date-Received: Sun, 18-Oct-87 09:17:45 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 30

It's rather funny to see a comment on a entry that you have sent to
info-vax, but have not yet received back from info-vax.  (I guess our
mailer is brain-dead?).  Anyways .... 
 
What I would like to be able to do is say $ RUN MYPROGRAM/TOPCPU=50:30
for example, so that myprogram will only run for 50 minutes, 30
seconds of cpu. The time does not have to be dead on, anything
reasonable close would be ok. The reason is simple ..... we have a
number of programs which under certain conditions, spin their wheels
forever.  The programs generate enormous amounts of output, which
should be immediately processes and then thrown away.  Right now, the
only reasonable ways are: 1) execute from a terminal, check with
<CTRL>T .  Terminate with <CTRL>Y.  Run cleanup proceedure. 2) submit
as a batch job with a time limit.  Wait until it is finished, then run
cleanup proceedure. Our system is often overloaded, so 1) is out to
lunch. Besides, you can not walk away from it. 2) is o.k., but takes a
minimum of two days to do (2 batch jobs).  I rather do it in one go. 
The other reason is convenence.  Without using <CTRL>T, or continually
watching the cpu accumulate, you have no assurance that the program
is running, is halted, or is going on forever.  One of our technicians
submitted a job that used more than 13 hours of cpu before it was
noticed ....
 
I realize that a /TOPCPU qualifier does not exist for a run command on
VMS (it does on MTS).   What I would like is a
process/command/anything that will halt a routine automatically
after a user specificed limit.  It should not halt the process,
thus the next command(s) could be executed.

Ernie Perkins, ALBERTA RESEARCH COUNCIL, ORSD