>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.