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

[McIDAS #XOE-622682]: Problem with Lose of Area Definitions

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: [McIDAS #XOE-622682]: Problem with Lose of Area Definitions
  • Date: Mon, 26 Jul 2010 15:14:40 -0600
Hi Fred,

re:
> I have been experimenting to see if I can find the cause of the RESOLV.SRV
> content disappearance.

I could not make this happen here at the UPC...

re:
> The file would still be there, but it would be empty
> after the error occurred.  The error seemed to occur when the computer was 
> busy
> with multiple programs from multiple satellites processing at the same time.  
> I
> made a copy of the dsserve.pgm for experimentation.  I tried putting in flush
> after the last write, unlocks (rather than the program close default unlock), 
> and
> taking out the initial file blanking on first use.  None of these had any
> effect.  I then tried putting in a 1/2 second sleep just before the exit of 
> the
> main dsserve program.  It ran over the weekend without failure after I put in 
> the
> sleep.

Wow!  This is reminiscent of the problem we found while writing object modules
created during a McIDAS build to the McIDAS library.  I found that putting in
a sleep of 1 second after each 'ar' would insure that all of the object modules
being written to the library were actually put in the library.  This started 
occurring
on more recent versions of Linux when the machine in question was fast.  SSEC
eventually ran into the same problem and adopted the same approach as I did, and
GEMPAK showed the same behavior.  We never really got to the bottom of the 
problem,
but suspected that it had(has) something to do with file timestamps only being 
good
down to the second.

re:
> It still has my other changes in it, so I will be taking them out one by
> one this week to ensure it still works.  I believe the problem is the 
> operating
> system buffering of files.

Great sleuthing!  Thanks for the update, and please keep us apprised of your 
findings.

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: XOE-622682
Department: Support McIDAS
Priority: Normal
Status: Closed