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

20030110: another quick question (or so I hope)

>From: "Paul L. Sirvatka" <address@hidden>
>Organization: COD
>Keywords: 200301101430.h0AEU2t18460 McIDAS-XCD REDIRECT


>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

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

   <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.


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.