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

20000106: McIDAS remote ADDE server (cont.)

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


>I was able to manually do a kill -HUP on the inetd PID. I 
>checked the files:
># grep mc /etc/services
>mcserv          500/tcp      # McIDAS ADDE port
>mccompress      503/tcp      # McIDAS ADDE compression port   
># grep mcadde /etc/inetd.conf
>mcserv  stream  tcp     nowait  mcadde  /home/mcidas/bin/mcservsh       
>       mcservsh -H /home/mcadde
>mccompress      stream  tcp     nowait  mcadde  
>       /home/mcidas/bin/mcservsh mcservsh -H /home/mcadde
>They look OK. Yet when I do a telnet cacimbo.ggy.uga.edu 
>500, it still refuses to connect.

This seems to be telling us that you are using NIS+.  Is this
true?  If so, the mcinet7.6.sh procedure for setting up the ADDE
remote server will not work.  We are not experts on use of NIS+
here at the UPC.  We think, however, that what you need to do

o login as 'root'
o cd /etc
o edit nsswitch.conf
o find the line that begins with 'services'
  If you are running NIS+, this should look like:

  services:   nisplus [NOTFOUND=return] files

o IF you are running NIS+ (i.e. if the nsswitch.conf entry looks like
  the example above, change it to:

  services:   files nisplus [NOTFOUND=return]

  This will change the search order from nisplus first and files second
  to files first (i.e. use entries in /etc/services) followed by nisplus

After doing the above, a 'telnet cacimbo.ggy.uga.edu 500' should return

Connected to cacimbo.ggy.uga.edu.
Escape character is '^]'.

If this doesn't work AND you are not running NIS+, you may be (incorrectly)
running two copies of inetd.  If this is the case, then it could
explain why things are not working on port 500.

Now, AFTER one can do the telnet and not get 'connection refused' there
is most likely still a problem with your setup.  I see by your
inetd.conf entry that there is a reference to /home/mcadde.  My strong
recommendation for setting up the ADDE remote server is that the home
directory for the user 'mcadde' be the same as the user 'mcidas'.  The
difference in the accounts is that 'mcidas' allows logins and 'mcadde'
does not (by virtue of its default shell being /bin/false).  I feel
that this needs to be changed in inetd.conf before things work the way
that you will want them to.

>On another issue... I now have the data being ingested into 
>the proper directories (/data/mcidasd). I have all of the 
>redirects set up from the edited LOCAL.NAM file to 
>/data/mcidasd. When I try to do something like a SFCPLOT T 
>USA 15:00 2000006, I get:
>Dataset files are invalid for relative position numbers
>I tried this from the menu as well and get the same error. 

This sounds like the account does not have the ADDE datasets setup,
setup correctly, or MD files are not accessible (or readable?) by the
REDIRECTions that you have in place.  The way that the new McIDAS
commands (i.e. ADDE commands) work is that they ask for data from an
element of a data set.  The default dataset being asked for in your
SFCPLOT example is RTPTSRC/SFCHOURLY.  If the definition of this
dataset does not exist, then SFCPLOT will not know how to get at the
data it wants to plot.

Part of the McIDAS configuration process was the setting up of ADDE
datasets.  This was done by:

o login as 'mcidas'

o cd data

  <edit LSSERVE.BAT only IF you want to setup your ADDE datasets in
  a manner that is different than the default we send out; this is
  typically only done by ADDE-experienced sites>

  <edit LOCDATA.BAT and change fully_qualified_host_identifier
  to the name of the machine that is going to run the ADDE remote
  server at your site.  Since you do not yet have the ADDE remote
  server working yet, these definitions of where to go and get
  data will lead to command failures for right now>

o start a McIDAS-X session

o define the McIDAS string XCDDATA to be the directory where your
  XCD-produced data files exists.  This is /data/mcidasd in your

  TE XCDDATA "/data/mcidasd

o create the datasets:


o specify where to go to get the data for the various datasets:


At this point, if the REDIRECTions correctly point to the XCD (and
ldm-mcidas) produced data files (and they are readable), and the
ADDE remote server is working, you should be able to plot/contour
data.  Given that your ADDE remote server is not yet working, you
will want to verify that you can plot data from the XCD-produced
data files at all:


This says that the data request will NOT go through any remote ADDE


This should plot the most currently decoded surface temperatures over
the continental US.  If this doesn't work, try a non-ADDE command:


For a number of the non-ADDE commands, you will need to specify the
Y2K compliant form of the DAY on the command line.

>If I try something with gridded data, I get:
>No grid matching search conditions.

It is likely that you never turned on XCD GRID decoding.  To check
this, do the following from a McIDAS-X session as the user 'mcidas':


If the XCD GRID decoder is working, you will see GRID files in the
5000 number range in the /data/mcidasd directory.  If you don't,
then run:


The last part of the listing from this command will show you the
active/inactive stations of the GRID data monitor, DMGRID:

Processing Data Monitor: DMGRID       is inactive
Decoder       Status      Configuration File
GRIB          Active      GRIBDEC.CFG

If you see that DMGRID is 'inactive', then you need to run:


At this point, GRID files should be created by XCD IF the appropriate
entry had been put in your LDM's pqact.conf file:

# Entries for XCD decoders
DDPLUS|IDS      ^.*     PIPE
        xcd_run DDS
HRS    ^.*      PIPE
        xcd_run HRS

>Finally, I need to download McIDAS again to put on my 
>Solaris X86 systems (clients) and I accidently deleted the 
>message where you sent me the new ftp password. Mind 
>sending it again?

No problem:

machine: ftp.unidata.ucar.edu
user: umcidas
pass: XXXXXX
directory: unix/760


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.