>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
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.