NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>From: "Thomas L. Mote" <address@hidden> >Organization: UGa >Keywords: 200308071535.h77FZeLd002958 McIDAS DSSERVE.BAT LSSERVE.BAT Hi Tom, >Sorry I didn't respond. We had a virus hit our computer lab (on the >Windows partition... the systems dual-boot) during this first week of >classes. What a headache! We had the same thing happen here at UCAR. Luckily, the system admins around here jumped on things quickly enough to limit damage. >Plus, we're trying to get the changes made on the NOAAport system to >conform with the GOES West channel departure. I understand completely. >We also saw our >university block numerous ports due to the recent bout of viruses. I >don't know if the McIDAS ports are open for ADDE access outside UGA. They appear to be. >Perhaps you can tell me; I can't get a straight answer from our >(overwhelmed) networking ops people. I tried two different tests: - point at cacimbo from a McIDAS session here at the UPC - logon to cacimbo as 'mcidas' and try a DSINFO IMAGE GINIEAST (the 'mcidas' account on cacimbo is setup to go through the remote ADDE server interface for all datasets hosted on cacimbo) The first test works fine for me: DATALOC ADD GINIEAST CACIMBO.GGY.UGA.EDU Group Name Server IP Address -------------------- ---------------------------------------- GINIEAST CACIMBO.GGY.UGA.EDU <LOCAL-DATA> indicates that data will be accessed from the local data directory. DATALOC -- done DSINFO I GINIEAST Dataset Names of Type: IMAGE in Group: GINIEAST Name NumPos Content ------------ ------ -------------------------------------- GE1KVIS 9999 GINI 1 km VIS East CONUS GE4K12 9999 GINI 4 km 12.0 um East CONUS GE4K39 9999 GINI 4 km 3.9 um East CONUS ... but the second one, from cacimbo to cacimbo doesn't... OK, I see what happened. The ADDE "pointing" (DATALOC) creates entries in the file ~mcidas/data/ADDESITE.TXT. If one specifies the DATALOCation by host name like: DATALOC ADD GINIEAST CACIMBO.GGY.UGA.EDU McIDAS stores the host name AND the IP address for the host in ~mcidas/data/ADDESITE.TXT. If the IP address for the host changes, then the IP information stored in ~mcidas/data/ADDESITE.TXT will be wrong. This can be corrected by running: DATALOC HOST or by running a DATALOC for any dataset to be found on the host: DATALOC ADD GINIEAST CACIMBO.GGY.UGA.EDU When either of these DATALOC commands are run, a gethostbyip id done to lookup the IP address from the name and the result is restored in ~mcidas/data/ADDESITE.TXT. >I would be happy to let you look. I'm not sure we have the sat data >configured correctly or not, but you can look. Our departmental techs >are working on the getting the client systems back up now, so I have no >remote system to try the ADDE access. As I said above, I logged on and started poking around. What I see tells me that by-and-large things are setup correctly, and since fixing the IP address for cacimbo in ~mcidas/workdata/ADDESITE.TXT, the access to datasets is working. I do have questions about a couple of things: - right now, you have a dataset named RTNIDS setup that points at the NEXRAD Level III images that comprise the RTNEXRAD dataset: /data/nexrad/NIDS/<station ID>/<product type> Since the setup of the dataset uses the descriptors as "replaceables": DIRMASK=/data/nexrad/NIDS/\ID/\TYPE/ FILEMASK=/\TYPE_* and since the product types do not match the dataset descriptors: RTNIDS/BREF1 ID=FTG != DIRMASK=/data/nexrad/NIDS/FTG/N0R/... I suggest deleting the RTNIDS dataset definitions. This will tidy things up a bit and should reduce confusion in the future. In fact, I just deleted this definition (it can be restored if necessary). - the configuration file specfied for use with the RTNEXRAD dataset is NNEXRAD.CFG (this definition is in ~mcidas/workdata/RESOLV.SRV). Since this is the name of the default configuration file included in the McIDAS distributions, I recommend changing it to UGANEXR.CFG. This appears to be the way things were setup previously since the file ~mcidas/workdata/UGANEXR.CFG exists and contains the same definitions listed in NNEXRAD.CFG. I made the change in RESOLV.SRV and LSSERVE.BAT before getting your go ahead since it was easy to do and won't break anything. - you have a RTGINI dataset defined, but it only includes GOES-East images. I figure that htis is a holdover from when you only were getting images from GOES-East from your NOAAPORT box. I recommend removing the RTINI dataset definitions from ~mcidas/workdata/RESOLV.SRV since all the data is accessbile from the datasets GINICOMP, GINIEAST, and GINIWEST. >One other problem I have seen is that some files (like GRID6*) are >being dumped to my ~mcidas/workdata directory instead of my designated >data directory (/data/mcidasd). I did a redirect.k LIST and the GRID6* >entry wasn't there, so I checked my ~mcidas/data/LOCAL.NAM file (has >the entry) and did a redirect.k REST LOCAL.NAM. A redirect.k LIST >shows the entry still isn't there. Obviously, there is another step I'm >missing. What needed to be added was: REDIRECT ADD GRID6 "/data/mcidasd REDIRECT ADD MDXX010* "/data/mcidasd REDIRECT ADD MDXX0110 "/data/mcidasd REDIRECT ADD MDXX011* "/data/mcidasd REDIRECT ADD MDXX0120 "/data/mcidasd REDIRECT ADD ETAMOS.RA* "/data/mcidasd REDIRECT ADD GFSMOS.RA* "/data/mcidasd I ran these REDIRECT commands to setup the REDIRECTions, but the LDM will need to be stopped and restarted to make sure that the new definitions are used in creating new files. As a review, I did the following: 1) fixed the name/IP problem in ~mcidas/data/ADDESITE.TXT 2) updated the dataset definitions in RESOLV.SRV (the file that is actually used by the ADDE server) and LSSERVE.BAT 3) created a local GINI ADDE configuration BATCH file, UGAGINI.BAT (in ~mcidas/workdata) 4) tidied up the locations of files in the NEXRCOMP dataset (not mentioned above) >If you'd like me to send you a password, I can. I have it from before, but I don't have a correct password for 'ldm'. On the LDM side: - I see that the pattern in ~ldm/etc/pqact.conf for procesing 1 km floater NEXRAD composites is incorrect. Here is what you have now: # # NEXRCOMP 1 km Regional BREF mosaic FNEXRAD ^pnga2area Q5 (RM) (.*) (.*) (.*) (.*) (........) (....) PIPE -close decoders/bin/pnga2area /data/nexrad/NEXRCOMP/1km/\4/\4_\6_\7 -l logs/ldm-mcidas.log This should be: # # NEXRCOMP 1 km Regional BREF mosaic FNEXRAD ^pnga2area Q5 (RO) (.*) (.*) (.*) (.*) (........) (....) PIPE -close decoders/bin/pnga2area -l logs/ldm-mcidas.log /data/nexrad/NEXRCOMP/1km/\4/\4_\6_\7 The differences are 'RO' instead of 'RM', and put the '-l logs/ldm-mcidas.log' flag before the file name specification - in all FNEXRAD pnga2area actions, you have the specification of the log file after the specification of the output data file: # # NEXRCOMP 6 km National BREF mosaic FNEXRAD ^pnga2area Q5 (RL) (.*) (.*) (.*) (.*) (........) (....) PIPE -close decoders/bin/pnga2area /data/nexrad/NEXRCOMP/6km/\4/\4_\6_\7 -l logs/ldm-mcidas.log The log file specification should come before the file name specification: # # NEXRCOMP 6 km National BREF mosaic FNEXRAD ^pnga2area Q5 (RL) (.*) (.*) (.*) (.*) (........) (....) PIPE -close decoders/bin/pnga2area -l logs/ldm-mcidas.log /data/nexrad/NEXRCOMP/6km/\4/\4_\6_\7 I would have made these changes for you, but the login I have for 'ldm' doesn't work. I will be more than happy to tune up your pqact.conf file if you give me the 'ldm' password. Send it to my personal email address, address@hidden, with no mention of the machine or account name to which it applies. >I appreciate your help. No worries. The problems just seem to be multiplying this week! I _know_ what you mean! Tom