From:	SMTP%"carl@SOL1.GPS.CALTECH.EDU" 16-JAN-1995 13:44:02.01
To:	EVERHART
CC:	
Subj:	Re: real cost

From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
X-Newsgroups: comp.os.vms
Subject: Re: real cost
Date: 15 Jan 1995 11:36:44 GMT
Organization: HST Wide Field/Planetary Camera
Lines: 59
Distribution: world
Message-ID: <3fb1cc$2lq@gap.cco.caltech.edu>
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu
To: Info-VAX@Mvb.Saic.Com
X-Gateway-Source-Info: USENET

In article <126@townleyc.win-uk.net>, townleyc@townleyc.win-uk.net (Chris Townley) writes:
= 
=In article <1995Jan11.090629.2451@janix.mfr.dec.com>, Ed Klavins (klavins@airola.zuo.dec.com) writes:
=>In article <3eqf59$2m3@gap.cco.caltech.edu> carl@SOL1.GPS.CALTECH.EDU writes:
=>>In article <121@townleyc.win-uk.net>, townleyc@townleyc.win-uk.net (Chris Townley) writes:
=>>=If you need to edit the DCL then you need to  delete the job & manually
=>>=resubmit it - I have forgotten that too many times over  a 24 hour time
=>>=span. 
=>>
=>>No, you don't need to delete and resubmit the job.  The problem you refer to is
=>>the fact that the queue manager stores the device and the FID of files queued. 
=>>That means that if you create a new version of the file, then the queue
=>>manager will still execute the old file, if it still exists.  However, you seem
=>>to be unaware of the COPY/OVERLAY command.  You can edit the procedure, or even
=>>create an entirely new procedure, then COPY/OVERLAY it to the file that's
=>>queued.
=>
=>Alternatively, for procedures such as DAILY.COM that may frequently be updated, you can add lines such as:
=>
=>$ if f$env("DEPTH") .eq. 0  .and.  f$mode() .eqs. "BATCH"
=>$ then
=>$   @'f$extr(0,f$loc(";",f$env("PROCEDURE")),f$env("PROCEDURE")) "''P1'" "''P2'" "''P3'" "''P4'" "''P5'" "''P6'" "''P7'" "''P8'"
=>$    exit $status
=>$ endif
=>
=>to ensure the most recent version of the command file is picked up when the 
=>procedure is first invoked.
=>
=>Ed.
=>
=
=Frankly I  think I would rather use Carl's solution !

Actually, Ed's approach DOES make a lot of sense for the sort of procedures he
was talking about:  Things that get modified often.  If you use his technique,
then if you edit the file, the changes WILL take effect, even if you don't
remembeer to COPY/OVERLAY afterwards.  On the other hand, for his technique to
work, you have to have anticipated the fact you were going to change the file
when you created it in the first place.  There's a tradeoff here:
	1)  If you anticipated changing the file, his technique is more
	    convenient;
	2)  My technique is more robust, in that it works even if you didn't
	    anticipate modifying the file.
	3)  On the other hand, using my technique, once you do the
	    COPY/OVERLAY, you've lost the original contents of the file unless
	    you remembered to make another copy of it.

=Mind you the easiest thing is to remember to delete the entry and resubmit
=the job when it has been edited after submission. 
	
And type in all the qualifiers and parameters by hand?  YUCK!
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.