>From: "Fingerhut, William A" <address@hidden> >Organization: Lyndon State >Keywords: 200208191756.g7JHuBK26547 McIDAS-XCD Linux Bill, This is the email that I was in the midst of sending you yesterday when you called. I am finishing it so that the information in our inquiry tracking system is complete. Sufficit to say that MD file decoding proceeded on your new RedHat 7.3 Linux box as the clock rolled past 0Z. This was the kind of behavior we have both seen on systems running McIDAS-XCD. As a review, what we did was: 1) consolidated XCD and ldm-mcidas created data files into a single directory, /var/data/ldm/mcidas/xcd 2) corrected a bug in xcd_run. The bug was the deleting of the log file right after redirecting all output (stdout and stderr) to the file. This bug seems to reek havoc on Linux systems, but not others 3) correct a typo in ~ldm/etc/pqact.conf. The typo was the spaces after DDPLUS|IDS and PIPE in the action that pipes textual products to xcd_run specifying the DDS flag: DDPLUS|IDS ^.* PIPE xcd_run DDS As I finish this note, I have to say that things seem to be working more-or-less correctly. The one thing that I do not understand, however, is that the permissions on the files being created by XCD decoders were -rw-r--r--. The umask set for both 'ldm' and 'mcidas' is 002, so files should be created with -rw-rw-r-- permissions. The only thing I can think of that would cause this to happen is in how the LDM was started/restarted yesterday. When you had a login as 'ldm', how did you do the login? What I am driving at is if you did: su ldm then the umask that would have been in place in your session would have been the one that was in place in the login from which you did the 'su ldm'. If you have occasion to become 'ldm' to do work, you should always login, or become 'ldm' with: su - ldm The '-' says to inherit and use all of the environment setup for 'ldm'. A 'su ldm' does not. The remainder of this email is what I was writing yesterday. >Since classes start in two weeks, I really don't want to move >to the latest version, 2002. I have a lot of scripts and just >don't need that now. I would venture to say -- without an intimate knowledge of your scripts -- that the work you have put into getting them to work with v7.8 would translate directly to v2002. >We were behind schedule before the hack, >so now things are really rushed. I understand. I would love to see you using a current release, however, since the amount of effort I put into bug fixes for a previous release is minimal. >I can see consolidating the data in one directory. I don't >believe any scripts have "hard wired" directories; they all >rely on file redirection. I will try this. > >The directories, xdata and xcd, are nsf mounted by each >workstation in the lab. ADDE obsoletes this, but we are not >100% ADDE -- just mostly. OK, I understand. >Labstuff contains primarily our menu scripts, and other >'enhancements' used locally. LWPATH.NAM is a backup in case >someon loose theirs, and needs a quik fix. OK. I just get nervous when I see copies of LWPATH.NAM in directories other than the user's McIDAS working directory. The potential for screwing up and using the wrong one is just too great. >Should I consolidate xdata and xcd? I think so, yes. This will make XCD and ldm-mcidas installation/configuration easier. It should help eliminate the type of problem you are facing now and before. The easiest way to combine the directories is to move all files from one to the other; delete the now empty directory; and then make a soft link to the existing directory using the deleted directory name: cd /var/data/ldm/mcidas mv xdata/* xcd cd xdata rm * cd .. rmdir xdata ln -s xcd xdata 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.