HDTenEightyP/NetNews huggingface dataset:
From: olin@vger.cheme.cornell.edu (Steve Thompson)
Subject: Mixed cluster anyone?
Reply-To: olin@vger.cheme.cornell.edu
Organization: Chemical Engineering, Cornell University, NY
Date: Thu, 24 Dec 1992 12:55:13 GMT

I received my first DEC 3000/400 AXP workstation a couple of days ago (only
9 days from receipt of order; well done guys!). I would like to ask those
of you running a mixed cluster (I know there are some of you out there)
how you did it. Simply setting the same cluster group number and password
on VAX and AXP systems appears not to be sufficient; a cluster does not
form. I know that it's not supposed to work, but it would be really
convenient for me if I could get it to work. I have been told by DEC
(unofficially, of course) that it should work just fine. Thanks.

Steve

---------------------------------------------------------------------------
Steve Thompson, System Mangler   Internet: thompson@cheme.cornell.edu
School of Chemical Engineering   Bitnet:   thompson@crnlchme
Olin Hall, Cornell University    Phone:    (607) 255 5573
Ithaca NY 14853
---------------------------------------------------------------------------
Newsgroups: vmsnet.alpha
From: chamber@mailhost.aa.cad.slb.com (Craig Chamberlain)
Subject: C include files can change member_alignment
Organization: Schlumberger CAD/CAM at Ann Arbor, MI
Date: Mon, 21 Dec 1992 16:22:22 GMT

I discovered at least one C include file, stat.h, which changes the C
compiler's alignment mode to nomember_alignment.  The default is
member_alignment, which generates better code.  If you have two source
files which include the same struct declaration, but one source file
also includes <stat.h>, the structures may not be compatible in terms
of memory layout between the two files.  In stat.h it looks like there
is some attempt to save the member_alignment, but it doesn't get
restored.

$ type inc_stat.c
#include <stat.h>
$ cc/preprocess_only inc_stat.c
$ type inc_stat.i
# 1 "DISK1:[PASCAL.TEST]INC_STAT.C;1"
# 1 "SYS$COMMON:[SYSLIB]DECC$RTLDEF.TLB;1"
#pragma nostandard
#pragma member_alignment __save
#pragma nomember_alignment
typedef unsigned off_t;
typedef unsigned short ino_t;
typedef char *dev_t;
struct stat
{
 dev_t st_dev;
 ino_t st_ino[3];
 unsigned short st_mode;
 int st_nlink;
 unsigned st_uid;
 unsigned short st_gid;
 dev_t st_rdev;
 off_t st_size;
 unsigned st_atime;
 unsigned st_mtime;
 unsigned st_ctime;
 char st_fab_rfm;
 char st_fab_rat;
 char st_fab_fsz;
 unsigned st_fab_mrs;
};
typedef struct stat stat_t;
int stat(char *__file_spec, stat_t *__buffer);
int fstat(int __file_desc, stat_t *__buffer);
unsigned short umask(unsigned short __old_mask);
#pragma standard
-- 
(My opinions do not necessarily represent those of my employer.)
Craig Chamberlain, Software Engineer, Applicon Schlumberger
Ann Arbor, Michigan  chamber@ann-arbor.applicon.slb.com  (313) 995-6310
Newsgroups: vmsnet.alpha
From: chamber@mailhost.aa.cad.slb.com (Craig Chamberlain)
Subject: problems with SIGFPE signal handling
Organization: Schlumberger CAD/CAM at Ann Arbor, MI
Date: Mon, 21 Dec 1992 21:57:37 GMT

If anybody can explain some problems I'm having with integer and
floating point signal handling on the Alpha, I would really appreciate
it.


 1. I can't get integer division by zero handling to work at all
    on the Alpha.

    integer division by zero results
    DECstation: sig is 5 (SIGTRAP), code is 7
           VAX: sig is 8 (SIGFPE), code is 2 (FPE_INTDIV_TRAP)
         Alpha: the signal isn't handled, and the program fatals with
                SYSTEM-F-INTDIV, arithmetic trap, integer divide by zero


 2. Floating point division by zero is signaled as an overflow trap.

    floating division by zero results
    DECstation: sig is 8 (SIGFPE), code is 0 (unknown)
           VAX: sig is 8 (SIGFPE), code is 9 (FPE_FLTDIV_FAULT)
         Alpha: sig is 8 (SIGFPE), code is 3 (FPE_FLTOVF_TRAP)


 3. Floating point overflow is signaled as an underflow trap.

    floating overflow results
    DECstation: sig is 8 (SIGFPE), code is 0 (unknown)
           VAX: sig is 8 (SIGFPE), code is 8 (FPE_FLTOVF_FAULT)
         Alpha: sig is 8 (SIGFPE), code is 5 (FPE_FLTUND_TRAP)


I am using signal.h and the signal function, /standard=vaxc, and
/float=ieee_float (floating point mode doesn't seem to make any
difference).
-- 
(My opinions do not necessarily represent those of my employer.)
Craig Chamberlain, Software Engineer, Applicon Schlumberger
Ann Arbor, Michigan  chamber@ann-arbor.applicon.slb.com  (313) 995-6310
Newsgroups: vmsnet.alpha
From: chamber@mailhost.aa.cad.slb.com (Craig Chamberlain)
Subject: SIGINT handles only once
Organization: Schlumberger CAD/CAM at Ann Arbor, MI
Date: Tue, 22 Dec 1992 16:31:59 GMT

Here's another signal handling problem I've discovered.
SIGINT, which is for CTRL-C, seems to want to be handled
only once, even though it is reset with a new call to signal()
each occurrence.  On the VAX my test program runs fine.
CTRL-C must be hit on the main console three times.  On the
Alpha, the first CTRL-C is handled, the second one isn't,
and the third one quietly terminates the program.

If anyone else has encountered these problems or can even duplicate
them, it would be very helpful to me to know that.  Email replies
appreciated.  (Are other people also experiencing the problems I've
been posting about or am I making a fool of myself with these posts?)


VAX:

$ cc test_sigint.c
$ link test_sigint
$ r test_sigint
ready for 1st test
 Cancel

signal handled: sig 2 code -2
SIGINT
ready for 2nd test
 Cancel

signal handled: sig 2 code -2
SIGINT
ready for 3rd test
 Cancel

signal handled: sig 2 code -2
SIGINT
finished


ALPHA:

$ cc/standard=vaxc/float=ieee_float test_sigint.c
$ link test_sigint
$ r test_sigint
ready for 1st test
 Cancel

signal handled: sig 2 code -2
SIGINT
ready for 2nd test
 Cancel

 Cancel


Here is the code:

/* test_sigint.c */

#include <stdio.h>
#include <string.h>
#include <signal.h>
#include <setjmp.h>

#ifndef sigmask
#define sigmask(x) (1 << ((x)-1))
#endif


static void (*save_sigint)();

static jmp_buf env;


static void
e__except()

{


  longjmp(env, 1);

}


static void
e__hdwerr (sig, code, scp)
int sig;
int code;
struct sigcontext* scp;

{

  
  /* re-enable the signal that just occurred */
  sigsetmask (sigblock (0) & ~sigmask(sig));
  
  if ((int) signal (SIGINT, (void (*)(int)) e__hdwerr) == -1)
    printf("error - signal(SIGINT, ...) re-init failed\n");
  
  printf("signal handled: sig %d code %d\n", sig, code);
  if (sig == SIGINT)
    printf("SIGINT\n");
  
  e__except();
  
  printf("error - execution should not have reached here\n");
  
} /* e__hdwerr */


void
initialize()

{


  save_sigint = signal (SIGINT, (void (*)(int)) e__hdwerr);
  if ((int) save_sigint == -1)
    printf("signal(SIGINT, ...) failed");
		
}


int true = 1;


int
main (argc, argv)
int argc;
char *argv [];

{


  initialize();

  if (setjmp(env) == 0) {
    printf("ready for 1st test\n");
    while (true)
      ;
  }
  else {
    if (setjmp(env) == 0) {
      printf("ready for 2nd test\n");
      while (true)
	;
    }
    else {
      if (setjmp(env) == 0) {
	printf("ready for 3rd test\n");
	while (true)
	  ;
      }
      else
	printf("finished\n");
    }
  }
  
} /* main */
-- 
(My opinions do not necessarily represent those of my employer.)
Craig Chamberlain, Software Engineer, Applicon Schlumberger
Ann Arbor, Michigan  chamber@ann-arbor.applicon.slb.com  (313) 995-6310
From: beg@yocto.kuee.kyoto-u.ac.jp (Mirza Muhammad Ajmal Beg (ogura))
Newsgroups: vmsnet.alpha
Subject: test
Date: 25 Dec 92 03:06:23 GMT
Distribution: vmsnet.alpha
Organization: Dept. Electronics, Kyoto Univ., Kyoto, Japan

test
--













































_______________________________________________________________________________

             AJMAL BEG
             OGURA LAB,
             ELECTRONICS,                             
             KYOTO UNIVERSITY,JAPAN
______________________________________________________________________________
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.alpha
Subject: Re: SIGINT handles only once
Date: 23 Dec 92 16:02:32 GMT
Distribution: world
Organization: Mitech Corporation, Concord MA

In article <22DEC199220451474@eql.caltech.edu>, rankin@eql.caltech.edu (Pat Rankin) writes:
>      You call printf() and then longjmp() out of a signal handler and end
> up surprised that there are problems?

If he wants to continue to kludge I can assure that the following code 
(from SIOD) "works" on Alpha. Possibly it may work because of the 
interposed stack frames, but I am also careful to never allow an err_ctrl_c() 
call while already inside other calls to the VAXCRTL, 
hence the nointerrupt flag. (If you cannot be good, at least be careful).

Note that when this code is run on the Macintosh I am forced to use
the polling technique anyway, because of a lack of interrupt capability.

void handle_sigint(int sig SIG_restargs)
{signal(SIGINT,handle_sigint);
 if (nointerrupt == 1) interrupt_differed = 1;
 else err_ctrl_c();}

void err_ctrl_c(void)
{err("control-c interrupt");}

void err(char *message)
{nointerrupt = 1;
 printf("ERROR: %s\n",message);
 longjmp(errjmp,1);}
From: gjc@mitech.com (George J. Carrette)
Newsgroups: vmsnet.alpha
Subject: speed of SYS$READEF
Date: 22 Dec 92 15:42:44 GMT
Organization: Mitech Corporation, Concord MA

Since I am now running enough of my code to be curious about
speed, a question is how much speed-up an Alpha can be expected to
provide on realtime programs. The program READEF tests one
of the basics, SYS$READEF, by calling it N times in a loop.
Thus:

   $ write sys$output f$getsyi("HW_NAME")
   DEC 3000 Model 500
   $ readef 1000000
    ELAPSED:    0 00:00:02.60  CPU: 0:00:02.60  BUFIO: 0  DIRIO: 0  FAULTS: 0

   $ write sys$output f$getsyi("HW_NAME")
   VAXstation 4000-90
   $ readef 1000000
    ELAPSED:    0 00:00:03.65  CPU: 0:00:03.49  BUFIO: 0  DIRIO: 0  FAULTS: 2

Does anybody else think that SYS$READEF could use some tuning here?

#include <stdio.h>
#include <stdlib.h>
#include <lib$routines.h>
#include <starlet.h>

/* time a bunch of calls to sys$readef */

main(int argc, char **argv)
{long j,n,mask,status;
 n = (argc > 1) ? atol(argv[1]) : 100000;
 status = lib$init_timer(0);
 if (!(status & 1)) lib$signal(status);
 for(j=0;j<n;++j)
   {status = sys$readef(0,&mask);
    if (!(status & 1)) lib$signal(status);}
 status = lib$show_timer(0);
  if (!(status & 1)) lib$signal(status);}
From: jeh@cmkrnl.com
Newsgroups: vmsnet.uucp
Subject: Re: system abort error
Date: 1 Jan 93 18:37:30 PST
Organization: Kernel Mode Consulting, San Diego, CA

In article <1993Jan1.114856.883@whscdp.whs.edu>, kmoch@whscdp.whs.edu writes:
> I'm running DECUS UUCP V2.0 with ANU-NEWS 6.1 and I've been getting an error
> rather consistently [...]
> p:uucp >> h:spool   [01/01-11:37:41-0000024d] * Wr qio cmpl err 
> (%SYSTEM-F-ABORT, abort) u:root    

This is a result of overly-zealous error checking in the terminal I/O code.
You can ignore this error.  Fixed in V2.1 (not yet distributed).  

> do I need to provide some other info?

Normally, yes, debug output would be helpful, but it isn't necessary in this
case. 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows-NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
Newsgroups: vmsnet.uucp
Subject: Re: Something is stripping blanks...
From: Ned Freed <ned@innosoft.com>
Date: 25 Dec 1992 01:33:05 -0700 (PDT)
Reply-To: synful+vmsnet@DRYCAS.CLUB.CC.CMU.EDU
Organization: The Internet
Return-Path: <synful+vmsnet-errors@DRYCAS.CLUB.CC.CMU.EDU>
Errors-To: synful+vmsnet-errors@DRYCAS.CLUB.CC.CMU.EDU
X-Vms-To: IN%"synful+vmsnet%DRYCAS.BITNET@ymir.claremont.edu"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mime-Version: 1.0

Certainly PMDF strips blanks in several contexts...  PMDF acts as a BITNET
gateway and thus loss of trailing blanks is sometimes inevitable.

The UUCP channel in particular strips trailing blanks in headers and between
the header and body. Both of these actions are directly related to common
code that's shared with the BITNET interface.

I seem to recall taking out some additional superfluous blank stripping
code in the UUCP channel some time ago. I don't recall the details, however.
These channels have been extensively revised in each of the last few
releases.

Finally, your comments about UUENCODE simply reinforce the fact that its
a poor choice of encoding. Using ` instead of spaces fixes some of the
trailing space problems but then promptly proceeds to break several other
implementations of UUENCODE. UUENCODE will never be a universal winner
because it was never precisely specified and now there are simply too
many semi-interoperable implementations.

                                Ned
Newsgroups: vmsnet.uucp
From: don@rata.vuw.ac.nz (Don Stokes)
Subject: Re: system abort error
Organization: Victoria University of Wellington CSC
Date: Sun, 3 Jan 1993 05:02:58 GMT

jeh@cmkrnl.com writes:
> don@rata.vuw.ac.nz (Don Stokes) writes:
> > .... which is the result of outstanding $QIOs being $CANCELled when
> > the protocol is torn down; there were some circumstances before this was
> > done where UUCICO could hang if carrier was unexpectedly lost.  The 
> > SS$_ABORT tels you it's not suffering that bug.  8-)
> 
> Exactly!  

Yeah, I was "supporting" a site that had a particularly flakey connection
and could reproduce this problem pretty much at will (ie by waiting a day 
or two for it to happen -- I'd seen it happen elsewhere once in a blue moon).

What I _think_ was happening was that the modem was dropping CTS when it
hung up, and the terminal driver was duly holding up traffic; uucico would
correctly detect the loss of carrier, but didn't take any action (it still
doesn't -- just reports the fact), continuing to Q IOs.  It would eventually
time out, but for some reason would hang, presumably when it tried to do a
syncronous I/O (SETMODE!HANGUP QIO?) behind the wedged ones.  (I
haven't looked at the code for a while.)  Note that an incoming call to the
modem would raise the necessary signals again, and uucico would go merrily
on its way....

Anyway, blowing all outstanding I/Os out of the water before attempting to
close the connection down has fixed it.  Kudos to Mark (or was it Tom --
bit rot is setting in) for putting max effort into fixing it -- those sorts
of bugs are pigs to track down.
 
> (One wonders just how many centuries of VAX cpu time has been spent checking
> IOSBs over the past 15 years.  Not to mention probing buffers, copying
> buffers, etc.)

Not as many as have been burned throughout the C-speaking world looking for
the ends of nul-terminated strings....  <sigh>  K&R, you botched.  8-(

--
Don Stokes, ZL2TNM (DS555)                      don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre          don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand.           +64-4-495-5052
From: jeh@cmkrnl.com
Newsgroups: vmsnet.uucp
Subject: Re: system abort error
Date: 2 Jan 93 16:02:13 PST
Organization: Kernel Mode Consulting, San Diego, CA

In article <C08nxx.9LB@comp.vuw.ac.nz>, don@rata.vuw.ac.nz (Don Stokes) writes:
> jeh@cmkrnl.com writes:
>> In article <1993Jan1.114856.883@whscdp.whs.edu>, kmoch@whscdp.whs.edu writes:
>> > p:uucp >> h:spool   [01/01-11:37:41-0000024d] * Wr qio cmpl err 
>> > (%SYSTEM-F-ABORT, abort) u:root    
>> 
>> This is a result of overly-zealous error checking in the terminal I/O code.
>> You can ignore this error.  Fixed in V2.1 (not yet distributed).  
> 
> .... which is the result of outstanding $QIOs being $CANCELled when
> the protocol is torn down; there were some circumstances before this was
> done where UUCICO could hang if carrier was unexpectedly lost.  The 
> SS$_ABORT tels you it's not suffering that bug.  8-)
> 
> --
> Don Stokes, ZL2TNM (DS555)                      don@zl2tnm.gen.nz (home)
> Network Manager, Computing Services Centre          don@vuw.ac.nz (work)
> Victoria University of Wellington, New Zealand.           +64-4-495-5052

Exactly!  

(Of course, a future "enhancement" by Digital to the terminal driver may
resurrect the bug, or a similar one.  It's happened to us before.  In fact,
if I remember correctly, I tried something that looks very much like the 
current "end of call" code under VMS 4.7, and it would sometimes get wedged...)

You will also sometimes see SS$_ILLIOFUNC, illegal I/O function, for a similar
reason.  

(One wonders just how many centuries of VAX cpu time has been spent checking
IOSBs over the past 15 years.  Not to mention probing buffers, copying buffers,
etc.)

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
drivers, internals, networks, applications, and training for VMS and Windows-NT
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: jeh@cmkrnl.com
Newsgroups: vmsnet.uucp
Subject: Re: Changing polling times
Date: 29 Dec 92 17:58:16 PST
Organization: Kernel Mode Consulting, San Diego, CA

In article <1992Dec29.170210.414@hsh.com>, lee@hsh.com (Lee Havemann) writes:
> Now that we have a private (leased) line installed between us and our feed, I
> would like to change some of the timing features in UUCP.   When we send
> mail, reply or followup on an article, I would like the files to go out
> immediately. 
> 
> I changed the times in the systems. file to Any,1,1,15, and that seems to 
> allow for immediate mail delivery (as mentioned in the manual :-),
> but is it set correctly to poll our feed every 15 minutes for news/mail? 

yes -- assuming that your sleeptime is no larger than 15 minutes.

> I guess I have to shorten the sleeptime if I want the news to get out faster 
> also. Is this assumption correct?

yes, but you also need to do something else:  You need to change NEWSSKIM to
run more often.  

When someone on your machine 
writes a news article, it gets put in a temporary file in news_manager_dev:[*].
(If it's to be fed to multiple sites, multiple files are created, one in each
directory under news_manager_dev:)  NEWSSKIM periodically runs and picks these
up and turns them into compressed files in uucp_spool, together with the 
"work file" (C file) which will cause uucp to transmit them.  

As shipped, NEWSSKIM runs once per hour.  If you make it run more often you'll
also need to make some changes in its log file naming code.

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and 
Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
Newsgroups: vmsnet.uucp
Subject: Re: Mail Rewrite Rules Problem - V2.0
From: allebrandi@inland.com (Tom Allebrandi)
Date: 22 Dec 92 01:09:35 CST
Organization: Inland Steel Company; East Chicago, IN

In article <009651E43BA598A0.25C03787@Pasadena-DC.BofA.Com>, Dean Nedelman <nedelman@pasadena-dc.bofa.com> writes:
>>	U uucp sfpp
>>	F D.sfpp03L
>>	I D.sfpp03L
>>	C rmail graue
>                 ^^^^^^ This is the text string that is passed to the mail
> rewrite rules.  Note that is says graue, NOT graue@sfpp.com.  This is why
> it is not matching the rewrite rules.
> 

An additional point of clarification - The X file was created by the
host that sent it to you. In your case, PSI has recognized that in
many parts of the world "graue@sfpp.com" would be user "graue" on
your gateway machine. They never sent you the "sfpp.com" part of
the address for that reason. You night be able to ask them to.

> Add the following line to the end of the INBOUND-TO section
> 
> 	*			spvx01::\001

That's probably the easiest solution. Make sure that that line is the
last [INBOUND-TO] rule in the file. (Since it matches all patterns
it would strand any [INBOUND-TO] rules that follow it.)

Another approach which is somewhat labor intensive is to set forwarding
entires for the affected users. From a privileged account go into VMS
Mail and do

	set forward/user=graue spvx01::graue

You can do this regardless of whether or not graue has an account on the
local machine. You would have to do this for every user that needs
their mail forwarded from the gateway machine. It might be easier to
forward everything via the rewrite rules and send the exceptions back via
VMS Mail forward entries :-)

Tip of the day: VMS Mail forwarding entries can be 31 characters long.
For example, I could do

	set forward/user=ThomasMAllebrandi Allebrandi

to give a "full name" alias for myself.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | NFS grunt   - CMU/Tek-IP
East Chicago, IN           | Chairperson - VMSnet Working Group, DECUS VAX SIG
219 399 6306               | Internet:  allebrandi@inland.com
DECUServe: allebrandi      | UUCP:      ...!uunet!inland!allebrandi
Newsgroups: vmsnet.uucp
Subject: Re: Something is stripping blanks...
From: Ned Freed <ned@innosoft.com>
Date: 24 Dec 1992 12:58:22 -0700 (PDT)
Reply-To: synful+vmsnet@DRYCAS.CLUB.CC.CMU.EDU
Organization: The Internet
Return-Path: <synful+vmsnet-errors@DRYCAS.CLUB.CC.CMU.EDU>
Errors-To: synful+vmsnet-errors@DRYCAS.CLUB.CC.CMU.EDU
X-Vms-To: IN%"synful+vmsnet%DRYCAS.BITNET@ymir.claremont.edu"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mime-Version: 1.0

Welcome to the reality of modern mailers! Blank stripping is extremely
common, widespread, and actually unavoidable in many contexts. In particular,
mailers that have been extended to deal with BITNET messages have to learn to
both strip extraneous blanks that are added as well as to expect trailing
blanks to disappear.

This behavior is not legal within the strict confines of Internet messaging.
However, most of the cases where stripping happens are outside the realm
where Internet standards can be strictly applied.

So, your answers are: (1) Your experiment isn't bogus, but it only served to
illustrate common behavior, (2) MX probably does strip blanks since it has
to deal with BITNET, (3) Stripping blanks is neither legal nor illegal, and
(4) Blank stripping should not be done unless absolutely necessary, but it
is often necessary.

Blank stripping affects several encoding formats badly (some UUENCODEs
in particular) so it is important that if you elect to encode messages to
eliminate blanks stripping you do so in a way where the cure isn't worse
than the disease. Both of the approved MIME encodings for messages were
designed with full knowledge of this and are therefore immune to blank
addition or stripping. Needless to say, they both protect their contents
as any encoding should.

                                Ned