The attached error report has been occurring for weeks on the list that I am
co-list owner of. We cannot figure out who the subscriber is that is causing
the errors. It is not the [log in to unmask] address that is listed in the
report - that address is not subscribed & there are no addresses subscribed
under a globecomm.net domain (maybe the postings are getting forwarded to this
hotmail account via the actual subscriber). It seems like someone subscribed
using iname, but with a personalized email domain. We've never had one of
these that we could not figure out, and we get many of these same errors every
day. Any ideas would be appreciated.
Thanks,
Janis Thomas
---------------------- Forwarded by Janis Thomas/Pti on 09/17/99 08:03 AM
---------------------------
"L-Soft list server at LISTSERV.AMERICAN.EDU (1.8d)"
<[log in to unmask]> on 09/17/99 02:58:59 AM
To: [log in to unmask], Janis Thomas/Pti, [log in to unmask]
cc:
Subject: DB2-L: error report from GLOBECOMM.NET
The enclosed message, found in the DB2-L mailbox and shown under the spool ID
9907701 in the system log, has been identified as a possible delivery error
notice for the following reason: "Message/Delivery-Status" body part found in
the message body.
------------------------ Message in error (162 lines)
-------------------------
Received: from listserv (listserv.american.edu [147.9.238.200]) by
listserv.american.edu (8.9.3/8.7) with ESMTP id DAA4812410 for
<[log in to unmask]>; Fri, 17 Sep 1999 03:58:58 -0400
Received: from rmx04.globecomm.net (rmx04.iname.net [206.253.130.33]) by
listserv.american.edu (8.9.3/8.7) with ESMTP id DAA4812908 for
<[log in to unmask]>; Fri, 17 Sep 1999 03:58:55 -0400
Received: from localhost by rmx04.globecomm.net (8.9.1/8.8.0) with internal
id
DAA03895
Date: Fri, 17 Sep 1999 03:58:13 -0400 (EDT)
From: Mail Delivery Subsystem <[log in to unmask]>
Message-Id: <[log in to unmask]>
To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="DAA03895.937555093/rmx04.globecomm.net"
Subject: Returned mail: Service unavailable
Auto-Submitted: auto-generated (failure)
X-Report-Type: Nondelivery; boundary="> Error description:"
An error was detected while processing the enclosed message. A list of
the affected recipients follows. This list is in a special format that
allows software like LISTSERV to automatically take action on incorrect
addresses.
--> Error description:
Error-For: Requested mail action aborted: exceeded storage allocation
Error-Code: 0
Error-Text: Service unavailable
Error-End: One error reported.
This is a MIME-encapsulated message
--DAA03895.937555093/rmx04.globecomm.net
The original message was received at Fri, 17 Sep 1999 03:58:13 -0400 (EDT)
from lmtp05.iname.net [206.253.130.42]
**
This is an automatic message to inform you that your email was not
forwarded through iName's server.
The iName email address that you tried to send mail to may not be active.
Reasons for the failed delivery attempt could include:
1. The iName customer has selected a new personalized iName email address
rendering their old iName email address inactive.
2. The iName customer may have signed up for one of iName's free offers
and then not validated their forwarding address.
3 The address may simply be typed incorrectly. Please check that you
typed the email address correctly.
iName provides email users with a permanent, personalized and secure email
address that is independent of how one accesses the Internet. iName acts
as a global forwarding service. All email sent to a permanent iName address
is automatically forwarded to a user specified destination email address.
Please visit iName's Online Support Area at
http://www.iname.com/info/intro/index.html for further information.
**
----- The following addresses had permanent fatal errors -----
<[log in to unmask]>
----- Transcript of session follows -----
... while talking to mail9.hotmail.com.:
>>> RCPT To:<[log in to unmask]>
<<< 552 Requested mail action aborted: exceeded storage allocation
554 <[log in to unmask]>... Service unavailable
--DAA03895.937555093/rmx04.globecomm.net
Content-Type: message/delivery-status
Reporting-MTA: dns; rmx04.globecomm.net
Received-From-MTA: DNS; lmtp05.iname.net
Arrival-Date: Fri, 17 Sep 1999 03:58:13 -0400 (EDT)
Final-Recipient: RFC822; [log in to unmask]
Action: failed
Status: 5.5.0
Remote-MTA: DNS; mail9.hotmail.com
Diagnostic-Code: SMTP; 552 Requested mail action aborted: exceeded storage
allocation
Last-Attempt-Date: Fri, 17 Sep 1999 03:58:13 -0400 (EDT)
--DAA03895.937555093/rmx04.globecomm.net
Content-Type: message/rfc822
Received: from smv14.iname.net by rmx04.globecomm.net (8.9.1/8.8.0) with SMTP
id DAA03890 ; Fri, 17 Sep 1999 03:58:13 -0400 (EDT)
Received: from listserv.american.edu (listserv.american.edu [147.9.238.200])
by smv14.iname.net (8.9.3/8.9.1SMV2) with ESMTP id CAA24587;
Fri, 17 Sep 1999 02:18:33 -0400 (EDT)
Received: from listserv (listserv.american.edu [147.9.238.200]) by
listserv.american.edu (8.9.3/8.7) with ESMTP id CAA3859576; Fri, 17 Sep 1999
02:17:48 -0400
Received: from LISTSERV.AMERICAN.EDU by LISTSERV.AMERICAN.EDU (LISTSERV-TCP/IP
release 1.8d) with spool id 9902345 for [log in to unmask];
Fri, 17 Sep 1999 02:16:47 -0400
Received: from csimo02.mx.cs.com (csimo02.mx.cs.com [205.188.156.53]) by
listserv.american.edu (8.9.3/8.7) with ESMTP id CAA3857210 for
<[log in to unmask]>; Fri, 17 Sep 1999 02:16:45 -0400
Received: from [log in to unmask] by csimo02.mx.cs.com (mail_out_v22.4.) id
eJNKa03044 (4571) for <[log in to unmask]>; Fri, 17 Sep
1999
02:13:50 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 65
Message-ID: <[log in to unmask]>
Newsgroups: bit.listserv.db2-l
Date: Fri, 17 Sep 1999 02:13:50 EDT
Reply-To: DB2 Data Base Discussion List <[log in to unmask]>
Sender: DB2 Data Base Discussion List <[log in to unmask]>
From: Rick Davis <[log in to unmask]>
Subject: Re: Leafdist - how to fix ?
To: [log in to unmask]
Alan,
There's several things you can try.
1. Ensure ample primary space. Secondary extents in either the table or index
can be quite a problem if major access is sequential or skip-sequential.
2. Consider 'seeding' new tables with dummy rows if its possible and ample
freepages.
3. For rapidly growing indexes, LEAFDIST will continue to be a problem until
the percentage of added entries represents a smaller percentage of the total.
4. For a brand new table, large LEAFDIST isn't necessarily bad until its
quite large due to the many page-splits.
5. See DB2/OS390 V5 Admin. Guide, bookmanager ref. 5.9.5.3.1.
HTH, Rick
In a message dated 1999-09-16 9:09:44 PM Central Daylight Time,
[log in to unmask] writes:
> I have a number of indexes where the Leafdist has grown significantly since
> they
> were reorg'd only 1 month ago.
> Cardinality seems to have increased around 6-10K each week in most cases.
(i.
> e
> evenly across the weeks).
>
> I'm seeking some tips on how to stop the leafdist rising in the following
> situations:
> 1. Leafdist jumps dramatically once but card increases (non-clustering IX )
> 2. Leafdist continues to rise dramatically each week (non-clustering IX
and
> PK)
> 3. Leafdist jumps dramatically once, then starts to reduce each week by
> small
> amounts (non-clstr IX and PK)
>
> I have had a look at SYSCOLDIST and the non-key cols have low frequency
xxE-
> 05.
> I have some ideas what to do but would like some confirmation or successful
> solutions that have worked for others. (In his book Mullins makes some
> suggestions based on the coldist - still pondering how to apply this to my
> problem set)
>
> Thanks in advance
> Allan Caldwell
--DAA03895.937555093/rmx04.globecomm.net--
|
