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

20000105: McIDAS-XCD data ingest (cont.)

>From: "Thomas L. Mote" <address@hidden>
>Organization: University of Georgia
>Keywords: 200001042125.OAA01383 McIDAS-XCD setup

Tom,

re: configuring XCD

>I had already done all of this before I sent the first 
>e-mail. I did read all of the web pages that you 
>mentioned, and I did the redirection. I had copied the 
>EXAMPLE.NAM to LOCAL.NAM and edited it. I then did a 
>REDIRECT REST LOCAL.NAM and REDIRECT MAKE. I did the BATCH 
>"XCD.BAT and BATCH "XCDDEC.BAT.

OK.  The symptoms you reported led me to believe that the REDIRECTions
needed to locate data files had not been set.

>HOWEVER, I think I did this while running the LDM. I did stop and 
>start the ldm AFTER completing these steps, but that must 
>have not been sufficient. 

This makes sense.  McIDAS REDIRECTions are inherited by XCD decoders by
virtue of being run by startxcd.k which, in turn, is run from the
Bourne shell script xcd_run which, in turn, is run during LDM startup.

>I just went back and stopped the LDM, repeated these steps, 
>and it worked. Thanks!

Super.  Now all that is needed is a little cleanup in the 'mcidas'
working directory.

>I remembered what the problem was with the ADDE server. I 
>had tried this before Christmas and forgotten that I had 
>run into a snag. Here's what I get when I try to set it up:
>
># grep mcserv /etc/services
>mcserv          500/tcp      # McIDAS ADDE port
>#   
># sh ./mcinet7.6.sh  install mcadde
>mcinet7.6: /etc/services: mcserv already set up
>mcinet7.6: /etc/services: mccompress already set up
>mcinet7.6: /etc/inetd.conf: mcserv already set up
>mcinet7.6: /etc/inetd.conf: mccompress already set up
>mcinet7.6: telling inetd to reread its configuration
>mcinet7.6: waiting for inetd to reread its configuration
>mcinet7.6: WARNING: inetd not listening
>Try running the script again in a few minutes.
>mcinet7.6: WARNING: inetd not listening on compress port
>Try running the script again in a few minutes.
>#                                                                             

The WARNING message is telling us that the 'kill -HUP' to the inetd
process is failing.  The process for setting up the remote ADDE
server is:

o mcinet7.6.sh modifies /etc/services and /etc/inetd.conf
o a HUP is sent to the inetd process telling it to reread its configuration
  file, /etc/inetd.conf

>I am running this as root after setting up /etc/services. I 
>have tried this without anything else running, including 
>the LDM. I have tried several times -- after waiting a 
>few minutes -- and get the same error.

Hmm... can you as 'root' send a HUP to inted successfully?

>I should mention that this machine is running a heavily 
>patched version of Solaris 2.5.1. For reasons that I won't 
>bother you with, I don't want to upgrade this system to 
>Solaris 7 until I am absolutely forced to. 

This should work on Solaris 2.5.x.

>Finally, one minor question. I know there is a way to make 
>McIDAS save up to 10 AREA files (without renumbering) 
>rather than four. I did this in the past, but have 
>forgotten how to do it. Can you point me to a web page that 
>will tell me how to do this?

The number of images that are kept is governed by the existance of the
McIDAS file ROUTE.SYS in the directory in which the AREA files will be
created.  If ROUTE.SYS does not exist there, or if it is not readable
and writable by the user running the LDM, then the number of images
that are kept is fixed (4 for all products except the MDR radar images
and 6 for the MDR images).  A copy of ROUTE.SYS that is configured to
keep 10 of each kind of image in the Unidata-Wisconsin datastream is
included in the McIDAS-X 7.6 distribution.  It will be installed in the
~mcidas/workdata directory.  In addition, a copy of SYSKEY.TAB can be
found in the ~mcidas/data directory.  Both of these files should be
copied to the directory where AREA files will be made.  This is the
/data/mcidasd directory on your system.  After you copy these you
should make sure that they both have group read/write permissions.
This should be sufficient IF you put the users 'mcidas' and 'ldm' in
the same group.

>Thanks for your help.

You are welcome.

Tom