>From: Jim Heimbach <address@hidden> >Organization: UNCA >Keywords: 199909141652.KAA04088 McIDAS Jim, > O.K., now McIDAS-X is running at about 95% on my LINUX box (I never >seem to get 100%). Remember, the Linux boxes are going to be clients of data, not producers. It will not need XCD installed or configured. It will also not need the remote ADDE server installed or configured. >Now my task is to get a user account running and >I find that it is not merely a task of cloning what I did on my ULTRA-2. >So some questions: > > First LWPATH.NAM. For the user account, I should rely on >/home/mcidas/data/LOCAL.NAM which was made by editing a copy of >/home/mcidas/data/EXAMPLE.NAM. Right? Right. I assume that the account is on the same machine so that the directories in LOCAL.NAM are correct. >Then in the mcidas command line >opened in the user account, I should do, > REDIRECT REST LOCAL.NAM > REDIRECT MAKE Right. >and that gets all the redirections set up in the user's mcidas run. Yes. It should create the file LWPATH.NAM in the user's MCDATA directory. This should be ~user/mcidas/data/LWPATH.NAM. >The way I read the on-line instructions is that this should also >create a LWPATH.NAM for the user, but I cannot find this anywhere. Did you first create the mcidas and mcidas/data subdirectories for the user? If not, the LWPATH.NAM would have been written into the first writable directory in the user's MCPATH. If the MCDATA directory didn't exist and none of the other directories in MCPATH were writable by the user, then the file would not be created and you would not find it. I am betting that the user needs a mcidas/data directory created. >Subsequent startings of mcidas by user comes up with the redirections, >but I guess my paths have the mcidas LWPATH.NAM being read. Need >I worry? > > Then there is .mcenv. Should the user have its own copy? No. > And XCDDATA: I did the following in a mcidas session in the user >account as suggested in a support message: > TE XCDDATA This didn't define it to anything. This needs to be: TE XCDDATA "xcd_output_data_directory IF you are setting things up for XCD (in the 'mcidas' account) and defining ADDE datasets (alson in the 'mcidas' account). > BATCH "XCD.DAT > BATCH "XCDDEC.BAT This only has to be done for machines running the XCD decoders. >What does this do? The first BATCH file sets up some REDIRECTions. The second BATCH execution creates a number of files used by XCD in the XCDDATA directory. This only needs to be done while setting up XCD, and XCD is already setup and running on your ingestion machine. >Is this stored in a configuration file somewhere? See above. >Should I do a setenv for XCDDATA? No, this is a McIDAS string. For the average user, you do not need to define this since it is used only for: o setting up XCD o setting up ADDE datasets; this is done centrally in the McIDAS account >I also did a TL XCDDATA and came up with >a blank. Because you defined it as blank: TE XCDDATA > I'm getting too old for this. I think that the instructions for setting up user accounts was pretty straightforward. It appears that you are somehow combining the instructions for the 'mcidas' account and XCD setup with that for user accounts. You don't need to do this. >Feel free to prowl around on >the LINUX box. My goal is to get McIDAS 7.6 on three other linux >boxes in the lab, one of which is happily running 7.5. The other >two PC's are presently grinding along in OS/2. I'm using Slackware >3.5 = LINUX 2.0.35. I will get on if I can get some time. Today and tomorrow are out since we are involved in User Committee meetings. I fly to Madison, WI on Sunday night and will return on Thursday. Sorry for your problems... Tom >From address@hidden Sat Oct 2 12:08:37 1999 As you suggested, my major problem was being too overzealous in my installation of McIDAS on a LINUX box (included ADDE and XCD). I started pretty much from scratch and things are running fairly well. Some further tweeking ought to get more products available. Thanks -- Jim
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.