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

20020719: McIDAS-X & XCD (cont.)



>From: "Fingerhut, William A" <address@hidden>
>Organization: Lyndon State
>Keywords: 200207191535.g6JFZa920941 McIDAS-X XCD REDIRECT

Bill,

Sorry to not be answering questions very fast, but I just returned
from a trip to Brasil and Argentina durning which I picked up a
bad case of the "grunge" (maybe dysentery, but I am not sure).
I am at home where I work a little and then go nap for awhile.

>From your email, it is apparent that the REDIRECT MAKE
>was never done. I just did 
>REDIRECT REST LOCAL.NAM
>REDIRECT MAKE
>BATCH "XCD.BAT
>BATCH "XCDDEC.BAT
>etc......      

The key elements in the sequence are doing the REDIRECT REST LOCAL.NAM
before doing the BATCH XCD.BAT.  The REDIRECT MAKE is not absolutely
necessary, but it doesn't hurt.

>I exited mcidas (as mcidas) and restarted mcidas.
>No error message, and redirections look okay. Yea!
>
>I restarted the ldm, just in case.

Restarting the LDM was a good move.  The reson for this is that the XCD
processes are started by the LDM via the 'xcd_run MONITOR' action in
~ldm/etc/ldmd.conf.  This has the effect of starting the XCD routine
startxcd.k whose job it is to keep all of the data monitors (e.g.,
DMSFC, DMRAOB, etc.) running.  These processes are then children of
xcdstart.k.

startxcd.k picks up things like McIDAS REDIRECTions upon startup only.
Changing REDIRECTions after startxcd.k is running will not result in
startxcd.k _or any of its children_ picking up the new/changed
REDIRECTions.

>Now for the main problem -- our surface and upper data haven't
>been found by mcidas (all users) since last Friday.

OK.  As the user 'mcidas' can you find the MD files into which that
data is decoded?  You do this by using DMAP from a McIDAS-X session
as the user 'mcidas':

DMAP MDXX

If 'mcidas' can see the files, then the REDIRECTions are OK.  If 
'mcidas' can not see the files, it either means that the files don't
exist or the REDIRECTions are wrong.

>I think that adde and redirection are okay.

OK.

>I am puzzled by not finding any *.RAT files???

This is not good because it indicates a problem.

>From linux, I just did a stat.k   -- on the SAODEC line,
>the GridF/MD is shown as 10, the time and pointer values,
>Begptr and Lasptr, increase every time I run stat.k     
>The Row column is empty. 
>
>Any ideas???

An idea:

if a bad/munged MD file existed before your modifying your REDIRECTions
the decoder will not be able to write correctly to it.  In this case
I would:

o stop the LDM
o delete the MD file(s)
o delete the *.RAP and *.RAT files that should exist in the XCD
  output directory

Also, just in case you didn't do this before, or if something got
deleted, make sure that you defined the McIDAS string XCDDATA.
Defining XCDDATA was one of the steps that had to be done in the XCD
setup process.  The BATCH file XCD.BAT uses the value of XCDATA to
setup REDIRECTions for all of the *.RAP and *.RAT files.  Looking at
the list of things you did above coupled with your comment about not
having the *.RAT files, I would ask you to check to make sure that you
did the following:

REDIRECT REST LOCAL.NAM
TE XCDDATA "whatever_directory_you_are_using_for_XCD_decoding
BATCH XCD.BAT
BATCH XCDDEC.BAT

The BATCH XCD.BAT line will setup the REDIRECTions for the *.RAP and
*.RAT files, and it is the last line that will create the *.RAP files
in the directory named in XCDDATA.

Before restarting the LDM make sure that the *.RAP files exist
in the XCD output directory.  I would do this using DMAP:

DMAP *.RA

The *.RAT files will get created by the XCD decoders if everything
else in the XCD setup is correct.

Got to run (literally)...

Tom


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.