>From: Greg McCurdy <address@hidden> >Organization: University of Nevada/DRI >Keywords: 200109212138.f8LLcW102610 McIDAS-X ADDE Greg, >I'm having a small problem getting the new mcidas version to run. Our >old version was lost during a disk crash so I'm going through a new >installation and not an upgrade. Our previous version didn't have the >adde running. Also our mcidas machine is behind a firewall, so I'm not >trying to access other sites. Even if you have no intention of accessing machines on the other side of your firewall, I believe that it is always best to have the remote ADDE server setup. The reason: if everyone's session points to the remote server on a single machine, they will not have to setup definition of ADDE datasets in their own account. The only ADDE setup that has to be done is in the 'mcidas' account on the machine running the ADDE server. This makes the end user's life _much_ easier. > The build and installation seemed to go with out problem (Sun Ultra I, >solaris 2.6). Presumably, you were using the Sun SC4.x, SC5.x or WS6 compilers? >The ldm ingestion process seems to go fine. Here's the >output of one product. > >Sep 21 21:17:07 pnga2area: Starting Up >Sep 21 21:17:07 pnga2area: output file pathname: >/var/data/mcidas/AREA017 5 >Sep 21 21:17:08 pnga2area: unPNG:: 157454 613456 3.8961 >Sep 21 21:17:08 pnga2area: Exiting This says that the ldm-mcidas decoder is correctly decoding Unidata-Wisconsin images, a good first step. >however when I start a mcidas session and run DSINFO (or several other >commands) I get something similiar to the following. > >stdin: not in compressed format > No Datasets found of Type : ..... in Group: ..... > >(... are all types and groups) What is the DATALOCation for those groups? To check this, run: DATALOC LIST >and > >DSINFO: Data service module problem, RC= -1 >DSINFO: Local interface module cannot be found > No Datasets found of Type: .... in Group: .... This is typically seen when 'compress' can not be found on the server that is being contacted by the DSINFO command. The question again is where were you pointing when you ran the DSINFO command? >ROUTE seems to list the proper AREA set and even shows that the products >are being updated. ROUTE will show that the files are being ingested. ROUTE is a non-ADDE command. Commands like DSINFO are ADDE in nature, so they will need ADDE dataset information defined. (Actually, DSINFO doesn't need this, but things like IMGDISP, IMGLIST, SFCPLOT, etc. do). >Any suggestions? I've double checked the >configurations for mcidas and mcadde and also tried the only test that I >found in the support archives (undefining MCCOMPRESS), but the same >results follow. The 'mcadde' account won't come into play at all if you are not going through the remote ADDE server (do the DATALOC to ascertain this). What could be happening if all data access is LOCAL-DATA and the datasets are defined is that 'compress' or 'uncompress' are not being found (or won't run). When you say that you undefined MCCOMPRESS and the problem still exists, did you exit and restart your McIDAS session from the Unix session in which you undefined MCCOMPRESS? If not, your session is still telling the ADDE server to do things in compressed mode. 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.