From ALAN at MC.LCS.MIT.EDU  Sun Dec 29 01:00:48 1985
From: ALAN at MC.LCS.MIT.EDU (Alan Bawden)
Date: Dec 28 85 19:00:48 EST
Subject: page fault in system
In-Reply-To: Msg of Sun 22 Dec 85 15:21:29 EST from David Vinayak Wallace <GUMBY at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].767454.851228.ALAN>

[ Why are we Cc'ing this message to HIC? ]

    Date: Sun, 22 Dec 85 15:21:29 EST
    From: David Vinayak Wallace <GUMBY at MC>
    ITS took a page fault.  Look in CRASS PAGFLT if you care.

Specifically, ITS took a page fault running in the scheduler.  It thought
it was looking at somebody's USTP bits, but U contains gubbish, and it
looks like the hardware pagetable must have contained some kind of a joke
as well.  I am tempted to agree with you that this was the result of
glitch.  (That must be what you think since you mailed this to Poor-MC,
right?)

    PS: Someone seems to have deleted the pooor-mc alias.

I don't think it ever really had that name, at least not for long.  I
suggested it, but I think somebody corrected my joke thinking it was a typo
almost instantly.

From GZ at MC.LCS.MIT.EDU  Mon Dec 23 11:50:31 1985
From: GZ at MC.LCS.MIT.EDU (Gail Zacharias)
Date: Dec 23 85 05:50:31 EST
Subject: Compression
In-Reply-To: Msg of Mon 16 Dec 85 15:46:52 EST from Alan Bawden <ALAN at MIT-MC.ARPA>
Message-ID: <[MC.LCS.MIT.EDU].764485.851223.GZ>

AR4:GZ;ENCODE and DECODE.  Encoding a large text file typically gives
a little over half of the original size.

From GSB at MC.LCS.MIT.EDU  Mon Dec 23 06:22:08 1985
From: GSB at MC.LCS.MIT.EDU (Glenn S. Burke)
Date: Dec 23 85 00:22:08 EST
Subject: IBO
Message-ID: <[MC.LCS.MIT.EDU].764318.851223.GSB>

I just got "IBO" on the dialups.  i tried 6985, 6986, and 6989 for
good measure...

From JNC at XX.LCS.MIT.EDU  Thu Dec 19 00:00:00 1985
From: JNC at XX.LCS.MIT.EDU (J. Noel Chiappa)
Date: Thu 19 Dec 85, 00:00
Subject: ICMP: GW table full
In-Reply-To: <[MIT-MC.ARPA].757281.851216.ALAN>
Message-ID: <12168408267.46.JNC@XX.LCS.MIT.EDU>

	This is a harmless message. The IP routing table (see PEEK 'W'
display) is a cache of the most recently used routes; when it fills up and
needs to add a new route, it punts the lest recently route. The message
is unnecessary. It would be good to notice if the cache is too small
(e.g. if the route discarded was used less than five minutes ago) and
log that; it might also be good to add a count of the number of cache
flushes and the number flushed in, say, the last hour.
-------

From ALAN at MIT-MC.ARPA  Tue Dec 17 05:20:56 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Dec 16 85 23:20:56 EST
Subject: ICMP: GW table full
Message-ID: <[MIT-MC.ARPA].757281.851216.ALAN>

If you run SYSMSG on MC you will generally find that the message buffer
is 90% full of messages of the form:
ICMP: GW table full, net/gw 20024,,600000 1200,,76 =>  30001,,255000 1200,,400045 MON 22:07:12
I presume this all means something to KLH and the rest of you TCP hackers,
but to me it is just an annoying amount of output that seems to be associated
no problem that I can see.  Is this a symptom of a real problem, or does it
just mean that some fixed size table should be made a little larger?  Or
perhaps we should consider not bothering the system console with this
common event, whatever it is.

From ALAN at MIT-MC.ARPA  Mon Dec 16 21:46:52 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Dec 16 85 15:46:52 EST
Subject: Compression
In-Reply-To: Msg of Mon 16 Dec 1985  13:54 EST from PGS%MIT-OZ at MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].756680.851216.ALAN>

    Date: Mon, 16 Dec 1985  13:54 EST
    From: PGS at OZ
        Date: Monday, 16 December 1985  12:08-EST
        From: David Vinayak Wallace <GUMBY at MC>
        do you know about the ARx devices?

    I don't think those perform text compression, do they?

No, they don't.  They make a collection of small files take less space on
disk by removing the average of half a block of wasted space at the end of
every file.  They also take up less room in your directory because the
names of the files are stored in the archive itself, leaving only one entry
stored in your directory.

If you are looking for a program that compresses ASCII text by taking
advantage of the fact that certain sequences of characters are more common
than others, I think that Gail Zacharias (GZ at MC) has the best program for
this that I have seen.  I can't seem to find it at the moment though. Gail?

From PGS%MIT-OZ at MIT-MC.ARPA  Mon Dec 16 19:54:00 1985
From: PGS%MIT-OZ at MIT-MC.ARPA (PGS%MIT-OZ at MIT-MC.ARPA)
Date: Dec 16 1985  13:54 EST
Subject: No subject
In-Reply-To: Msg of 16 Dec 1985  12:08-EST from David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
Message-ID: <PGS.12167620265.BABYL@MIT-OZ>

    Date: Monday, 16 December 1985  12:08-EST
    From: David Vinayak Wallace <GUMBY at MIT-MC.ARPA>
    To:   LIN at MIT-MC.ARPA
    cc:   BUG-ITS at MIT-MC.ARPA

    do you know about the ARx devices?

I don't think those perform text compression, do they?

From GUMBY at MIT-MC.ARPA  Mon Dec 16 18:08:03 1985
From: GUMBY at MIT-MC.ARPA (David Vinayak Wallace)
Date: Dec 16 85 12:08:03 EST
Subject: No subject
In-Reply-To: Msg of Mon 16 Dec 85 11:51:47 EST from Herb Lin <LIN at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].756162.851216.GUMBY>

do you know about the ARx devices?

From LIN at MIT-MC.ARPA  Mon Dec 16 17:51:47 1985
From: LIN at MIT-MC.ARPA (Herb Lin)
Date: Dec 16 85 11:51:47 EST
Subject: No subject
Message-ID: <[MIT-MC.ARPA].756101.851216.LIN>

help requested from a wizard.  Is there any way of doing rXX text compression
on large text files purely on ITS...  Something analagous to the SQUEEZE 
programs available for micros?

thans.XXX

thanks.

From CENT%MIT-AI.ARPA at MIT-MC.ARPA  Fri Dec 13 07:28:45 1985
From: CENT%MIT-AI.ARPA at MIT-MC.ARPA (Pandora B. Berman)
Date: Dec 13 85 01:28:45 EST
Subject: ai died
Message-ID: <[MIT-AI.ARPA].8641.851213.CENT>

ai suddenly hit a PI LEVEL 7 BUGHALT. crash dump to CRASH;SUDDEN LOSS

From GUMBY at MIT-MC.ARPA  Tue Dec 10 01:41:51 1985
From: GUMBY at MIT-MC.ARPA (David Vinayak Wallace)
Date: Mon,  9 Dec 85 19:41:51 EST
Subject: oops
Message-ID: <[MIT-MC.ARPA].747566.851209.GUMBY>

As you can guess, that should have gone to bug-system at oz.  Sorry

From GUMBY at MIT-MC.ARPA  Tue Dec 10 00:04:22 1985
From: GUMBY at MIT-MC.ARPA (David Vinayak Wallace)
Date: Mon,  9 Dec 85 18:04:22 EST
Subject: dialup problem
In-Reply-To: Msg of Mon 9 Dec 1985  16:22 EST from Chunka Mui <CHUNKA%MIT-OZ at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].747534.851209.GUMBY>

OZ doesn't have the hardware.  Your modem uses bell's 1200-baud
frequencies.  Vadic uses different ones.

From ALAN at MIT-MC.ARPA  Sun Dec  8 01:02:36 1985
From: ALAN at MIT-MC.ARPA (Alan Bawden)
Date: Sat,  7 Dec 85 19:02:36 EST
Subject: .msgs.; bloated
In-Reply-To: Msg of Sat  7 Dec 85 06:10:23 EST from Pandora B. Berman <CENT%MIT-AI.ARPA at MIT-MC.ARPA>
Message-ID: <[MIT-MC.ARPA].745744.851207.ALAN>

    Date: Sat,  7 Dec 85 06:10:23 EST
    From: Pandora B. Berman <CENT%MIT-AI.ARPA at MIT-MC.ARPA>
    for reasons unknown, AI can't figure out how to purge obsolete msgs
    from .MSGS.;. it wouldn't do it when the files weren't backed up, but
    i expected that. however, now the files are regularly backed up, the
    _LAST_ EXPIRE file looks well formed, but they -still- don't disappear
    on cue. MC, on the other hand, seems to have no problem in this regard.
    any ideas why?

A Typical message from MC:.MSGS.;*MSG > begins:

    DISTRIB:  *BBOARD
    EXPIRES: 12/14/85 12:38:14
    Received: from BORAX by MIT-MC.ARPA  7 Dec 85 12:38:13 EST

A typical message from AI:.MSGS.;*MSG > begins:

    Received: from MIT-MC.ARPA by MIT-AI.ARPA via Chaosnet; 7 DEC 85  12:37:44 EST
    DISTRIB:  *BBOARD
    EXPIRES: 12/14/85 12:38:14
    Received: from BORAX by MIT-MC.ARPA  7 Dec 85 12:38:13 EST

I suspect the recieved line at the front fakes GMSGS out when it tries to
find the expiration date.  This could be fixed by changing COMSAT to not do
this, or by fixing GMSGS to be smarter.  Somebody else is going to fix this
one.  (I don't think it can be all -that- hard guys!)

From CENT%MIT-AI.ARPA at MIT-MC.ARPA  Sat Dec  7 12:10:23 1985
From: CENT%MIT-AI.ARPA at MIT-MC.ARPA (Pandora B. Berman)
Date: Sat,  7 Dec 85 06:10:23 EST
Subject: .msgs.; bloated
Message-ID: <[MIT-AI.ARPA].8152.851207.CENT>

for reasons unknown, AI can't figure out how to purge obsolete msgs
from .MSGS.;. it wouldn't do it when the files weren't backed up, but
i expected that. however, now the files are regularly backed up, the
_LAST_ EXPIRE file looks well formed, but they -still- don't disappear
on cue. MC, on the other hand, seems to have no problem in this regard.
any ideas why?