HDTenEightyP/NetNews huggingface dataset:
From: allebrandi@inland.com (Tom Allebrandi)
Newsgroups: vmsnet.uucp
Subject: Re: UUCP and AT&T Mailers (Query)
Date: 9 Apr 92 15:16:10 GMT
Distribution: na
Organization: Inland Steel Company; East Chicago, IN

In article <1992Apr8.144639.549@sjh.org>, vaughan@sjh.org writes:
>I can't _delete_ protect the spool
> directory until maybe at night and trap the headers as they arrived.

When I need to trap inbound messages for testing, I go into
UUXQT_DCL.COM (in UUCP_BIN:) and change the command that deletes the D
file to a rename. (Remember to stop the UUXQT process so that the new
procedure is used.)


> Here is a sample of how they look: (an old one but the behavior is the same)
> From:	UUCP%"mailroom" 16-JUL-1990 10:39:21.25
> To:	sjhvax!vaughan
> CC:	
> Subj:	
> 
> Received: from h02924 by sjhvax.UUCP (DECUS UUCP w/Smail);
>           Mon, 16 Jul 90 10:39:17 EDT
> Message-Version: 2
>>To: sjhvax!vaughan 
> From: mailroom
> Date: Mon Jul 16 10:32:20 EDT 1990
> UA-Content-ID: <PMX-TERM-2.01-500270-h02924-mailroom-5>
> End-of-Header: 
> Email-Version: 2
> UA-Message-ID: <PMX-TERM-2.01-h02924-mailroom-2>
> To: sjhvax!vaughan
> End-of-Protocol: 
> Content-Type: multipart
> Content-Length: 57482  
> 

Not to seem dense, but what is the problem here? It looks ok to me.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | Chairperson - VMSnet Working Group, DECUS VAX SIG
East Chicago, IN           | Internet:  allebrandi@inland.com
219 399 6306               | UUCP:      ...!uunet!inland!allebrandi
                           | DECUServe: allebrandi
Newsgroups: vmsnet.uucp
Subject: Re: UUCP_MAILSHR files
From: allebrandi@inland.com (Tom Allebrandi)
Date: 7 Apr 92 15:54:50 CST
Organization: Inland Steel Company; East Chicago, IN

In article <1992Mar30.065114.17724@rata.vuw.ac.nz>, don@rata.vuw.ac.nz (Don Stokes) writes:
> I'm curious.  If I hack around with a file in UUCP_SPOOL that is destined
> to be fed into UUCP_MAILSHR, UUCP_MAILSHR gets upset, and claims that some-
> thing is missing from the command line.  It turns out, after much head
> scratching and experimentation, that uucp's own files are created with a
> maximum record size of 65535, and any other MRS causes the error.

You are probably getting 

	%UUCP-F-NORECIP, Required recipient parameter on command line missing

this message is a known red herring and usually means that something
else is wrong. Neat huh? :-)

Actually, I think that this occurs when the inbound initialization code
fails. The foreign protocol interface is designed around a
client/server model where the inbound side is supposed to act like a
server. When something  goes wrong, Mail calls the transports error
handler so that the error may be reported back to the client. If the
initialization routine dies, I think Mail calls it again in the hopes
of getting a clean context to report the error message on.

The problem is that the UUCP Mail Handler inbound initialization
routine performs a CLI$get_value() loop to read all of the target
addresses. When the inbound init routine is re-entered, it attempts to
execute the  CLI$get_value() loop again but the parameters have been
consumed. This makes the re-entered init routine think that that
command line was empty hence the message.


If you are running a 1.3 version of the Mail Handler, turn on the Crash
Dump Facility as described on page 1-5 of the System Manager's Guide. That
should lead you to the true error.


> Most languages don't support 65535 byte MRSs -- in the code I was playing
> with I introduced a USEROPEN to tweak the MRS as the file was being 
> written out.  (Ok, so I'm using UUCP_MAILSHR for things it was never 
> intended to do.....)
> 
> Is this behaviour a bug or a feature?

The inbound phase, which it sounds like you are having trouble with,
accepts any VMS text format file. I'm not sure that it properly handles
stream format but I know that it does not require "variable with carriage
return max record size 65535."

Tell me more about what you are trying to do.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | Chairperson - VMSnet Working Group, DECUS VAX SIG
East Chicago, IN           | Internet:  allebrandi@inland.com
219 399 6306               | UUCP:      ...!uunet!inland!allebrandi
                           | DECUServe: allebrandi
From: mark@infocomm.com
Newsgroups: vmsnet.uucp
Subject: Re: suggested minor fix to SYSDEP.C
Date: 7 Apr 92 10:34:29 PST
Organization: INFO COMM - Computer Consulting, Redwood City, Ca

In article <1027@mitech.com>, gjc@mitech.com (George J. Carrette) writes:
> Here is a suggested small improvement to SYSDEP.C, which may have already
> been done (I haven't seen the latest sources).
> 
> There are a couple calls to the VAXCRTL sleep function. It has been my
> observation that under certain conditions (related to use of HIBER, AST's,
> event flags, whatever) a sleep(6) can turn into something that never
> wakes up. Maybe it is a bug that is only in my old VAXCRTL (VMS 4.7).
> 
> The bug manifested itself for me when sometimes when carrier is
> lost during a file transfer a "Dropping DTR" turns into an indefinite sleep.
> 
> Anyway, I think that changing sleep(6) into msleep(6000) is a good idea
> in any case, following what seems to be the general suggestion from DIGITAL
> support people, to avoid the VAXCRTL whenever possible. 

You wouldn't happen to be running over LAT connected terminals, and/or have
VT's enabled. . .

I recently fixed such a problem ("Dropping DTR" takes forever) which turned out
to be some screwy timing with LAT AND/OR VT's interaction where the QIO (issued
with a timeout) to flush the tty input bufferline, never got started, so the
driver's timeout never started ticking.  This was fixed by implementing a 
timer mechanism (just as msleep does) around the call to do the flush.

Note, the routine that flushes the tty input was called directly from the
routine that issues the hangup.  The call to sleep in the hangup routine
remains since it was NOT the culprit.

--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE:	(415)369-9366	UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN:	mark@infocomm.com
Newsgroups: vmsnet.uucp
Subject: Re: UUCP and AT&T Mailers (Query)
From: allebrandi@inland.com (Tom Allebrandi)
Date: 7 Apr 92 16:15:27 CST
Distribution: na
Organization: Inland Steel Company; East Chicago, IN

In article <1992Mar31.231026.534@sjh.org>, vaughan@sjh.org writes:
> -- 
>   Has anyone gotten satisfactory comunications between Decus UUCP and
> AT&T's nonsense PMX Mail or ATTMail?  I can do it, but their headers seem
> to confuse both Decus UUCP and PMDF 4.0.  I end up without a host in the
> return address from a neighboring host, but all is well if it is more than
> one hop away.
> 

A couple of years ago, there was a rumor that AT&T was about to release
a version of UUCP Mail that violated the "no blank lines before the
headers" rule. I never heard anymore about it so I never bothered to do
anything about it.

Note that some [my opinion] misconfigured versions of MMDF generate
blank lines before the headers....

Could this be the problem?

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | Chairperson - VMSnet Working Group, DECUS VAX SIG
East Chicago, IN           | Internet:  allebrandi@inland.com
219 399 6306               | UUCP:      ...!uunet!inland!allebrandi
                           | DECUServe: allebrandi
Newsgroups: vmsnet.uucp
Subject: Re: Problem with new uucico.
From: jeh@cmkrnl.com
Date: 5 Apr 92 22:18:05 PDT
Organization: Kernel Mode Consulting, San Diego CA

In article <00957C26.B49123E0.14574@infores.wha.ma.us>, Jim Carey <jcarey@infores.wha.ma.us> writes:
> I tried the new uucico, with less than wonderful results (trimmed to fit):
> 
> p:uucp [03/17-13:39:38]   Calling        (poller) u:-       
> p:uucp [03/17-13:39:54]   Script log     (Hayes dialed ok) u:-       
> p:uucp [03/17-13:39:59]   Script log     (Unix login ok) u:-       
> p:uucp [03/17-13:40:03]   Startup ok     (g, xmt w=3, b=64) u:-       
> p:uucp [03/17-13:40:15]   Rqst mbx msg   (uupoll baron) u:-       
> p:uucp [03/17-13:41:06] * Other end not sndg (getdata tmo awtg rcvd data) u:-
> p:uucp [03/17-13:41:06] * Error rcvg fr link (see prev msg) u:-       
> p:uucp [03/17-13:41:06] * End of call    (failed : 88 secs) u:-       
> p:uucp [03/17-13:41:07]   Dropping DTR   () u:-       
> 
> When I switch back to the old one, things work fine.  I'm working on
> finding out what kind of system I'm talking to, but what debug
> switches should I turn on to gather useful data to track this down?

Sorry for the delay in answering -- I've been really busy.  (Good for my
consulting business, not so good for uucp development!)

Try setting debug to 03607, and mail me the results.  

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
uucp 'g' protool guru, VMSnet (DECUS uucp) Working Group, and
Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,eisner,uunet}!cmkrnl!jeh
From: ake@dayton.saic.com (Earle Ake)
Newsgroups: vmsnet.uucp
Subject: Re: Getting across DECnet from uucp
Date: 12 Apr 92 10:35:39 EDT
Organization: Science Applications Intl. Corp., Dayton, Ohio

In article <2791.29e5c92b@abel.incstar.com>, lhotka@abel.incstar.com writes:
> I know, I know, you should never post in anger or frustration, but REALLY!!
> 
> For the past hour and a half I have been trying to get uucp to let me mail
> across decnet by putting a wide variety of rewrite rules in the rewrite rules
> file.  All to absolutely no avail...
> 
> I have a MVII running DECUS uucp - ABEL.
> 
> I have a 6410 connected by decnet - ADAM.
> 
> I try sending mail to uucp%"user@adam.incstar.com" and it is an invalid
> Internet or uucp address - makes sense.
> 
> In the OUTBOUND-TO section I add a rule
> 
> 	*@adam.incstar.com	adam::\001
> 
> This seems logical to me somehow, but gets me nowhere fast.  I assume I am
> missing something really simple and easy here...  I have tried rules in other
> areas and other forms, but nothing seems to matter.
> 
> We run MX as well - hence I never actually ran into this until I tried to
> forward a message from ANU News which doesn't use MX to send mail apparently
> and find that the uucp% mail system just doesn't appreciate my decnet
> machine...

	Set up ANU News to use MX!  Look in your news_manager:news_address.cnf
file and see what is says.  You should route all message bound for *@*.uucp to
UUCP and others to MX.  Actually you may have a rewrite there that is messing
you up.

	If you want, send me your news_address.cnf file and I can try to help.


Earle
_____________________________________________________________________________
             ____ ____    ___
Earle Ake   /___ /___/ / /     Science Applications International Corporation
           ____//   / / /__                 Dayton, Ohio
-----------------------------------------------------------------------------
Internet: ake@dayton.saic.com        uucp: dayvb!ake         SPAN: 28284::ake
From: vaughan@sjh.org
Newsgroups: vmsnet.uucp
Subject: Re: New uucico works here
Date: 10 Apr 92 15:58:20 GMT
Distribution: na
Organization: St. Joseph Hospital, Cheektowaga NY

In article <1992Apr9.203829.1462@debisa>, n6vbg@debisa (Javier Henderson) writes:
> In lieu of all the problems people seem to be having with the new uucico,
> I'd like to mention that I've been using it without any problems ever since
> Jamie posted it.
> 
> Here are the particulars...
> 
> VAX 2000
> VMS 5.4-1
> UUCP 1.2b
> TYPAHDSZ 1024
> ALTYPAHDSZ 2048
> w7b512
> 
-- 
But ..but, I thought you should have enough to handle an entire window.

7 x 512 = 3584 (+ packet overhead bytes)

1024 + 2048 = 3072

  A difference > 512 bytes.  

Why does this work?  Is uucp just processing the window faster than it
can fill?

Just wondering, nothing else makes sense in our shop lately why should this? :)

Tom

-- 
Internet: vaughan@sjh.ORG
UUCP    : ..!{ames!canisius,doh1c,sigmast,ub}!sjhvax!vaughan
SMSNET  : 40961::vaughan                
Where   : Tom Vaughan / Mgr. Comp. Ops./ St. Joseph Hospital /Cheektowaga N.Y.
--
From: vaughan@sjh.org
Newsgroups: vmsnet.uucp
Subject: Re: UUCP and AT&T Mailers (Query)
Date: 11 Apr 92 19:33:47 GMT
Distribution: na
Organization: St. Joseph Hospital, Cheektowaga NY

In article <1992Apr9.091610.1920@inland.com>, allebrandi@inland.com (Tom Allebrandi) writes:
> 
> When I need to trap inbound messages for testing, I go into
> UUXQT_DCL.COM (in UUCP_BIN:) and change the command that deletes the D
> file to a rename. (Remember to stop the UUXQT process so that the new
> procedure is used.)
Will give it a go.

>> Here is a sample of how they look: (an old one but the behavior is the same)
>> From: UUCP%"mailroom" 16-JUL-1990 10:39:21.25
>> To:	sjhvax!vaughan
>> CC:	
>> Subj:	
>> 
>> Received: from h02924 by sjhvax.UUCP (DECUS UUCP w/Smail);
>>           Mon, 16 Jul 90 10:39:17 EDT
>> Message-Version: 2
>>>To: sjhvax!vaughan 
>> From: mailroom
>> Date: Mon Jul 16 10:32:20 EDT 1990
>> UA-Content-ID: <PMX-TERM-2.01-500270-h02924-mailroom-5>
>> End-of-Header: 
>> Email-Version: 2
>> UA-Message-ID: <PMX-TERM-2.01-h02924-mailroom-2>
>> To: sjhvax!vaughan
>> End-of-Protocol: 
>> Content-Type: multipart
>> Content-Length: 57482  
>> 
> 
> Not to seem dense, but what is the problem here? It looks ok to me.

   From: UUCP%"mailroom" 16-JUL-1990 10:39:21.25
               ^^^^^^^^
         Should be "h02924!mailroom"

   PMDF does the same thing, except that it adds the local channel to the
end, make its return address materially equivilent.  

  Like:

   From: in%"mailroom@sjhvax" 16-JUL-1990 10:39:21.25

 This is nuts, a critical connection needed for the operation of the hospital
and I get this nonsense.  Murphy's law I suppose. :)

 Somehow anything coming from these mailers looses the first host, the only
thing I can think of now is on arrival in my spool directory it looks different.
ie. blank line at top of file introduced by some malady/gremlins?

Thanks,

Tom

-- 
Internet: vaughan@sjh.ORG
UUCP    : ..!{ames!canisius,doh1c,sigmast,ub}!sjhvax!vaughan
SMSNET  : 40961::vaughan                
Where   : Tom Vaughan / Mgr. Comp. Ops./ St. Joseph Hospital /Cheektowaga N.Y.
--
Xref: sparky vmsnet.uucp:372 vmsnet.networks.tcp-ip.wintcp:95
Newsgroups: vmsnet.uucp,vmsnet.networks.tcp-ip.wintcp
Subject: Re: help - forwarding mail from TCP/IP to uucp
From: allebrandi@inland.com (Tom Allebrandi)
Date: 7 Apr 92 16:11:38 CST
Organization: Inland Steel Company; East Chicago, IN

In article <5404.29d326c4@hayes.com>, msieweke@hayes.com writes:
> I'm running VMS 5.3, DECUS uucp 1.2, and WIN/TCP 5.1.  I wish to route
> TCP/IP mail into uucp and have a replyable "From:" address.
> 
> I use the following line in the SMTP.CONF for TCP/IP mail:
> uucp%*                  MA              uucp%"**"
> 
> This allows the unix users to address mail to
>    uucp%uunet!host!user@hayes1
> and have the mail forwarded via uucp (HAYES1 is our VAX running uucp).
> 
> Unfortunately, the "From:" address is "user@<unix-node>" instead of
> "user@hayes.com".  I have tried dozens of permutaions of the
> mail_rewrite.rules file, but it doesn't seem to have any effect.
> Even "*@* \001@hayes.com" doesn't work.  I believe the uucp mailer
> is stripping a "WINS%" from the address and not using the rewrite
> rules for [OUTBOUND-FROM].
> 

Have you tried this:

[OUTBOUND-FROM]
wins%"*@*"	\001@hayes.com

??

The outbound phase recognizes that the message is coming through UUCP
from some other transport. Two things happen:

	1) The message is treated as if it is passing through from UUCP to
	   itself. In other words, new headers are not generated.

	2) The entire from address is passed to the rewriter to give you
	   maximum flexibility in detecting the address so that you can
	   perform any fixups that are required.

--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | Chairperson - VMSnet Working Group, DECUS VAX SIG
East Chicago, IN           | Internet:  allebrandi@inland.com
219 399 6306               | UUCP:      ...!uunet!inland!allebrandi
                           | DECUServe: allebrandi
Newsgroups: vmsnet.uucp
Subject: Re: Including double quotes in UUCP address
From: allebrandi@inland.com (Tom Allebrandi)
Date: 8 Apr 92 11:09:17 CST
Organization: Inland Steel Company; East Chicago, IN

In article <1992Apr7.114320.424@spacm1.spac.spc.com>, sysmgt007@spacm1.spac.spc.com (Dean Nedelman) writes:
> I receive mail from somebody at DEC.  When the mail arrives, the from
> address is: "nodea::nodeb::user"@site.enet.dec.com
> 
> The question is:  How do I reply to that address?  The mail from line
> is: uucp%""nodea::nodeb::user"@site.enet.dec.com"
> 

Ugh. Quoted mailbox names (the stuff left of the "@") is something that
I should handle better.

As our friends at a well known computer company would say: "Noted."

In the meantime, you could try the following hack to your MAIL_REWRITE.RULES:


[INBOUND-FROM]
"*"@*	\001@\002
[OUTBOUND-TO]
*::*@*		"\001::\002"@\003
*::*::*@*	"\001::\002::\003"@\004


The [OUTBOUND-TO]'s are a trick to allow you to give the mailbox name
using the ::'s without needing the quotes. In other words:

	uucp%"nodea::nodeb::user@site.enet.dec.com"

which the UUCP Mail Handler would convert to

	"nodea::nodeb::user"@site.enet.dec.com

when preparing the envelope. The [INBOUND-FROM] simply makes the
inbound address replyable in the presence of the [OUTBOUND-TO].


--- Tom
Tom Allebrandi             | Mail guru   - DECUS UUCP Development Team
Inland Steel Research Labs | Chairperson - VMSnet Working Group, DECUS VAX SIG
East Chicago, IN           | Internet:  allebrandi@inland.com
219 399 6306               | UUCP:      ...!uunet!inland!allebrandi
                           | DECUServe: allebrandi
From: vaughan@sjh.org
Newsgroups: vmsnet.uucp
Subject: Re: UUCP and AT&T Mailers (Query)
Date: 8 Apr 92 20:09:06 GMT
Article-I.D.: sjh.1992Apr8.160907.551
Distribution: na
Organization: St. Joseph Hospital, Cheektowaga NY

In article <1992Apr7.161527.1913@inland.com>, allebrandi@inland.com (Tom Allebrandi) writes:
> A couple of years ago, there was a rumor that AT&T was about to release
> a version of UUCP Mail that violated the "no blank lines before the
> headers" rule. I never heard anymore about it so I never bothered to do
> anything about it.
> 
> Could this be the problem?
-- 
  Tom,

    I checked the spool files on the AT&T, and in the spool directory on the 
vax.  There weren't any blank lines preceding or within the headers.

Tom

-- 
Internet: vaughan@sjh.ORG
UUCP    : ..!{ames!canisius,doh1c,sigmast,ub}!sjhvax!vaughan
SMSNET  : 40961::vaughan                
Where   : Tom Vaughan / Mgr. Comp. Ops./ St. Joseph Hospital /Cheektowaga N.Y.
--
From: sysmgt007@spacm1.spac.spc.com (Dean Nedelman)
Newsgroups: vmsnet.uucp
Subject: Including double quotes in UUCP address
Date: 7 Apr 92 11:43:20 PST
Organization: Security Pacific Automation Co., LA, CA

I receive mail from somebody at DEC.  When the mail arrives, the from
address is: "nodea::nodeb::user"@site.enet.dec.com

The question is:  How do I reply to that address?  The mail from line
is: uucp%""nodea::nodeb::user"@site.enet.dec.com"

This will NOT parse (the trouble being those pesky double quotes).  How do I
address something such that the double quotes remain in the address and still 
not a TPARSE error?

Thanks.

-- 
Dean (The Shadow)
+---------------------------------------------------------------------------+
| Dean I. Nedelman                            sysmgt007@spacm1.spac.spc.com |
| Systems Consultant               sysmgt007%spacm1.uucp@elroy.jpl.nasa.gov |
| Security Pacific Automation Co.       spacm1!sysmgt007@elroy.jpl.nasa.gov |
| 333 South Beaudry Ave.       {...,decwrl,ames,usc}!elroy!spacm1!sysmgt007 |
| Los Angeles, CA  90017                                                    |
|                                                                           |
| Systems programmers are the high priests of a low cult.                   |
+---------------------------------------------------------------------------+
Newsgroups: vmsnet.uucp
Subject: Re: New uucico works here
From: n6vbg@debisa (Javier Henderson)
Date: 11 Apr 92 19:08:32 PST
Distribution: na
Organization: What, me organized???

In article <1992Apr10.115820.555@sjh.org>, vaughan@sjh.org writes:
> -- 
> But ..but, I thought you should have enough to handle an entire window.
> 
> 7 x 512 = 3584 (+ packet overhead bytes)
> 
> 1024 + 2048 = 3072
> 
>   A difference > 512 bytes.  
> 
> Why does this work?  Is uucp just processing the window faster than it
> can fill?

Hm...good point, I hadn't thought of that. I guess the reason for which I
haven't got data overruns is because my neighboors are not using the larger
packets.

However, from Jamie's posting, I gather that the problems were presenting
right after the file transfer gets started.

Off to update modparams.dat and run autogen...

______________________________________________________________________________
Javier Henderson, N6VBG | Beat the 55mph limit...learn to fly!
n6vbg%debisa@mccall.com | 
Newsgroups: vmsnet.misc
From: mcmahon@tgv.com (John 'Fast-Eddie' McMahon)
Subject: Re: DECwindows on an Xterminal
Reply-To: mcmahon@tgv.com
Organization: TGV Incorporated (Tech Support) in Santa Cruz, CA
Distribution: vmsnet
Date: Tue, 14 Apr 1992 18:22:55 GMT


In article <fineberg.703214244@wugate.wustl.edu>, fineberg@wugate.wustl.edu (Charlie Fineberg) writes:
#>Another option is to take the FONTS.ALIAS file out of DECW$EXAMPLES and install
#>that on the Sun.  This will map the DEC fonts to MIT fonts that are "close".
#
#Where on the Sun?  Sorry, I'm just frustrating myself looking...

If you are running an MIT server...  try looking in /usr/lib/X11/fonts/misc

Otherwise... check your documentation.
--
John 'Fast-Eddie' McMahon    ()
TGV, Incorporated            () "You know you have answered too many            
603 Mission Street           ()  Tech Support questions when your Pavlovian   
Santa Cruz, California 95060 ()  response to a ringing phone is to throw it   
408-427-4366 or 800-TGV-3440 ()  out a window" - Me
E-Mail: MCMAHON@TGV.COM      ()
From: mec@math.ufl.edu (Mike E. Cerrato)
Newsgroups: vmsnet.misc
Subject: DECwindows on an Xterminal
Date: 7 Apr 92 16:27:32 GMT
Reply-To: sirotto%maple.decnet@pine.circa.ufl.edu
Distribution: vmsnet
Organization: University of Florida Department of Mathematics

I'm not exactly sure where to post this, so here goes.

I use various Suns and I've found that running Xwindows, I can TELNET
to the VAX here and run DECwindows MAIL on my X display.  It works
with no problems, but MAIL tries to use some odd fonts that don't
exist here (something by the name of MENU) and the default font is
rather small.  Are there any resources for MAIL to change font and
geometry like there are for Xwindoes programs?  I've looked in the
DECwindows user's guide but it didn't say.

Thanks!!
--
           ___  __
|\   |\   |    /  \  Internet:          sirotto%maple.decnet@pine.circa.ufl.edu
| \  | \  |   /      Usenet:     ...!uunet!uflorida!maple.circa.ufl.edu!sirotto
|  \ |  \ |--<       Bitnet:    "sirotto%maple.decnet%pine.circa.ufl.edu"@NERVM
|   \|   \|___\____/                                                           

SirOtto -- Gallant Knight of a rather large, squarish  |     Michael E. Cerrato
  table someplace in the West Panhandle of Florida.    |  University of Florida
Newsgroups: vmsnet.misc,alt.graphics.pixutils,comp.os.vms