>From: "Craddock, Mary Ellen" <address@hidden> >Organization: Northrop Grumman >>Keywords: 200304211441.h3LEf47U008241 McIDAS-X v2002b Compaq OSF/1 4.0F Hi Mary Ellen, >We are running from the McIDAS session, not the command line. >The user is "mel", not "mcidas". OK, good. >The result from the command DMAP LWPATH.NAM is: >"-rw- 307 Apr 18 17:11 LWPATH.NAM /usr/users/mel/mcidas/data/. >The result from the command "!pwd" is: "/usr/users/mel/mcidas/data". OK, this is all correct. >Based on the >email, it looks like everything is set up correctly. Yes, everything looks correct. Please do the following and send back the results: DMAP Frame DMAP *.001 What I am looking for is anything out of the oridinary. If things are setup correctly -- and they appear to be --, and if there has been no "strangeness" on your system -- this is what I am looking for -- then files that begin with Frame and end with .001 should be found in a subdirectory of /usr/users/mel/.mctmp. Sometimes when McIDAS messes up (typically from the environment not being quite correct), you may find FrameN.M files in the ~mcidas/help directory and *.001 files in the ~/mcidas/data directory. In this case, the file(s) need to be deleted so that things will run correctly. Also, can you send me back the results of: % env I want to see how the McIDAS environment variables MCDATA, MCPATH, MCTABLE_READ, MCTABLE_WRITE are setup for 'mel'. >Let me walk you through an example of what I am see happen in >steps...maybe you'll see something we don't. > >1.) Rename LWPATH.NAM to LWPATH.NAM.ORIG >2.) Touch LWPATH.NAM (size is 0bytes, no entries) OK, you did not have to create the file first _IF_ there are no other files named LWPATH.NAM in any directory in the user's MCPATH. >3.) Launch a McIDAS session. >4.) REDIRECT ADD AREA4* "/d2/peru/Satellite/apr2003 >5.) REDIRECT LIST > result: "Number of active redirection entries = 0" OK, this demonstrates what you have been telling me about. The file LWPATH.NAM (located in /usr/users/mel/mcidas/data) should get updated by the REDIRECT ADD invocation above. The fact that is not being updated verifies that there is a problem. >6.) more LWPATH.NAM > result: one blank line. Size of file is 34bytes. Hmm... One blank line!? This is most likely telling us what we need to know. >7.) REDIRECT ADD AREA6* "/d2/peru/Satellite/apr2003 >8.) REDIRECT LIST > result: "AREA6* /d2/peru/Satellite/apr2003" Weird! So, the second REDIRECT ADD _did_ cause an update to LWPATH.NAM. >9.) more LWPATH.NAM > result: overwrites the blank line with "AREA6* > /d2/peru/Satellite/apr2003/". Size of file=69bytes >10.) REDIRECT ADD AREA8* "/d2/peru/Satellite/apr2003 >11.) REDIRECT LIST > result: "AREA8*" (no path) Wow. OK, big problem!! >12.) more LWPATH.NAM > result: contains one line. overwrites AREA6* line with "AREA8* >/d2/peru/Satellite/apr2003". Size of file=103bytes >13.) REDIRECT ADD MDXX01* "/d1/RawSfc/apr2003 >14.) REDIRECT LIST > result: "Number of active redirection entries = 0" >15.) more LWPATH.NAM > result: contains one line. Overwrites AREA8* with "MDXX01* >/d1/RawSfc/apr2003". Size of file=108bytes Got it, you definitely do have a problem. Unfortunately, I can't replicate this problem here since we no longer have an OSF/1 4.0x machine in-house. I don't suppose that this box is accessible from the internet? I am guessing the answer is no. >Your email indicated that indeed the LWPATH.NAM does get overwritten each >time as it alphabetizes the entries but our version seems like it is not >able to keep the entries in memory to write them back to the file. Exactly. What would happen if you created an ASCII file with the REDIRECTions you want in it and then use 'REDIRECT REST fname' to restore the REDIRECTions to the session? The file I have in mind would look like: TEST.NAM:: AREA4* /d2/peru/Satellite/apr2003 AREA6* /d2/peru/Satellite/apr2003 MDXX01* /d1/RawSfc/apr2003 REDIRECT REST TEST.NAM Also, what happens if you edit the file LWPATH.NAM, add the entries like the ones in TEST.NAM (note that there are no quote marks!), and then ran: REDIRECT LIST or DMAP AREA4 >Thanks for the help. If I can't get on an OSF/1 4.0x machine to find out what may be wrong, then the only thing I can think of is a way to get around the problem. 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.