19991025: Monster ROUTE.SYS file.

>From: Jim Heimbach <address@hidden>
>Organization: UNCA
>Keywords: 199910251840.MAA08750

Jim,

>     I'm getting in a little panic here as when I came in this morning
>my McIDAS data disk was at 100%.  This surprised me as everything
>has been tooling along with no problem for weeks.  Some of the culprit
>monster files are,
>          633978880 Oct 25 09:00 ROUTE.SYS
>          33553620 Oct 25 00:24 FOUS14.RAT
>          26088580 Oct 25 09:04 SAOMETAR.RAP
>          33554260 Oct 25 09:04 SAOMETAR.RAT
>          33554260 Oct 25 09:03 TERMFCST.RAT
>     I can understand some size being necessary for the last four, but
>the ROUTE.SYS I find disturbing.  I have 
>
>          /home/mcidas/workdata/mcscour.sh
>
>working in a cron job.  I have ldm's scour running as well, but these
>wouldn't trim ROUTE.SYS.  The /data drive which holds mcidas and ldm data
>normally is at about 50% capacity.
>
>     Whazzup?  -- Jim H

Something _bad_ happened to ROUTE.SYS.  This file should never grow
without someone adding new products to it.  The most likely thing is
that a little endian machine running an _old_ version of McIDAS wrote
to this file for some reason.

Do you have an OS/2 machine still running an old version of McIDAS-OS2
which has a REDIRECTion for ROUTE.SYS that points to the one that
should be updated by the data decoding processes on your ingestion
machine and has write permission?  If all of your machines are running
Unidata McIDAS versions including and after 7.1, then they will all
understand big endian entries in ROUTE.SYS.  If you have an older
version of McIDAS running on a little endian machine (like OS/2), then
it will not understand the big endian entries in a current ROUTE.SYS.

The only machine that should ever update ROUTE.SYS is the one that is
running the data ingesters/decoders.  If more than one machine can
write to ROUTE.SYS, unpredictable things can happen.

In order to get back to normal, you will need to:

o delete this monster ROUTE.SYS file (you probably already have)

o create a new ROUTE.SYS from the DROUTE.BAT template that is included
  in the McIDAS-X distrubtion:

  BATCH DROUTE.BAT

  If you routinely make modifications to your routing setup, you should
  make a local copy of DROUTE.BAT called LROUTE.BAT and make your
  modifications to it and then run:

  BATCH LROUTE.BAT

o if you were allowing compositing PostProcessing to occur, you will
  need to verify that the routing table entries for the 'C' and 'N'
  products are RELeased.  You do this by:

  ROUTE LIST

  Look at the entries whose product codes begin with 'C' and 'N'.
  If they are SUSpended (i.e. if they have an 's' in column one
  of the ROUTE LISTing), then you will need to RELease them:

  ROUTE REL C
  ROUTE REL N

o finally, you will need to find out if another machine has write permission
  to ROUTE.SYS.  If one does, you should eliminate its write capability.

This is a strange one to say the least.

Tom

>From address@hidden  Mon Oct 25 14:39:42 1999
>     Many thanks for the quick turnaround.  I did what you said and
>for now the system is up and the students and staff
>are off my back.
>     Something I am looking into is the possibility that another
>machine is writing to ROUTE.SYS.  Last Friday, I went to work
>on a LINUX box which had McIDAS 7.5 running on it.  I thought I
>would pull a sneaky by tar-ing everything that was relevant
>on one of the LINUX boxes running 7.6, then moving the tar file
>over.  Things went fairly well. I had to tweak the routings, but
>I went home feeling good as one should on a Friday.  This is the
>only change made which could have had an influence over the
>weekend.  At any rate, that machine is off, awaiting a couple of
>hours for a formal installation by myself.  
>     That's my guess and I'll fill you in if more strangeness 
>occurs.
>              -- Jim H
>