>From: Erick Lorenz <address@hidden> >Organization: UC Davis >Keywords: 200009220039.e8M0dBb07890 McIDAS-X 7.60 Linux Erick, re: multiple announcements >I remember those announcements but they didn't sink in that they applied to >the AREA files. I think I was hoping that since I was getting the latest >version that all this would be in place. >>redirect.k ADD ROUTE.SYS \"/var/data/mcidas >>batch.k CIMSS.BAT > >I had to do a ROUTE INIT first before this worked. I had assumed tht since you were attempting to use lwtoa3 that you had already put a copy of a viable ROUTE.SYS into the target directory, /var/data/mcidas in your case. The addition of the CIMSS products to the routing table would then be an extra. The fact that you did not have to do a ROUTE INIT tells me one of two things: o your REDIRECTion to the copy of ROUTE.SYS in the output data directory did not exist o you had a valid REDIRECTion, but no routing table >Anyway as soon as I did all this, AREA0000 popped up in /var/data/mcidas >before I could do an ls on that directory so I think everything is fine. Unfortunately, everything is not fine. A file named AREA0000 indicates a problem. The reason? AREA0000 is an invalid AREA file name. What you should do is: <as 'ldm'> ldmadmin stop <as 'mcidas' make sure that the LDM is not running when you do this> cd workdata cp ROUTE.SYS /var/data/mcidas redirect.k ADD ROUTE.SYS \"/var/data/mcidas batch.k CIMSS.BAT <as 'ldm'> ldmadmin start >Perhaps I should wait to celebrate but I think this a record for the fewest >number of "HELP!"s on an installation for me. You are pretty close, but not out of the woods yet. >I am now going to set up some user accounts that have home directories on >ATM20, the server, even though the users will be logging in from other >Linux stations. I want their home directories to be on the server because >it is the only host that will be running Linux all the time and besides the >users will not always be able to get to the same station. > >What I am now wondering is whether it is best to copy the mcidas manager >directory to each client host so that the user is running mcidas off of >local binaries or whether it would work to export the mcidas manager from >ATM20 to all the clients. The simplest setup is for each machine to NFS mount the file system where McIDAS-X is installed. Then each user's account should include ~mcidas/bin (e.g. /home/mcidas/bin or where ever the McIDAS binaries are located) in his/her PATH. Also, each user will need to have McIDAS environment variables defined for his/her session. This is done in .cshrc (C shell users; .profile for Bourne/Korn shell users). What has to be defined is described in detail in: Configuring Unidata McIDAS-X Accounts http://www.unidata.ucar.edu/packages/mcidas/mcx/config_mcx.html >1. ATM20 (server) > /home/mcidas (for use on 20 only) > /home/users/mcidas-user1 > /home/users/mcidas-user2 > ATM51 (client) > /usr/local/mcidas (for use by ATM51) > /home -> ATM20:/home (nfs mount) > /mcidas-user1 -> atm20:/home/users/mcidas-user1 > /mcidas-user2 -> atm20:/home/users/mcidas-user2 > ATM52 (client) > /usr/local/mcidas (for use by ATM52) > /home -> ATM20:/home (nfs mount) > /mcidas-user1 -> atm20:/home/users/mcidas-user1 > /mcidas-user2 -> atm20:/home/users/mcidas-user2 > >2. ATM20 (server) > /home/mcidas (for use by all machines) > /mcidas-user1 -> atm20:/home/users/mcidas-user1 > /mcidas-user2 -> atm20:/home/users/mcidas-user2 > ATM51 (client) > /home -> ATM20:/home (nfs mount) (sees /home/mcidas) > /mcidas-user1 -> atm20:/home/users/mcidas-user1 > /mcidas-user2 -> atm20:/home/users/mcidas-user2 > ATM52 (client) > /home -> ATM20:/home (nfs mount) (sees /home/mcidas) > /mcidas-user1 -> atm20:/home/users/mcidas-user1 > /mcidas-user2 -> atm20:/home/users/mcidas-user2 > >My guess is that option 2 might have poorer performance even though users >are running mcidas with their own CPUs just because the load times are >dependent on network traffic but it would also be much easier to maintain. > >If (2) is possible is the trade-off worth it? Performance of NFS on Linux is known to be _not so good_ (but improving with time), so it might be better to replicate the existence of the ~mcidas directory strucuture on each machine. I want to add, however, that if there will be simultaneous McIDAS-X sessions run from different machines by the same user, then you will run into problems with the sessions stepping on each other. From your listing I think I am seeing that you want to have 4 accounts setup for McIDAS-X use. Is this correct? Are you planning on having more that 4 McIDAS-X sessions active at the same time? Is your planned setup based on having a few user accounts that are accessible by a large number of sessions (again, having multiple McIDAS-X sessions running out of the same account from multiple machines)? McIDAS works best (has the least number of potential gotchas) if each McIDAS-X user runs his/her McIDAS-X session from their own account. The overhead for doing this is small. Each user simply needs to have his/her own mcidas/data subdirectory. The McIDAS-X binaries are shared from ~mcidas/bin; the ancillary data files are shared from ~mcidas/data (ancillary data files are things like map outline files, enhancements, stretch tables, etc.); and data from /var/data/mcidas (your system setup from above). As soon as you try to run simultaneous McIDAS-X sessions from a single account but on different machines you _will_ run into problems unless you know exactly what you are doing (and students never really know what they are doing). If you give me a better idea of exactly what you are trying to accomplish, I can help you layout a setup that should work nicely. 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.