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--