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

20040105: McIdas v2003; missing/empty SYSKEY.TAB file

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: 20040105: McIdas v2003; missing/empty SYSKEY.TAB file
  • Date: Mon, 05 Jan 2004 15:16:56 -0700
>From: "Anderson, Alan C. " <address@hidden>
>Organization: St. Cloud State
>Keywords: 200401052043.i05Kh1p2009406 McIDAS-X SYSKEY.TAB

Hi Alan,

>We have encountered a problem here that seems strange.   On at least 2
>terminals, I have found that the  SYSKEY.TAB file is present, but shows  0
>content.  Found this when McIDAS  would not start properly,  giving the error
>message as follows:
>       Error in startup script: systemkey word 1 read failed (-1) while
>       executing
>
>       mcidas syskey$i
>               (procedure "syskeyLoad" line 10)
>       file   /home/mcidas/bin/mcgui.k   line 234
>
>I snooped a bit in the email support archive and found what seemed like
>a related item from UC Davis.
>
>Went to look for SYSKEY.TAB  and found the file listed but empty.
>Copied the current file from waldo,  our ldm ingestor  and now mcidas
>seems to work fine.  Checked on a couple of other terminals and found
>the same thing.

The most likely cause for what you are seeing is:

- you have a REDIRECTion in place for SYSKEY.TAB
- the REDIRECTion points to a location for which there was no SYSKEY.TAB
  at some point
- McIDAS tried to read SYSKEY.TAB in that location

In this case, it creates a 0 length file where none existed previously.

>All terminals  (except waldo, our data ingestor)  have been idle over
>the holiday,  but not sure why that should be a factor.

If the REDIRECTion pointed to a copy of SYSKEY.TAB that is located in
the directory in which McIDAS data files are written, and if you have
an LDM 'scour' entry that scours this directory, then SYSKEY.TAB could
get scoured if it didn't get updated for a day or two.  As soon as the
file is deleted, a McIDAS application that tries to read the file will
create a 0-length copy in the same location.

>The first machine with the problem had just
>had  McIDAS v 2003 installed in early Dec.  and I am sure it worked at
>that time.

Sounds like SYSKEY.TAB was there and got deleted by some process.

>At least one other terminal,  also with  V 2003 was set up earlier last
>fall and seemed fine.

And in this case, SYSKEY.TAB did not get deleted.

>The other terminals with the problem are still set up with v. 7.8 and we
>are in the process of upgrading to v 2003.

OK.

>Any ideas as to what would cause this or how to prevent it?

If the location for SYSKEY.TAB is the directory in which you are
decoding McIDAS data, I would check the LDM scouring that is in place.
The most likely culprit is a cron-initiated 'ldmadmin scour' entry when
the ~ldm/etc/scour.conf file is setup to scour the directory containing
McIDAS decoded data.  It is this exact reason that I have folks scour
McIDAS data using the script 'mcscour.sh' and advise them to _not_ use
LDM's 'scour' utility (unless they _really_ know what they are doing).

>Thanks

Please let me know what you find out...

Cheers,

Tom