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

19990520: 19990514: dchrly

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: 19990520: 19990514: dchrly
  • Date: Thu, 20 May 1999 10:57:02 -0600
Geff,

I have posted dchrly for Irix (we are running 6.5.3) under
~gbuddy/nawips-5.4/binary/irix.

Hopefully this will work for you. If you still see problems
where the output file is corrupt- presumably using sflist
dies- if you can try to tell me at what hour/last station
that sucessfully gets listed before the crash, as soon as possible
then this would help me determine if the problem is with the decoder 
or overloaded LDM while I still have all of the raw files online..

Steve Chiswell
Unidata User Support

>From: Geff Underwood <address@hidden>
>Organization: .
>Keywords: 199905201501.JAA14463

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Steve,
>
>>Two reasons I can think of the above situation happening-
>>
>>1) A corrupt SA bulleting is being received and is trying to be stored
>>   in the TEXT field of the file.
>>
>>   Note that if this is the case, the problem should be reproduceable.
>>   I have checked and reingested and rechecked our raw data files here
>>   as well as the resultant files produced from dchrly and have not 
>>   found any corruption. I did notice this problem almost 2 years ago but
>>   since then provided a patch. If your version is lacking the patch,
>>   this could still be a problem... and we can rectify this by updating your 
>>   decoder or gempak distribution. Are you running under IRIX 6.5.x?
>
>Yes, we are running IRIX 6.5.2m.
>
>>2) If your decoding machine is having a hard time keeping up with the 
>>   amount of incoming data, then its possible that the LDM would get
>>   bogged down and overflow the PIPE output to dchrly, and as a result,
>>   a second copy of dchrly could be started up. When two running dchrly
>>   programs try to write to the same file, data corruption is almost
>>   guaranteed. If this is the problem, you would probably notice the machine 
>>   running very slow, and you would probably see dchrly invocations in the da
> ta logs
>>   where dchrly is started several times without a shutting down log message.
>
>I checked the log for today, and found one instance where two "Starting
>up." messages appeared before one "Shutting Down.", but today's file is
>still usable.
>
>>I can install my current dchrly executable on your machine to see if that
>>solves your problem if any patches atc are missing from your distribution.
>>If the problem is with the machine load, then we should see if anything has 
>>recently started consuming a large portion of your resources.
>
>I think we should try your dchrly; there haven't been any crontab changes
>this month, and there are no runaway jobs at the moment.
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGPfreeware 5.0i for non-commercial use
>Charset: noconv
>
>iQA/AwUBN0QjnMXnbEgeKlfEEQLZ2wCgiT5rYjGQnO7XQhr5d1IwPBE63MIAn3tM
>CNGxUqi2fJ6WrH/V3fyFqxby
>=8KT1
>-----END PGP SIGNATURE-----
>