20000824: Strange ROUTE entries after sounder data

>From: Thomas Mote <address@hidden>
>Organization: University of Georgia
>Keywords: 200008241414.e7OEEjN11917 ldm-mcidas ROUTE.SYS BATCH McIDAS

Tom,

>After spending all of that time getting cacimbo (my SPARC 20) running
>correctly, we decided we'd better eventually move over to this dual
>Pentium LINUX system I mentioned (sirocco.ggy.uga.edu). I'm feeding from
>cacimbo to sirroco while I get it ready.

I saw your messages to Anne on this move.

>I've actually made quite a bit of progress. After a few glictes, the LDM
>seems to be working fine. GEMPAK and McIDAS installed/built correctly. I
>got the ADDE server working (I think, haven't checked it yet), and the XCD
>decoders working. Sirocco seems to be handling the load much
>better. It also has a 100Mbit card and is on the same hub as my
>instructional lab, which will be important when I start using it in class.

Sounds good.

>I was setting up postprocessing for the GOES composites when I ran into
>problems. I made sure the xcd_run was set up and released the appropriate
>ROUTE entries.

For reference, xcd_run controls the XCD data decoding.  For ROUTE PostProces
BATCH file processing, you need to do the same configuration to the
Bourne shell script file, batch.k.  A copy of 'batch.k' is distributed
with ldm-mcidas; it should be copied to some intransient directory in
the 'ldm' account (like ~ldm/decoders).  Edit it just like you did for
xcd_run, and make sure that the directory it is in is in the PATH for
'ldm' and it is set to be executable.

>After a while, I would get very strange ROUTE entries:
>
>                 2144--213         62144 0621              4

Hmm...  The routing entries are written by the decoder, pnga2area in
this case.

>The entries appear 10-20 times in the ROUTE LIST.

Sounds very bad.

>I started with a fresh ROUTE.SYS file, released the entires for
>postprocessing, the did an "ldmadmin watch -f MCIDAS" and tailed the
>BATCHPP.LOG file. The strange ROUTE entries occured with...
>
>Aug 24 13:46:21 pqutil:    78707 20000824134610.164  MCIDAS 000  pnga2area
>Q0 CB 1110 GOES-10_SND UNKBAND 14km 20000824 1200
>Aug 24 13:48:19 pqutil:    76537 20000824134810.615  MCIDAS 000  pnga2area
>Q0 CD 1130 GOES-10_SND UNKBAND 14km 20000824 1200
>
>in the feed and...
>
>BATCH CB 0 100237 120000 1 "
>BATCH CD 0 100237 120000 1 "
>
>Are these the CIMSS products?

Yes, these are CIMSS products.  The indicator in the 'ldmadmin watch'
output is the 'Q0' time quartile indicator.

>I haven't tried to configure for those yet.

OK.

>The last two things I need to do are: (1) configure for the CIMSS
>products, and (2) configure for the NOAAPort GINI products in
>/data/goeseast.

OK, this should not be too difficult.

>I have saved your e-mails from when you did this on
>cacimbo and was going to try to reproduce on sirocco. Also, it doesn't
>appear that the composites are actually being created.

So, something is wrong.

>If you want a peek, the mcidas login is ... temporarily. (I know
>it's short on space for now. I will eventually move the disk on cacimbo
>over to this system.)

I tried getting on the machine and running McIDAS things, but I was unable
to:

cd workdata
dmap.k ROUTE.SYS
dmap.k: Cannot create negative UC

This says that you are out of memory!?  This is strange given that
you appear to have a bunch of swap available:

$top
 12:59pm  up 3 days,  3:17,  4 users,  load average: 0.61, 0.24, 0.55
82 processes: 75 sleeping, 3 running, 4 zombie, 0 stopped
CPU states: 11.3% user,  6.0% system,  1.5% nice,  1.8% idle
Mem:   257684K av,  254516K used,    3168K free,   55228K shrd,   58460K buff
Swap:  530104K av,    2368K used,  527736K free                  119584K cached

The thing I did notice, however, was that you were totally out of disk
space:

$ df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda6              7155068   6792364         0 100% /
/dev/hda2                23333      5001     17128  23% /boot
/dev/fd0                  1412       647       693  48% /mnt/floppy

This could be the reason for the dmap.k failure.  As soon as you can get some
space for maneuvering, I will login again and continue to take a look.

>Thanks.
>
>P.S. Still bugging UCNS about port 503. Having a hard time just getting a
>reponse from anyone. I can't negotiate with anyone because I can't find
>the person responsible for blocking the port!

Keep after it.  Eventually, someone will be found that understands the
network setup and also be able to make the needed change.

Tom