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

20040225: graphics gone missing in McIDAS session

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20040225: graphics gone missing in McIDAS session
  • Date: Wed, 25 Feb 2004 14:52:23 -0700
>From: "Alliss, Randall J." <address@hidden>
>Organization: Northrop Grumman
>Keywords: 200402252120.i1PLK0rV026848 McIDAS FrameN.M

Randy,

> i have been running mcidas, without incident, on a linux box for the last
>few weeks. 
>Something has happened. No matter what account i use on this machine the
>graphics for frames 9-19 are gone therefore anything i load in the frames is
>not visible (imagery or maps etc). my .mcidasrc file has -f  64. Frames 1-8
>and 20-64 are ok.
> 
>any clues?

This sounds like the FrameN.M (e.g., Frame9.0, etc.) files have been
created in a directory in your MCPATH by someone other than yourself so
you don't have write permission to them.  I see this happen most often
for C-shell users when the McIDAS environment variable definitions for
the user 'mcidas' are not correct/complete.  To check my guess, run the
following command in your McIDAS session that is having the problem:

DMAP Frame

If you see FrameN.M files that are NOT in a temporary directory that is
at the end of your MCPATH, and you do not have write permission for
them, you will have found the problem.  The solution is to become
whoever owns the errantly placed FrameN.M files and remove them.  Then,
correct the environment variable settings for that user so the
situation does not reoccur.

If this is not the problem, we will need more information about the
environment on your machine when you see the problems.  One thing to
look for would be logs of old subdirectories of your ~/.mctmp
directory.  Associated with these might be interprocess communication
segments that have not been released back to the OS.  You can use the
'ipcrm' command in Unix to remove the offending, old segments, and use
rm to remove the directories under .mctmp.

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.

>From address@hidden  Wed Feb 25 14:48:23 2004

Randy -

This is a long shot, but try running these two McIDAS commands:

DMAP Frame
  (should list one for every frame)
DMAP *.001
  (should at least be FRAMENH.001 and TERMCHAR.001)

The files listed should all be located in the .mctmp directory created 
at the start of the McIDAS session.

- Becky