[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19990512: update on question about .mctmp files produced by ldm

>From: weather <address@hidden>
>Organization: NMSU/NSBF
>Keywords: 199905121648.KAA15213 McIDAS redirect.k


>It appears that correcting the redirect for the topo files
>fixed the problem here on wxmcidas.  The .mctmp directories are
>produced as the processes are running but then are cleaned up later.

This is good to know.  It would be good for the support archive to be
able to list what the bad REDIRECTion was and what it should have been.

>I discovered that the redirect was incorrect on psnldm as well.
>I have not been able to change it though.  From a telnet
>session I try:
>/export/home/mcidas% redirect.k DELETE AREA901*
>redirect.k: No match.

This is most likely due to there being a REDIRECTion for LWPATH.NAM as '.'
(current working directory).  If this is the case, you should:

cd workdata
redirect.k DELETE AREA901*

The 'cd' will put you in the correct directory so that the correct copy
of LWPATH.NAM will be updated.

>So I can't change it..

Try the 'cd'.

>AREA901* is there, it is pointed at /home/mcidas/data
>instead of /export/home/mcidas/data.  Do I have to attach to a running
>McIDAS session, if so I can't remember how to do that?

What you were doing was fine, but a REDIRECTion for LWPATH.NAM (the
disk image of your REDIRECTions) would have prevented the "operational"
copy of LWPATH.NAM from being updated.

>I have been unable to establish a remote X-window login to psnldm.
>It gets to the Solaris CDE screen and then goes no further, so I
>can't run a McIDAS session from here.

I think you will find that the 'cd' will get you going nicely.


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.