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

20030317: scouring *.XCD at stc (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20030317: scouring *.XCD at stc (cont.)
  • Date: Mon, 17 Mar 2003 16:26:10 -0700
>From: "Anderson, Alan C. " <address@hidden>
>Organization: St. Cloud State
>Keywords: 200303111741.h2BHfFB2012143 McIDAS-X v2002 setup

Hi Alan,

>I checked the items you note at the end of your message
>
>Logged in as ldm,  and the cron entry for ldm is limited to 
>ldmadmin scour   and    util/prune....   (for gempak images?0

OK, scouring can be done by either 'ldm' or 'mcidas'.  It shouldn't
make a difference who as long as the mcscour.sh file is setup
correctly and it doesn't get overwritten with new McIDAS upgrades
or installs.

>Logging in as mcidas,  the cron entry is listed as mcscour.sh
>and the path listed is correct,  /home/mcidas/workdata/mcscour.sh

OK.  As I think about this more, we may want to move that cron
entry over to 'ldm's.  The reason for this would be that it would
match the way the majority of sites have their scouring setup, and
it would consolidate the list of scouring activities into one
cron file.  To do the move, I would:

1) copy /home/mcidas/workdata/mcscour.sh to ~ldm/decoders
   assuming

2) verify that the copy just done is executable by 'ldm'

3) comment out the cron entry for 'mcidas' and add the same entry
   for 'ldm'

>mcscour.sh is executable,  by at least owner (mcidas) and group

This is how it should be.

>looked at mcscour.sh  and find the lines, at least the delwxt line
>just as you describe,,  delwxt.k 1 10

Yup, this is as it should be.

>While in ~mcidas/workdata,  ran  delwxt.k 1 10 
>Response was just:  Done  (after some disk whirring)
>
>So the deletion program runs,  but somehow does not seem to 
>find the right directory.

Are you sure that no files were deleted in the directory containing
the *.IDX and *.XCD files?  It may have run correctly and just been
quite.

>I have looked at my path statements,
>at LWPATH.NAM,  checked the file   .mcenv  and have not found 
>anything that catches my eye.

The entries to be aware of were the ones in LWPATH.NAM.  The stuff in
.mcenv is only used by the remote ADDE server, so it is not relevant
to the scouring.

Better than looking at the entries in LWPATH.NAM is seeing what the
McIDAS file REDIRECTions are:

<as 'mcidas'>
cd ~/workdata
redirect.k LIST

dmap.k \*.IDX
dmap.k \*.XCD

If these last two dmap.k invocations don't point you to the .IDX and
.XCD files that are to be scoured (not likely since XCD decoding should
not work in that case) then you have found a problem.

>I also stopped and started the 
>ldm, but realize that would not matter.  Cron runs independent, 
>and cron is set to do the right thing.

You are absolutely correct.  The cron-initiated scouring is somewhat
separate from the XCD decoding.

>Not sure if it is doing it where we want.

Well, the fact that the *.IDX and *.XCD files are building up tells us
that the scouring is not working the way it should.  Perhaps the
delwxt.k executable is not working?  I would like to get onto waldo to
sniff around...

Tom