20010921: McIDAS-X 7.80 installation problem

>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[4521]: Starting Up 
>Sep 21 21:17:07 pnga2area[4521]: output file pathname: 
>/var/data/mcidas/AREA017 5 
>Sep 21 21:17:08 pnga2area[4521]: unPNG::  157454 613456 3.8961 
>Sep 21 21:17:08 pnga2area[4521]: 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