[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20030110: another quick question (or so I hope)
- Subject: 20030110: another quick question (or so I hope)
- Date: Fri, 10 Jan 2003 08:28:51 -0700
>From: "Paul L. Sirvatka" <address@hidden>
>Organization: COD
>Keywords: 200301101430.h0AEU2t18460 McIDAS-XCD REDIRECT
Paul,
>In addition to yesterdays query, I have another.
The only email we received from you yesterday was the one where you
asked if I had been too busy to answer a query from December. Looks
like the first order of business is to track down what is happening
to your emails!
>I cannot find our MDXX
>files. IT seems that they just stopped being sent.
MDXX files are created locally by McIDAS-XCD decoding processes. If
they are no longer being created, I would first suspect that the
either the LDM isn't running, or the XCD processes are not being run
from the LDM.
>Could you tell me where
>they get created and where they are placed?
That is something that every site decides for themselves. The location
of the MDXX files that are created by XCD decoding processes will
be governed by McIDAS file REDIRECTions made in the 'mcidas' account.
To find out what your setup was, you should:
<login as 'mcidas'>
cd ~mcidas/workdata
redirect.k LIST
Look through the listing from the REDIRECT command for the entries
pertaining to MDXX files. This will tell you where the decoding was
setup.
Now, why the files are not being created is the bigger mystery. I
would troubleshoot this as follows:
<as 'ldm'>
1) do a 'ps -eafx | grep DM'. If you don't see any processes that
begin with DM (e.g., DMSFC, DMRAOB, DMSYN, DMMISC, or DMGRID), then
it is most likely that the XCD supervisory routine startxcd.k
is not/no longer running. You should then check to see if it
is running: 'ps -eafx | grep startxcd.k'. If it is not running,
stop and restart your LDM:
ldmadmin stop
<wait for all LDM processes to exit>
ldmadmin start
If the XCD data monitors (DMSFC, etc.) are still not running,
then you need to check ~ldm/etc/ldmd.conf to make sure that
they are still setup to run. The line in ldmd.conf that does
this will look like:
exec "xcd_run MONITOR"
2) If the LDM processes are all setup OK, and the XCD data monitors are
running, then you have to check things in the 'mcidas' account'.
The first thing to check is the MDXX file REDIRECTions I refer
to above. If these are OK, then the next thing to check REDIRECTions
for XCD files that end in .RAT and .RAP (dmap.k \*.RA). If
these don't exist, then you have found the likely problem. You
need to stop the LDM, reconfigure XCD, and then restart the LDM.
First, you need to verify that you have the McIDAS string XCDDATA
defined:
<as 'mcidas'>
cd workdata
tl.k XCDDATA
If this doesn't exist, you must define it to be the directory where
you want XCD-produced files to be stored (use the location from the
REDIRECTion I mentioned at the beginning of this email):
te.k XCDDATA \"file_where_you_want_XCD-produced_files_to_exist
Then, rerun the XCD setup BATCH files:
batch.k XCD.BAT
batch.k XCDDEC.BAT
After these have run successfully, you can restart your LDM.
>I think they should be in workdata
Typically, no. I strongly recommend that sites setup their XCD
decoding to place data files off in a file partition that has lots
of space. ~mcidas/workdata is typically under /home which may or
may not have enough space especially if a site is decoding the
grids that are in NOAAPORT.
Tom