[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20030320: scouring of *.XCD at stc (cont.)



>From: "Anderson, Alan C. " <address@hidden>
>Organization: St. Cloud State
>Keywords: 200303181640.h2IGeXB2004042 LDM-6 McIDAS-XCD scour

Hi Alan,

>Thought I would provide the current status on the scouring issue  for
>waldo.

Sounds good.

>I just checked the machine (a little after  18Z) and again found 3
>*.XCD files,   for Mar.  18, 19 & 20.20
>
>I then went to ~ldm/util   and ran mcscour.sh manually,  and it removed
>the oldest file,  Mar. 18.
>
>Then realized that this would likely have happened automatically anyway
>when cron runs mcscour at 21 Z  in a few hours.

Cron runs off of local time.  Hmm...  I wonder if you have your clock
on GMT?  If so, then it will be 21Z not 21:00.

>So, I am guessing the  the following interpretation of our setup.
>
>The listing of  the line  delwxt.k   1  10  means to delete all files
>older than 1 day before the current day when cron runs.  This  would
>result in our having at least 2  days  of  *.XCD always present,
>namely the  current day and the previous day.  Not postitive if this is
>the meaning of the   line, but that is my guess.  The listing
>delwxt.k  1  10   does Not mean  just  1 file (current day) is kept.

I think that you are correct.

>Since cron does not run the mcscour.sh   until  21 Z,   we will
>actually have  files for 3 days  until  21Z,  after which it is pared
>back to  2.

This sounds correct.  So, if you run your clock on GMT, you will end
up having 3 files online for the great majority of the time.

>For example,  the cron entry for mcscour.sh will not run again until
>21Z on the 21st.  By that time,  a new file (for the 21st) will start
>to build,  and it will take until 21 Z on the  21st for the file for
>Mar. 19th to be deleted.  So for most of the 21st I will have files for
>Mar.  19, 20 and 21.  If I want to reduce the amount of file space used
>by *.XCD,  I could change the time of the cron entry for mcscour  to an
>earlier hour,  say 02 Z.

This sounds entirely reasonable.  So, the question is: do you run
waldo's clock on GMT?  If yes, then the cron entries should be in GMT,
and your solution of changing when the scour runs would be right on
the money.  The other thing you can do, of course, is run the scour
more than once per day.  This will not hurt anything.

>Perhaps my problem is not really a problem.

I think you are right.

>One other mystery (to me):  When I look at the mcscour.log file
>(updated when I ran mcscour manually, as noted above,)   I find lines
>showing the action  of doqtl.k,    igu.k,   lwu.k but NO  line for
>delwxt.k.
>Yet as I noted above,  the oldest  *.XCD file was deleted.
>Any idea why  the log file  does not list the running of  delwxt.k ?

If you run DELWXT from a McIDAS session, I think you will notice that it
runs silently.  You could add the DEV=CCC keyword sequence to the
delwxt.k entry in mcscour.sh to make it more verbose.

>Thats all Tom,  Thanks again.

How goes the install on the new machine?

Tom

>From address@hidden Fri Mar 21 09:25:02 2003

Hi Tom

Yes, waldo's clock is set to run GMT.   Not sure if that is 
a disadvantage,  I think I made this choice since all the 
met products are in GMT and thought it might avoid confusion
when questions of time arose.

Regarding the new terminal,  after our last exchange about 
the testing phase (disregard the failure to draw a map over 
the topo image),  I did the install.

Seemed to go ok,  lots of screens with  "installing ....,but
when it finished the last line was :
        fatal error: don't know how to make target 'mcxall'

Not sure what this means,  but:
MCIDAS  started ok.  I  just typed mcidas,  saw that it 
started, and then did an exit.  Did not try and run any 
commands.

Went on and installed the MCIDAS2002 ADDE server as per web 
directions.   I am currently working on 'configuring the mcidas
user account'.  

Will work a bit more on that today.  What is your interpretation
of the install message  listed above.  

Alan 

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.