Hi Trung, re: > Below is the outputs from running the commands you recommended. > > MAP SAT > MAP: NO IMAGE OR NO NAVIGATION FOR FRAME OK. This shows that the image never got loaded into the frame or that the navigation information did/could not be written to the disk-based backing store for the frame. > DMAP Frame > > PERM SIZE LAST CHANGED FILENAME > DIRECTORY > ---- --------- ------------ --------- --------- > -rw- 2816 Sep 21 13:55 Frame1.0 /home/dpi/.mctmp/249921538 > -rw- 2816 Sep 21 13:55 Frame10.0 /home/dpi/.mctmp/249921538 > -rw- 2816 Sep 21 13:55 Frame2.0 /home/dpi/.mctmp/249921538 > -rw- 2816 Sep 21 13:55 Frame3.0 /home/dpi/.mctmp/249921538 > -rw- 2816 Sep 21 13:55 Frame4.0 /home/dpi/.mctmp/249921538 > -rw- 2816 Sep 21 13:55 Frame5.0 /home/dpi/.mctmp/249921538 > -rw- 2816 Sep 21 13:55 Frame6.0 /home/dpi/.mctmp/249921538 > -rw- 2816 Sep 21 13:55 Frame7.0 /home/dpi/.mctmp/249921538 > -rw- 2816 Sep 21 13:55 Frame8.0 /home/dpi/.mctmp/249921538 > -rw- 2816 Sep 21 13:55 Frame9.0 /home/dpi/.mctmp/249921538 > 28160 bytes in 10 files This looks good. McIDAS creates directories under ~/.mctmp with a name that is the same as the shared memory handle for the session. What I was looking for was Frame1.0 being in a directory like /home/mcidas/data or /home/mcidas/help. Since your DMAP invocation does not show this, you are likely not experiencing the problem that I was thinking about. > echo $MCPATH > /home/dpi/mcidas/data:/home/dpi/mcidas/help:/home/mcidas/data:/home/mcidas/help This looks exactly like what I would want except for the '/home/dpi/mcidas/help' directory. Do you create your own HELP files for locally developed McIDAS routines? If yes, are they stored in /home/dpi/mcidas/help? Just curious... > I could see Frame1.0 no different from others. But Look like the > Framen.m files ended up in the wrong directory, do they? No, they are where they should be. > If so, where are they supposed to be in? They are where they should be. > Should I delete the whole directory '249921538' ? Absolutely no! This directory and all of its contents should be removed when you EXIT your McIDAS session. > I checked out the directory .mctmp from other user accounts, they were all > empty. That is the correct state when the other accounts are not running a McIDAS session. So, what to try next??? Can you make one or two of the images available that you are unable to display? Putting them on an FTP site that I can get access to would probably be best. Also, please send me the output from 'env' run just before you start a McIDAS session in which the IMGDISPs fail. And, as soon as you start a McIDAS session in which the IMGDISPs fail, please send me the output of '!env' run from the McIDAS Text and Command window. Also, can you confirm (or refute) that you are unable to display the image(s) when referenced from one dataset, but that you are able to display them when referenced from another dataset? Your situation is strange enough that I am having a hard time visualizing what could be happening. Would it be possible for me to temporiarily get access to your account so I could do some more in-depth investigation? Cheers, Tom **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: QNX-338397 Department: Support McIDAS Priority: Normal Status: Closed
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.