20040521: McIDAS data access problem

>From: "Thomas L. Mote" <address@hidden>
>Organization: UGa
>Keywords: 200405211813.i4LIDotK018278 McIDAS install

Hi Tom,

>You knew when I started asking about the McIDAS support archive
>that you would har from me eventually!

I had a sneaking suspicion that this would be the case :-)

>The good news is that we have received funds to update all of
>our lab systems. The bad news is that our tech staff wanted us
>to use Fedore Core 1 for Linux, which meant rebuilding McIDAS
>on the client systems.

We are using Fedora Core 1 Linux on multiple machines here at the
UPC.  We did run into some problems with NFS mounting when
using SMP kernels, but that problem appears to have gone away with
the latest kernel 2.4.22-1.2188.nptlsmp.

>The build went fine. I tried, this time, to follow the installation 
>instructions as close as possible. I just built mcx, and the tests on
>the install were fine.  I was working on configuring the mcidas account.

OK.

>I stole
>the LOCAL.NAM,

>LSSERVE.BAT (do I even need this for a client install?)

No, not really.  I strongly recommend that client machines access all
data from a remote ADDE server(s) even if the remote server is running
on the same machine.  This makes configuring user accounts so much
easier: all a user has to do is "point" at a server (DATALOC ADD ...)
that allows access, and they have ready access to data.

>and LOCDATA.BAT from cacimbo. The REDIRECT REST
>and MAKE were fine. A REDIRECT LIST now shows all of the data
>in the proper directory, which I confirmed I could read. DMAP AREA
>looks fine and shows all my area files on cacimbo.

If the machine you are working on is not the machine running the ADDE
remote server, or if the machine is the one running the ADDE remote
server and you are configuring an account that is _not_ 'mcidas', then
you really shouldn't have to setup file REDIRECTions at all.  You will,
however, setup "pointers" to datasets, and this is what LOCDATA.BAT is
used for.

>Now, should I run the BATCH LSSERVE.BAT on a client system?

I wouldn't, no.

>I went ahead and did it, because it seemed like I should. The RESOLV.SRV
>file appears where it should. I then ran the BATCH LOCDATA.BAT
>and ADDESITE.TXT appears where it should.

Yes, but you don't need to if the data is accessible through a remote
ADDE server in a different account on the same machine or on a
different machine.  From what I can understand, cacimbo runs your ADDE
remote server, and you are setting up new, client machines.  If yes,
then the process of getting the account ready to use McIDAS is as
simple as:

1) build and install McIDAS in the 'mcidas' account on the machine

2) define McIDAS environment variables used in the account

   Example:

   User is 'mcidas'
   <set in .chsrc (for C-Shell users)>
   source ~mcidas/admin/mcidas_env.csh

   <set in .bash_profile for Bash users>
   . ~mcidas/admin/mcidas_env.sh


   User is NOT 'mcidas'
   <set in .chsrc (for C-Shell users)>
   source ~mcidas/admin/user_env.csh

   <set in .bash_profile for Bash users>
   . ~mcidas/admin/user_env.sh

   Make sure that the settings are active before proceeding to step 3)

3) setup LOCDATA.BAT in ~mcidas/data to point at specific servers
   by dataset group name

   <as 'mcidas'>
   cd ~mcidas/data
   cp DATALOC.BAT LOCATA.BAT
   <edit LOCDATA.BAT and set ADDE server name for each dataset

4) setup the local MYDATA dataset
   
   User is 'mcidas'
   cd ~/workdata
   batch.k MYDATA.BAT

   User is NOT 'mcidas'
   cd ~/mcidas/data
   batch.k MYDATA.BAT

>OK, I fired up mcidas and tried to access some data using the GUI.

GUI or MCGUI?  There is an important difference.

>I simply get these "Error: Can't read" type errors, then it hangs.

OK sounds like you are using the MCGUI.

>If I try
>to change my client routing from any ADDE server to LOCAL-DATA
>(my data drive is NFS mounted), the data location shows LOCAL,

I think that this is a bug.  It should read LOCAL-DATA.

>but I still can't get any data files. (It's interesting, if I change to 
>another ADDE site, then exit mcidas and restart, the change was saved. If I
>try changing to local, exit mcidas, and restart, the change isn't saved.
>I don't know if that's a helpful clue or not.)

The bug is that the dataset should read LOCAL-DATA, not LOCAL.

>I thought I had asked about a problem like this in the past, so I searched
>my own name on the archives (scary!). I found a lot of correspondence,
>but no similar problem.

I am betting that the problem is that your Unix session has MCCOMPRESS
set (to ask for compressed data transfers), but 'compress' and
'uncompress' can't be found.  Please make sure that you have installed
compress/uncompress on the machine.  If you find that
compress/uncompress were not installed with the OS, you can run McIDAS
and specify that it should not use compressed data transfers:

mcidas -config

<select NONE for compression in the appropriate radiobutton>

Start the session and then try your display again.  If it works, it is
proof that the problem is compress/uncompress are not being found.

The other thing you can do is exercise the system from the command line:

<example for 'mcidas'>

cd ~/workdata
mcenv
dataloc.k LIST
dsinfo.k IMAGE RTIMAGES              <- what happens here?
<etc.>
exit

>Once we get this set up, we will simply "ghost" the partitions to other
>identical systems.

Sounds good.

>Thanks for any suggestions you might have.

I am betting on the lack of compress.  You will be pleased to learn
that McIDAS is moving to use of gzip/gunzip and both of these are built
when McIDAS-X (mcx option) is built.  The most recent startup GUI has a
radiobutton for GZIP compressed transfers, but this will only work for
you if the server(s) you are going to are setup to support GZIP
compressed transfers.

Please let me know if the above was not clear enough or you have
some other problem.

Cheers,

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.

>From address@hidden  Fri May 21 13:47:40 2004

Tom,

Bingo! Added ncompress from the fedora site and
that took care of the problem, at least in the
McIDAS account. I have yet to set up the user
account, but I think I'll be fine. I do think
you had mentioned this to me, but it has been
some time.

It might be helpful on the "configuring accounts"
web page to make the distinction between server
and client systems (i.e., regarding LSSERVE.BAT). 
It wasn't obvious to me, but, then again, maybe 
I'm not that representative of users.

Thanks again...

Tom