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

19990325: windfall at its old, bad tricks (cont.)

>From: "Jennie L. Moody" <address@hidden>
>Organization: UVa
>Keywords: 199903091926.MAA12825 McIDAS ROUTE SYSIMAGE.SAV

Jennie,

re: email bouncing
>Hmmm, email to me? was bouncing, or email to ldma?

Sorry I didn't include some of the output earlier:

    Return-Path: <address@hidden>
    Received: (from majordo@localhost)
            by unidata.ucar.edu (8.8.8/8.8.8) id BAA05125
            for netcdfgroup-out; Wed, 24 Mar 1999 01:31:03 -0700 (MST)
    X-Authentication-Warning: laraine.unidata.ucar.edu: majordo set sender to 
owner-
    address@hidden using -f
    Organization: .
    Keywords: 199903240831.BAA05121
    Date: Wed, 24 Mar 1999 08:30:26 +0000 (GMT)
    From: Jonathan Gregory <address@hidden>
    Subject: GDT 1.3 - a netCDF standard for climate data
    To: address@hidden
    Message-id: <address@hidden>
    MIME-version: 1.0
    X-Mailer: Elm [revision: 212.4]
    Content-type: TEXT/PLAIN
    Content-transfer-encoding: 7BIT
    Sender: address@hidden
    Precedence: bulk
    Reply-To: Jonathan Gregory <address@hidden>
    
    --CAA05181.922269044/unidata.ucar.edu--
    
    From address@hidden  Wed Mar 24 10:10:48 1999
    Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9])
            by unidata.ucar.edu (8.8.8/8.8.8) with SMTP id KAA20526
            for <address@hidden>; Wed, 24 Mar 1999 10:10:48 -0700
    (MST)
    Organization: .
    Keywords: 199903241710.KAA20526
    Received: from aeolus.evsc.virginia.edu by mail.virginia.edu id aa13120;
              24 Mar 99 12:10 EST
    Received: from localhost (localhost) by aeolus.evsc.Virginia.EDU 
(8.8.5/8.6.6) w
    ith internal id MAA43486; Wed, 24 Mar 1999 12:10:45 -0500
    Date: Wed, 24 Mar 1999 12:10:45 -0500
    From: Mail Delivery Subsystem <address@hidden>
    Subject: Returned mail: Insufficient permission: Error 0
    Message-Id: <address@hidden>
    To: address@hidden
    MMDF-Warning:  Parse error in original version of preceding line at 
mail.virgini
    a.edu
    Auto-Submitted: auto-generated (failure)
    
    The original message was received at Wed, 24 Mar 1999 12:10:44 -0500
    from mail.Virginia.EDU [128.143.2.9]
    
       ----- The following addresses had permanent fatal errors -----
    <address@hidden>
    
       ----- Transcript of session follows -----
    bellmail: cannot append to /usr/spool/mail/jlm8h
    bellmail: cannot create ./dead.letter
    bellmail: error closing file: Bad file number
    550 <address@hidden>... Insufficient permission: Error 0
    
       ----- Message header follows -----
    
    Return-Path: address@hidden
    
    Return-Path: address@hidden
    Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by 
aeolus.evs
    c.Virginia.EDU (8.8.5/8.6.6) with SMTP id MAA46556 for 
<address@hidden.virgin
    ia.edu>; Wed, 24 Mar 1999 12:10:44 -0500
    Received: from laraine.unidata.ucar.edu by mail.virginia.edu id aa13097;
              24 Mar 99 12:10 EST
    Received: (from majordo@localhost)
            by unidata.ucar.edu (8.8.8/8.8.8) id JAA20232
            for ldm-users-out; Wed, 24 Mar 1999 09:59:45 -0700 (MST)
    X-Authentication-Warning: laraine.unidata.ucar.edu: majordo set sender to 
owner-
    address@hidden using -f

  ...

So, the address that was having problems was:

address@hidden

>I changed the
>forward (which Kevin has set up) and this should have fixed ldma.

OK, it wasn't ldma.

>If email to me personally on windfall was bouncing, I don't get
>it.

It was email on aeolus.

>If email to me as address@hidden was bouncing, that could have
>occurred from running out of space on the machine which that alias
>redirects mail to (address@hidden, I cleared up
>space over there this morning.)  I guess it would help if I had
>some idea what mail was getting bounced??

This might have been the problem.

re: *.001, FrameN.M, and SYSIMAGE.SAV in ~mcidas/help
>Hmmmm, I didn't do the dmap to look for every occurrence of these files
>(but I thought I had looked in all relevant directories, /home/mcidas/help
>didnt occur to me), but I have learned my lesson.  I will follow your
>instructions next time.

Using dmap.k is the easiest thing since it plays by McIDAS' rules.  The
procedure again is:

o logon as 'mcidas'
o cd to workdata
o run:

  dmap.k FORM=ALL

>I have noticed that the machine is not scouring files in mcidasd....the log
>seems to report that files are getting deleted, and they *are* getting deleted
>from xcd, however, the MD files and GRID files in mcidasd have not been 
>removed since I restarted the ldm.  I have been "watching" this, I actually
>deleted a couple of files myself, and was getting ready to write a message
>about this to you.  I was trying to figure out if the aliasing of rm would
>make a difference (I don't understand how something like the mscour.sh shell
>inherits these environment variables), it doesn't make any sense since the
>scouring is occurring in the xcd directory.  

I took a look at this.  The reason that the DOQTLs were not working in
/incoming/data/mcidasd was related to the REDIRECTions for MDXX files
for the user 'mcidas'.  As you may recall, the McIDAS BATCH file
BROADCAST.BAT (located in ~mcidas/workdata) was saying to change
the REDIRECTion for MDXX00* files to /incoming/data/mcidasd; then
kick off the scheduler to do the scouring; then change the REDIRECTions
for MDXX00* files back to /incoming/data/xcd.  The REDIRECTions in
effect for 'mcidas' are more specific than MDXX00*, so they continued
to take precedence.  The effect of this was that the 'DOQTL 1 30 3'
scouring was being run on files in /incoming/data/xcd again.  In order
to get the scouring that you want, I modified ~mcidas/workdata/BROADCAST.BAT

from:

REDIRECT ADD MDXX00* "/incoming/data/mcidasd
DOQTL 1 30 3
REDIRECT ADD MDXX00* "/incoming/data/xcd

to:

REDIRECT ADD MDXX000* "/incoming/data/mcidasd
REDIRECT ADD MDXX001* "/incoming/data/mcidasd
REDIRECT ADD MDXX002* "/incoming/data/mcidasd
REDIRECT ADD MDXX0030 "/incoming/data/mcidasd
DOQTL 1 30 3
REDIRECT ADD MDXX000* "/incoming/data/xcd
REDIRECT ADD MDXX001* "/incoming/data/xcd
REDIRECT ADD MDXX002* "/incoming/data/xcd
REDIRECT ADD MDXX0030 "/incoming/data/xcd

Now the new REDIRECTions are very specific, so they will work.  I
tested this by running mcscour.sh from the 'ldma' account; looking at
~ldma/logs/mcscour.log and also at /incoming/data/mcidasd/MDXX*.  The
files are now getting scoured correctly.

>I would write a more coherent message, and cut and paste some info here
>for you to look at, but I have a scheduled appointment with a student
>and she is sitting here waiting for my attention.

No problem, I know that you are busy.

>I appreciate you noticing there is some problem.  (I wish there wasn't...)

I wish that there were no problems as well.

Tom

>From address@hidden  Fri Mar 26 08:17:02 1999

re: bounced mail on aeolus
>There was no temp space left on aeolus.

re: using dmap.k to search for files in MCPATH directories
>Okay.  I do see that this creates its own instance of Frame, etc
>in /home/mcidas/.mctmp, but otherwise things look okay.

re: changing REDIRECTions in BROADCAST.BAT to be specific for scouring
>Geez, I should have seen that this was the problem.

Thanks Tom.
Jennie