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

[LDM #VZP-575055]: 6.11.1 LDM error documentation

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: [LDM #VZP-575055]: 6.11.1 LDM error documentation
  • Date: Mon, 19 Nov 2012 10:07:02 -0700
Carissa,

> Yes.
> 
> /nwprod/exec/decod_dcelrw -v 2 -t 300 -d
> /dcom/us007003/decoder_logs/decod_dcelrw.log
> /nwprod/fix/bufrtab.EUMS_SATWIND /nwprod/fix/bufrtab.JAPAN_SATWIND
> /nwprod/fix/bufrtab.005 < 2012111915.satwnd_Japan
> 
> With the input line taken exactly from the ldm logs.
> 
> I don't believe it worked, even on the first ob. It should have created
> this file: BUFR.0.elrw.1.1146.1353337322.118. And my logs only show
> evidence of it at the timestamp when I ran it by hand. But lets try it
> again, I will add the close in and see if I can get anything else helpful.

The operating-system buffers the pipe, so it's possible that the pqact(1) 
process can close the pipe before the decoder has read everything -- and then 
the decoder crashes.

> The background of this is we are upgrading our supercomputers from AIX
> to RHEL6. So LDM is getting an upgrade as well from 6.7.0. So with newly
> compiled decoders, new LDM and new platform it is a whole host of
> possible culprits.

Ouch!

> But out of 15 decoders, only 2 aren't working with
> the same errors (makes me think a decoder issue...except I can run it by
> hand successfully :( )

I thought you said that the decoder wasn't producing the output file that it 
should have.

> Carissa

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: VZP-575055
Department: Support LDM
Priority: Normal
Status: Closed