>From: "Thomas L. Mote" <address@hidden>
>Organization: University of Georgia
>Keywords: 200001042125.OAA01383 McIDAS-XCD setup
Tom,
>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
is:
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
with:
Trying...
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
cp DSSERVE.BAT LSSERVE.BAT
cp DATALOC.BAT LOCDATA.BAT
<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
case:
TE XCDDATA "/data/mcidasd
o create the datasets:
BATCH LSSERVE.BAT
o specify where to go to get the data for the various datasets:
BATCH LOCDATA.BAT
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:
DATALOC ADD RTPTSRC LOCAL-DATA
This says that the data request will NOT go through any remote ADDE
server.
SFCPLOT T USA
This should plot the most currently decoded surface temperatures over
the continental US. If this doesn't work, try a non-ADDE command:
SFCPLT T USA X DAY=2000006
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':
DMAP GRID
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:
DECINFO
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:
DECINFO SET DMGRID ACTIVE
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
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.