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

[McIDAS #QHK-962400]: FRNTDISP: error from m0wtxget -41001

Hi Marty,

> We have put the ssh holes in our firewall -- as well as notifyme ports.  This
> time I have left instructions to not remove them:)

Very good.

> The machine we are currently having problems with is on our Secondary Install
> with both FRNTDISP and I also noticed that WWDISP is not working.

OK.  I verified that FRNTDISP on your primary machine (cldbz1.usurf.usu.edu)
works without error.  For "the files", the ADDE setup in the 'mcidas' account
accesses the RTWXTEXT dataset as LOCAL-DATA.

> The machines you should be able to access are:

> cldbz1.usurf.usu.edu   -- Primary Install 

RTWXTEXT-realted things (e.g., FRNTDISP, WWDISP, etc.) seem to work without
error on this machine.

> climate-db2.usurf.usu.edu -- Secondary Install

When I logged onto climate-db2, I noticed that most McIDAS-XCD processes
were not running even though the LDM was running.

The first thing I did was to find out which copy/where 'xcd_run' would be
used for 'exec' actions in ~ldm/etc/ldmd.conf.  The PATH for the user
'ldm' was set so that 'xcd_run' was found in the ~ldm/decoders directory
(as is recommended).  I took a quick look at ~ldm/decoders/xcd_run and
saw that MCHOME was defined to be /home/mcidas.  Since 'mcidas' on
climate-db2 is setup to have its HOME directory in /usr/local/mcidas,
I figured that this might be the "smoking gun".   I edited this
copy of 'xcd_run' to correct MCHOME.

After looking through ~ldm/etc/ldmd.conf and ~ldm/etc/pqact.conf, I
started the LDM.  I now see McIDAS MD files being decoded, and the
backing store for data in the RTWXTEXT dataset (~ldm/data/mcidas/*.XCD)
being updated.  I will give the system some time to process data before
returning to the FRNTDISP issue.

In looking through the contents of the ~ldm/data/mcidas directory (the
place where McIDAS-XCD decoders write their output), I noticed that
a number of the files there dated to October 14 (some 6 days ago).  This
led me to be suspicious of the McIDAS scouring setup in the 'ldm'
account.  I dumped the crontab entries and saw that the copy of 'mcscour.sh'
to be run is in the ~ldm/util directory.  A quick look through this
file showed that it had the same problem as ~ldm/decoders/xcd_run: MCHOME
was set to /home/mcidas when it should have been set to /usr/local/mcidas.
I edited ~ldm/util/mcscour.sh to correct the MCHOME setting, and then
run it to make sure that it worked correctly, it did.

The next thing I noticed was that several files in the ~mcidas/workdata
directory (*.ERR, *.IDM, etc.) which should get updated by the McIDAS-XCD
decoder processes run by 'ldm' were not getting updated.  The reason
for this is that they already existed, were owned by 'mcidas', and
had read/write permissions set to read/write for 'mcidas' and read
for 'ldm'.  I stopped the LDM and deleted these files (as 'mcidas')
and restarted the LDM.  Decoding seems to be working correctly now.

The next thing I tried was running FRNTDISP as 'mcidas' to see if
it would now work; it didn't.  I verified that it would work by
pointing to the remote ADDE server on adde.ucar.edu:

<as 'mcidas'>
frntdisp.k OUT=RAW
ASUS01 KWBC 201627                                              2009293 1627

1226 PM EDT TUE OCT 20 2009

VALID 102015Z

So, there is nothing wrong with FRNTDISP itself.  A little code
diving shows that the error being returned, -41001, is an
indication that the no data was returned from the server in
the read attempt.  I think we need to wait for a bit (couple
three hours) to see if this disappears when new frontal position
information is received.

(a little later)
I got a bit antsy waiting for data, and several tests I ran
for WXTLIST and WWLIST all failed, so I decided to re-setup
XCD decoding.  I did this by:

- stopping the LDM (as 'ldm')

- deleting all *.IDX, *.IDT, *.RA* and *.XCD files in
  ~ldm/data/mcidas (as 'ldm')

- rerunning the XCD setup BATCH file

  <as 'mcidas'>
  cd $MCDATA
  batch.k XCD.BAT

I am now waiting for enough data to come in to see if routines
that access the RTWXTEXT dataset on climate-db2 work correctly
(they all work correctly when pointing at adde.ucar.edu).

I will continue to monitor things and get back to you with updated
information later...


Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
Unidata HomePage                       http://www.unidata.ucar.edu

Ticket Details
Ticket ID: QHK-962400
Department: Support McIDAS
Priority: Normal
Status: Open

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.