diff --git a/Makefile b/Makefile index f26b0985..b4a966f3 100644 --- a/Makefile +++ b/Makefile @@ -28,13 +28,14 @@ SRC = syseng sysen1 sysen2 sysen3 sysnet kshack dragon channa \ fonts zork 11logo kmp info aplogo bkph bbn pdp11 chsncp sca music1 \ moon teach ken lmio1 llogo a2deh chsgtv clib sys3 lmio turnip \ mits_s rab stan_k bs cstacy kp dcp2 -pics- victor imlac rjl mb bh \ - lars drnil radia gjd maint bolio cent shrdlu vis cbf + lars drnil radia gjd maint bolio cent shrdlu vis cbf digest DOC = info _info_ sysdoc sysnet syshst kshack _teco_ emacs emacs1 c kcc \ chprog sail draw wl pc tj6 share _glpr_ _xgpr_ inquir mudman system \ xfont maxout ucode moon acount alan channa fonts games graphs humor \ kldcp libdoc lisp _mail_ midas quux scheme manual wp chess ms macdoc \ aplogo _temp_ pdp11 chsncp cbf rug bawden llogo eak clib teach pcnet \ - combat pdl minits mits_s chaos hal -pics- imlac maint cent ksc klh + combat pdl minits mits_s chaos hal -pics- imlac maint cent ksc klh \ + digest BIN = sys sys1 sys2 emacs _teco_ lisp liblsp alan inquir sail comlap \ c decsys graphs draw datdrw fonts fonts1 fonts2 games macsym \ maint imlac _www_ gt40 llogo bawden sysbin -pics- lmman r shrdlu diff --git a/build/misc.tcl b/build/misc.tcl index 0e8f282c..f8b9beac 100644 --- a/build/misc.tcl +++ b/build/misc.tcl @@ -242,6 +242,11 @@ respond "*" ":midas sysbin;_sysnet;mails\r" expect ":KILL" respond "*" ":link device; chaos mail, sysbin; mails bin\r" +# DIGEST +respond "*" ":midas digest; ts digest_digest\r" +expect ":KILL" +respond "*" ":link dragon; hourly digest, digest; ts digest\r" + # TIME respond "*" ":midas sys1;ts time_sysen2;time\r" expect ":KILL" diff --git a/doc/digest/-read-.-this- b/doc/digest/-read-.-this- new file mode 100755 index 00000000..4a988f92 --- /dev/null +++ b/doc/digest/-read-.-this- @@ -0,0 +1,21 @@ +This directory is for the ITS mail digesting tool. + +DEFS > contains the digest definitions. + +DIGEST ORDER contains documentation on the definitions and other + information on how to use the digestifier. + +LOG * files contain digestifier log output. + +TS DIGEST is the installed binary of the digestifier. + (DRAGON;HOURLY DIGEST should be a link to DIGEST;TS DIGEST.) + +DIGEST > is the source for TS DIGEST. + +TS MBXLOC is a utility program for locking inboxes so that COMSAT and + the digestifier wont touch them (so that you can edit them + yourself, should that become necessary). + +MBXLOC > is the source for TS MBXLOC. + +DIGEST BUGS ia the archive for BUG-DIGEST mail. diff --git a/doc/digest/digest.bugs b/doc/digest/digest.bugs new file mode 100755 index 00000000..c574ef8b --- /dev/null +++ b/doc/digest/digest.bugs @@ -0,0 +1,2025 @@ +Date: Sat, 26 May 90 18:38:46 EDT +From: "Pandora B. Berman" +Sender: CENT5@MC.LCS.MIT.EDU +Subject: bouncing mail +To: AVIATION-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, + PAGANISM-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, SCHEME-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, + SUBGENIUS-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +cc: SCA-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +Message-ID: <671367.900526.CENT5@MC.LCS.MIT.EDU> + +fyi, this is the administrative msg we have installed to go out with the +next SCA digest. if your digests have also had bouncing mail as described, +you might want to place similar msgs to go out with your digests. the KS is +currently hard to reach, so if you want to place such a msg but can't reach +the KS to do so, send your msg to me and i will install it appropriately. +---------- +Modern-world interrupt for the technically interested: + +The name MC.LCS.MIT.EDU was moved yesterday from the KS10 running ITS to a +Microvax running some version or another of unix (don't ask me which). The +KS10 wasn't on the Internet; the Microvax is. For a brief period during +the move there was confusion about which host the name belonged to, which +caused some mail to the digest to bounce. We believe that all such mail +actually bounced to the -Request list. All the mail that bounced in this +fashion to the -Request list has now been dropped back into the SCA +incoming mailbox for digestification. If you sent mail to the digest and +it returned to you complaining that MC was an unknown host or SCA@MC was an +unknown address, please try again. Otherwise, please just wait a bit, and +your missive should appear -- we're a talkative lot, and the digestifier is +running a bit behind our volubility. + At this moment the digest is still being produced on the KS10, which +will continue to run for a few more weeks under an assumed name. This +works by magic -- don't ask. A new improved digestifier which will run on +unix is currently being written and should be ready soon. At that point +the digestification process will move to the Microvax, and there may be +some disruption as we shake out the bugs. Watch this space for updates. + +We now return you to news of the Current Middle Ages. + +SCA-Request@MC.LCS.MIT.EDU + +Date: Mon, 14 May 90 00:03:24 EDT +From: "Pandora B. Berman" +Subject: MC going down the tubes +To: SCA-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, PAGANISM-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, + SCHEME-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, AVIATION-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, + SUBGENIUS-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +cc: BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +Message-ID: <667947.900514.CENT@MC.LCS.MIT.EDU> + +As you may have heard, the MC ITS machine is going away soon. Regular +mail will be turned off 17 May; at that point the name MC.LCS.MIT.EDU +will move to some unix box belonging to LCS, and the ITS machine will +answer only to the name OLD-MC.LCS.MIT.EDU. By the 17th we expect to +have moved all ordinary mailing lists from the old MC to the new one, +so that transfer should be fairly transparent. + +However, we won't move the digests then. Instead, we will set up on +the new MC forwarding pointers to direct the mail for the digests to +their mailboxes on the old MC. The ITS digestifier will continue to +use those inboxes to produce the digests for another sevral days. + +The reason we are putting off moving the digests is that, while we +have been given digestifiers for unix, we have also been told they are +not very effective. A noble volunteer is working on a new +digestifier, writing in GNU Emacs Lisp, which we expect to be more +useful than the currently available programs, and which we have every +hope will be ready before the old MC is physically turned off on 25 +May. If it isn't, we will temporarily use whichever of the +already-available digestifiers looks least unreasonable. Since the +situation is still very fluid, we can't guarantee that the digests +will work during this transitional period. You may wish to use the +Administrivia feature of the ITS digestifier to warn your list members +that things may not run smoothly during the next few weeks. + +Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 10 May 90 08:50:41 EDT +Received: from umich.edu by mintaka.lcs.mit.edu id aa17863; 10 May 90 8:40 EDT +Received: from ummts.cc.umich.edu by umich.edu (5.61/1123-1.0) + id AA28352; Thu, 10 May 90 08:40:03 -0400 +Date: Thu, 10 May 90 08:38:48 EDT +X-Modified: Modified by sender Thu, 10 May 90 08:39:26 EDT and reposted. +From: Pat_McGregor@um.cc.umich.edu +To: BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.lcs.mit.edu, CENT@MC.lcs.mit.edu, + EXPOTECH@applelink.apple.com +Cc: SCA-REQUEST%MC.LCS.MIT.EDU@MINTAKA.lcs.mit.edu, + Mailing-List-Administrator@um.cc.umich.edu +Message-Id: <6172788@um.cc.umich.edu> +Subject: Sca digest address problem + +Unto the Lady Eilonwy, redoubtable guardian of the Rialto, Ladie Catherine +Aimee and Gwynneth, and unto the estimable Mukra, my coworker, come greetings +from Siobhan Medhbh O'Roarke, with a foot in each World. + +Lady Catherine-Aimee's registration for the digest has been removed as of +5 minutes ago. Please add: + + EXPOTECH@applelink.apple.com + +in to the rolls ethereal immediately lest they become despondent over +their lack of connectedness! + +Regards, + + siobhan + +Date: Thu, 10 May 90 02:40:40 EDT +From: "Pandora B. Berman" +Subject: Sca digest address problem +To: BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, + "EXPOTECH@applelink.apple.com"@MINTAKA.LCS.MIT.EDU, + "postmaster@applelink.apple.com"@MINTAKA.LCS.MIT.EDU +cc: SCA-REQUEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, + mailing-list-administrator@UM.CC.UMICH.EDU, + smor@UM.CC.UMICH.EDU +Message-ID: <666791.900510.CENT@MC.LCS.MIT.EDU> + + Subject: Sca digest address problem + To: SCA-REQUEST@MC.lcs.mit.edu + From: "Expotech, Aimee Moran,VCA" + Date: 19 Apr 90 13:38 GMT + Milords, + Justin du Coeur indicated that you are the sysops for the Rialto, and + to lay our problem at your feet... + We have been receiving the Sca DIgests regularly for a couple of months + now. Last Sunday, April 15, AppleLink changed its gates with Internet + and Bitnet, so that although our personal messages are going out and + coming in okay, suddenly we are not receiving the digests. + Could you please check this out for us? Our internet address is: + Expotech@Applelink.apple.com + Thank you very kindly for your assistance. + Catherine-Aimee leMoyne + Gwynnyd of York + + Date: Thu, 19 Apr 90 21:56:14 EDT + From: MarkA_Davis@um.cc.umich.edu + To: postmaster@applelink.apple.com + Cc: sca-request@mc.lcs.mit.edu, Mailing-List-Administrator@um.cc.umich.edu + Subject: Mailing lists + The list administrator of the Society for Creative Anachronism mailing + list is having trouble sending to someone at your host. Could you + please investigate? + Also, there's really no need for the list to stop by the University of + Michigan on its way to apple. If it's agreeable to everyone else, I'd + like to remove EXPOTECH from our exploder and have it added to the main + list at MIT. + Mark Davis, mailing-list-administrator@um.cc.umich.edu, LISTADM@UMICHUM + + Cc: SMOR@um.cc.umich.edu, + "Expotech, Aimee Moran,VCA" + Subject: Digests lost... + To: SCA-REQUEST@mc.lcs.mit.edu + From: "Expotech, Aimee Moran,VCA" + Date: 09 May 90 13:37 GMT + Hello, SCA-sysops! + Lamentably we are still having fits with our AppleLink-Internet + address. We began getting the Digest again last week (we got 678, 679, + and 680) and then it stopped again. + I am in communication with the AppleLink Internet postmaster, and we + are pursuing the glitch to see if it originates at the gate. Would you + please, one more time, check our address and make sure it is + "expotech@applelink.apple.com"? Oddly, we are getting other mail which + is addressed that way, but not the Digest. Obviously, we miss the + digest, and wish also to be sure we're not missing other messages. + I am *greatly* appreciative of your efforts in this matter. + Sincerely, + Catherine-Aimee leMoyne + +All and sundry: We apologize about the delay in dealing with this problem. +One of our principal machines here decided to die in a permanent fashion, +and we have had to spend some time scurrying around picking up the pieces. + +Mark Davis: Yes, please remove the EXPOTECH address from your subsidiary +list. As long as APPLE.COM is on the Internet, there is no need for the +mail to clog your system by hopping in and out again. Let us know when +you have removed the address, and then we'll add it here. + +Catherine-Aimee and Gwynnyd: My ladies, as you can discern from the +messages above, we don't know how your address is given on the mailing +list, because your address isn't directly on the main list here. When Mr. +Davis or Mistress Siobhan has removed you at UMichigan, we will be glad to +add you here in the form you suggest. That may not, however, solve the +problem, as I explain below. + +AppleLink Postmaster: This is the bounce message we are receiving. Someone +in your part of the world seems to think that any mail over 32K long is too +long. That's very restrictive, and in the case of digested mailing lists +really can't be dealt with by having the author split the mail into smaller +chunks. Such lists often have digests longer than 32K -- our automatic +digestifying program is tuned to keep digests under 50K, which seems to be +the trip point for many systems. And administrators of such lists simply +don't have the time to specially cater to a small number of list members +whose systems complain in this fashion. Anything you can do to help would +be appreciated. Thank you. + + Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 22 Apr 90 03:58:30 EDT + Received: from umich.edu by mintaka.lcs.mit.edu id aa18158; 22 Apr 90 3:53 EDT + Received: from ummts.cc.umich.edu by umich.edu (5.61/1123-1.0) + id AA13505; Sun, 22 Apr 90 03:52:58 -0400 + Received: from umix.cc.umich.edu by um.cc.umich.edu via Internet with TCP; Sun, 22 Apr 90 03:52:40 EDT + Received: by umix.cc.umich.edu id AA05734; Sun, 22 Apr 90 03:42:35 EDT + Received: from [90.1.0.10] by apple.com with SMTP id AA06981; Sun, 22 Apr 90 00:38:45 -0700 for @um.cc.umich.edu:SCA-REQUEST@mc.lcs.mit.edu + Received: from apple.com by goofy.apple.com with SMTP id AA22231; Sun, 22 Apr 90 00:38:22 -0700 for fair@apple.com + Date: Sun, 22 Apr 90 00:38:22 -0700 + From: Mail Delivery Subsystem + Message-Id: <9004220738.AA22231@internal.apple.com> + To: bounces@apple.com + To: @um.cc.umich.edu:SCA-REQUEST@mc.lcs.mit.edu + MMDF-Warning: Parse error in original version of preceding line at lcs.mit.edu + Subject: Returned mail: Service unavailable + + ----- Transcript of session follows ----- + The maximum amount of text that a Macintosh "text edit" window + can display is 32K. Please break up your correspondence into + pieces that are smaller than that, and resend. + + letter too large (39461 bytes) from @Mintaka.lcs.mit.edu:SCA-Request@MC.LCS.MIT.EDU to expotech + 554 ... Service unavailable + + ----- Unsent message follows ----- + Received: from apple.com by goofy.apple.com with SMTP (5.61/25-eef) + id AA22229; Sun, 22 Apr 90 00:38:22 -0700 + for expotech + Received: from umich.edu by apple.com with SMTP (5.61/25-eef) + id AA06974; Sun, 22 Apr 90 00:38:15 -0700 + for EXPOTECH@applelink.apple.com + Received: from ummts.cc.umich.edu by umich.edu (5.61/1123-1.0) + id AA13289; Sun, 22 Apr 90 03:38:04 -0400 + Received: from umix.cc.umich.edu by um.cc.umich.edu via Internet with TCP; Sun, 22 Apr 90 03:37:47 EDT + Received: by umix.cc.umich.edu id AA05336; Sun, 22 Apr 90 03:31:20 EDT + Received: from mc.lcs.mit.edu by mintaka.lcs.mit.edu id aa17020; 22 Apr 90 3:22 EDT + Date: 22 Apr 90 03:11:59 EDT + From: Automatic SCA Digestifier <@Mintaka.lcs.mit.edu:SCA-Request@MC.LCS.MIT.EDU> + To: SCA%MC.LCS.MIT.EDU@Mintaka.lcs.mit.edu + Subject: SCA Digest #671 +[digest text omitted] + +Lady Eowyn Eilonwy of Alewife Brook, Deputy List Bureaucrat + +Date: Mon, 7 May 90 16:15:44 EDT +From: "Pandora B. Berman" +To: MLY%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +cc: BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +Message-ID: <665901.900507.CENT@MC.LCS.MIT.EDU> + + Date: Fri, 27 Apr 90 02:54:05 EDT + From: Alan Bawden + Subject: Digestification software + To: MLY%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU + cc: BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU + Date: Thu, 26 Apr 90 11:42:00 EDT + From: Richard Mlynarik + Subject: Digestification software + To: BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU + cc: MLY%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU + Using the advanced ITS  feature I hear that there is + some consideration of using some mess of unix shell scripts + to try to support the present crop of digests in the brave new + future. + I think a much better idea would be for me to volunteer to write + the necessary code in gnu emacs (the only decent system programming + environment for unix!) + Sounds like an excellent idea to me. I forget if you grok MIDAS code, but + if you do, you should look through MC:DIGEST;DIGEST > to see what the + current one does. I'm pretty happy with it. + +i don't mean to rush you, but what's the prognosis on this? alan would like +to start shutting things down in about two weeks. i have received copies of +two things which claim to be unixish digestifiers, which i haven't yet +tried to show to anyone knowledgeable about unix, so i have no idea how +close they would come to our current mode of operations or how effective +they would be. + +Date: Fri, 27 Apr 90 02:54:05 EDT +From: Alan Bawden +Subject: Digestification software +To: MLY%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +cc: BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +Reply-to: Alan@Reagan.AI.MIT.EDU +In-reply-to: Msg of Thu 26 Apr 90 11:42:00 EDT from Richard Mlynarik +Message-ID: <663499.900427.ALAN@MC.LCS.MIT.EDU> + + Date: Thu, 26 Apr 90 11:42:00 EDT + From: Richard Mlynarik + ... + I think a much better idea would be for me to volunteer to write + the necessary code in gnu emacs ... + + If anybody wants me to act on this offer, speak up. + +Sounds like an excellent idea to me. I forget if you grok MIDAS code, but +if you do, you should look through MC:DIGEST;DIGEST > to see what the +current one does. I'm pretty happy with it. + +Date: Thu, 26 Apr 90 11:42:00 EDT +From: Richard Mlynarik +Subject: Digestification software +To: BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +cc: MLY%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +Message-ID: <663307.900426.MLY@MC.LCS.MIT.EDU> + +Using the advanced ITS  feature I hear that there is +some consideration of using some mess of unix shell scripts +to try to support the present crop of digests in the brave new +future. + +I think a much better idea would be for me to volunteer to write +the necessary code in gnu emacs (the only decent system programming +environment for unix!) + +If anybody wants me to act on this offer, speak up. + +Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 11:48:45 EDT +Received: from A.GP.CS.CMU.EDU by mintaka.lcs.mit.edu id aa22983; + 20 Apr 90 11:46 EDT +From: Christopher Maeda +Date: Fri, 20 Apr 90 11:45:14 EDT +To: mt@media-lab.media.mit.edu +CC: bug-digest@MC.lcs.mit.edu +In-reply-to: Michael Travers's message of Fri, 20 Apr 90 00:29 EDT <19900420042942.4.MT@OUROBOROS.MEDIA.MIT.EDU> +Subject: Indigestion +Reply-to: cmaeda@cs.cmu.edu +Message-ID: <9004201146.aa22983@mintaka.lcs.mit.edu> + +Since aviation has become entirely a usenet forward, I was thinking of +writing something that will grab news from an nntp server and digest +it. Anyone know if something like that has been done already? + +Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 09:55:03 EDT +Received: from life.ai.mit.edu by mintaka.lcs.mit.edu id aa17297; + 20 Apr 90 9:51 EDT +Received: from PIGPEN.AI.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA27180; Fri, 20 Apr 90 09:50:24 EDT +Date: Fri, 20 Apr 90 09:47 EDT +From: Alan Bawden +Subject: Indigestion +To: cygint!Gumby@labrea.stanford.edu, mt@media-lab.media.mit.edu +Cc: bug-digest@mc.lcs.mit.edu +In-Reply-To: <9004200532.AA18951@cygnus.com> +Message-Id: <19900420134759.6.ALAN@PIGPEN.AI.MIT.EDU> + + Date: Thu, 19 Apr 90 22:32:37 PDT + From: Gumby Vinayak Wallace + ... + Contact the guy who now maintains dead-flames. His name's Mark + Rouleau; I think his address is mer6@virginia.edu. I dunno; his phone + numbers are (were?) 804 924 0631 (W) or 804 971 7473 (H). + + Hmm, I think I left his name in the NAMES file on MC in a comment near + the entry for dead-flames-digest. + +I reached him once by mailing to Dead-Flames-Request@MC (which forwards to +Dead-Flames-Request@Virginia.EDU). + +Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 01:52:55 EDT +Received: from labrea.Stanford.EDU by mintaka.lcs.mit.edu id aa01005; + 20 Apr 90 1:50 EDT +Received: by labrea.stanford.edu; Thu, 19 Apr 90 21:50:47 PST +Received: by cygnus.com (4.0/SMI-4.0) + id AA18951; Thu, 19 Apr 90 22:32:37 PDT +Date: Thu, 19 Apr 90 22:32:37 PDT +From: Gumby Vinayak Wallace +Message-Id: <9004200532.AA18951@cygnus.com> +To: mt@media-lab.media.mit.edu +Cc: bug-digest@mc.lcs.mit.edu +Reply-To: cygint!Gumby@labrea.stanford.edu +In-Reply-To: Michael Travers's message of Fri, 20 Apr 90 00:29 EDT <19900420042942.4.MT@OUROBOROS.MEDIA.MIT.EDU> +Subject: Indigestion + + Date: Fri, 20 Apr 90 00:29 EDT + From: Michael Travers + + So, does anybody know of any decent digesters that run on something + besides ITS? I have a package called Digest.Kit that comes from HP and + consists of horrible unix shell scripts and such, but I don't think I + will like it. + +Contact the guy who now maintains dead-flames. His name's Mark +Rouleau; I think his address is mer6@virginia.edu. I dunno; his phone +numbers are (were?) 804 924 0631 (W) or 804 971 7473 (H). + +Hmm, I think I left his name in the NAMES file on MC in a comment near +the entry for dead-flames-digest. + +Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU; 20 Apr 90 00:38:54 EDT +Received: from media-lab.media.mit.edu by mintaka.lcs.mit.edu id aa28552; + 20 Apr 90 0:34 EDT +Received: by media-lab (5.57/4.8) id AA05909; Fri, 20 Apr 90 00:34:31 EDT +Date: Fri, 20 Apr 90 00:29 EDT +From: Michael Travers +Subject: Indigestion +To: bug-digest@MC.lcs.mit.edu +Message-Id: <19900420042942.4.MT@OUROBOROS.MEDIA.MIT.EDU> + +So, does anybody know of any decent digesters that run on something +besides ITS? I have a package called Digest.Kit that comes from HP and +consists of horrible unix shell scripts and such, but I don't think I +will like it. + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU; 15 Jan 90 02:54:28 EST +Date: Mon, 15 Jan 90 02:55:55 EST +From: "Pandora B. Berman" +Subject: feature wanted +To: BUG-DIGEST%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU +Message-ID: <688844.900115.CENT@AI.AI.MIT.EDU> + + Date: 15 Jan 90 02:17:08 EST + From: Automatic SCA Digestifier + + To: SCA%MC.LCS.MIT.EDU@Mintaka.LCS.MIT.EDU + Subject: SCA Digest #573 + + Today's Topics: + + Arval's blazon + Events near Dayton + +there were two topics for today's digest (see above), but three included +msgs -- two msgs had the same topic. please implement the proposal to +include a count with topics used multiple times. the idea of adding, below +the topics, a line to the effect of "there were 17 msgs which gave no +subject" is also a good idea.. + +Date: Sat, 13 Jan 90 04:22:38 EST +From: Alan Bawden +Subject: OK, so now we have -three- digestifiers running on MC... +To: BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +Message-ID: <637839.900113.ALAN@MC.LCS.MIT.EDU> + +I have written a new digestifier. Currently only the SCA digest is using +it, but I would like to convert the others as soon as I am satisfied that +it doesn't have any problems. See MC:DIGEST;DIGEST ORDER for +documentation, MC:DIGEST;DEFS > for individual digest definitions, and +MC:DIGEST;LOG > for a log of its actions. + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Sep 89 14:48:09 EDT +Date: Tue, 5 Sep 89 14:50:35 EDT +From: David Chapman +Subject: Digestifier +To: "bawden@PARC.XEROX.COM"@MINTAKA.LCS.MIT.EDU +cc: BUG-DIGEST@MC.LCS.MIT.EDU, Postmaster@MC.LCS.MIT.EDU +In-reply-to: Msg of Tue 5 Sep 89 10:46 PDT from Alan Bawden +Message-ID: <640987.890905.ZVONA@AI.AI.MIT.EDU> + + Perhaps somebody should fix the digestifier to put a legal address in the + header. There is no machine named "MINTAKA.MC.LCS.EDU". I though only + Unix weenies made mistakes like that, not people who dare to touch PDP-10 + code. + +My fault. What an amazing braino. I'm quite surprised no one has +noticed it before. (Maybe many people did and sent complaints to +foo-request%mc.lcs.mit.edu@mintaka.mc.lcs.edu?) + +Anyway. Fixed in the source and installed. + + +Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 5 Sep 89 13:54:07 EDT +Received: from arisia.Xerox.COM by mintaka.lcs.mit.edu id aa07683; + 5 Sep 89 13:49 EDT +Received: from roo.parc.Xerox.COM by arisia.Xerox.COM with SMTP + (5.61+/IDA-1.2.8/gandalf) id AA15855; Tue, 5 Sep 89 10:45:05 -0700 +Received: from mr-bun.parc.Xerox.COM by roo.parc.xerox.com with SMTP + (5.61+/IDA-1.2.8/gandalf) id AA02295; Tue, 5 Sep 89 10:48:06 PDT +Date: Tue, 5 Sep 89 10:46 PDT +From: Alan Bawden +Subject: Digestifier +To: Postmaster@mc.lcs.mit.edu +Cc: BUG-DIGEST@mc.lcs.mit.edu +Message-Id: <19890905174629.9.ALAN@MR-BUN.parc.xerox.com> + +Perhaps somebody should fix the digestifier to put a legal address in the +header. There is no machine named "MINTAKA.MC.LCS.EDU". I though only +Unix weenies made mistakes like that, not people who dare to touch PDP-10 +code. + + Date: 4 SEP 89 00:04:44 EDT + From: Automatic SubGenius Digestifier + Subject: SubGenius Digest #260 + To: SubGenius%mc.lcs.mit.edu@mintaka.mc.lcs.edu + Reply-To: SubGenius%mc.lcs.mit.edu@mintaka.mc.lcs.edu + Message-Id: <8909040029.aa11726@mintaka.lcs.mit.edu> + + SubGenius Digest #260 4 SEP 89 00:04:44 EDT + +I suppose I should also complain about the Scheme digest that showed up +truncated the other day. I don't know where it got truncated (and I'm +actually glad it was, because some pinhead tried to mail out the entire +XScheme sources), but some IO screwup in the digestifier would be a good +candidate. + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 1 Aug 89 21:41:06 EDT +Date: Tue, 1 Aug 89 21:41:00 EDT +From: David Chapman +To: BUG-DIGEST%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU +In-reply-to: Msg of Sat 29 Jul 89 11:58:51 EDT from David Chapman +Message-ID: <628385.890801.ZVONA@AI.AI.MIT.EDU> + + Date: Sat, 29 Jul 89 11:58:51 EDT + From: David Chapman + To: BUG-DIGEST%MC.LCS.MIT.EDU at MINTAKA.LCS.MIT.EDU + + The digester ought to make %'ed reply-to: fields, since a lot of + people's mailers don't grok MX records and can't reply to MC. + + I'll fix this in a crockish way soon if someone doesn't do it in a + clean way... (I don't know MIDAS, but I do know FORMAT!) + +I did this. + + +Date: Sat, 29 Jul 89 11:58:51 EDT +From: David Chapman +To: BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +Message-ID: <602793.890729.ZVONA@MC.LCS.MIT.EDU> + +The digester ought to make %'ed reply-to: fields, since a lot of +people's mailers don't grok MX records and can't reply to MC. + +I'll fix this in a crockish way soon if someone doesn't do it in a +clean way... (I don't know MIDAS, but I do know FORMAT!) + +Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 26 May 89 14:24:38 EDT +Received: from reagan.ai.mit.edu by mintaka.lcs.mit.edu id aa23726; + 26 May 89 14:21 EDT +Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 214311; Fri 26-May-89 14:20:25 EDT +Date: Fri, 26 May 89 14:20 EDT +From: Alan Bawden +Subject: fryer +To: MAEDA%MC.LCS.MIT.EDU@lcs.mit.edu +cc: SRA%MC.LCS.MIT.EDU@lcs.mit.edu, BUG-DIGEST%MC.LCS.MIT.EDU@lcs.mit.edu +In-Reply-To: <584376.890526.MAEDA@MC.LCS.MIT.EDU> +Message-ID: <19890526182020.7.ALAN@PIGPEN.AI.MIT.EDU> + + Date: Fri, 26 May 89 06:15:42 EDT + From: "Christopher M. Maeda" + ... If it doesn't lose, I'll put in the rest + in a couple of days. + +Please wait until I look at it before giving it to the other digests. + +Date: Fri, 26 May 89 06:15:42 EDT +From: "Christopher M. Maeda" +Subject: fryer +To: alan@AI.AI.MIT.EDU +cc: SRA%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU, BUG-DIGEST%MC.LCS.MIT.EDU@MINTAKA.LCS.MIT.EDU +Message-ID: <584376.890526.MAEDA@MC.LCS.MIT.EDU> + +I finished the error handlers for Fryer and tested it out on some +digests. It seems to work so I installed it on MC. It's only set up +to do the aviation digest. If it doesn't lose, I'll put in the rest +in a couple of days. + +The code is in mc:maeda;fryer >. +The aviation digest is handled by dragon;daily digest. + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Mar 89 03:17:21 EST +Date: Fri, 31 Mar 89 03:17:52 EST +From: "Christopher M. Maeda" +To: CENT@AI.AI.MIT.EDU +cc: ALAN@AI.AI.MIT.EDU, SRA@LCS.MIT.EDU, + BUG-DIGEST@MC.LCS.MIT.EDU +In-reply-to: Msg of Fri 31 Mar 89 02:33:11 EST from Pandora B. Berman +Message-ID: <567012.890331.MAEDA@AI.AI.MIT.EDU> + + Date: Fri, 31 Mar 1989 02:10 EST + From: Rob Austein + To: "Pandora B. Berman" , MAEDA@AI.AI.MIT.EDU + Cc: Bug-DIGEST@MC.LCS.MIT.EDU + FYI, -all- the digests are running the new version of the digestifier. + Chris has been overexposed to unix and I guess he thought he was + making a hard link, not a symbolic link. + + well, fuck me harder. alan says he thought he urged chris to de-install the + new one because he (alan) had discovered by eyeballing the code that it + wouldn't work. if chris didn't, please do it yourself. + +Huh? The new digest is dragon;dgstbg bin. I did a ":link daily +aviatn,dgstbg bin" and then deleted it the next day and linked it back +to digest bin. I don't think any of the digests were running the new +software (except aviatn for one day). I got another "digest too big" +bounce after I put back aviatn, too. + +I could be wrong though. What *is* the difference between a hard link +and a symbolic link? + + +Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 31 Mar 89 03:12:09 EST +Date: Fri, 31 Mar 1989 03:13 EST +Message-ID: +From: Rob Austein +To: "Pandora B. Berman" +Cc: ALAN@AI.AI.MIT.EDU, BUG-DIGEST@MC.LCS.MIT.EDU, MAEDA@AI.AI.MIT.EDU, + sra@XX.LCS.MIT.EDU +In-reply-to: Msg of 31 Mar 1989 02:33-EST from "Pandora B. Berman" + +I jumped to confusions. Should have said "all the digests are running +from the same binary" (ie, all of Puff's links point at the same +file). Closer examination shows that I mis-read the (stupid numeric +month format) date and that the version that's actually running is one +I compiled on 24 Feb 89. + +Sorry for the false alarm. + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 31 Mar 89 02:32:46 EST +Date: Fri, 31 Mar 89 02:33:11 EST +From: "Pandora B. Berman" +To: SRA@LCS.MIT.EDU +cc: CENT@AI.AI.MIT.EDU, MAEDA@AI.AI.MIT.EDU, ALAN@AI.AI.MIT.EDU, + BUG-DIGEST@MC.LCS.MIT.EDU +Message-ID: <566995.890331.CENT@AI.AI.MIT.EDU> + + Date: Fri, 31 Mar 1989 02:10 EST + From: Rob Austein + To: "Pandora B. Berman" , MAEDA@AI.AI.MIT.EDU + Cc: Bug-DIGEST@MC.LCS.MIT.EDU + FYI, -all- the digests are running the new version of the digestifier. + Chris has been overexposed to unix and I guess he thought he was + making a hard link, not a symbolic link. + +well, fuck me harder. alan says he thought he urged chris to de-install the +new one because he (alan) had discovered by eyeballing the code that it +wouldn't work. if chris didn't, please do it yourself.. + +Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 31 Mar 89 02:09:01 EST +Date: Fri, 31 Mar 1989 02:10 EST +Message-ID: +From: Rob Austein +To: "Pandora B. Berman" , MAEDA@AI.AI.MIT.EDU +Cc: Bug-DIGEST@MC.LCS.MIT.EDU +In-reply-to: Msg of 30 Mar 1989 23:30-EST from "Pandora B. Berman" + +FYI, -all- the digests are running the new version of the digestifier. +Chris has been overexposed to unix and I guess he thought he was +making a hard link, not a symbolic link. + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 Mar 89 08:29:31 EST +Received: from JONES.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 26 MAR 89 08:29:22 EST +Date: Sun, 26 Mar 89 08:27 EST +From: Christopher Maeda +Subject: digestifier +To: bug-digest@MC.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU +Message-ID: <19890326132732.1.MAEDA@JONES.AI.MIT.EDU> + +I just fixed it to break up large digests. It counts characters and +messages while parsing the subject lines. Once it reads more than the +maximum number of characters, it quits reading in messages and writes +them out instead. Any unread messages are then copied to a file called +JNAME _OLD_. The digestifier then writes another digest. It stops when +there is no more _OLD_ files and no inbox left. + +These changes are in the latest version of digest > in mc:gumby; I +copied the binary to dragon;dgstbg bin and linked the daily aviatn demon +to it. If everything goes ok for the next couple of days, we can link +the rest of the digests to it. + +Chris + + +Date: Fri, 24 Feb 89 23:36:03 EST +From: Rob Austein +Subject: Digests moved to COMSAT BULK +To: DEAD-FLAMES-REQUEST@MC.LCS.MIT.EDU, + AVIATION-REQUEST@MC.LCS.MIT.EDU, + PAGANISM-REQUEST@MC.LCS.MIT.EDU, SCA-REQUEST@MC.LCS.MIT.EDU, + SUBGENIUS-REQUEST@MC.LCS.MIT.EDU, SCHEME-REQUEST@MC.LCS.MIT.EDU +cc: BUG-MAIL@MC.LCS.MIT.EDU, BUG-DIGEST@MC.LCS.MIT.EDU +Reply-To: Bug-MAIL@AI.AI.MIT.EDU +Message-ID: <544373.890224.SRA@MC.LCS.MIT.EDU> + +Now that we have all of Alan's good work on making COMSAT use the +LOCK: device, it seemed ok to move the digests to COMSAT BULK. So I +did. The actual switch was a one line change to GUMBY;DIGEST >. + +The only change this entails from the point of view of a digest +administrator is that you should look in MC:.BULK.; for [O]STATS files +if you care about such things, rather than in MC:.MAIL.;. The various +mailing lists still reside in MC:.MAIL.;NAMES > and should remain +there; the NAMES file in .BULK. should never be anything besides a +link to the one in .MAIL.; or chaos will ensue. + +Obviously, any digests that have already been sent out via regular +COMSAT will remain in regular COMSAT's queue until they are delivered +or time out. But digests posted from now on will go via COMSAT BULK. + +The overall result of this change should be improved performance for +both digests and regular mail, since the main effect will be to lessen +contention for MC's regular COMSAT's limited processing time. + +Please report any problems you think may have been caused by this +change to BUG-MAIL. + +--Rob + +Date: Fri, 24 Feb 89 05:27:18 EST +From: Alan Bawden +Subject: Local mailbox screw eliminated +To: BUG-MAIL@MC.LCS.MIT.EDU, BUG-DIGEST@MC.LCS.MIT.EDU, + NICK@MC.LCS.MIT.EDU +Message-ID: <1915.890224.ALAN@MC.LCS.MIT.EDU> + +COMSAT now uses the LOCK: device to coordinate access to local mailboxes. +See the code for gory details. MC:.BULK.;NAMES 999999 is now a link to +MC:.MAIL.;NAMES >. In theory, new mail can be placed in either +.MAIL.;MAIL > -or- .BULK.;MAIL > and it should be delivered to exactly the +same places. + +Mail hacker visible changes: + + 1. The newest version of COMSAT will not run under an ITS without the + LOCK: device. Under ITS versions before 1630 COMSAT will crash. + Currently AI, MC, and ML are running ITS version 1632, and the new + COMSAT is installed on all of them. If we have to revert to an + earlier version of ITS on any of these machines (heaven forbid!) then + we will have to revert to the previous COMSAT, and on MC we would + have to shut down the BULK COMSAT completely (if you don't see why, + you haven't thought about it hard enough!). + + 2. Occasionally you will now see a line in the STATS file like: + + 030310 TO->GLURK(USERS1;)... Inbox locked. + + This means that mailer found that some other COMSAT (or the GMSGS + program, which I hacked to do this locking as well) was in the + process of hacking the mailbox in question. This will be treated as + a temporary error, and the mail will be queued for later delivery. + + 3. Since -both- mailers on MC compile the NAMES file separately, it + now takes -double- the CPU time to install a new NAMES file. This is + a waste since both compilations (presumably) result in equivalent + LIST EQV files. Sorry. + + 4. I copied the entries for the AIList mailing list from the + .BULK.;NAMES > into .MAIL.;NAMES > (these were the only BULK-specific + mailing lists). No one should -ever- create a separate NAMES file + for the BULK COMSAT again. + + 5. Since both mailers have the same NAMES file, they now both deliver + failed mail to .MAIL.;FAILED STUFF. + +Please note that the BULK COMSAT continues to be a totally independent +mailer. It shares the NAMES file, but all of its queues and databases are +its own. + +I suppose the various digests can be switched over to using .BULK. whenever +their maintainers feel that they want to give it a try. + +(The LOCK: device is documented in .INFO.;ITS LOCKS for those that want to +learn more about how this works.) + +(To help test this all out, this mail will be delivered by the BULK COMSAT.) + +Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 23 Feb 89 21:11:17 EST +Received: from QUESTION-AUTHORITY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 176157; Thu 23-Feb-89 21:11:44 EST +Date: Thu, 23 Feb 89 21:08 EST +From: Alan Bawden +Subject: Which mailer should digests use? +To: GUMBY@AI.AI.MIT.EDU +cc: CENT@AI.AI.MIT.EDU, SRA@XX.LCS.MIT.EDU, BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU +In-Reply-To: <543211.890223.GUMBY@AI.AI.MIT.EDU> +Message-ID: <19890224020836.2.ALAN@QUESTION-AUTHORITY.AI.MIT.EDU> + + Date: Thu, 23 Feb 89 02:52:52 EST + From: David Vinayak Wallace + Date: Wed, 22 Feb 89 02:32:36 EST + From: Pandora B. Berman + then there would be the possibility of getting both comsats to use a + single NAMES file. + + Yow, what an idea. Why not; I guess they both use the same lsr file. + Bulk shouldn't write FAILED files; if it lost presumably so would + the mailer in .mail. + +I presume by "FAILED files" you are talking about the files named +"NAMED ERRnnn"? Since the bulk Comsat would be writing them in .BULK. I +don't see why it should be prevented from generating them. + + alan also just wondered what would happen if both + comsats tried to put stuff into FAILED STUFF; how will the loser handle + the resulting error? + + I don't understand; couldn't it just block? This seems to me to be + the same as someone typing gumby and then going to lunch while it's + in a more break. + +When COMSAT discovers that someone typed gumby and so it gets a FILE +LOCKED error it doesn't "block". Insead it gets a temporary error, fails +to deliver the message, and requeues it. Comsat never blocks delivering +mail, nor should it when we introduce the appropriate locking. When a +Comsat finds that a local mailbox is locked by another Comsat, it will +treat the error as a temporary error and requeue the message for later. + +I was wondering about FAILED STUFF because I couldn't recall whether it was +a special case, being the destination of last resort, or just another +mailing list. If it really is just another mailing list, then there +shouldn't be any problem. + +Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 23 Feb 89 20:52:55 EST +Date: Thu, 23 Feb 1989 20:52 EST +Message-ID: +From: Rob Austein +To: David Chapman +Cc: BUG-digest@MC.LCS.MIT.EDU, BUG-mail@MC.LCS.MIT.EDU, Alan@AI.AI.MIT.EDU +Subject: I >thought< I remembered there being a more complex screw: + + Date: Thursday, 23 February 1989 20:02-EST + From: David Chapman + + Date: Wed, 26 Oct 88 17:25 EDT + From: Alan Bawden + + Hold on. It's not as easy as you think to control local delivery. + Recall that people can change their INQUIR entries to say that + mail should be sent to them @MC, which the BULK mailer will see, + and then they can edit .MAIL.;NAMES > to say where it should + really go, which the BULK mailer will -not- see, and it will thus + start delivering locally. Also, when the host table changes, and + an address suddenly becomes unparsable, the mailer will revert to + local delivery. + +Huh? If COMSAT BULK sends mail to USER@AI and USER has her INQUIR +entry forwarding mail to USER@MC, AI will ship the mail back to MC's +normal COMSAT, which will see .MAIL.;NAMES and will do the right +thing. That's the whole point of sending the mail to AI instead of +having COMSAT BULK deliver it locally on MC. + +If AI becomes an unparsable address I think we will have bigger things +to worry about than where the subgenius mailing list goes. + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Feb 89 20:01:39 EST +Date: Thu, 23 Feb 89 20:02:09 EST +From: David Chapman +Subject: I >thought< I remembered there being a more complex screw: +To: BUG-digest@MC.LCS.MIT.EDU, BUG-mail@MC.LCS.MIT.EDU +Message-ID: <543767.890223.ZVONA@AI.AI.MIT.EDU> + +Date: Wed, 26 Oct 88 17:25 EDT +From: Alan Bawden +Subject: bulk digests +To: ZVONA@AI.AI.MIT.EDU +cc: BUG-MAIL@AI.AI.MIT.EDU + + Date: Tue, 25 Oct 88 14:59:15 EDT + From: David Chapman + So as long as there are no local recipients on a BULK list, it's OK? + That's easy, then: indirect local recpients, if any, through AI or + someplace. + + Should we start systematically moving big lists to BULK? + +Hold on. It's not as easy as you think to control local delivery. Recall +that people can change their INQUIR entries to say that mail should be sent +to them @MC, which the BULK mailer will see, and then they can edit +.MAIL.;NAMES > to say where it should really go, which the BULK mailer will +-not- see, and it will thus start delivering locally. Also, when the host +table changes, and an address suddenly becomes unparsable, the mailer will +revert to local delivery. + +It would be better if we were to first introduce a lock to control local +delivery, and then arrange for the BULK mailer to share the NAMES file +somehow. + + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Feb 89 15:51:14 EST +Date: Thu, 23 Feb 89 15:51:42 EST +From: David Chapman +To: BUG-digest@MC.LCS.MIT.EDU, postmaster@MC.LCS.MIT.EDU +Message-ID: <543586.890223.ZVONA@AI.AI.MIT.EDU> + +While I think of it: there's one thing that running the digests +through bulk WON'T do for us, which is probably the thing we actually +want, and that is to improve percieved mailer response. The digests +go out at night, when not many people are on. During the day they +contribute very little to mailer load. The SIMTEL stuff comes in +during the day (at random, essentially, whenever SIMTEL thinks to talk +to MC and (for some bizzare reason) its actually willing to accept +mail). I get a fair amount of my mail through MC and am frustrated at +the slow turn around; bulking the digests won't help with that. + + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Feb 89 08:07:56 EST +Received: from NICO.AI.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 22 FEB 89 15:16:28 EST +Date: Wed, 22 Feb 89 15:13 EST +From: Christopher Maeda +Subject: Bulk Mailer Screw Conditions +To: SRA@XX.LCS.MIT.EDU +cc: bug-digest@MC.LCS.MIT.EDU, jtw@XX.LCS.MIT.EDU, alan@AI.AI.MIT.EDU +In-Reply-To: +Message-ID: <19890222201349.3.MAEDA@NICO.AI.MIT.EDU> + + Date: Mon, 20 Feb 1989 23:01 EST + From: Rob Austein + + Date: Monday, 20 February 1989 17:23-EST + From: David Chapman + But you + didn't answer my questions: what are the screw conditions, and how do + we do this? + + We do it by changing the word ".MAIL." to the word ".BULK." in the + digestifier source code. + +This sounds so simple even I could do it. (I even volunteer.) What are +the differences between the two comsats? Do they really not require any +of the headers to be munged in the generated message (or anything else +like that)? + + The screws that I know of involve the lack of any file locking + protocol that will keep the two COMSATs from treading on each other's + toes should they happen to attempt to update the same file at the same + time. At one point Alan had some plan for fixing this but I don't + know if it got finished. The usual fix at the moment is to use + separate inboxes for the two mailers. Eg, ARPANET-BBOARDS-BUGS (the + SMTP source path given in ANBB postings) traslates to two different + filenames: .MAIL.;NAMES translates it to ANBB;BBOARD BUGS and + .BULK.;NAMES translates it to ANBB;BBOARD ANTS. Not a big deal. + Delivering to a local (on MC) user mailbox via COMSAT BULK is a bad + idea, for similar reasons; fortunately, don't have any user mailboxes + on MC, so we don't care. + +Does this screw case just apply to MC since there are two comsats +running? I can see how local delivery would cause the comsats to step +on each other. I don't see how this would apply otherwise. + + There is also a screw involving the way some + people forard their mail using both NAMES > and INQUIR, which Alan can + describe if you really care; the short answer is that mail sent + through COMSAT BULK to somebody whose INQUIR entry says that they read + their mail on MC should be sent to some other ITS machine (probably + AI) instead of attempting to deliver it locally. + +I modified aviation's distribution file so that any local (mc) addresses +get sent to ai. Is this the simple solution? + + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Feb 89 08:07:46 EST +Date: Thu, 23 Feb 89 02:52:52 EST +From: David Vinayak Wallace +Subject: Which mailer should digests use? +To: CENT@AI.AI.MIT.EDU +cc: ALAN@AI.AI.MIT.EDU, SRA@LCS.MIT.EDU, + BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU +In-reply-to: Msg of Wed 22 Feb 89 02:32:36 EST from Pandora B. Berman +Message-ID: <543211.890223.GUMBY@AI.AI.MIT.EDU> + + Date: Wed, 22 Feb 89 02:32:36 EST + From: Pandora B. Berman + then there would be the possibility of getting both comsats to use a + single NAMES file. +Yow, what an idea. Why not; I guess they both use the same lsr file. +Bulk shouldn't write FAILED files; if it lost presumably so would +the mailer in .mail. + + alan also just wondered what would happen if both + comsats tried to put stuff into FAILED STUFF; how will the loser handle + the resulting error? + +I don't understand; couldn't it just block? This seems to me to be +the same as someone typing gumby and then going to lunch while it's +in a more break. + + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Feb 89 08:07:41 EST +Date: Thu, 23 Feb 89 02:47:34 EST +From: David Vinayak Wallace +Subject: Which mailer should digests use? +To: SRA@MC.LCS.MIT.EDU +cc: BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU +In-reply-to: Msg of Sat 18 Feb 89 05:16:24 EST from Rob Austein +Message-ID: <543209.890223.GUMBY@AI.AI.MIT.EDU> + +This is a good idea if you can get the comsats to lock each other out. +I think the restrictions on local addresses probably aren't too bad +(just tell digest maintainers that each name on their list should be +qualified -- and local addresses should appear as foo@ai). + + +Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 23 Feb 89 00:18:34 EST +Date: Wed, 22 Feb 1989 16:10 EST +Message-ID: +From: Rob Austein +To: Christopher Maeda +Cc: alan@AI.AI.MIT.EDU, bug-digest@MC.LCS.MIT.EDU, jtw@LCS.MIT.EDU, + sra@LCS.MIT.EDU +Subject: Bulk Mailer Screw Conditions +In-reply-to: Msg of 22 Feb 1989 15:13-EST from Christopher Maeda + + Date: Wednesday, 22 February 1989 15:13-EST + From: Christopher Maeda + + We do it by changing the word ".MAIL." to the word ".BULK." in the + digestifier source code. + + This sounds so simple even I could do it. (I even volunteer.) What are + the differences between the two comsats? Do they really not require any + of the headers to be munged in the generated message (or anything else + like that)? + +I don't see why it would require special munging, it's just another +COMSAT. You do have to think about what you're doing, but you have to +do that with the current setup too. + + Does this screw case just apply to MC since there are two comsats + running? + +Right. + + I modified aviation's distribution file so that any local (mc) addresses + get sent to ai. Is this the simple solution? + +That should handle the INQUIR problem. The worse case if you do that +is that AI will ship it back to MC's regular COMSAT for delivery. + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Feb 89 03:39:39 EST +Date: Wed, 22 Feb 89 02:32:36 EST +From: "Pandora B. Berman" +Subject: Which mailer should digests use? +To: SRA@LCS.MIT.EDU +cc: ALAN@AI.AI.MIT.EDU, BUG-DIGEST@MC.LCS.MIT.EDU, + POSTMASTER@MC.LCS.MIT.EDU +Message-ID: <542452.890222.CENT@AI.AI.MIT.EDU> + + Date: Mon, 20 Feb 1989 23:01 EST + From: Rob Austein + To: David Chapman + Cc: BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU + Subject: Which mailer should digests use? + .... + The screws that I know of involve the lack of any file locking + protocol that will keep the two COMSATs from treading on each other's + toes should they happen to attempt to update the same file at the same + time. At one point Alan had some plan for fixing this but I don't + know if it got finished.... + +alan has not been partaking of this discussion because he isn't on +postmaster or bug-digest (and says he doesn't want to be). i have forwarded +to him the relevant pieces of this discussion. he says the fix to keep the +2 comsats from tromping on each other is to insert a lock into the place in +comsat that does local delivery. if someone will kindly inform him where to +find this, he can insert the lock. + then there would be the possibility of getting both comsats to use a +single NAMES file. alan also just wondered what would happen if both +comsats tried to put stuff into FAILED STUFF; how will the loser handle +the resulting error? + + +Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 20 Feb 89 23:03:04 EST +Date: Mon, 20 Feb 1989 23:01 EST +Message-ID: +From: Rob Austein +To: David Chapman +Cc: BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU +Subject: Which mailer should digests use? +In-reply-to: Msg of 20 Feb 1989 17:23-EST from David Chapman + + Date: Monday, 20 February 1989 17:23-EST + From: David Chapman + But you + didn't answer my questions: what are the screw conditions, and how do + we do this? + +We do it by changing the word ".MAIL." to the word ".BULK." in the +digestifier source code. + +The screws that I know of involve the lack of any file locking +protocol that will keep the two COMSATs from treading on each other's +toes should they happen to attempt to update the same file at the same +time. At one point Alan had some plan for fixing this but I don't +know if it got finished. The usual fix at the moment is to use +separate inboxes for the two mailers. Eg, ARPANET-BBOARDS-BUGS (the +SMTP source path given in ANBB postings) traslates to two different +filenames: .MAIL.;NAMES translates it to ANBB;BBOARD BUGS and +.BULK.;NAMES translates it to ANBB;BBOARD ANTS. Not a big deal. +Delivering to a local (on MC) user mailbox via COMSAT BULK is a bad +idea, for similar reasons; fortunately, don't have any user mailboxes +on MC, so we don't care. There is also a screw involving the way some +people forard their mail using both NAMES > and INQUIR, which Alan can +describe if you really care; the short answer is that mail sent +through COMSAT BULK to somebody whose INQUIR entry says that they read +their mail on MC should be sent to some other ITS machine (probably +AI) instead of attempting to deliver it locally. + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Feb 89 17:23:46 EST +Date: Mon, 20 Feb 89 17:23:43 EST +From: David Chapman +Subject: Which mailer should digests use? +To: SRA@LCS.MIT.EDU +cc: BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU +In-reply-to: Msg of Mon 20 Feb 1989 17:02 EST from Rob Austein +Message-ID: <541433.890220.ZVONA@AI.AI.MIT.EDU> + + The digest stuff, on the other hand, is simply a silly use of the + resources that we already have. COMSAT BULK is nearly idle, and the + digests are the one thing that could easily be moved there. + +Well, as I said, I think that bulkifying digsts is a reasonable thing +to do, regardless of the resolution of the SIMTEL issue. But you +didn't answer my questions: what are the screw conditions, and how do +we do this? + + +Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 20 Feb 89 17:03:58 EST +Date: Mon, 20 Feb 1989 17:02 EST +Message-ID: +From: Rob Austein +To: David Chapman +Cc: BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU +Subject: Which mailer should digests use? +In-reply-to: Msg of 20 Feb 1989 16:36-EST from David Chapman + +As far as I know, the SIMTEL20 people started doing it unilaterally. +There is some justification for it, the idea that the scarcest +resource on the entire Internet at one point was (and possibly still +is) bandwidth through the "Mailbridge" gateways that connect the +ARPANET and the MILNET. So they're sending only one copy of +everything through the gateway and letting MC do all the ARPANET side +delivery. I suppose if we were organized enough to figure out which +addresses in our mailing lists were MILNET side we could route all +that traffic through SIMTEL20 for the same reason. (It would also be +interesting to see how they reacted with the shoe on the other foot.) + +JTW and I talked about this a little after it became clear what was +going on and we sort of vaugely decided that since SIMLTEL20 and MC +are both in the business of providing mail services to people for free +we should do what we could to accomodate them as long as we could. + +I don't think we ever claimed that MC was a network wide list server. +I think we did claim that it was a good place to give homes to lists +that would otherwise be orphaned by fascist administrative policy on +other machines (including our own). I think we've been doing that. + +I find the fact that the SIMTEL20 people set this up without asking +permission somewhat rude, but the number of sites that are providing +this kind of free service to people is small enough that I think we +should probably all hang together if we don't want to hang separately. + +The digest stuff, on the other hand, is simply a silly use of the +resources that we already have. COMSAT BULK is nearly idle, and the +digests are the one thing that could easily be moved there. + +--Rob + +Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 20 Feb 89 17:01:21 EST +Date: Mon, 20 Feb 1989 17:00 EST +Message-ID: +From: JTW@LCS.MIT.EDU +To: David Chapman +Cc: BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU +Subject: Which mailer should digests use? +In-reply-to: Msg of 20 Feb 1989 16:36-EST from David Chapman + + + From: David Chapman + Re: Which mailer should digests use? + + How did the SIMTEL20 business start? Did they just unilaterally start + doing it, or did they ask someone? I seem to recall that when MC as + set up there was some talk of it's being a network-wide list server + resource, which is absurd in retrospect, but maybe they latched on to + that? + +Actually, I don't think it's all that absurd, and the fact that some +of the people in lcs think that's what it is is a big part of why we +can occasionally get them to, how you say, pay for it (with space, or +repairs, or air conditioning, or not getting all bent out of shape +when "people" waste their time frotzing with it, or whatever). + +The truth of the matter is this - the whole ITS mail situation is on +the verge of collapse anyway. To continue offering even minimal +service after April 1 we have to get TCP running on the local +networks, which means a) ethernet, b) IP hacked at least enough to +understand subnets, broadcasts, and minimal routing, and c) TCP hacked +enough to at least support reasonable retransmission calculations, and +preferably all of the spiffy new algorithms that make it actually work +in overloaded and fast-net-gatewayed-to-slow-net situations. To offer +reasonable service, there's the whole issue of domain resolution and +MX support and better queueing and and and blah blah blah plugh. + +Amazingly, there's some good news. In most cases the new NSFNET paths +to things are proving to be substantially faster and more reliable +than the current Arpanet paths. So (given that we (euphemism) actually +make that April 1 deadline, and specially if all the TCP changes make +it) there's a good possibility that mailer performance is going to get +quite a bit better. If not, we're out of business anyway. So lets sit +tight until then, and see what happens. + + -john + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Feb 89 16:36:25 EST +Date: Mon, 20 Feb 89 16:36:26 EST +From: David Chapman +Subject: Which mailer should digests use? +To: SRA@MC.LCS.MIT.EDU +cc: BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU +In-reply-to: Msg of Sat 18 Feb 89 05:16:24 EST from Rob Austein +Message-ID: <541394.890220.ZVONA@AI.AI.MIT.EDU> + +How did the SIMTEL20 business start? Did they just unilaterally start +doing it, or did they ask someone? I seem to recall that when MC as +set up there was some talk of it's being a network-wide list server +resource, which is absurd in retrospect, but maybe they latched on to +that? + +My vote, anyway, is that if something has to give, that's where it +should happen. Very few of the SIMTEL list addressees are within MIT +(let alone ai/lcs). If, as we just established, MC's mailer is a slow +one, there's just no reason at all we should be doing these guys this +service. + +If we agree that's the right thing, I'm willing to play the heavy and +take the flack (if that's what is holding us back). + +Bulking digests seems reasonable to me, so long as digest mail gets +delivered reliably. (I still haven't been able to quite understand +the screw conditions.) How would the bug lists work, for instance? + +My guess from watching the queue a lot is that locally-generated +digest mail is a lot less than 50%, but it would certainly help. + +--David + + +Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Feb 89 15:52:44 EST +Date: Sat, 18 Feb 1989 15:52 EST +Message-ID: +From: Rob Austein +To: JTW@LCS.MIT.EDU +Cc: BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU +Subject: Which mailer should digests use? +In-reply-to: Msg of 18 Feb 1989 13:10-EST from JTW@LCS.MIT.EDU + + Date: Saturday, 18 February 1989 13:10-EST + From: JTW@LCS.MIT.EDU + + I'd like to understand where all the COMSAT time is going before we do + this. We keep talking about how overloaded MC is, but sometimes I get + the feeling that we just have a very low-capacity mailer. + +Well, yeah, it is a low capacity mailer, we knew that, it's only got +one delivery thread and it's running on top of slow network code. Its +major saving grace is that it has some major hair to maximize use of a +connection once it's acquired it, but these days as often as not the +network or some other randomness nullifies this benefit by breaking +the connection before it finishes dequeuing to that host. + + How many digests are there? + +Half a dozen at present. See MC:GUMBY;DIGEST >. + + If we move them -all- to BULK, do you + think the load will split closer to 50-50, or will we just kill + BULK instead of the normal COMSAT? (Presumably related to how + much traffic Wancho is forwarding through MC...) + +My guess is closer to 50-50. I think the normal traffic is quite +sufficient to keep regular COMSAT occupied, even without Wancho. + + Where does the time + go? Munging the queue? Waiting for TCP conns? + +Waiting for TCP conns, mostly. Look at the STATS files, they're +timestamped. + +Part of what I'm interested in is to see how well COMSAT performs if +we remove enough of the load that it might occasionally be able to try +dequeuing things because it's time to so rather than because it's been +time to do so for 12 hours but it finally got to that point in the +queue. + +Received: from LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 18 Feb 89 13:10:42 EST +Date: Sat, 18 Feb 1989 13:10 EST +Message-ID: +From: JTW@LCS.MIT.EDU +To: Rob Austein +CC: BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU +Subject: Which mailer should digests use? +In-reply-to: Msg of 18 Feb 1989 05:16-EST from Rob Austein + +I'd like to understand where all the COMSAT time is going befor we do +this. We keep talking about how overloaded MC is, but sometimes I get +the feeling that we just have a very low-capacity mailer. + +How many digests are there? If we move them -all- to BULK, do you +think the load will split closer to 50-50, or will we just kill +BULK instead of the normal COMSAT? (Presumably related to how +much traffic Wancho is forwarding through MC...) Where does the time +go? Munging the queue? Waiting for TCP conns? + + -john + +Date: Sat, 18 Feb 89 05:16:24 EST +From: Rob Austein +Subject: Which mailer should digests use? +To: BUG-DIGEST@MC.LCS.MIT.EDU, POSTMASTER@MC.LCS.MIT.EDU +Message-ID: <541474.890218.SRA@MC.LCS.MIT.EDU> + +I hereby formally (whatever that means) propose that all digests be +moved to MC's BULK COMSAT. There are several reasons for this: + +1) As things stand, MC's regular COMSAT is guaranteed to be tied up +for several hours after the midnight digestifiers run. This is a +pain. It may not be common knowledge, but MC is the backup (after XX) +for LCS's attempt at a lab-wide mailsystem, so people who pay the +hardware repair bills do actually care about timeliness, somewhat. + +2) MC's regular COMSAT has been running overloaded for a long time +now. STATS files get truncated when Alan or Penny guns COMSAT and +restarts it or when the machine reboots, almost never for any other +reason. I don't know when the last time was I saw LISTS MSGS under +2000 blocks. By contrast, BULK COMSAT's LISTS MSGS file is 23 blocks +long, and all of its OSTATS files are 51 blocks long. It would be +nice if we could fix things so that mail would continue to work if +both Alan and Penny go on vacation for two weeks. + +3) We seem to have tacitly accepted Wancho and company's use of MC as +a relay machine, by refusing to do anything sufficiently rude to +discourage them. There is no good way presently available to reroute +that traffic into the BULK queue. The digests, on the other hand, +would be trivial to reroute. + +4) Given the relative loading of the two mailers, I think that we +would actually be improving the quality of the service to the digest +recipients if we moved their traffic to the BULK COMSAT. Right now +the only things using BULK COMSAT are AILIST and ARPANET-BBOARDS. + +The only drawback I can think of is that one has to be a little more +careful in setting up the bug addresses for the digests, due to the +known locking problems between the two COMSATs. Big deal. Digests +are already a special case to set up, one more bit of hair isn't going +to change anything. + +Votes? Dead silence will be taken as meaning that if I go and do this +in a fit of annoyance at clogged mail queues, nobody will mind. + +--Rob + +Date: Wed, 16 Nov 88 15:10:23 EST +From: Scheme Requestee +Subject: Scheme Digest #6 +To: mohan%hpljsm@HPLABS.HP.COM +cc: BUG-DIGEST@MC.LCS.MIT.EDU +In-reply-to: Msg of Fri 11 Nov 88 09:15:36 pst from Joe Mohan +Message-ID: <505644.881116.SCHREQ@MC.LCS.MIT.EDU> + + Date: Fri, 11 Nov 88 09:15:36 pst + From: Joe Mohan + To: Scheme-request@mc.lcs.mit.edu + Re: Scheme Digest #6 + Full-Name: Joe Mohan + + I like the idea of a digest, provided there is some clumping of + messages. I would like it even better, if there is some + classification, as in AI Digest these days. But individual messages + wrapped in a digest header makes no sense. How about at least + adjusting the frequency so that we have say 5 to 10 messages in each + digest. Seems like a weekly digest will work just fine. + +This is all reasonable (although I think one week wouldn't be fast +enough turnaround), but unfortunately the software that does the +digesting doesn't have these features, and no human around here is about +to spend the time to do manual digest editing. I could talk to the +people who wrote the digester about clumping messages together, but I +don't think they'll be very sympathetic. + +Even if there is only one message in a digest, it still makes sense for +the digesting software to deal with the list since then messages will be +sent in the middle of the night instead of at prime time. (Another +benefit is that the message will be seen elsewhere as having been sent +by scheme-request@mc, so error reports will go there instead of to the +originator of the message.) The digest was instituted because the MC +mailer was becoming overloaded, and has already helped quite a bit. To +have a digest consisting of one message may seem weird, but it's uniform +and simple. + +- Jonathan Rees + +Received: from SRI-NIC.ARPA (TCP 1200000063) by MC.LCS.MIT.EDU 21 Jun 88 19:27:29 EDT +Date: Tue, 21 Jun 88 16:26:20 PDT +From: Ken Harrenstien +Subject: Re: I put OLD-OZ and MX in MC's COMSATs' HFLUSH lists +To: Alan@AI.AI.MIT.EDU, Moon@STONY-BROOK.SCRC.SYMBOLICS.COM +cc: JTW@XX.LCS.MIT.EDU, SRA@mc.lcs.mit.edu, ZVONA@AI.AI.MIT.EDU, + BUG-COMSAT@mc.lcs.mit.edu, bug-mail@mc.lcs.mit.edu, + bug-digest@mc.lcs.mit.edu, KLH@SRI-NIC.ARPA +In-Reply-To: <19880621200355.0.ALAN@PIGPEN.AI.MIT.EDU> +Message-ID: <12408317967.36.KLH@SRI-NIC.ARPA> + +Hi. I just dipped into my local KLH-ITS mail file which has been +accumulating stuff forwarded from AI/MC (I gave up trying to telnet-read +mail at MIT long ago), and have a couple comments about the bulk mailing +stuff. + +(1) Good idea. Even better idea if COMSAT could split its load up +automatically and farm it out to subsidiary unqueuers. Hmmm, maybe a good +thesis project... + +(2) Local mail delivery can be handled by locking. That is, when COMSAT +attempts to write to a mail file, it should seize the lock and if it doesn't +get it just waits until it's free -- normally this doesn't take much time, +so it's probably fine just to wait rather than trying to do something else +(which would be too hairy). + +I don't think locking is too hard to enforce. Local mail file writing is +concentrated in just one or two places. Even if you can't figure out +a simple way to do file locking (e.g. opening for append, but without +actually writing anything), you can always just use a single global lock, +perhaps in the LOCK file (you'll need to make a few changes to the way +this file is referenced and used if you want all of the COMSATs to share it). + +Good luck. +------- + +Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 21 Jun 88 16:09:53 EDT +Received: from BRAHMA.ACA.MCC.COM by MCC.COM with TCP/SMTP; Tue 21 Jun 88 15:08:51-CDT +Date: Tue, 21 Jun 88 15:08 CDT +From: David Vinayak Wallace +Subject: digest size +To: Chapman.pa@Xerox.COM +cc: BUG-digest@MC.LCS.MIT.EDU, DANA@AI.AI.MIT.EDU +In-Reply-To: <19880621191420.3.ZVONA@SPIFF.parc.xerox.com> +Message-ID: <880621150846.8.GUMBY@BRAHMA.ACA.MCC.COM> + + Date: Tue, 21 Jun 88 12:14 PDT + From: Chapman.pa@Xerox.COM + + Uh, the offending digest was nowhere near 100K. So let's not worry + about this yet. (The only way this could really be useful would be for + the digester to ask COMSAT how big a message COMSAT was currently + willing to deal with, and that's clearly too much work.) + +Any self-respecting mailer should deal with 100K (comsat itself has a +self-image problem -- memory image, that is), but maybe 64K is better. +DIGEST shouldn't ask COMSAT -- COMSAT should check and gun itself if the +freespace gets below a certain level. + +Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 21 Jun 88 16:07:02 EDT +Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 120878; Tue 21-Jun-88 16:04:00 EDT +Date: Tue, 21 Jun 88 16:03 EDT +From: Alan Bawden +Subject: I put OLD-OZ and MX in MC's COMSATs' HFLUSH lists +To: Moon@STONY-BROOK.SCRC.SYMBOLICS.COM +cc: JTW@XX.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU, ZVONA@AI.AI.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU, + bug-mail@MC.LCS.MIT.EDU, bug-digest@MC.LCS.MIT.EDU +In-Reply-To: <19880621174539.2.MOON@EUPHRATES.SCRC.Symbolics.COM> +Message-ID: <19880621200355.0.ALAN@PIGPEN.AI.MIT.EDU> + + Date: Tue, 21 Jun 88 13:45 EDT + From: David A. Moon + I don't see why you don't just make the bulk mailer never, ever + write a local file, and instead ... + +I didn't do it because I would have had to understand a fair amount more +about COMSAT first. Everyone should please recall that I once swore that +if I was ever forced to start learning about how COMSAT worked, I would +simply terminate mail service on ITS instead. I've already bent that rule +by doing what I have done, and I did spend several hours trying to produce +a COMSAT that would not do local delivery, and I couldn't find a way to do +it. + +Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 21 Jun 88 15:16:55 EDT +Received: from Semillon.ms by ArpaGateway.ms ; 21 JUN 88 12:15:28 PDT +Date: Tue, 21 Jun 88 12:14 PDT +From: Chapman.pa@Xerox.COM +Subject: Re: digest size +To: Gumby@MCC.COM +cc: BUG-digest@MC.LCS.MIT.EDU, DANA@AI.AI.MIT.EDU +In-Reply-To: <880620210207.8.GUMBY@BRAHMA.ACA.MCC.COM> +Message-ID: <19880621191420.3.ZVONA@SPIFF.parc.xerox.com> +Line-fold: no + +Uh, the offending digest was nowhere near 100K. So let's not worry +about this yet. (The only way this could really be useful would be for +the digester to ask COMSAT how big a message COMSAT was currently +willing to deal with, and that's clearly too much work.) +------- + +Received: from STONY-BROOK.SCRC.Symbolics.COM (TCP 20024224620) by MC.LCS.MIT.EDU 21 Jun 88 13:47:21 EDT +Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 422745; Tue 21-Jun-88 13:45:51 EDT +Date: Tue, 21 Jun 88 13:45 EDT +From: David A. Moon +Subject: I put OLD-OZ and MX in MC's COMSATs' HFLUSH lists +To: Alan Bawden +cc: JTW@XX.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU, ZVONA@AI.AI.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU, + bug-mail@MC.LCS.MIT.EDU, bug-digest@MC.LCS.MIT.EDU +In-Reply-To: <19880621021223.9.ALAN@PIGPEN.AI.MIT.EDU> +Message-ID: <19880621174539.2.MOON@EUPHRATES.SCRC.Symbolics.COM> + +I don't see why you don't just make the bulk mailer never, ever +write a local file, and instead send all such requests over to the +other Comsat (through the network) and have it write the file. This +would even include the AILIST archive file. Then there would have +to be such fear of screwing things up when making a mailing list +be distributed by the bulk mailer. + +I've only thought of two problems with this. One is the purely +clerical problem of finding all the places in Comsat that know about +delivery to the local host and turning them off for the bulk mailer, +so the network will still be used. The other is to make sure that +when mail is sent to the other Comsat for delivery to a local user's +mailbox, the address transmitted is the user's name rather than the +file name of the user's mailbox, to avoid the problem you mentioned +that is caused by the two Comsats having different NAMES files. +I think a good way to cope with this would be for the bulk mailer +never to do any user-name-to-mailbox expansion through INQUIR, the +tourist user directory database, etc. -- any address reaching that +point would just be transmitted to the other Comsat. The only +address expansion done by the bulk mailer would be done via its +NAMES file, and the only kind of delivery done would be network delivery. + +Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by MC.LCS.MIT.EDU 20 Jun 88 22:14:11 EDT +Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 120714; Mon 20-Jun-88 22:12:28 EDT +Date: Mon, 20 Jun 88 22:12 EDT +From: Alan Bawden +Subject: I put OLD-OZ and MX in MC's COMSATs' HFLUSH lists +To: JTW@XX.LCS.MIT.EDU, SRA@MC.LCS.MIT.EDU +cc: ZVONA@AI.AI.MIT.EDU, BUG-COMSAT@MC.LCS.MIT.EDU, bug-mail@MC.LCS.MIT.EDU, + bug-digest@MC.LCS.MIT.EDU +In-Reply-To: , + The message of 19 Jun 88 17:33 EDT from JTW@XX.LCS.MIT.EDU, + <438861.880619.ZVONA@MC.LCS.MIT.EDU>, + The message of 19 Jun 88 22:25 EDT from ZVONA@MC.LCS.MIT.EDU, + The message of 19 Jun 88 22:25 EDT from David Chapman, + <433170.880608.SRA@MC.LCS.MIT.EDU>, + <12404850562.46.SRA@XX.LCS.MIT.EDU> +Message-ID: <19880621021223.9.ALAN@PIGPEN.AI.MIT.EDU> + + Date: Sun, 19 Jun 88 22:25 EDT + From: David Chapman + I see that COMSAT BULK is actually running. Would it in fact help + with the too-big-mail problem? Should I be using it? Is it reliable? + +Well, just how big was the file that blew out? Clearly it can only help if +your digest is still within -some- limit... I think the digestifier really +should be keeping a limit on the size of the digest it is willing to +create. If the day's inbox doesn't fit in a single digest, it should write +the remainder of the inbox into a separate file (with second filename +"BACKLOG"?) to appear at the beginning of the next day's digest. Any +mailing list that consistently loses ground with this scheme does not +deserve our support. + + Date: Wed, 8 Jun 88 13:45:15 EDT + From: Rob Austein + ... + Alan, IWBNI ... (2) you sent BUG-COMSAT a short note explaining in + English just what you ended up doing with all this .BULK. stuff and + what the current proceedure is for launching COMSAT, etc. + +All I did was create a .BULK. directory that contains all the same files +as .MAIL.. COMSAT decides a start-up time which directory to use based on +its JNAME. If its JNAME is "VDNBRG", then it uses .BULK. (and sets it's +JNAME to be "BULK"). If its JNAME is anything else, it uses .MAIL. (and +sets its JNAME to be "IV"). + +There is a CHANNA;RAKASH VDNBRG to be certain that a bulk mailer gets +started at ITS boot time. There is a DRAGON;HOURLY VDNBRG to be certain +that the bulk mailer doesn't stay dead for more than an hour. + + Date: Wed 8 Jun 88 13:59:18-EDT + From: Rob Austein + So, how does anything ever get queued for the BULK mailer? As far as I can + tell the only thing currently going there is AILIST. + +You just have to know to write a request into .BULK.;MAIL >. Currently the +only program that knows how to do this is the AIList digestifier, which I +believe is a special purpose program that runs on Lisp Machines. + +I did -not- do anything to prevent the bulk mailer from delivering mail +into local mailboxes. If both COMSAT IV and COMSAT BULK try to deliver +mail into the same local inbox, mail will be lost. Fortunately, this is +not much of an issue, since there are no -users- who keep their inboxes on +MC. (AIList makes -one- local delivery, into an archive file that the +other COMSAT never touches.) + +Unfortunately, it is not quite as easy ask you might at first think to +determine that mail delivered by the bulk mailer will not go to any local +users. For example, suppose user FRED has an INQUIR entry that says to +deliver his mail to MC. Then in MC:.MAIL.;NAMES > he says to forward his +mail to framistat%octal!dingbat!bang!mit-eddie.arpa@uk.nrl.dialnet.symbolics.com +(which is too long to fit in his INQUIR entry). Well, if FRED is on a +mailing list expanded by COMSAT BULK, his INQUIR entry will cause the bulk +mailer do decide that FRED is a local user, but since COMSAT BULK looks in +.BULK.;NAMES > and not .MAIL.;NAMES >, it will not see his forwarding +entry, and so will deliver mail to GUEST1;FRED MAIL! + +Currently, the safest way to move a mailing list to BULK delivery is to +start by examining the expansion of the mailing list as performed by the +regular COMSAT to be certain that you know -all- of the entries in the +NAMES file that effect the mailing list. + +I'll bet the digest program has ".MAIL." wired into it somewhere, but that +should be easy to fix so that mailing lists could choose the mailer that +they want to use. + +Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 20 Jun 88 22:03:19 EDT +Received: from BRAHMA.ACA.MCC.COM by MCC.COM with TCP/SMTP; Mon 20 Jun 88 21:02:14-CDT +Date: Mon, 20 Jun 88 21:02 CDT +From: David Vinayak Wallace +Subject: digest size +To: David Chapman +cc: BUG-digest@MC.LCS.MIT.EDU, DANA@AI.AI.MIT.EDU +In-Reply-To: <400030.880619.ZVONA@AI.AI.MIT.EDU> +Message-ID: <880620210207.8.GUMBY@BRAHMA.ACA.MCC.COM> + + Date: Sun, 19 Jun 88 16:40:44 EDT + From: David Chapman + + Right, OK, so there was indeed enough volume on the (digested) + paganism list that it went over COMSAT's threshold. This makes the + automatic digestifier pretty useless. (Gumby, Dana, has this never + happened for you?) Is there anything that can be done about this? + + The size message COMSAT can deal with is limited mostly by the size of + the names database, right? That means that if this second-COMSAT hack + were hacked, it would have a tiny NAMES database and so could send + much bigger messages, right? + +The size of largest message COMSAT can deal with is a function of the +free space; since there are some storage leaks this size goes down +periodically. If comsat is bouncing rediculously small messages, gun it +down at a convenient time and relaunch it. Then rename the badreq +file(s) to be MAIL files. + +You can't make them too large; more than 100K causes various hosts to +barph (there are some VMS hosts which react by summarily closing the +connection, then mail the offending message fragment (the Message So +Far) back to the request list. Since COMSAT wasn't able to deliver the +message and since the remote host didn't accept it then send a refusal, +COMSAT follows the spec and tries to deliver the message again. This +fills the -request box with about 200 messages of about 90K each. + +It wouldn't be too hard to cause the digester to check after scanning +each message, and stop if the input file position is over 100K. That +would keep each digest under that. I suppose it could then even restart +itself. A mere matter of programming. Any volunteers? + +Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 19 Jun 88 17:33:57 EDT +Date: Sun, 19 Jun 1988 17:33 EDT +Message-ID: +From: JTW@XX.LCS.MIT.EDU +To: David Chapman +cc: bug-mail@MC.LCS.MIT.EDU, bug-digest@MC.LCS.MIT.EDU +In-reply-to: Msg of 19 Jun 1988 16:40-EDT from David Chapman + +The size that comsat can handle is limited dynamically by AvailMem - +AllTheRestOfTheJunkInCore. There is a bug in the GC such that this +number tends to shrink over time. If you find that you're losing and +what you're trying to do isn't absurd, rebooting comsat will often +help. Unfortunately I don't have a good feel for what absurd is these +days, but I would hope that 100K would be possible. If things start +getting this big, other people are going to have problems too, and you +might consider sending out smaller digests more often. + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 19 Jun 88 16:41:19 EDT +Date: Sun, 19 Jun 88 16:40:44 EDT +From: David Chapman +To: BUG-mail@MC.LCS.MIT.EDU, BUG-digest@MC.LCS.MIT.EDU +cc: DANA@AI.AI.MIT.EDU +Message-ID: <400030.880619.ZVONA@AI.AI.MIT.EDU> + +Right, OK, so there was indeed enough volume on the (digested) +paganism list that it went over COMSAT's threshold. This makes the +automatic digestifier pretty useless. (Gumby, Dana, has this never +happened for you?) Is there anything that can be done about this? + +The size message COMSAT can deal with is limited mostly by the size of +the names database, right? That means that if this second-COMSAT hack +were hacked, it would have a tiny NAMES database and so could send +much bigger messages, right? + + + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 May 88 19:26:44 EDT +Date: Mon, 23 May 88 19:24:02 EDT +From: David Chapman +Subject: Messages got lost? +To: Gumby@MCC.COM +cc: BUG-digest@MC.LCS.MIT.EDU +In-reply-to: Msg of Mon 23 May 88 17:59 CDT from David Vinayak Wallace +Message-ID: <383911.880523.ZVONA@AI.AI.MIT.EDU> + +Oh. His message apparently never got into the digest at all. +Probably never got to MC, in fact, because there hasn't been any +problem since. + + + +Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 23 May 88 20:05:49 EDT +Received: from BRAHMA.ACA.MCC.COM by MCC.COM with TCP/SMTP; Mon 23 May 88 17:59:39-CDT +Date: Mon, 23 May 88 17:59 CDT +From: David Vinayak Wallace +Subject: Messages got lost? +To: David Chapman +cc: BUG-digest@MC.LCS.MIT.EDU +In-Reply-To: <383521.880523.ZVONA@AI.AI.MIT.EDU> +Message-ID: <880523175935.2.GUMBY@BRAHMA.ACA.MCC.COM> + + Date: Mon, 23 May 88 13:06:35 EDT + From: David Chapman + + Perhaps this guy lost because he sent it at 23:00 from the west coast? + + How would he lose then? + +23:00 PST is 02:00 EST. Therefore it becomes an early message in the +next day's digest. + +More insidious is the case where it lies on a gateway (like a UUCP +machine which communicates at midnight) and arrives just after the +digest has begun to be built. + +I think a perusal of the Received headers of the incoming messages would +show you that this is what happened. + + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 May 88 13:04:02 EDT +Date: Mon, 23 May 88 13:06:35 EDT +From: David Chapman +Subject: whither administrivia? +To: Gumby@MCC.COM +cc: BUG-digest@MC.LCS.MIT.EDU +In-reply-to: Msg of Thu 19 May 88 17:57 CDT from David Vinayak Wallace +Message-ID: <383521.880523.ZVONA@AI.AI.MIT.EDU> + + I think it would be better if the admin came before the toc, because + people are likely to skip over the toc and so miss the admin. + + Perhaps. This is where it appears in most digests. How can they skip + the administriva without running across it? Oh. maybe they use + undigestify. + +It just seems visually hidden. If you don't read the whole toc, in +particular, you won't see it. + + hmm. How about adding (administrivia) to the top of the + TOC if appropriate? + +Good idea. + +I suspect a lot of people just skip the toc, however. (I do.) How +about indenting the admin by four spaces? I think that would set it +off visually in a way that would make it stand out. (This is useful +only if the toc doesn't run over a screenful...) + + Does bug-digest go to a file? + +Now it does: gumby;digest bugs. + + Perhaps this guy lost because he sent it at 23:00 from the west coast? + +How would he lose then? + + + +Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 19 May 88 19:00:08 EDT +Received: from BRAHMA.ACA.MCC.COM by MCC.COM with TCP/SMTP; Thu 19 May 88 17:57:27-CDT +Date: Thu, 19 May 88 17:57 CDT +From: David Vinayak Wallace +Subject: whither administrivia? +To: David Chapman +cc: BUG-digest@MC.LCS.MIT.EDU +In-Reply-To: <381126.880519.ZVONA@AI.AI.MIT.EDU> +Message-ID: <880519175717.2.GUMBY@BRAHMA.ACA.MCC.COM> + + Date: Thu, 19 May 88 12:47:52 EDT + From: David Chapman + + I think it would be better if the admin came before the toc, because + people are likely to skip over the toc and so miss the admin. + +Perhaps. This is where it appears in most digests. How can they skip +the administriva without running across it? Oh. maybe they use +undigestify. hmm. How about adding (administrivia) to the top of the +TOC if appropriate? + +Does bug-digest go to a file? + + (here's an example.) + + Date: 19 MAY 88 00:06:51 EDT + From: Automatic Paganism Digestifier + Reply-To: Paganism at mc.lcs.mit.edu + To: Paganism at mc.lcs.mit.edu + Re: Paganism Digest #5 + + Paganism Digest #5 19 MAY 88 00:06:51 EDT + + Today's Topics: + + More info on the "Ring of Fire" PBS series + digestify + A new member request, not to go into digest + maybe you _can_ have your cake and eat it too + Power Animals + Merrymeet Announcement and Reg. Form! + Biography + paganism digest #4 + + Administrivia: + + Has anyone besides Brett Slocum sent a message to PAGANISM and had it + not appear in the next day's digest? Please let me know if so. + +Perhaps this guy lost because he sent it at 23:00 from the west coast? + + + +Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 19 May 88 12:45:48 EDT +Date: Thu, 19 May 88 12:47:52 EDT +From: David Chapman +To: BUG-digest@MC.LCS.MIT.EDU +Message-ID: <381126.880519.ZVONA@AI.AI.MIT.EDU> + +I think it would be better if the admin came before the toc, because +people are likely to skip over the toc and so miss the admin. + +(here's an example.) + + Date: 19 MAY 88 00:06:51 EDT + From: Automatic Paganism Digestifier + Reply-To: Paganism at mc.lcs.mit.edu + To: Paganism at mc.lcs.mit.edu + Re: Paganism Digest #5 + + Paganism Digest #5 19 MAY 88 00:06:51 EDT + + Today's Topics: + + More info on the "Ring of Fire" PBS series + digestify + A new member request, not to go into digest + maybe you _can_ have your cake and eat it too + Power Animals + Merrymeet Announcement and Reg. Form! + Biography + paganism digest #4 + + Administrivia: + + Has anyone besides Brett Slocum sent a message to PAGANISM and had it + not appear in the next day's digest? Please let me know if so. + + David/paganism-request@mc.lcs.mit.edu + + + ---------------------------------------------------------------------- + + Date: Tue, 17 May 88 17:19 EDT + From: David C. Plummer + Subject: More info on the "Ring of Fire" PBS series + Message-ID: <19880517211911.9.DCP@SWAN.SCRC.Symbolics.COM> + + This information is from the May 1988 'GBH member's magazine. The + _Adventure_ series (of which the _Ring_of_Fire_ is the first four + +...etc. + + + + + + +Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 May 88 23:42:58 EDT +Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 112745; Tue 17-May-88 23:37:51 EDT +Date: Tue, 17 May 88 23:37 EDT +From: David Chapman +To: gumby@AI.AI.MIT.EDU, alan@AI.AI.MIT.EDU, cent@AI.AI.MIT.EDU +cc: postmaster@MC.LCS.MIT.EDU, dana@AI.AI.MIT.EDU +Message-ID: <19880518033750.1.ZVONA@NULLSTELLENSATZ.AI.MIT.EDU> + +This is a draft DRAGON;DIGEST ORDER, documenting Gumby's digester. (Is +that a rational place to keep the file? Or should it go in .INFO.;?) +Comments requested. + + -*- Text -*- + + How to digest an ITS mailing list + +High-volume mailing lists tie up COMSAT, the ITS mailer, in proportion +to the number of messages sent, rather than in proportion to the total +number of characters sent. For example, delivering a message to AI-List +takes two and a half hours! Mail to hosts that are neither local to MIT +nor directly connected to the central nodes of the arpanet -- ``weird'' +hosts -- is particularly expensive. Any mailing list which gets more +than a few messages per day and which goes to more than about ten weird +hosts is going to impose a lot of overhead on COMSAT. + +Also, the overhead of reading mail from a list is a function of the +number of messages received, as well as the number of characters. For +these two reasons, large mailing lists should be >digested<; that is, +all the messages sent to it during each day are bundled up and sent out +as a single, long message. This message is sent in a special format +which can be >undigested< -- broken out into individual messages -- by +many mail-reading programs. + +This file explains how to have a mailing list be digested automatically. +We'll take as a running example a hypothetical mailing list called +FOOBLATZ. + +All digested ITS mailing lists must reside on MC.LCS.MIT.EDU. You can +make forwarding pointers from AI.AI.MIT.EDU or other ITS machines +by putting a line like + +(FOOBLATZ (EQV-LIST FOOBLATZ@MC)) + +in the machine's .MAIL.;NAMES file. + +You don't need an account on MC in order to digest a list. All the +relevant manipulations can be done remotely from AI, because ITS +supports a virtual machine-independent file system. To read and write +files on MC, simply prepend MC: to the file name. For example, you can +modify MC's NAMES database by reading MC:.MAIL.;NAMES into an EMACS, +modifying it, and saving it with c-X c-S in the usual way. + +For reasons that will presently be explained, a digested mailing list +must have an associated home directory on MC (which could be used for +other things as well) called the >sname<, and an associated +one-to-six-character >jname<. The jname is not necessarily the name of +the list, if the list has a long name; it should be a version of it that +fits in six characters. FOOBLATZ might have as sname COMAIL; (which is +a general large-list directory on MC) and as jname FOO. + +There's two parts to causing a mailing list to be digested. The first +part is that the mailing list entry in MC:.MAIL.;NAMES > should be split +in two. In our example, mail sent to FOOBLATZ should be sent collected +into a file for later digestion, rather than actually sent out to +recipients of the mailing list. This file is called MC:sname;jname +INBOX; in our example, that's MC:COMAIL;FOO INBOX. Mail sent to this +file should have R-OPTION FAST-APPEND, so the NAMES entry on MC will +look like this: + +(FOOBLATZ (EQV-LIST ([COMAIL;FOO INBOX] (R-OPTION FAST-APPEND)))) + +The digester will snarf mail out of the inbox and digest it and send +it to a >different< list, which has the actual list subscribers on it. +We could call this list FOOBLATZ-REALLY: + +(FOOBLATZ-REALLY (EQV-LIST (@FILE [COMAIL;FOO LIST]))) + +The digester does some magic to make it look as if the digested message +is being sent to FOOBLATZ, even though it is actually sent to +FOOBLATZ-REALLY. That way your subscribers will never know the name +FOOBLATZ-REALLY, and can't screw things up by sending to it directly. + +Note here that the mailing list is specified indirectly via a file. +This is a good idea for large mailing lists that change frequently, +since you don't have to mess around with the NAMED ERR file. + +The second part of setting up a digested list is that you need to tell +the system that the list will be digested. The first step of that is to +put your mailing list in the table of digested lists. This table lives +in the file MC:GUMBY;DIGEST >, which is actually the MIDAS (assembly +language) source for the digesting program. The table is more or less +the first thing in the file; it looks like this: + +;;; JNAME, SNAME, "PNAME", "RCPT", "RPLTo" +define Lists + List GDFLMS,GDEAD, "Dead-Flames", "dead-flames-humans", "Dead-Flames" + List AVIATN,AVIATN,"Aviation", "aviation-digest", "Aviation" + ... +termin + +Each line defines one mailing list. The JNAME and SNAME we've already +explained. Spaces count in these fields count, so don't put them in. +Spaces outside the quotation marks don't count in the other fields, so +put them in so the columns line up nicely. The PNAME is the actual name +of the list, FOOBLATZ. The RCPT is the list that digested messages get +sent to; FOOBLATZ-REALLY in this case. The RPLTo is the address put in +the Reply-to: field that gets sent out on the digest. This will +normally be the same list as the address for incoming mail, namely +FOOBLATZ. So the line we want to add to the table is + + List FOO,FOO, "Fooblatz", "fooblatz-really", "Fooblatz" + +Be careful when messing with the DIGEST source file. If you screw up, +mail sent to all the digested lists will lose. + +Once you've added your list to the table, you need to recompile the +DIGEST source file. To do that, type + +:MIDAS MC:GUMBY;DIGEST_ + +to DDT (the ITS executive). (Note the underbar at the end.) It will +print some random lines of information. If any of them looks like an +error message, do not procede; send mail to BUG-DIGEST@MC.LCS.MIT.EDU, +asking for help. Otherwise, you've successfully created a file +GUMBY;DIGEST BIN, which is a new digester that knows about your mailing +list. + +This object code file needs to be run by a system dragon (demon job) +every day at midnight. The DRAGON; directory contains magic that spawns +dragons. Two steps are required. First, you need to move DIGEST BIN to +the DRAGON; directory: + +:COPY MC:GUMBY;DIGEST BIN,MC:DRAGON; + +Second, you need to tell the system to run this BIN on a daily basis. +The incantation for this is + +:LINK MC:DRAGON;DAILY jname,MC:DRAGON;DIGEST BIN + +where jname is the JNAME of your list; in our case + +:LINK MC:DRAGON;DAILY FOO,DRAGON;MC:DIGEST BIN + +This completes the process of making a list be digested. If you run +into any problems, send mail to BUG-DIGEST@MC.LCS.MIT.EDU. + +Three other files are magic for the digester. You can put something in +the file sname;jname ADMIN (MC:COMAIL;FOO ADMIN, for instance), and the +digester will put it right after the table of contents in the next +digest. (Then it'll delete the ADMIN file.) This is useful for making +administrivial announcements. + +sname;jname NUMBER (MC:COMAIL;FOO NUMBER) contains the issue number, in +in ascii, of the current issue. If this file does not exist, the +digester assumes issue number 1 and creates the file. If there is a +problem parsing this file, it is renamed to sname;jname BADNUM, and the +issue number is whatever was parsed, with "E" appended (e.g. +"259E"). + +The digester renames the INBOX to sname;jname > (MC:COMAIL;FOO >, where +> is actually some integer) as it works on it. If it wins, it deletes +that file. If it crashes, the file is left around so you can recover +the day's mail. + + + + \ No newline at end of file diff --git a/doc/digest/digest.order b/doc/digest/digest.order new file mode 100755 index 00000000..70e9f1e0 --- /dev/null +++ b/doc/digest/digest.order @@ -0,0 +1,334 @@ + Digestifying an ITS Mailing List + +Why Digestify? +-------------- + +First, what is digestifying and why do it? A mailing list is used by a +mailer program (such as ITS's COMSAT) to distribute messages to more than +one address, translating the single list address given into the addresses +of the intended recipients. Normally this process occurs without any +built-in delays; the mailer receives a message, checks the set of +addressees for mailing lists to expand, performs such expansions, and +immediately delivers the message to the desired recipients. + +However, some mailing lists have a consistently high volume of mail +travelling to them. Any message sent through an ITS machine ties up its +COMSAT in proportion to the number of recipients and the number of messages +sent, rather than in proportion to the total number of characters sent -- +for example, delivering any message to AI-List (one very large mailing +list) takes two and a half hours! Mail to hosts that are neither local to +MIT nor directly connected to the central nodes of the Arpanet -- "weird" +hosts -- is particularly expensive. Thus, any mailing list which gets more +than a few messages per day and which goes to more than about ten weird +hosts imposes a large load on COMSAT. + +Also, the overhead to list members of reading mail sent to the list is a +function of the number of messages received, as well as the number of +characters. For these two reasons, large mailing lists should be +-digested-; that is, arrangements should be made to collect all the +messages sent to such a list during each day, bundle them up as one single, +long message, and send that message, the digest, to the list members. The +digest has a special format which can be undigested or burst -- broken up +into individual messages -- by many mail-reading programs. + +This file explains how to get the digestifier daemon to digest a ITS +mailing list automatically, using as an example a hypothetical mailing list +called FOOBLATZ. + + +How To Digestify +---------------- + +So now that you've decided your mailing list should be digested, how do +you arrange that? + +First, all automatically digestified ITS mailing lists currently must +reside on MC.LCS.MIT.EDU; if yours lives elsewhere, you must move it to MC. +You can make forwarding pointers from other machines to MC; on another ITS +machine, such a pointer would be a line like + +(FOOBLATZ (EQV-LIST FOOBLATZ@MC)) + +in the other machine's .MAIL.;NAMES file. + +Second, you must alter the mailing list entry in MC:.MAIL.;NAMES > . Mail +sent to FOOBLATZ needs to be collected into a file, the inbox, for later +digestification, rather than immediately sent out to members of the mailing +list. So the mailing list entry for FOOBLATZ should look like + +(FOOBLATZ (EQV-LIST ([COMAIL;FOO INBOX] (R-OPTION FAST-APPEND)))) + +Note that the FAST-APPEND option makes COMSAT append new mail to the end of +the inbox, which will cause the FOOBLATZ Digest to include the messages +sent to FOOBLATZ in the chronological order in which they arrived at MC. +Not including this option will cause the digest to include the messages in +the reverse order of arrival, which will confuse many list members. +Further, as explained below in the digestifier algorithm section, when +discussion grows very brisk, the inbox may contain more than one digest's +worth of messages; in this case the digestifier will create a digest +starting at the beginning of the file and going until it reaches its size +limit, so the FAST-APPEND option will ensure that the older part of the +conversation is sent out first, and that very old messages don't accumulate +unsent. + +Third, you must create an entry in the file MC:DIGEST;DEFS > for your +digest. Everything in that file up to the first ^_ (ascii 037) is a +comment, and after that comes a series of digest definitions, separated by +^_'s; to make life easy, put yours at the end. + +Each digest definition has a format that looks like an RFC822 mail header +-- that is, it consists of a series of named fields of the form: + +Name: FooBlatz +Inbox: COMAIL;FOO INBOX +Administrivia: COMAIL;FOO ADMIN +Record: COMAIL;FOO RECORD +First-Issue-Number: 259 +AUTHOR: FOOBLATZ-REQUEST +RCPT: (@FILE [COMAIL;FOO LIST]) +From: FooBlatz Daily Blast + +Reply-To: FOOBLATZ%MC.LCS.MIT.EDU@Mintaka.LCS.MIT.EDU +To: FOOBLATZ%MC.LCS.MIT.EDU@Mintaka.LCS.MIT.EDU + +Continuation lines, such as the second line of the From: field in the +example above, -must- start with a space or a tab. Blank lines between +fields are ignored, so you can insert them in your digest entry if you +like. The order of the fields in the definition does not matter. +Capitalization of field names does not matter, but capitalization of field +values does -- if you want the From: field to look like "FooBlatz-Request" +in the digests sent out, capitalize it that way. + +Here is a catalog of all of the currently accepted fields, their +meanings, and whether they are required for the digestifier to work: + + Name: (required) + + The name of the digest, such as "FooBlatz". This name is usually used + before the word "Digest", as in "FooBlatz Digest #259". + + Inbox: (required) + + The name of the file that COMSAT delivers mail to for this digest. The + device is defaulted to "DSK", the directory is defaulted to "COMAIL", + and the second filename is defaulted to "INBOX". You -must- supply the + first filename. Thus you can say just "Inbox: FOO" if your inbox is + DSK:COMAIL;FOO INBOX. + + Administrivia: (optional) + + The name of the file that the digestifier should check for + administrative messages that should be inserted at the front of the + next digest. By default this file has the same name as the inbox file, + but with the second filename of "ADMIN". If you don't specify an + Administrivia field, then the digestifier will not look for an + administrivia file at all -- if you want to use the default file name, + you can simply give Administrivia: a blank field. + + If this field exists, the digestifier will look for a file of the + specified name; if the file exists, the digestifier will include its + contents in the digest between the list of message topics and the first + message, and delete the file. Note that the administrivia file is not + a mailbox -- its contents will be included in the digest exactly, + including all the headers and other (for this purpose) extraneous + nonsense of anything sent to the file as mail. Spare your list members + by avoiding this action; log in and write the file directly if that's + at all possible. When you write the file, you don't need to explicitly + create white space around your text; the digestifier will automatically + provide blank lines before and after it. + + Record: (optional) + + The name of the file that the digestifier uses to keep track of the + state of the digest. This contains vital data like the current issue + number and the time that the most recent digest was mailed. By default + this file has the same name as the inbox file, but with the second + filename of "RECORD". + + Do not try to create this file yourself! Doing so will only confuse + the situation. The digestifier will create this file the first time it + processes your digest; if you don't specify a Record field, the + digestifier will use the default name for this file. + + First-Issue-Number: (optional, usually) + + This field is -only- used by the digestifier when it creates a new + record file the first time it processes your digest. This is used to + initialize the issue number stored in the record file so that the next + digest created will have the given number. It should consist of a + string of digits (only digits!) representing a decimal number, like + "259". + + If this field is not present and the digestifier can't find a record + file, then the digest definition is broken and no digest will be + produced. For safety, you can remove the First-Issue-Number from your + digest definition after your record file is created; that way, if + someone accidentally deletes your record file, the digestifier won't + automatically recreate it and start duplicating issue numbers. + + When converting an existing digest to use this digestifier, the initial + contents of this field should be set to the contents of the existing + "NUMBER" file associated with that digest, to preserve continuity of + issue numbers. + + RCPT: (required) + + This is the digest recipient, the address to which the digest will + actually be mailed (independent of what you may list in the To: and + From: fields!). This has exactly the format of a recipient from + .MAIL.;NAMES >, except it cannot be continued onto a continuation line. + Typically you will keep the actual mailing list in a file, say + COMAIL;FOO LIST, and have a RCPT field like + + RCPT: (@FILE [COMAIL;FOO LIST]) + + Defining the list in an indirect file is a good idea for large mailing + lists that change frequently, since it allows you to avoid recompiling + NAMES > and messing with the NAMED ERR file. + + When converting an existing digest to use this digestifier, note that a + separate entry in NAMES > is no longer called for to hold the mailing + list which includes the actual list members. You can use such a list, + but it's probably easier to simply specify the indirect file containing + the list members explicitly in this field. + + AUTHOR: (required) + + This is where delivery error messages should be directed. + + Unlike the RCPT: field, this is not a NAMES > style recipient; nor is + it an RFC822 style recipient (something of the form User@Host). It can + only be a simple string -- "FOOBLATZ-REQUEST" in our example. This + means that unless you put a single person's name here, you will have to + create a mailing list to receive the errors. + + If you want to try to keep human-generated requests apart from + mailer-generated errors, you can create a mailing list separate from + your administrative list -- called, say, FooBlatz-Errors -- and put it + here in the AUTHOR: field. + + From: (required) + Reply-To: (optional) + To: (optional) + + The values of these three fields are copied verbatim into the header of + all generated digests. If the optional fields are not given, the + generated digests will not have these fields -- no default values are + generated for them. Please be careful to specify only RFC822-legal + values for these fields. Currently most digests use an address of the + form + + From: FooBlatz Daily Blast + + or + To: FOOBLATZ%MC.LCS.MIT.EDU@Mintaka.LCS.MIT.EDU + + (By the way, there is no reason why MC's name has to appear here. Your + subscribers don't need to know that MC is involved in producing the + digest as long as you give them -some- address that reaches your + inbox.) + + Generally the From: field will contain the name of the mailing list's + auxiliary administration list -- FooBlatz-Request in our example. This + is the address where people will generally send their administrative + requests. It need -not- be the same as the address that appears in the + AUTHOR: field, although typically it is. + + The To: and Reply-To: fields should contain the address of the mailing + list itself -- that is, the address where people send mail they want + included in the digest. Mail sent to this address should eventually + reach your digest's inbox file. + + Actually, many other well-known RFC822 header fields can be given as + fields in the digest definition, but most digests will want to use + exactly these three. (See the source code if you want to know what + others will work. Note that Date, Subject and Message-ID headers are + automatically generated for each issue of each digest by the + digestifier.) + + +Digestifier Algorithms +---------------------- + +The digestifier is run automatically once every hour. It reads through the +file DIGEST;DEFS > and considers each digest in turn, keeping a log of its +actions in the file DIGEST;LOG >. + +For each digest, the digestifier considers a number of factors to determine +whether or not it is going to produce a digest this time: + +1. The current time of day. The hours between 2AM and 7AM are "Prime + Time" and the digestifier prefers to create a digest then. + +2. The current size of the digest's inbox. The digestifier never produces + a digest larger than a certain size (around 48000 characters). If the + inbox looks like it contains more than 1.5 digests worth of material, + then the inbox is "bloated" and the digestifier tries to create a + digest soon. + +3. How long ago the previous digest was mailed. The digestifier tries not + to produce digests so frequently that people and mailers are + overwhelmed with them, nor so infrequently that a message can sit in + the inbox for an unreasonably long time. + +The precise test is: + + (AND + (OR ; more than 1.5 digests pending + (AND ; between 2AM and 7AM + ))) + +In English, this translates as: + If the last issue of this digest was sent out less than an hour and a +half ago, wait. If the last issue went out longer ago than that and the +inbox is bloated, create a digest. But if the inbox isn't bloated, check +whether it's prime time; if it is, and the last issue went out yesterday, +then create and send today's issue. + +The various numbers and times are all subject to future adjustment of +course. + +This digestifier should be fairly robust in the face of system crashes, +being gunned down in the middle of processing, etc. The worst that can +happen is that a duplicate issue can be produced, and that can only occur +if the digestifier is zapped during an extremely small window. I'll be +surprised if it ever happens. + +It is perfectly safe to run two digestifiers at once, since both the +digestifier and COMSAT use the LOCK device to coordinate access to inboxes. + +In fact, if you edit the DEFS file, it is probably a good idea to run the +digestifier once yourself and check the LOG file to see if you made any +errors. Even if your inbox is empty, this procedure will catch many +possible problems with your digest definition. You should be able to run +the digestifier by typing: + + :DIGEST;DIGEST + +to DDT. This might take a couple of minutes to finish (the digestifier +might decide to produce some digests!) so be patient. Then you should look +at what was appended to the end of the current DIGEST;LOG > file. + +This digestifier tries to be fairly civic-minded about cleaning up after +itself. If it encounters any errors during the processing of a digest it +logs the error, then carefully deletes any partially-written output and +either proceeds to the next digest, or kills itself (depending on the +nature of the error). Only a few amazingly unlikely errors should ever +leave a dead disowned job as a corpse. + +Mail is always delivered through the bulk COMSAT (through the .BULK. +directory.) + +This digestifier is careful to check the messages included in the digests +it builds for lines of "-"s that could confuse digest bursting or +undigestifying tools, and modifies the first "-" in any suspect line to be +a space. + +Send bug reports to Bug-DIGEST. + + +This digestifier was written by Alan Bawden and supersedes previous digests +written by Rob Austein, David Wallace, and Chris Maeda. A lot of the +documentation was adapted from documentation written by David Chapman for +the GUMBY digestifier. + diff --git a/doc/digest/new.admin b/doc/digest/new.admin new file mode 100755 index 00000000..a27b8381 --- /dev/null +++ b/doc/digest/new.admin @@ -0,0 +1,32 @@ +Congratulations! We're the lucky winners in the lottery to choose the +lucky victim, er, test case for the new improved automatic digestifier, +which has just been finished by the small but dedicated cadre of ITS +hackers. This change should if anything improve the situation for +list members. Specific differences you may notice: + +All messages included in the digest will now include all the To: and CC: +fields they arrived here with. So if a message was sent to some particular +list member but cc'd to the whole list, or sent to several lists, that will +now be obvious. For those of us who use undigestifying or digest-bursting +tools, this change will have the beneficial effect of causing each message +burst from the digest to automatically have a legal mail header. + +There are now rules governing the maximum size of digests sent out. If +there is too much accumulated mail, the digestifier will send out the +oldest section as the digest and save the newest section for later. +Conversely, the digestifier also has the ability to produce more than one +digest a day. The effect of this change is that list members whose sites +have difficulty swallowing very large mail should no longer run into that +problem; on the other hand, if the discussion grows extensive, it will get +throughput in efficient chunks. + +The digestifier will now check each included message for lines that begin +with lots of dashes. Such lines are created by the digestifier to separate +messages from each other, so similar lines inside any message have the +potential to confuse digest-bursting tools. To guard against this problem, +the digestifier will now change the initial dash of any such lines inside +messages to a space. + +If this change causes any problems, please report them to us. + +SCA-REQUEST@MC.LCS.MIT.EDU \ No newline at end of file diff --git a/doc/programs.md b/doc/programs.md index 224a2538..336b7cbf 100644 --- a/doc/programs.md +++ b/doc/programs.md @@ -82,6 +82,7 @@ - DDTDOC, interactive DDT documentation. - DECUUO, TOPS-10 and WAITS emulator. - DFTP, Datacomputer file transfer. +- DIGEST, digestify a mailing list. - DIRCPY, copy directory. - DIRDEV, list directories, sorted or subsetted. - DIRED, directory editor (independent from EMACS DIRED). diff --git a/src/digest/digest.184 b/src/digest/digest.184 new file mode 100755 index 00000000..f021f7da --- /dev/null +++ b/src/digest/digest.184 @@ -0,0 +1,2007 @@ +; -*- Midas -*- + +title DIGEST + +a=:1 +b=:2 +c=:3 +d=:4 +e=:5 +in=:6 ; Current input +out=:7 ; Current output + +t=:10 +tt=:11 +x=:12 +y=:13 +z=:14 + +p=:17 + +$version==:.ifvrs + +..bch==:0,,-1 +chdfsi==:1 ; DEFS file input +chlogo==:2 ; LOG file output +chlock==:3 ; LOCK device channel +chibxi==:4 ; Inbox input +chibxo==:5 ; Inbox output +chrec==:6 ; Record file channel +chadmi==:7 ; Administrivia file input +chdigo==:10 ; Digest output +cherri==:11 ; ERR: input for FORMAT + +%fr==:0,,525252 +%fl==:1,,525252 +%flurk==:200000 ; Inbox didn't fit in core +%fladm==:100000 ; Administrivia feature +%flnpr==:040000 ; Not Prime Time +%flwai==:020000 ; Digest sent less than C(WAITIM) mins ago +%fldla==:010000 ; Need to delete administrivia file + +call=:pushj p, +return=:popj p, +save==:push p, +rest==:pop p, +pause=:.break 16,100000 +slose=:.lose %lssys + +define bltdup org,len + move tt,[,,+1] + blt tt,+-1 +termin + +define syscall name,args + .call [setz ? .1stwd sixbit /name/ ? args(400000)] +termin + +define conc foo,bar +foo!bar!termin + +define fall sym +if2, ifn .-, .err Can't fall into sym? +termin + +popj1: aos (p) +cpopj: return + +rfn"$$rfn==:1 +rfn"rsixtp==:cpopj +rfn"$$ruc==:1 +rfn"$$pfn==:1 +rfn"psixtp==:cpopj +.insrt dsk:syseng;rfn > + +datime"$$abs==:1 +datime"$$out==:1 +datime"$$outz==:1 +datime"$$rfc==:1 +.insrt dsk:syseng;datime > + +format"$$time==:1 +format"datime==:datime"timrfc ; ~Q +format"time==:datime"twdasc ; ~:Q +format"date==:datime"timrfc ; ~@Q +format"$$pfn==:1 +format"pfn==:rfn"pfn +format"$$errs==:1 +format"erri==:cherri +.insrt dsk:syseng;format > + +format"defop "Z,op.Z ; Don't try this at home kids... + +op.Z: format"nextarg a + jumpge e,op.Z4 + move a,sy.idx(a) + move a,asym(a) + dmove a,sy.ptr(a) + call op.Z0 + movei c,": + format"tyo c + movei c,40 + format"tyo c + format"getarg a +op.Z4: dmove a,sy.ptr(a) + call op.Z0 + jrst format"loop + +op.Z0: jumple b,op.Z3 + ldb c,a + jrst op.Z2 + +op.Z1: ildb c,a +op.Z2: format"tyo c + sojg b,op.Z1 +op.Z3: return + +define format &string&,args,ioloc,type=[$format] + call [ + call type +.zzz.==-1 +irp arg,,[args] + save arg +.zzz.==.irpcnt +termin + hrroi a,[ascii string] + movei b,.length string + movni c,.zzz.+1 +ifnb ioloc,[ movei out,ioloc ] + jrst format"format] +termin + +$forma: save a + save b + save c + save out + call @-4(p) + rest out + rest c + rest b + rest a + rest (p) + return + +define princ &string& + call [ + call $princ + <.length string>,,[ascii string] + ] +termin + +$princ: exch a,(p) + save b + hlrz b,(a) + hrrz a,(a) + hrli a,440700 + call outstr + rest b + rest a + return + +define report &string&,args +format string,[args][logo][$report] +termin + +$report==:$format + +define die &string&,args +format string,[args][logo][$die] +termin + +$die: report "~2&Fatal error: " + call @(p) + move t,-1(p) + movei t,-2(t) + report "~&PC/ ~:H",[t] + jrst quit + +define barf &string&,args +format string,[args][logo][$barf] +termin + +$barf: report "~&Error: " + call @(p) + move t,-1(p) + movei t,-2(t) + report "~&Aborting. (PC/ ~:H)",[t] + jrst abort + +; JSP T,LOSE with error code in TT +lose: trne tt,-100 .see iocint + jrst losioc + syscall lose,[movei %lssys(tt) ? movei -2(t)] + slose + +losioc: syscall lose,[movei 1+<.lz %piioc> ? movei -2(t)] + slose + +edie: save t + call $die + report "~:@E.~%",[tt] + return + +fdie: save t + call $die + report "~F -- ~:E.~%",[t,b,tt] + return + +ebarf: save t + call $barf + report "~:@E.",[tt] + return + +fbarf: save t + call $barf + report "~F -- ~:E.",[b,tt] + return + +; Format of IO block: +..bio==:0,,-1 +io.bp==:0 ; Byte pointer into buffer +io.bc==:1 ; Count of available input or space +io.cal==:2 ; Routine to put or get next buffer +io.pos==:3 ; Position (plus IO.BC) +io.ibp==:4 ; Initial IO.BP +io.ibc==:5 ; Initial IO.BC +io.chn==:6 ; Channel, or other argument to buffer routine +io.buf==:7 ; Buffer aobjn, or "" +io.sta==:8 ; Status, or "" +io.siz==:9 ; Size of this structure + +; In the following macros, LOC can be indexed, but not indirect. + +define ioout ac,loc=[(out)] + +io.bp + +io.bc + +io.cal +termin + +define ioflush loc=[(out)] + +io.cal +termin + +define ioin ac,eofcod=[...],loc=[(in)] + +io.bc + call [ +io.cal ? eofcod ] + +io.bp +termin + +define iopos ac,loc=[...] + +io.pos + +io.bc +termin + +; CALL CHCOPY: Stream to channel copy until EOF +; .+1: Error code in TT +; .+2: Normal +; IN (a/v): Address of input IO block +; A (a/v): Unit output channel +chcopy: syscall siot,[moves tt ? movei (a) ? move io.bp(in) ? move io.bc(in)] + return + save [chcopy+2] + call io.cal(in) ; No, you cannot JRST IO.CAL(IN) + aos (p) + return + +; CALL IOCOPY: Stream to stream copy until EOF +; IN (a/v): Address of input IO block +; OUT (a/v): Address of output IO block +iocopy: save a + save b +iocpy0: move a,io.bp(in) + move b,io.bc(in) + call outstr + save [iocpy0+2] + call io.cal(in) + rest b + rest a + return + +; CALL OUTSTR: Output a string +; A (arg): Byte pointer +; B (arg): Byte count +; OUT (a/v): Address of output IO block +outst4: sub b,io.bc(out) + call outst7 + movn b,io.bc(out) + setzm io.bc(out) + call io.cal(out) +outstr: movn b,b + addm b,io.bc(out) + skipg io.bc(out) + jrst outst4 +outst7: jumpge b,cpopj + save t +outst8: ildb t,a + idpb t,io.bp(out) + aojl b,outst8 + rest t + return + +; CALL OPENO: Open buffered output stream +; A (a/v): Channel in RH, opened in unit output mode +; C (arg): Aobjn to buffer +; OUT (a/v): Address of IO block +openo: hrrzm a,io.chn(out) + movei t,(c) + hrli t,440700 + movem t,io.ibp(out) + movem t,io.bp(out) + hlro t,c + imul t,[-5] + movem t,io.ibc(out) + movem t,io.bc(out) + movem t,io.pos(out) + move t,[call ocall] + movem t,io.cal(out) + return + +; OCALL: Buffer routine for buffered unit output stream +ocall: exch out,(p) ? save x ? save y ? save t ? save tt + movei out,-<1+io.cal>(out) + move y,io.ibc(out) + sub y,io.bc(out) + jumpe y,ocallx + movn t,io.bc(out) + addm t,io.pos(out) + move t,io.ibc(out) + addm t,io.pos(out) + movem t,io.bc(out) + move x,io.ibp(out) + movem x,io.bp(out) + syscall siot,[moves tt ? move io.chn(out) ? move x ? move y] + jsp t,[ cain out,logo + jrst lose + jrst ebarf ] +ocallx: rest tt ? rest t ? rest y ? rest x ? rest out + return + +; CALL OPENI: Open buffered input stream +; A (a/v): Channel in RH, opened in block ascii input mode +; C (arg): Aobjn to buffer +; IN (a/v): Address of IO block +openi: hrrzm a,io.chn(in) + movei t,(c) + hrli t,440700 + movem t,io.ibp(in) + move x,c + aobjn c,.+2 + .lose + movem c,io.buf(in) + hlro t,c + imul t,[-5] + movem t,io.ibc(in) + setzm io.pos(in) + move t,[call icall] + movem t,io.cal(in) + save [-1] ? save in ? save x ? save t ? save tt + jrst icall0 + +; ICALL: Buffer routine for buffered block ascii input stream +icall: exch in,(p) ? save x ? save t ? save tt +repeat 2, sos -5(p) + movei in,-<1+io.cal>(in) + skipge t,io.sta(in) + jrst icalle + move x,io.buf(in) + move tt,-1(t) + movem tt,-1(x) +icall0: syscall iot,[moves tt ? move io.chn(in) ? move x] + jsp t,edie + movem x,io.sta(in) + jumpl x,icall9 + move x,io.ibc(in) +icallx: movem x,io.bc(in) + addm x,io.pos(in) + move tt,io.ibp(in) + movem tt,io.bp(in) + rest tt ? rest t ? rest x ? rest in ? rest (p) + return + +icall9: move t,-1(x) + sub x,io.buf(in) + movei x,(x) + imuli x,5 + jumpl x,icallf ; Zero length file + call unpad + addi x,(t) + jrst icallx + +icalle: move tt,-4(p) + movem tt,-5(p) +icallf: setzi x, + jrst icallx + +; SICALL: Buffer routine for string input stream +sicall: exch in,(p) + setzm io.bc-<1+io.cal>(in) + rest in + rest -1(p) + return + +; SOCALL: Buffer routine for string output stream +socall: save t + save tt + movei tt,%enrbf + jsp t,edie + +; JSP T,WOTSTR: With output to string +; X (arg): Length of string to allocate +; OUT (val): Address of stack allocated IO block +wotstr: save [440700,,0] ; IO.BP + save x ; IO.BC + save [call socall] ; IO.CAL + save x ; IO.POS + save [350700,,0] + save out + save t + save a + movei t,4(x) + idivi t,5 + movei a,(t) + call alloc + jsp t,edie + hrrm a,-7(p) + hrrm a,-3(p) + movei out,-7(p) + rest a + return + +; JSP T,WOTOUT: Finish WOTSTR +; A,B (val): String +; OUT (val): Restored +wotout: rest out + rest a + rest b + sub b,-1(p) + sub p,[3,,3] + jrst (t) + +; CALL MBXLOCK: Lock a mailbox +; .+1: Error code in TT +; .+2: Normal +; B (a/v): Name block +; See .INFO.;ITS LOCKS +mbxloc: move x,1(b) + rot x,1 + add x,2(b) + rot x,1 + add x,3(b) + idivi x,777773 + hrli y,(sixbit /MBX/) + syscall open,[moves tt ? movsi .uao ? movei chlock + [sixbit /LOCK/] ? move y] + return + aos (p) + return + +; CALL BIGIOT: Break an IOT into chunks +; .+1: Error code in TT +; .+2: Normal +; A (a/v): Block mode channel in RH +; Z (a/v): IOT pointer (updated) +; Only clobbers T and TT +; Goddamn IOT system call can't work for more than 32. blocks. (For more +; than 128. blocks the pointer isn't negative, and some devices even look +; at bits 4.8 and 4.7 as well!) +bigiot: tlnn z,-1 + jrst bigio2 +bigio1: move t,z + tlo t,700000 + syscall iot,[moves tt ? movei (a) ? move t] + return + movei tt,(t) + subi tt,(z) + hrli tt,(tt) + add z,tt + tlne z,-1 + jumpge t,bigio1 +bigio2: aos (p) + return + +; And while we're being embarrassed by ITS, there is always this joke: + +; CALL UNPAD: Count the number of characters in the last word in a file. +; T (arg): Last word +; T (val): Number of characters (1 - 5) +; Only clobbers TT +unpad: xor t,[ .byte 7 ? ^C ? ^C ? ^C ? ^C ? ^C ] + move tt,t + subi tt,2 + xor t,tt + jffo t,.+1 + movei t,7(tt) + idivi t,7 + return + +; JSP TT,ACSAVE: Save A through E, IN and OUT +svpc==:-8 ; SVPC(P) is return PC +svac0==:-8 ; SVAC0+C(P) is saved value of C +acsave: save a + save b + save c + save d + save e + save in + save out + call (tt) + caia + aos -7(p) + rest out + rest in + rest e + rest d + rest c + rest b + rest a + return + +; CALL FINAL: RENMWO, FINISH, CLOSE +; .+1: Error code in TT +; .+2: Normal +; A (a/v): Channel in RH +; B (a/v): Name block +final: .call renmwo + return + .call finish + jfcl + .call close + jsp t,fdie + aos (p) + return + +; CALL GOBOPN: Open a file +; .+1: Error code in TT +; .+2: Normal +; A (a/v): Block input channel in RH +; B (a/v): Name block +; E (val): Word count +gobopn: hrli a,.bai + .call open + return + adjsp p,4 + movei x,-3(p) + syscall rfname,[movei (a) + movem 0(x) ? movem 1(x) ? movem 2(x) ? movem 3(x)] + movei x,(b) + syscall rfdate,[movei (a) ? movem y] + caia + skipge y + setzi y, + syscall rauth,[movei (a) ? movem z] + caia + skipn z + movsi z,(sixbit /???/) + syscall fillen,[moves tt ? movei (a) ? movem e] + jrst gobop8 + report "~&Reading ~F (~D words, ~:Q, ~S).",[x,e,y,z] + aos -4(p) +gobop8: adjsp p,-4 + return + +; CALL GOBBLE: Read an entire ASCII file into core +; .+1: Error code in TT +; .+2: File didn't fit +; .+3: Normal +; A (a/v): Block input channel in RH +; C (a/v): Page aobjn to free core (updated) +; E (arg): Word count +; D (val): Byte pointer (incremented: 350700,,) +; E (val): Byte count +gobble: move d,c + lsh d,12 ; D: Word aobjn to given memory + hrloi x,-1(e) + eqvi x,(d) ; X: Word aobjn for file + hlro t,d + movn t,t ; = length of given memory + camle e,t + skipa y,d + skipa y,x ; Y: ... rounded down to given memory + move e,t ; E: ... rounded down to given memory + jumpe e,gobbl1 ; Don't ask for core you don't need... + move t,y + lsh t,-12 + trz t,-400 + tlo t,-400 + syscall corblk,[moves tt ? movei %cbndw + movei %jself ? move t ? movei %jsnew] + return +gobbl1: move z,y + call bigiot + return + aos (p) + movei t,1777(e) + lsh t,-12 + hrli t,(t) + add c,t ; Update C + hrli d,350700 ; Convert D into ascii byte pointer + imuli e,5 ; Convert E into character count + came x,y + return + aos (p) + jumpe e,cpopj + move t,-1(z) + call unpad + subi e,5 + addi e,(t) + return + +open: setz ? sixbit /OPEN/ + moves tt + move a + move 0(b) ? move 1(b) ? move 2(b) ? setz 3(b) + +topen: setz ? sixbit /OPEN/ + moves tt + move a + move 0(b) ? [sixbit /_DGST_/] ? [sixbit /OUTPUT/] ? setz 3(b) + +renmwo: setz ? sixbit /RENMWO/ + moves tt + movei (a) + move 1(b) + setz 2(b) + +finish: setz ? sixbit /FINISH/ + moves tt + setzi (a) + +close: setz ? sixbit /CLOSE/ + moves tt + setzi (a) + +.vector pdl(lpdl==:100.) + +.scalar uname,jname,xuname,xjname,sname + +usrvar: sixbit /OPTION/ ? tlo %opint\%opopc + sixbit /MASK/ ? move [%pipdl\%piioc] + sixbit /UNAME/ ? movem uname + sixbit /JNAME/ ? movem jname + sixbit /XUNAME/ ? movem xuname + sixbit /XJNAME/ ? movem xjname + sixbit /SNAME/ ? movem sname +lusrvar==:.-usrvar + +its: sixbit /MC/ ? sixbit /AI/ ? sixbit /ML/ ? sixbit /MD/ +nits==:.-its + +itsnam: 440700,,[asciz /MC.LCS.MIT.EDU/] + 440700,,[asciz /AI.AI.MIT.EDU/] + 440700,,[asciz /ML.AI.MIT.EDU/] + 440700,,[asciz /MD.LCS.MIT.EDU/] +nits==:.-itsnam + +go: move p,[-lpdl,,pdl-1] + setzi 0, ; Clear flags + movei t,heap+lheap + movem t,heapcor + move t,[-lusrvar,,usrvar] + syscall usrvar,[movei %jself ? move t] + slose + skipn debug + jrst nodbg + setom mintim ; Throw caution to the winds + move x,sname ; But only on my directory +irps foo,,[log,dfs,mai,dig] + movem x,foo!dir +termin +nodbg: +.scalar date + syscall rqdate,[movem date] + slose + setoi t, + camn t,date + jrst quit0 + hrrz t,date + idivi t,2*60. ; T: time of day in minutes + caml t,bprime + camle t,eprime + tlo %flnpr +.scalar date6,time6 + .rdatim t, + movem t,time6 + movem tt,date6 +.scalar mach6 + syscall sstatu,[repeat 6,[ ? movem mach6]] + slose +.scalar hostz + move x,mach6 + movsi t,-nits + came x,its(t) + aobjn t,.-1 + skipl t + .lose + move t,itsnam(t) + movem t,hostz + +.vector logo(io.siz) +.vector logbuf(llogbuf==:200.) + + move a,[%dowov\.uao,,chlogo] + movei b,logblk + move c,[-llogbuf,,logbuf] + movei out,logo +go6: .call open + jsp t,[tlze a,%dowov + jrst go6 + cain tt,%efldv + jrst quit0 ; Don't make trouble... + cain tt,%efldr + jrst quit0 ; Send mail to digestifier maintainers? + jrst lose ] + tlzn a,%dowov + jrst go7 + syscall fillen,[moves tt ? movei (a) ? movem x] + jsp t,lose + caml x,[50.*2000*5] ; 50 blocks + jrst go6 + .access chlogo,x +go7: call openo + report "Digestifier version ~D running on ~A (~S).~@ + Job: ~S ~S Date: ~:Q~ + ",[versio,hostz,mach6,uname,jname,date] + tlnn %flnpr + report " (Prime Time)" + movei a,chdfsi + movei b,dfsblk + move c,[-npdefs,,pgdefs] + call gobopn + jsp t,fdie + call gobble + jsp t,fdie + die "File is too big!" + jrst gogo + +.vector defsd(2) +.scalar deflst + +abort: move p,[-lpdl,,pdl-1] + syscall delewo,[movei chdigo] + jfcl + .close chdigo, + syscall delewo,[movei chibxo] + jfcl + jrst next + +dlnext: syscall delewo,[movei chibxi] + jsp t,edie +danext: .close chibxi, + tlnn %fldla + jrst next + syscall delewo,[movei chadmi] + jsp t,edie + .close chadmi, +next: .close chibxo, + .close chlock, + dmove d,defsd +gogo: tlz %flurk\%fladm\%flwai\%fldla + call nxtmsg + jrst done + dmovem d,defsd ; So ABORT skips to next digest + report "~2& -- Next --" + call initat + call rddef + dmovem d,defsd + movem a,deflst +gogo1: jumpe a,goibx + report "~&~:Z",a + hrrz a,sy.nxt(a) + jrst gogo1 + +done: report "~2& -- Done --~2&" +quit: ioflush logo + .close chlogo, +quit0: skipe debug + pause + .logout 1, + +.vector ibxblk(4) + +goibx: move e,deflst + movei x,digblk + move y,[sixbit /INBOX/] + movei t,atibx + movei b,ibxblk + call fname + barf "No inbox specified." + skipn ibxblk+1 + barf "Illegal inbox name: ~F",[b] + jrst goadm + +.vector admblk(4) + +goadm: move e,deflst + movei x,ibxblk + move y,[sixbit /ADMIN/] + movei t,atadm + movei b,admblk + call fname + caia + tlo %fladm + jrst gorec + +.vector recblk(4) + +gorec: move e,deflst + movei x,ibxblk + move y,[sixbit /RECORD/] + movei t,atrec + movei b,recblk + call fname + jfcl + move a,[.bai,,chrec] + .call open + jsp t,gorec5 +gorec6: move x,[-nprec,,pgrec] + movsi y,(-nprec,,0) + syscall corblk,[moves tt ? movei %cbndw + movei %jself ? move x + movei chrec ? move y] + jsp t,fbarf + syscall dskupd,[moves tt ? movei chrec] + jsp t,fbarf + .close chrec, + jrst getibx + +gorec5: caie tt,%ensfl + jrst fbarf + report "~&Creating new record file: ~F",[b] + hrli a,.bao + .call topen + jsp t,fbarf + move x,[-nprec,,pgrec] + syscall corblk,[moves tt ? movei 0 ? movei %jself ? move x] + jsp t,ebarf + move x,[-nprec,,pgrec] + syscall corblk,[moves tt ? movei %cbndw + movei %jself ? move x + movei %jsnew] + jsp t,ebarf + setzm rec + bltdup rec,lrec + move e,deflst + movei t,atinum + call fnum + barf "Unspecified or unparsable First-Issue-Number." + movem x,rcinum + move z,[-lrec,,rec] + call bigiot + jsp t,fbarf + call final + jsp t,fbarf + hrli a,.bai + .call open + jsp t,fbarf + jrst gorec6 + +.scalar ibxlst + +bloat: /2 ; How big an inbox is before we consider it + ; bloated: 1.5 digests. (Digests are only + ; produced during Prime Time unless the + ; inbox becomes bloated.) +bprime: 2*60. ; "Prime Time" starts at 2AM +eprime: 7*60. ; and ends at 7AM +mintim: 90. ; At least 90 minutes between digests no + ; matter what. +waitim: 18.*60. ; At least 18 hours between digests if the + ; inbox isn't bloated. + +getibx: move a,date + move b,rcdate + call datime"timsub + idivi a,60. ; Get that in minutes + report "~&Last digest mailed ~D minute~P ago.",[a] + camg a,mintim + jrst [ report "~&Too soon for another digest." + jrst next ] + camge a,waitim + tlo %flwai + movei a,chibxi + movei b,ibxblk + move c,[-npibx,,pgibx] + call mbxlock + jsp t,[caie tt,%enafl + jrst ebarf + report "~&Inbox locked." + jrst next ] + call gobopn + jsp t,[caie tt,%ensfl + jrst fbarf + report "~&No inbox found." + jrst next ] + camge e,bloat ; If the inbox is bloated, or it is + tlnn %flnpr\%flwai ; Prime Time and we haven't produced a digest + jrst gtibxg ; recently, then go. + report "~&No digest needed." + jrst next + +gtibxg: report "~&Reading inbox ..." + ioflush logo + call gobble + jsp t,fbarf + tlo %flurk + call fstmsg + jrst [ tlne %flurk ; This can't ever happen, but... + barf "Excessive whitespace in inbox." + report "~&Inbox is empty." + jrst dlnext ] + setzi b, + call rdmsg + jrst [ tlne %flurk + barf "Excessively large message in inbox." + jrst gtibx2 ] +gtibx1: call cons + call nxtmsg + jrst [ tlne %flurk + jrst gtibx4 + jrst gtibx5 ] + dmovem d,ibxd + call rdmsg + jrst [ tlne %flurk + jrst gtibx3 + jrst gtibx2 ] + jrst gtibx1 + +gtibx2: call cons +gtibx5: call nreverse + movem a,ibxlst + jrst godig + +.vector ibxd(2) +.vector ibxi(io.siz) +.vector ibxbuf(libxbuf==:1000.) + +gtibx4: dmovem d,ibxd +gtibx3: call nreverse + movem a,ibxlst + report "~&Preparing updated inbox ..." + ioflush logo + move a,[.uao,,chibxo] + movei b,ibxblk + .call topen + jsp t,fbarf + setoi x, + adjbp x,ibxd+0 + syscall siot,[moves tt ? movei chibxo ? move x ? move ibxd+1] + jsp t,fbarf + movei a,chibxi + move c,[-libxbuf,,ibxbuf] + movei in,ibxi + call openi + movei a,chibxo + call chcopy + jsp t,ebarf + report " done." + ioflush logo + jrst godig + +.vector digo(io.siz) +.vector digbuf(ldigbuf==:1000.) +.scalar digname +.scalar nmsgs +.scalar sbjlst +.scalar nsubj +.vector admi(io.siz) +.vector admbuf(ladmbuf==:100.) + +majsep: 70. ; major separator length +minsep: 30. ; minor separator length +usrsep: 25. ; users are allowed separators this long + +godig: move b,ibxlst + call length + movem t,nmsgs + report "~&~D message~P found in inbox.",[nmsgs] + move c,ibxlst + setzm sbjlst + setzm nsubj +subj1: hlrz e,(c) + movei t,atsubj + call find + jrst subj2 + dmove a,sy.ptr(a) + call sbjtrm + jumpe b,subj2 ; Empty subject fields are worthless + call intern + aos sy.sbj(a) + aos nsubj + move b,sbjlst + call memq + call cons + movem b,sbjlst +subj2: hrrz c,(c) + jumpn c,subj1 + move b,sbjlst + call nreverse + movem a,sbjlst + + move e,deflst + movei t,atname + call find + barf "No Name specified." + movem a,digname + movei t,atsubj + call dflt + format "~Z Digest #~D",[digname,rcinum] + movei a,chdigo + move c,[-ldigbuf,,digbuf] + movei out,digo + call mopen + jsp t,ebarf + movem e,deflst + format "~v<~Z Digest #~D~; ~Q~>",[majsep,digname,rcinum,date] + format "~2&Today's Topics:~%" + skipn c,sbjlst + jrst nosubj +subj9: hlrz a,(c) + format "~% ~Z",[a] + move t,sy.sbj(a) + caie t,1 + format " (~D message~P)",[t] + hrrz c,(c) + jumpn c,subj9 +nosubj: move t,nmsgs + sub t,nsubj + skipe t + format "~% ~D message~P without subject~P",[t] + tlnn %fladm + jrst noadm + move a,[.bai,,chadmi] + movei b,admblk + .call open + jsp t,[cain tt,%ensfl + jrst noadm + jrst fbarf ] + report "~&Found administrivia file." + tlo %fldla + move c,[-ladmbuf,,admbuf] + movei in,admi + call openi + format "~2&Administrivia:~2&" + call iocopy +noadm: format "~2&~v<~;-~>~2&",[majsep] + move a,ibxlst +godig1: hlrz e,(a) + call mtype + format "~2&~v<~;-~>~2&",[minsep] + hrrz a,(a) + jumpn a,godig1 + iopos b,digo + format "End of ~Z Digest",[digname] + iopos a,digo + sub a,b + format "~&~v<~;*~>",[a] + + iopos a,digo + report "~&Mailing ~Z Digest #~D (~D message~P, ~D characters).~ + ",[digname,rcinum,nmsgs,a] + ;; Haven't done anything permanent up to now. Now we start to do + ;; things that we can't take back: + aos rcinum + syscall pgwrit,[movei ] + jsp t,ebarf + ;; If something goes wrong now, we might skip an issue number + call mclose + jsp t,ebarf + move t,date + movem t,rcdate + ;; If something goes wrong now, we might duplicate the contents of + ;; a digest + tlnn %flurk + jrst dlnext ; Usually just go delete inbox + report "~&Updating inbox." + movei a,chibxo + movei b,ibxblk + call final + jsp t,fdie + jrst danext + +; CALL FNUM: Find and parse a number +; .+1: Symbol not found or can't parse it +; .+2: Symbol found and parsed +; E (a/v): List +; T (arg): Index to search for +; X (val): Number +fnum: jsp tt,acsave + call find + return + setzi x, + setoi y, + adjbp y,sy.ptr(a) + skipg z,sy.len(a) + return +fnum1: ildb t,y + move t,chtype(t) + tlnn t,%ctdig + return + imuli x,10. + addi x,-"0(t) + sojg z,fnum1 + aos (p) + return + +; CALL FNAME: Find and parse a file name +; .+1: Symbol not found +; .+2: Symbol found +; E (a/v): List +; T (arg): Index to search for +; X (arg): Default name block +; Y (arg): Default FN2 +; B (a/v): Name block to fill in +fname: jsp tt,acsave + hrli x,(x) + hrri x,(b) + blt x,3(b) + movem y,2(b) + call find + return + aos (p) + setoi x, + adjbp x,sy.ptr(a) + move y,sy.len(a) + jrst rfn"rfn + +ruc: sojl y,[ movei a,^C ? return ] + ildb a,x + cail a,140 + subi a,40 + return + +; CALL MOPEN: Start sending mail +; .+1: Error code in TT +; .+2: Normal +; A (a/v): Channel in RH +; C (a/v): Aobjn to buffer +; E (a/v): Initial contents list +; OUT (a/v): Address of IO block +mopen: jsp tt,acsave + hrli a,.uao + movei b,maiblk + .call topen + return + call openo + movei t,atdate + call dflt + format "~Q",date + movei t,atmsid + call dflt + call mkmsid + movei t,atfrom + call find + jrst rebdrg + movei t,atauth + call find + jrst rebdrg + move b,a + movei t,atrcpt + call find + jrst rebdrg + format "FROM-PROGRAM:~S~@ + FROM-XUNAME:~S~@ + FROM-UNAME:~S~@ + AUTHOR:~Z~@ + RCPT:~Z~@ + HEADER-FORCE:NULL~@ + REGISTERED:F~@ + TEXT;-1~%",[xjname,xuname,uname,b,a] + movem e,svac0+e(p) + aos (p) + jrst mtype0 + +rebdrg: movei tt,%ebdrg + return + +; CALL MTYPE: Format mail +; .+1: Error code in TT +; .+2: Normal +; E (a/v): Attribute List +mtype: jsp tt,acsave +mtype0: jumpe e,mtype5 +mtype7: move t,sy.idx(e) + caml t,aidx+attext + jrst mtype4 + format "~:Z~%",e + hrrz e,sy.nxt(e) +mtype6: jumpn e,mtype7 +mtype5: format "~%" + return + +mtype4: format "~%" + camn t,aidx+attext + format "~Z",e + return + +; CALL MKMSID: Output a message ID +mkmsid: .gennum t, + format "",[versio,date6,time6,t,hostz] + return + +; CALL MCLOSE: Finish sending mail +; .+1: Error code in TT, mail may or may not have been sent +; .+2: Normal, mail is on it's way! +; OUT (a/v): Address of IO block +mclose: jsp tt,acsave + format "~&" + ioflush (out) + hrrz a,io.chn(out) + movei b,maiblk + jrst final + +; CALL FIND: Find a symbol in a (sorted) list +; .+1: None found +; .+2: Found one +; E (a/v): List +; T (a/v): Index to search for (canonicalized) +; A (val): First symbol found +find: move t,aidx(t) + movei a,(e) + jumpe a,cpopj +find1: camg t,sy.idx(a) + jrst find2 + hrrz a,sy.nxt(a) + jumpn a,find1 + return + +find2: camn t,sy.idx(a) + aos (p) + return + +; CALL INSERT: Insert a symbol in a sorted list +; A (a/v): Symbol to insert +; E (a/v): List (updated) +insert: move t,sy.idx(a) + movei x,e + jrst insrt1 + +insrt3: camge t,sy.idx(y) + jrst insrt2 + movei x,sy.nxt(y) +insrt1: hrrz y,(x) + jumpn y,insrt3 +insrt2: hrrzm y,sy.nxt(a) + hrrzm a,(x) + return + +; CALL DFLT: Default +; .+1 (arg): Instruction to output default value +; .+2: Return +; E (a/v): List (updated) +; T (arg): Index to search for +; A (val): Symbol found, or newly inserted +; B - E passed to routine +dflt: call find + jrst dflt1 + aos (p) + return + +dflt1: aos a,(p) + save b + save t + movei x,80. + jsp t,wotstr + xct -1(a) + jsp t,wotout + save a + movei a,sy.siz + call alloc + jsp t,edie + rest sy.ptr(a) + movem b,sy.len(a) + rest sy.idx(a) + rest b + jrst insert + +%ct==:1,,525252 + +%ctact==: 400000 +%cteof==: 200000 +%cteom==: 100000 +%ctcr==: 040000 +%ctlf==: 020000 +%cteol==:%ctcr\%ctlf +%ctsp==: 010000 +%cttab==: 004000 +%cthws==:%ctsp\%cttab +%ctws==:%cthws\%cteol +%ctnpr==: 002000 +%ctcol==: 001000 +%ctalp==: 000400 +%ctdig==: 000200 +%ctanm==:%ctalp\%ctdig + +define defch ch,-line +loc chtype+ch + line +termin + +chtype: repeat 200, %ctact\%ctnpr,,.rpcnt +defch 41, repeat 177-41, 0,,.rpcnt+41 +defch "0, repeat 10., %ctdig,,<.rpcnt+"0> +; STRCMP and STRHSH depend on the CHTYPE entries for upper and lower case +; being identical: +defch "A, repeat 26., %ctalp,,<.rpcnt+"A> +defch "a, repeat 26., %ctalp,,<.rpcnt+"A> +defch ^_, %ctact\%ctnpr\%cteom,,^_ +defch ^M, %ctact\%ctnpr\%ctcr,,^M +defch ^J, %ctact\%ctnpr\%ctlf,,^J +defch ^I, %ctact\%ctnpr\%cttab,,^I +defch 40, %ctact\%ctnpr\%ctsp,,40 +defch ":, %ctact\%ctcol,,": +loc chtype+200 + +; CALL INCH: Advance one character +; CALL CRLFCH: Advance one character, where CRLF counts as one +; CALL RINCH: Back up one character +; CALL INITCH: Initialize for parsing (reloads C) +; CALL SETCH: Move to saved point +; CALL MOVECH: Move relative to current point +; JSP T,SCAN: Advance one character, exit to .-1 +; C (a/v): Character (updated) +; D (a/v): Byte pointer (updated) +; E (a/v): Byte count (updated) +; T (arg): Distance (for MOVECH) or old point (for SETCH) +; Only clobbers T and TT +crlfch: tlne c,%ctcr + save [incrl1] +inch: sojle e,inch9 + ildb c,d + move c,chtype(c) + return + +incrl1: tlne c,%ctlf + jrst inch + return + +rinch: skipa t,[-1] +setch: subm e,t +movech: sub e,t + adjbp t,d + movem t,d +initch: jumple e,movch9 + ldb c,d + move c,chtype(c) + return + +inch9: ibp d +movch9: movsi c,%cteof + return + +scan: sojle e,scan9 + ildb c,d + move c,chtype(c) + jrst -2(t) + +scan9: ibp d + movsi c,%cteof + jrst -2(t) + +; CALL BLANK: Skip blank lines +; C,D,E as usual +blank: call initch + tlne c,%cteol + jsp t,scan + move x,e + tlne c,%cthws + jsp t,scan + tlne c,%cteol + jrst blank + tlne c,%cteof\%cteom + return + move t,x + jrst setch + +; CALL FIELD: Pick up a field, and advance to next one +; A,B (val): Field +; C,D,E as usual +field: call initch + dmove a,d +field1: tlnn c,%cteof\%cteom\%cteol + jsp t,scan + move x,e + tlne c,%cteof\%cteom + jrst field9 + call crlfch + tlne c,%cthws + jrst field1 +field9: sub b,x + return + +; CALL FSTMSG: Advance to first message +; CALL NXTMSG: Advance to next message +; .+1: End of file +; .+2: Normal (positioned at start of first non-blank line) +; D,E as usual +fstmsg: save c + jrst fstms1 + +nxtmsg: save c + call initch + tlnn c,%cteof\%cteom + jsp t,scan +nxtms1: tlne c,%cteof + jrst nxtms8 + call inch +fstms1: call blank + tlne c,%cteof\%cteom + jrst nxtms1 + aos -1(p) +nxtms8: rest c + return + +; CALL RDDEF: Parse definition from DEFS file +; A (val): List of attribute cells +; D,E as usual +rddef: jsp tt,acsave + movei out,logo + setzm svac0+a(p) +rddef0: call blank + tlne c,%cteof\%cteom + jrst rddef9 + tlne c,%cthws + jrst rddef1 + call field + call type + skipl t,sy.idx(c) + camn t,aidx+attext ; TEXT attribute isn't ever legal... + jrst rddef3 + call xfield + jrst rddef0 + +rddef3: report |~&Ignoring unknown "~Z" field.|,c + jrst rddef0 + +rddef9: dmovem d,svac0+d(p) + return + +rddef1: call field + report |~&Ignoring indented text: "| +rddef2: call strtrm + call strtyp + princ |"| + jrst rddef0 + +; CALL RDMSG: Parse message from mail file +; .+1: Message ended with EOF +; .+2: Message ended with EOM +; A (val): List of attribute cells +; D,E as usual +rdmsg: jsp tt,acsave + movei out,logo + setzm svac0+a(p) + call blank +rdmsg0: call initch + tlne c,%cteof\%cteom\%cteol + jrst rdmsg7 + call field + call type + skipl t,sy.idx(c) + caml t,[grtext,,0] ; Only groups before GRTEXT are kept + jrst rdmsg0 + call xfield + jrst rdmsg0 + +rdmsg7: call blank + dmove a,d + tlne c,%ctws + jsp t,scan + tlne c,%cteof\%cteom + jrst rdmsg9 +rdmsg8: tlnn c,%cteof\%cteom\%ctws + jsp t,scan + move x,e +rdmsg5: tlne c,%cthws + jsp t,scan + tlnn c,%cteof\%cteom\%cteol + jrst rdmsg8 + tlnn c,%cteol + jrst rdmsg6 + call inch + came c,chtype+"- + jrst rdmsg5 + dmove y,d + camn c,chtype+"- + jsp t,scan + sub z,e + movei t,40 + camle z,usrsep + dpb t,y + jrst rdmsg8 + +rdmsg6: sub b,x + move c,asym+attext + call xfiel0 + call initch +rdmsg9: dmovem d,svac0+d(p) + tlnn c,%cteof + aos (p) + return + +; Common to RDDEF and RDMSG +xfield: call strtrm +xfiel0: dmovem d,svac0+d-1(p) ; & alternate entry point + dmove d,a ; D,E: String + movei a,sy.siz + call alloc + jsp t,edie + dmovem d,sy.ptr(a) + setzm sy.hsh(a) + setzm sy.sbj(a) + move c,sy.idx(c) + movem c,sy.idx(a) + movei b,svac0+a-1(p) + jrst xfiel3 + +xfiel1: movei b,sy.nxt(x) +xfiel3: hrrz x,(b) + jumpe x,xfiel2 + caml c,sy.idx(x) ; Preserve order! + jrst xfiel1 +xfiel2: hrrzm x,sy.nxt(a) + hrrzm a,(b) + dmove d,svac0+d-1(p) + return + +; CALL TYPE: Get the type of a field +; A,B (arg): Field string +; A,B (val): Value string +; C (val): Keyword symbol +type: save d + save e + dmove d,a + call initch + tlne c,%ctws + jsp tt,scan + dmove a,d + tlnn c,%cteof\%ctws\%ctcol + jsp t,scan + sub b,e + call intern ; A: Keyword symbol + tlne c,%ctws + jsp t,scan + tlnn c,%ctcol + jrst type9 + call inch + tlne c,%ctws + jsp t,scan +type9: move c,a + dmove a,d + rest e + rest d + return + +..bgr==:1,,-1 +grorig==:1 +grrsnt==:2 +grtext==:3 +grdef==:4 + +define defxattr name,string +defattr [name][string][grorig] +defattr [x!name][ReSent-string][grrsnt] +termin + +define irpattr body +define defattr name,string,group=grorig +body +termin + +; All RFC822 attributes are here, plus a few other common ones. I have +; commented out those that I have explicitly decided not to include in +; digests. Before changing the status of any attribute here, please +; -think- about what you are doing. Fields that are rare (such as +; "Fonts"), and fields that have high utility (such as "Reply-To") are fine +; to include. Fields that are both common, and of low utility (such as +; "Received" and "In-Reply-To") are bad to include. (Minimizing the number +; of fields included is good because some people don't have a tool for +; bursting the digest, and so they have to read all the fields we include!) + +; Note that the fields included here are -both- the fields that appear in +; digested messages, and the fields that appear in the headers that we +; produce. (It wouldn't be hard to change this if necessary.) + +; defattr rtrn,Return-Path +; defattr rcvd,Received +defxattr msid,Message-ID +; defxattr inrp,In-Reply-To +; defxattr sup,Supersedes +; defxattr refs,References +; defattr imsg,Included-msgs +; defattr irefs,Included-References +defattr font,Fonts +defattr ctm,Character-Type-Mappings +defxattr date,Date +defxattr from,From +; defxattr send,Sender +defxattr path,Path +defxattr rpto,Reply-To +defxattr to,To +defxattr cc,CC +defxattr fcc,FCC +defxattr bcc,BCC +defxattr subj,Subject +defxattr sum,Summary +defxattr kwds,Keywords +defxattr com,Comments +defattr text,TEXT,grtext +defattr name,Name,grdef +defattr ibx,Inbox,grdef +defattr rec,Record,grdef +defattr adm,Administrivia,grdef +defattr auth,AUTHOR,grdef +defattr rcpt,RCPT,grdef +defattr inum,First-Issue-Number,grdef +termin + +.idx.==0 +..bat==:0,,-1 +irpattr [ at!name==:.idx. ? .idx.==.idx.+1 ] +nattr==:.idx. + +aptr: irpattr [ 350700,,[ascii "string"] ] +nattr==:.-aptr + +alen: irpattr [ .length "string" ] +nattr==:.-alen + +aidx: irpattr [ ,,at!name ] + +.vector asym(nattr) + +; CALL INITAT: Create initial symbol table entries +initat: jsp tt,acsave + movei t,heap+lheap + movem t,heapptr + setzm symtab + bltdup symtab,lsymtab + movsi e,-nattr +intat1: move a,aptr(e) + move b,alen(e) + call intern + movem a,asym(e) + move t,aidx(e) + movem t,sy.idx(a) + aobjn e,intat1 + return + +.vector symtab(lsymtab==:251.) ; 251 is prime + +..bsy==:0,,-1 +sy.ptr==:0 +sy.len==:1 +sy.idx==:2 +sy.nxt==:3 +sy.sbj==:4 +sy.hsh==:5 +sy.siz==:6 + +; CALL INTERN: Convert string into symbol +; A,B (a/v): String +; A (val): Symbol +intern: jsp tt,acsave + call strhsh + move t,c + idivi t,lsymtab + skipe d,symtab(tt) + jrst intrn2 + movei e,symtab(tt) +intrn3: movei a,sy.siz + call alloc + jsp t,edie + move t,svac0+a(p) + movem t,sy.ptr(a) + move t,svac0+b(p) + movem t,sy.len(a) + setzm sy.sbj(a) + movem c,sy.hsh(a) + hrrzm a,(e) + setzm sy.nxt(a) + setom sy.idx(a) + movem a,svac0+a(p) + return + +intrn1: movei e,sy.nxt(d) + skipn d,(e) + jrst intrn3 +intrn2: came c,sy.hsh(d) + jrst intrn1 + dmove x,sy.ptr(d) + call strcom + jrst intrn1 +intrn9: movem d,svac0+a(p) + return + +; CALL STRTRM: Trim string +; A,B (a/v): String +strtrm: save c ? save d ? save e +strtr0: dmove d,a ; & alternate entry point + call initch + tlne c,%ctws + jsp t,scan + dmove a,d + tlne c,%cteof + jrst strtr9 +strtr1: tlnn c,%cteof\%ctws + jsp t,scan + move x,e + tlne c,%ctws + jsp t,scan + tlnn c,%cteof + jrst strtr1 + sub b,x +strtr9: rest e ? rest d ? rest c + return + +; CALL SBJTRM: Trim a subject string +; A,B (a/v): String +sbjtrm: save c ? save d ? save e + dmove d,a + call initch +sbjtr1: tlne c,%ctws + jsp t,scan + dmove a,d + came c,chtype+"R + jrst strtr0 + call inch + came c,chtype+"E + jrst strtr0 + call inch + came c,chtype+": + jrst strtr0 + call inch + jrst sbjtr1 + +; CALL STRTYP: Type string +; A,B (a/v): String +strtyp: jsp tt,acsave + setoi a, + adjbp a,svac0+a(p) + jrst outstr + +; CALL STRHSH: Hash string +; A,B (a/v): String +; C (val): Hash (>= 0) +strhsh: movei c,17. + dmove x,a + jumpe y,cpopj + ldb t,x + jrst strhs1 + +strhs2: ildb t,x + rot c,7 +strhs1: add c,chtype(t) + sojg y,strhs2 + tlze c,400000 + hrri c,9973.(c) + return + +; CALL STRCOM: Compare strings +; .+1: Strings differ +; .+2: Strings match +; A,B (a/v): String +; X,Y (arg): String +strcom: came b,y + return + jumpe y,popj1 + move z,a + ldb t,z + ldb tt,x + jrst strcm1 + +strcm2: ildb t,z + ildb tt,x +strcm1: move t,chtype(t) + came t,chtype(tt) + return + sojg y,strcm2 + aos (p) + return + +.scalar heapptr,heapcor + +; CALL ALLOC: Allocate memory from the heap +; .+1: Error code in TT +; .+2: Normal +; A (arg): The number of words desired +; A (val): Aobjn to allocated block +alloc: movns t,a + addb a,heapptr + camge a,heapcor + jrst alloc1 +alloc9: hrli a,(t) + aos (p) + return + +alloc1: caige a,heap + jrst alloc2 + move x,a + trz x,1777 ; X: new HEAPCOR + move y,heapcor + sub y,x + hrloi y,-1(y) + eqvi y,(x) + lsh y,-12 + tlo y,-1_8 + syscall corblk,[moves tt ? movei %cbndw + movei %jself ? move y ? movei %jsnew] + jrst alloc8 + movem x,heapcor + jrst alloc9 + +alloc2: movei tt,%efldv +alloc8: movn a,t + addm a,heapptr + return + +; CALL CONS: Cons +; A (arg): Car +; B (arg): Cdr +; B (val): New cons +cons: hrli a,(b) + sos b,heapptr + camge b,heapcor + jrst cons1 + movsm a,(b) + return + +cons1: aos heapptr + movs b,a + movei a,1 + call alloc + jsp t,ebarf + movem b,(a) + movei b,(a) + return + +; CALL NREVERSE: Reverse a list +; CALL NRECONC: Reverse and concatenate a list +; A (arg): New tail for NRECONC +; B (arg): List +; A (val): Reversed list +nrever: setzi a, +nrecon: jumpe b,reta +nrecn1: hrrz t,(b) + hrrm a,(b) + jumpe t,retb + hrrz a,(t) + hrrm b,(t) + jumpe a,rett + hrrz b,(a) + hrrm t,(a) + jumpn b,nrecn1 +reta: return + +retb: movei a,(b) + return + +rett: movei a,(t) + return + +; CALL MEMQ: Membership test +; .+1: Not found +; .+2: Found +; A (a/v): Element +; B (a/v): List +memq: movei x,(b) + jumpe x,cpopj +memq1: hlrz t,(x) + cain t,(a) + jrst popj1 + hrrz x,(x) + jumpn x,memq1 + return + +; CALL LENGTH: Length of a list +; B (a/v): List +; T (val): Length +length: movei x,(b) + setzi t, + jumpe x,cpopj +lngth1: hrrz x,(x) + aoj t, + jumpn x,lngth1 + return + +intsv0==:t ; Save T +intsv9==:z ; Through Z +intsvn==:intsv9+1-intsv0 + +intctl==:400000+intsv0_6+intsvn ; control bits +intpc==:-<3+intsvn> ; INTPC(P) is PC before interrupt. +intdf1==:intpc-2 ; INTDF1(P) is .DF1 before interrupt. +intdf2==:intpc-1 ; INTDF2(P) is .DF2 before interrupt. +intrq1==:intpc-4 ; INTRQ1(P) are first word bits. +intrq2==:intpc-3 ; INTRQ2(P) are second word bits. +intac0==:intpc+1-intsv0 ; INTAC0+C(P) is C before interrupt. + +tsint: +loc 42 + -ltsint,,tsint +loc tsint + intctl,,p + %piioc ? 0 ? -1 ? -1 ? iocint +ltsint==:.-tsint + +dismis: setz ? sixbit /DISMIS/ ? movsi intctl ? setz p + +; IOC interrupt of .CALL with error return argument just fails to skip and +; returns with IOC error number as error code. +iocint: hrrz x,intpc(p) + .suset [.rbchn,,y] + syscall status,[movei (y) ? movem z] + slose + tlnn z,-100 ; Better not look like standard error + .lose + move y,(x) + tlc y,(.call) + movsi t,(setz) + tlnn y,-1 ; Better be .CALL [ SETZ ? ... ] + came t,(y) + jrst losint +iocnt2: move t,2(y) + tlc t,%clerr + tlne t,(7^9 @(17)) ; Unindexed, direct, error return? + aoja y,iocnt1 ; Nope, keep looking + movei t,(t) + caig t,intsv9 + caige t,intsv0 + caia + addi t,intac0(p) ; Some locations are on the stack now + hlrzm z,(t) + aos intpc(p) + .call dismis + slose + +iocnt1: jumpge t,iocnt2 +losint: ;; Dismis interrupt and do .LOSE at interrupting PC. + move t,intrq1(p) + jffo t,.+2 + caia ; So just .LOSE 0 + addi tt,1 + hrl tt,intpc(p) + syscall dismis,[movsi intctl ? move p ? move intpc(p) + move intdf1(p) ? move intdf2(p) ? move tt] + slose + +cnst0: +constants +repeat <.-cnst0+77>/100, conc cnst,\.rpcnt,=:cnst0+.rpcnt*100 + +versio: $version + +variables + +debug: 0 + +logblk: sixbit /DSK/ + sixbit /LOG/ + sixbit />/ +logdir: sixbit /DIGEST/ + +dfsblk: sixbit /DSK/ + sixbit /DEFS/ + sixbit />/ +dfsdir: sixbit /DIGEST/ + +maiblk: sixbit /DSK/ + sixbit /MAIL/ + sixbit />/ +maidir: sixbit /.BULK./ + +digblk: sixbit /DSK/ + 0 + sixbit /INBOX/ +digdir: sixbit /COMAIL/ + +patch:: +pat: block 100. +epatch: -1 ; Make memory exist, end of patch area + +pgdefs==:<.+1777>_-12 +npdefs==:20. ; Even .MAIL.;NAMES > isn't this big! +defs=:pgdefs_12 +ldefs==:npdefs_12 + +pgibx==:pgdefs+npdefs +npibx==:10. ; Usually makes a 45000. character digest. +ibx=:pgibx_12 +libx==:npibx_12 + +pgheap==:pgibx+npibx +npheap==:10. +heap=:pgheap_12 +lheap==:npheap_12 + +pgrec==:pgheap+npheap +rec=:pgrec_12 +rcinum=:rec+1 ; Number of next issue +rcdate=:rec+2 ; Date of previous issue (or 0 if unknown) +nprec==:2 ; Lots of room for expansion +lrec==:nprec_12 + +pgfree==:pgrec+nprec + +ifg pgfree-400, .err Memory bloat! + +end go