[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20040809: McIDAS trouble after replacing defective disk (cont.)



>From: Gilbert Sebenste <address@hidden>
>Organization: NIU
>Keywords: 200408052220.i75MKIaW005874 McIDAS LDM mcscour.sh

Gilbert,

re: what is not working in the graphical startup

>The "-e 12m" won't go away, even if you set it back to "0".

OK.  I will look into this.

>So, I:
>
>Deleted .mcidasrc in /home/mcidas
>Did a mcidas -config
>Set everything the way I wanted it
>
>Now, the settings have been saved correctly.

Hmm...

re: the NASA imagery has stopped working

>I wonder if this upgrade made the ADDE transfer from their server 
>impossible; they may be running and old version of McIDAS.

After poking around some, I am left with the impression that this may
be the case.  In v2004, the length of the group portion of an ADDE
dataset name is limited to 8 characters (the documentation says that it
was in v2003 as well).  Your DATALOC setting for the NASA machine is:

weather-niu Mci-37> dataloc.k ADD NASAIMAG GEO.MSFC.NASA.GOV

Group Name                    Server IP Address
--------------------         ----------------------------------------
NASAIMAGERY                  GEO.MSFC.NASA.GOV

The group name nere is 11 characters long, 3 more than the maximum.

I am wondering if low level code is now preventing the request from
even going to the NASA machine.  The reason I say this is that the
failure to find NASAIMAGERY is _way_ too quick to actually be going
out to the NASA machine.  To convince yourself of this, try the
following:

<as 'mcidas' on weather>
cd workdata
dsinfo.k IMAGE NASAIMAGERY

Notice how fast the dsinfo.k invocation returns with:

weather-niu Mci-39> dsinfo.k I NASAIMAGERY
    No Datasets found of Type: IMAGE in Group: NASAIMAGERY
DSINFO -- done

Another thought: when was the last time you accessed the NASA machine?
Perhaps they have changed something on their side!?

The main reason I suggest this is that I am unable to get data listings
from their ADDE server from machines still running v2003.  This could,
of course be due to security measures they have taken on their side.

NOTE for archive: I tried accessing the NASA machine using Gilbert's
v2003 executables by changing PATH to use /home/mcidas/mcidas2003/src
instead of /home/mcidas/bin.  There was no change after doing this.
I also tried all three types of data transfer:

MCCOMPRESS=NONE       <- no compression
MCCOMPRESS=COMPRESS   <- 'compress' compression
MCCOMPRESS=GZIP       <- 'gzip' compression

All three worked when going to adde.ucar.edu; none worked going
to the NASA machine.

Did you have to provide a machine name/IP in order to get access
to their server?

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.


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.