HDTenEightyP/NetNews huggingface dataset:
From: hoffmann@evax.tuwien.ac.at (Peter Hoffmann)
Subject: Re: MX 3.1c and UCX 2.0 - Do they work?
Reply-To: hoffmann@evax.tuwien.ac.at
Organization: Technical University Vienna, Computing Services
Date: Fri, 4 Sep 1992 18:55:44 GMT

In article <1992Aug27.141711.9810@magnus.acs.ohio-state.edu>, GAYNOR@agvax2.ag.ohio-state.edu (Jim Gaynor) writes:
>
>Just got ahold of UCX 2.0.  However, I haven't installed it yet. 
>Among other things, I'm wondering if MX 3.1c will work properly with
>UCX 2.0.  At the moment, I'm running MX 3.0 (and some revision letter
>I can't recall right now), and UCX 1.3a.  I figure that if this does
>work out, I'll upgrade UCX and MX in one swell foop.  :-)
>
>So, does anyone have any first-hand experience on MX 3.1c and UCX 2.0?
>

I've got UCX 2.0 some days ago. I encountered some problems in sending
smtp mails with UCX 2.0 SMTP, especially to hosts running the MX-software.

We discovered, that UCX uses in the receipt field only the form user@host,
host without domain extension (e.g: xyz@foo.bar.none becomes xyz@foo)

We tried to install MX 3.1c. After disabling UCX SMTP-Support, 
the MX-Software took over all the mail delivery work successfully. 


--------------------------------------------------------------------------------
  Peter Hoffmann              Computing Services Technical University Vienna 
  VAX System Manager                       Wiedner Hauptstrasse 8 - 10 / 020 
  INTERNET: hoffmann@evax.tuwien.ac.at                A-1040 Vienna, Austria 
  UNA:      EVAX::HOFFMANN                        Tel. (++43 1) 58801 / 5487 
  PSI:      02322623106032::HOFFMANN                  FAX (++43 1) 587 42 11 
Newsgroups: vmsnet.mail.misc,vmsnet.misc,vmsnet.uucp
From: coleve@cc.uvcc.edu
Subject: Re: Gateway to NYNEX???
Organization: Utah Valley Community College
Date: Fri, 4 Sep 1992 02:21:02 GMT

In article <1992Sep3.171443.4485@dmc.com>, munroe@dmc.com (Dick Munroe) writes:
> I've got some clients at a NYNEX site in the Boston area.  Their mail system
> is
> PROFS and they don't know how to get mail out of there universe into the
> internet (and back).  Does anybody out there know a way to get to/from 
>PROFS at
> NYNEX?  
 
It occurs to me that DEC sells a mess-age router to PROFS gateway and innosoft
sells an SMTP to message router gateway.  Perhaps the combination may actually
WORK?

> I'm planning to bring up DECUS UUCP/MX/NEWS there soon if there isn't a quick
> answer.  

That would work fine if they would actually "lower" themselves to climb down
from their mainframe and log in to a VAX, but the cultural difference may be
very hard to overcome.

Who knows?  Maybe if they try it they will like it and get rid of thier 
Iron Blue Monster!

-- 
-- Vern Cole -- Systems Manager -- Utah Valley Community College --
Xref: sparky vmsnet.mail.misc:72 vmsnet.misc:794 vmsnet.uucp:680
From: munroe@dmc.com (Dick Munroe)
Newsgroups: vmsnet.mail.misc,vmsnet.misc,vmsnet.uucp
Subject: Gateway to NYNEX???
Date: 3 Sep 92 17:14:43 EDT
Organization: Doyle, Munroe Consultants, Inc., Hudson, MA

I've got some clients at a NYNEX site in the Boston area.  Their mail system is
PROFS and they don't know how to get mail out of there universe into the
internet (and back).  Does anybody out there know a way to get to/from PROFS at
NYNEX?  

I'm planning to bring up DECUS UUCP/MX/NEWS there soon if there isn't a quick
answer.

Dick Munroe
-- 
Dick Munroe				Internet: munroe@dmc.com
Doyle Munroe Consultants, Inc.		UUCP: ...uunet!thehulk!munroe
267 Cox St.				Office: (508) 568-1618
Hudson, Ma.				FAX: (508) 562-1133

GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection.
Newsgroups: vmsnet.mail.pmdf
Subject: vrfy and expn commands
From: Fritz Wittwer <wittwer@tech.ascom.ch>
Date: 26 Aug 1992 08:20 +0200
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 26 Aug 1992 08:20 +0200
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO0QK4WQ0295O5Y3@YMIR.CLAREMONT.EDU>
X-Organization: Ascom Tech Ltd. - Corporate Research Div. - Berne - Switzerland
X-Vms-To: list_ipmdf
X-Vms-Cc: wittwer
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Hello

A sendmail guru told me sometimes ago, that our pmdf does not support the
commands expn and vrfy correctly.

The vrfy command answers '250 Possible DECnet address not checked.' if he
specifies a decnet address, and this is not the answer he expexted.
Is there a chance that this will change sometime? And what's the meaning of
250, I saw this codes somewhere in an RFC, but i can't remeber the exact
meanings.

He told me to that the expn command didn't work. For me it seems to work,
except the inclusion of the personal name (sendmail seems to do it). Are there
any other differences?

Sorry for this stupid questions, but we have a lot of SUN (and sendmail) users
here, and some of them have an understanding like 'SUN OS is the standard,
anything wich is different violates the standards and should be shut down; if
there are standards wich differ from SUN OS, then the standards ar just wrong'.


Regards
	Fritz
From: klensin@infoods.mit.edu (John C Klensin)
Newsgroups: vmsnet.mail.pmdf
Subject: 4.1 configuration on upgrade
Date: 27 Aug 92 18:01:41 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 27 Aug 1992 14:01:41 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO2O6CKQ5E95NS43@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>


Since I did an upgrade from 4.0 to 4.1, my PMDF.CNF file was essentially
preserved, and it looks like a number of interesting and/or important
4.1 options did not make it into it.

(1) General question:  What should I (and others in this situation) be
looking at wrt to adding to/changing the CNF file that isn't discussed
in the upgrade instructions in the installation guide (almost nothing
is) or in the "new features" list and that is not obvious from looking
at the new list of channel keywords.  I know this sounds like a "what
should I know that I don't" question, but it really isn't--it is closer
to "what of this sort was left out of the documentation and release
notes that would have been there if people had more time".

(2) Specific question: A new automatic config (looking another host on
which a new 4.1 installation was done) seems to generate  "defragment"
and "reprocess" channels and to use these as keywords. They are not in
table 3-10, the channel keyword list, nor are they in  the index.    I
can guess what these might be, but, for those of us upgrading older
configurations, pointers to specific documents or other suggestions
about how these are used, how they are supposed to be entered into the
PMDF.CNF file, etc., would be appreciated.

(3) Is it possible to run CONFIGURE.COM from a user process in what
might be thought of as a test environment, putting the output files into
a user directory?  This would be extremely useful for comparing the
incrementally-upgraded configuration files for a running system with
those that the 4.1 configuration generator would produce de novo.  If
not, can we get this as a request into some appropriate development
queue?

(4) I fear this has already been answered, but, if so, I've misplaced
the answer, for which I apologize.  The release notes indicate the
availability of a mechanism for restricting who can post to lists.  I
have a vague memory to a keyworded attribute list out at the end of
an alias as the syntax.  Could you folks review this feature or point to
some documentation I haven't been able to find?

  thanks,
  --john
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: pmdf v4.1-1 and slow delivery
Date: 23 Aug 92 21:12:31 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 23 Aug 1992 13:12:31 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNX7JJM5QA95O1A9@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"tkslen@ubvms.cc.buffalo.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I just installed vms v5.5-1 and pmdf v4.1-1 on monday.  Ever since then it
> seems
> my queues build during the day (all of them from the local to the bitnet and
> internet queues) then during the night they catch up.  I feel this is from the
> low volume of new mail during the night.
> Anyone have any idea's of what could be causing the performance problem.  The
> cpu the queue is running on not 100% loaded.  The log files from the delivery's
> show no errors, just successful delivery's.
> When I installed pmdf all I did was run bitnet_domains.  Should I have run
> something else?

This sounds a lot like a queue cache ownership problem.  If the ownership ot
the queue cache is incorrect, then some incoming mail (depends upon the
channel) may not get registered in the queue cache and thus will sit around
undelivered until it is registered in the queue cache.  At about midnight, the
RETURN job will run and will synchronize the cache and finally some of this
mail will be noticed and delivered.

The queue cache is the file PMDF_ROOT:[TABLE]QUEUE_CACHE.DAT.  It should be
owned by [PMDF] or whatever your PMDF account is.  If you do not have a PMDF
account, then it should be owned by the [SYSTEM].  Its protection should be
(S:RWED,O:RWED,G,W).  There was a problem with 4.1-0, -1, and -2 kits which
could lead to the queue cache not having the proper ownership.

... and then your problem may be something entirely different.  If that is the
case, the best way to start in tracking the problem down is to identify which
channels seem to be afflicted the most.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: RE:  A problem with NETFIND (fyi)
From: Mike Schwartz <schwartz@latour.cs.colorado.edu>
Date: 27 Aug 1992 09:45:03 -0600
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 27 Aug 1992 09:45:03 -0600
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: WHITE-PG%BITNIC.BITNET@ymir.claremont.edu, info-multinet@TGV.COM, 
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO2JD7RRFM95OH2A@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"mls@slac.stanford.edu"
X-Vms-Cc: IN%"WHITE-PG@BITNIC.BITNET", IN%"info-multinet@TGV.COM",
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Mike, I'm surprised at you.  This "problem with Netfind" was in reality a
problem with the information your mailer gives out.  Moreover, one day
after you told me about it, I changed Netfind to detect such problems,
and not give out the invalid information.
 - Mike
From: rickm@oregon.uoregon.edu (Rick Millhollin)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: PhoneNet Channel Problem
Date: 25 Aug 92 22:56:17 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 25 Aug 1992 15:56:17 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO05Y0GYC295NKER@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Please ignore that posting ... problem fixed by Innosoft support.
From: kvc@summer.innosoft.com (Kevin V. Carosso)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: postmaster bounces - 4.1-10
Date: 29 Aug 92 04:35:55 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 28 Aug 1992 20:35:55 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO4MHDOH4I95ONJ8@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ECF_STBO%JHUVMS.BITNET@ymir.claremont.edu"
X-Vms-Cc: info-pmdf
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I would recommend that people on bitnet with a heavy mail load install
> bn_master and bn_gateway /open/head/shared. Here these images are invoked
> hundreds of times a day. I have also streamlined task_server.com by adding a
> set nover and letting all the logfile information just go into the single
> process log file. If there is a problem, we can always go back to the old
> one. Wirth the one shipped there are way too many files created, with way too
> much data in them for normal operation. Our [log] directory was getting up to
> 10,000 blocks w/ hundreds of files!

We've considered adding some things to PMDF to reduce (or eliminate) the normal
level of logging for high-traffic sites.  The sorts of things you've done
would be included in that.  About the only drawback is tracking things down
when a problem occurs.  We're thinking about the best way to reduce logging
with the least adverse impact to problem-tracking.

	/Kevin Carosso
	 Innosoft
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: vrfy and expn commands
Date: 26 Aug 92 10:47:45 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 26 Aug 1992 02:47:45 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO0SLJN9DE95O9QY@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"WITTWER@tech.ascom.ch"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

You'd better have you sendmail guru reread the relevant RFCs and
explain in some detail why the results you cite are incorrect. As far
as I know PMDF fully supports both VRFY and EXPN to the full extent
possible. sendmail offers nowhere near comparable support for these
commands.

				Ned
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: More on (Any status returned by $ PMDF SEND command in 4.1?)
Date: 28 Aug 92 15:39:51 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 28 Aug 1992 08:39:51 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO3YAEZZ5Q95OKYS@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"DMPM%DUKEMC.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>>I would like to use PMDF SEND command under program control, but
>>cannot find any sort of return status on failure (except for the text message).
>>Is there anything like deliver_status and deliver$message in this facility?
>>Even upon failure (such as bad address) $status is 1.
>>This is a much needed feature.
>>
>>Thanks,
>>
>>Jim
>
> I would like to change this a bit.  Some failures do result in an error in
> $status.  However, my problem is:
>
> %PMDF-E-ALLADDRBAD, All addresses specified are bad; message not sent
> $ stat = $status        !Does $status return anything - no
> $ sho sym stat
>   STAT = "%X00000001"

My previous message already addressed all of this and was sent before I received
this additional posting of yours.  However, for those interested, I'll explain
what is going on here that is causing some errors to set $STATUS and others not
to.

PMDF SEND, as shipped with PMDF, uses LIB$SIGNAL to signal an error.  Now,
LIB$SIGNAL will, in the case of a fatal error, also call $EXIT and $EXIT will
properly set the $STATUS and $SEVERITY symbols.  So, the errors which causes
$STATUS to be set were, undoubtedly, fatal errors.  All other errors (non-fatal
errors and warnings) were merely signalled but no $EXIT performed.  The
suggested code change I sent you should do what you want: display messages when
an informational, non-severe, or severe status code occurs AND always set
$STATUS and $SEVERITY appropriately.

Dan
From: shawn Allin - Alcan KRDC Computer Services
Newsgroups: vmsnet.mail.pmdf
Subject: Can I set up a form of directory service (ala X.500 or WHOIS) in PMDF?
Date: 27 Aug 92 16:20:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 27 Aug 1992 12:20:00 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO2KLST8CY95O86V@YMIR.CLAREMONT.EDU>
X-Vms-To: INFO-PMDF@YMIR.CLAREMONT.EDU
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Date sent:  27-AUG-1992 12:13:45

     Hi,

Now that we have a number of widely disparate mail systems connected with
PMDF-glue, (CC:mail, TCP, VMS...) my management would like me to set up a
lookup service for usernames at the various locations.  Can this be done
with PMDF in a non-interactive method?  I say non-interactive, because
something like WHOIS would require (I assume) a full-time link and the
transport to be supported.  We have a variety of periodic Phonenet, UUCP,
etc connections here.  So we'd like to set something up so that you send a
message to a MAILSERV-like address and it sends the lookup results back
to the user via mail.
Has anyone done this?  Is this a FAQ?

     Thanks,

     Shawn Allin
     Alcan International Ltd.,
     P.O. Box 8400,
     Kingston, Ont.,
     Canada  K7L 5L9
     (613) 541-2178

     ACCESS@KRDC.INT.Alcan.CA
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Help:  Any status returned by $ PMDF SEND command in 4.1?
Date: 28 Aug 92 14:58:40 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 28 Aug 1992 07:58:40 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO3W27U27695OJ77@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"DMPM%DUKEMC.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I would like to use PMDF SEND command under program control, but
> cannot find any sort of return status on failure (except for the text message).
> Is there anything like deliver_status and deliver$message in this facility?
> Even upon failure (such as bad address) $status is 1.
> This is a much needed feature.

At present, PMDF SEND calls LIB$SIGNAL when an error is detected.  This call
is made only in one place and it should be pretty straightforward or you to
change the following code chunk

  (* Call PMDF SEND *)
  item_list_adr::unsigned := iaddress (item_list);
  i := pmdf_send (item_list_adr);
  if not odd (i) then LIB$SIGNAL (i);

to

  (* Call PMDF SEND *)
  item_list_adr::unsigned := iaddress (item_list);
  i := pmdf_send (item_list_adr);
  if not odd (i) then $EXIT (i);

I have not made this change to PMDF (i.e., this is not a patch which everyone
should apply).  I'll leave the final decision to Ned as it was originally his
decision to use LIB$SIGNAL in PMDF SEND and he may have had a reason for that
choice.

Dan

------------------------------------------

P.S. Here's a better way to implement the change

  (* Call PMDF SEND *)
  item_list_adr::unsigned := iaddress (item_list);
  i := pmdf_send (item_list_adr);

  (* Dispose of the To: address list *)
  while address_list <> nil do begin
    tmpaddr := address_list^.link;
    dispose (address_list);
    address_list := tmpaddr;
  end; (* while *)

  (* Dispose of the extra header list *)
  while header_list <> nil do begin
    tmphdr := header_list^.link;
    dispose (header_list);
    header_list := tmphdr;
  end; (* while *)

  (* Dispose of the file list *)
  while file_list <> nil do begin
    tmpfile := file_list^.link;
    dispose (file_list);
    file_list := tmpfile;
  end; (* while *)

  (* Now exit *)
  $EXIT (i);

end. (* send *)
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problem with personal aliases
Date: 25 Aug 92 18:28:13 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 25 Aug 1992 10:28:13 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNZUE72KW295O5EK@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"GHC@VGER.NIDDK.NIH.GOV"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

First of all, you cannot test personal aliases with PMDF TEST/REWRITE. It
does not contain any logic for testing them and will not produce
results that even vaguely resemble what you should get from personal
aliases. This restriction is a permanent one and will not be lifted in
the future -- the handling of the expansion of personal aliases is totally
ideosyncratic to the user agent doing the expansion. VMS MAIL, PMDF SEND,
Multinet MM, and our unreleased PMDF user agent all handle personal aliases
and all do it differently. The only aspect of personal aliases you can
test with PMDF TEST/REWRITE is whether or not they expand into the
proper list of envelope addresses.

Second, the message you received on HELIX was munged by a broken sendmail
configuration. One of sendmail's many problems is that it cannot handle
group address syntax. (More accurately, the configurations that ship
with 99.999% of the sendmails of the world don't handle group addresses
properly.) In practice this is a non-issue since you cannot use an
empty group address for anything anyway. But the address you should
have seen was something like this:

    To: HELIX: ;

The @host stuff is garbage that sendmail slapped on there. Ironically, there
are also some sendmails out there that will strip this garbage back off. What
a pile.

Finally, I don't know what you expected to get, but this is the expected
result when you use a persnoal alias that is marked private and noexpand.
If you want the alias to expand into the real address just mark it expand
and it will. If you want it to expand into an alias other people can use
mark it public.

				Ned
From: jjc+@pitt.edu (Jeffrey J. Carpenter)
Newsgroups: vmsnet.mail.pmdf
Subject: Holding Mail
Date: 27 Aug 92 18:33:38 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 27 Aug 1992 14:33:38 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO2P9YJ87695OHP1@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"INFO-PMDF@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Hi,

I am running PMDF 4.0, JNET 3.4, Multinet 3.0, and VMS 5.4-3.

We have a machine on campus that will be down for several days.  Is
there a way I can configure a channel for this specific host so that it
does not follow the normal schedule for return of undeliverable mail?

Is this what the PMDF_HOLD logical in RETURN.COM is intended for?

Thanks,


	jeff
From: kvc@summer.innosoft.com (Kevin V. Carosso)
Newsgroups: vmsnet.mail.pmdf
Subject: PMDF Process Symbiont
Date: 29 Aug 92 04:45:25 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 28 Aug 1992 20:45:25 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GO4MSF5R7695ONCS@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ECF_STBO%JHUVMS.BITNET@ymir.claremont.edu"
X-Vms-Cc: info-pmdf
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> hundreds of times a day. I have also streamlined task_server.com by adding a
> set nover and letting all the logfile information just go into the single
> process log file. If there is a problem, we can always go back to the old

One thing you might want to watch out for.  Using only the IDLE_TIMEOUT option
means that a really active TASK_SERVER won't time out and exit and allow for
a new TASK_SERVER.LOG file.  You might want to consider using the LIFETIME
option which specifies a delta time after which the TASK_SERVER process will
exit and be restarted even if it never reaches IDLE_TIMEOUT.  For example,

    LIFETIME = 0 06:00:00

in the PMDF_PROCESS_SMB.OPT will create a fresh TASK_SERVER process and new
log file every 6 hours.  The exit is done cleanly, between processing jobs.
Unfortunately this didn't make it into the printed manuals, but is in the
on-line BookReader docs.

	/Kevin Carosso
	 Innosoft

ps.  The default if you don't specify is 24 hours I believe.