20000222: dcmetr

Dcmetar is 1) routinely dropping metars from bulletins which implement
the PIL id in line 2 of the bulletin and 2) crashes on bad 5appp group
in the RMK section:


1) I noticed dcmetr dropping a number of reports which start with the new
MTRxxx on the first line of the bulletin following the WMO header
(see Fred Branksi's info on PILs being implemented in bulletins).
The METAR and SPECI lines still exist in S(A/P)US70 & 80 bulletins,
but individual reports now carry the PIL line.
I see that the MTR (AFOS) check was removed from MT_FIND in 4/98,
but probably need to reimplement this check.

491 
SAUS45 KMSO 191403 RTD
MTRHMM
METAR KHMM 191350Z 00000KT 20SM SKC M07/M10 RMK NOSPECI 4/001
     T10721100 

647 
SAUS41 KOKX 191403
MTRLGA
SPECI KLGA 191402Z 04008KT 1SM -FZRA BR OVC004 M01/M01 A2991 RMK AO2
 SFC VIS 1 1/2 FZDZE1359FZRAB1359 R04/P6000FT $


Resulting decoder logs:

[25920] 000222/1358 [DCMETR 2]  MTRHMM METAR KHMM 191350Z 00000KT 20SM SKC
M07/M10 RMK NOSPECI 4/001 T10721100

[25920] 000222/1358 [DCMETR 5]  No valid station found in report:  MTRHMM METAR
KHMM 191350Z 00000KT 20SM SKC M07/M10 RMK NOSPECI 4/001

[25920] 000222/1358 [DCMETR 2]  MTRLGA SPECI KLGA 191402Z 04008KT 1SM -FZRA BR
OVC004 M01/M01 A2991 RMK AO2 SFC VIS 1 1/2 FZDZE1359FZRA

[25920] 000222/1358 [DCMETR 5]  No valid station found in report:  MTRLGA SPECI
KLGA 191402Z 04008KT 1SM -FZRA BR OVC004 M01/M01 A2991


2) I found an occasion for dcmetr to segment fault on our Solaris x86
machine this weekend. The problem was a miscoded metar from KRWI in the
14Z observation from Feb 19, 2000. The remarks section is being 
inappropriately interpreted as a pressure tendency group. 

KRWI 191350Z 22012G18KT 7SM FEW060 FEW090 SCT100 OVC130 17/14
     A2996 RMK RB 57E15=

It should probably have been RAB57RAE15. Instead, since the RB is separated
from the 57E15 group, the decoder is interpreting the group as 5appp.

When this group gets passed to mt_pten, the appp group gets stored in
the pressure tendency as 7x10E15 (the pr_p03d routine only checks to make
sure the ppp is not 999). Later in the storage routine, PR_P03C is
called and the program segment faults:

Feb 22 19:58:47 DCMETR[25201]: Starting Up
signal SEGV (no mapping at the fault address) in pr_p03c at line 35 in file
"prp03c.f"
   35               PR_P03C = psign ( itendc + 1 ) * ptend
=>[1] pr_p03c(p03d = 7e+15), line 35 in "prp03c.f"
  [2] mt_gemp(lunf = 1, ihhmm = 1350, nparm = 29, parms = ARRAY, cprms = ARRAY,
imnem = ARRAY, numprm = 29, saoflg = false, iret = 0), line 90 in "mtgemp.f"
dbx: out of memory to allocate 1177590784 bytes of expression value
  [3] mt_dcod(curtim = , line 390 in "mtdcod.f"


I placed a check in the mt_pten routine to ensure appp is all numeric:
<clip>
C------------------------------------------------------------------------
        iret = 0
C
        do i=2,5
           CALL ST_ALNM(stpten(i:i),ityp,ier)
           if(ityp.ne.1) then
              iret = 22
              return
           endif
        end do

        pten = PR_P03D ( stpten ( 2:5 ) )
<clip>




Steve Chiswell
Unidata User Support