HDTenEightyP/NetNews huggingface dataset:
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Reverse-rewriting an empty From:-header
From: Ned Freed <ned@innosoft.com>
Date: 06 Oct 1992 21:10:00 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 06 Oct 1992 21:10:00 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPN65MT1828WWQCH@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"bob@camb.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I sometimes see ``service messages'' from Message Router which produce
> mail with empty From:-headers.  My first thought was to rewrite such
> empty From:-headers so that the mail came from the postmaster.

> (1) Is this a good idea?

This should be handled in the FROM_MR.TXT file. There is a special hook ($E)
for handling empty addresses.

The envelope address should be left blank. This is perfectly legal and
proper for service messages.

> (2) If so, can I do it with the REVERSE mapping?  I haven't been able to
>     figure it out so far.

Nope, it is not possible to create an address out of nothing using the
reversal database.

> (3) Is there some way to prevent this ``empty From:-header'' situation
>     from arising in the first place?

Use the $E rule properly.

> (4) What's the prospect on standardization on the format of these
>     Service messages?

Practically none. Message Router does not do return of contents. The Internet
world pretty much demands return of content, and this demand is very likely to
extend to any future standardization of error message return formats. It
certainly applies now to the current format recommended by Nathaniel
Borenstein's RFC that covers this.

The prospects are slightly brighter if you don't consider the return of
content issue, but given the fact that the IETF people dealing with
mail are currently stuck dealing with SMTP extensions, I would not hold my
breath waiting for something to come out in this area.

					Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: API kit availability
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 14 Oct 1992 14:05:10 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 14 Oct 1992 14:05:10 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPXWJQHAC28WXOGZ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"DMPM@mc.duke.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> 1) The documented format for PMDF_debug is (enqueue_debug, dequeue_debug)
>    but I find it to work the opposite of this.

I just checked the actual source and it is indeed as documented.  There was,
however, a problem in the C version, PMDFdebug, in which dequeue debugging was
not set and enqueue debugging was first set to the value of the enqueue_debug
argument and then set to the value of the dequeue_debug value.  I've fixed this
in the latest version of the API.  In the meantime, call PMDF_debug and not
PMDFdebug.  Pass a 0 for false and a -1 for true.

> 2) I get some link warnings.  Here is output of link:

Arggg.  The link command in the documentation is wrong.  It should read

    $ link program,pmdf_root:[api]api/lib,pmdf_root:[exe]pmdfshr_link/opt,
                   pmdf_root:[exe]ident/opt,pmdf_root:[exe]pmdflib/lib

If this doesn't do the trick, let me know.  This entire link command will
change come PMDF V4.2.

Dan
From: s503@hec.ca (Eddy BELIVEAU)
Newsgroups: vmsnet.mail.pmdf
Subject: How to remove X-ENVELOPE-TO when using MAILLIST
Date: 8 Oct 92 21:05:14 GMT
Organization: Ecole des Hautes Etudes Commerciales de Montreal
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Oct 1992 16:05:14 -0500 (EST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPPHJ459TE8WWZRZ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@ymir.bitnet"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Date:   8-OCT-1992 15:48:07

Hi! I'm using PMDF 4.1
    And we are beginning to use the MAIL SERVER Channel

    One of my users told me the following:

    When he send a message to a list, the message is delivered correctly
    but on the header, you will see a line named X-ENVELOPE-TO which
    give the list of many dozens of username...

    Is there a way to (1) remove that line from the header
                   or (2) preferably, substitute the name of the list
                          instead of the list of all users subscribed to
                          that list
                          example:        X-ENVELOPE-TO: my-list-L

    I set-up my mailing list as described in section 11.6.2.3

    $ create pmdf_mailserv_mail_dir:my-list-L.dis

    I added the next lines in PMDF_ALIAS_FILE

      my-list-L:         my-list-L-forward
      my-list-L-expand:  <pmdf_mailserv_mail_dir:my-list-L.dis, my-list-L-error
      my-list-L-request: mailserv
      my-list-L-error:   postmaster

    In MAIL, I use the following command
      > set forward/user=my-list-L-forward in%my-list-L-expand



    and I added the next command in my mail program
    $MAIL
    > set forward /user=my-list-L in%my-list-L

    This permit our users to use MY-LIST-L instead of IN%MY-LIST-L

Thank you in advance for any tips.

Eddy

=========================================================================
| EDDY BELIVEAU,                           |   Bitnet:  s503@hecmtl01   |
| Ecole des HAUTES ETUDES COMMERCIALES     | Internet:  s503@hec.ca     |
| MONTREAL         +-----------------------+----------------------------+
| Quebec, CANADA   | Phone: (514) 340-6073 | Any   horizontal  surface  |
| H3T 1V6          | Fax  : (514) 340-5637 | soon tends to be piled up  |
=========================================================================
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Looping mail
Date: 15 Oct 92 19:42:07 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Oct 1992 12:42:07 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPZ8X9ZTQK8WXS1I@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"IMHW400@INDYVAX.IUPUI.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

This sort of things has to be tracked down intelligently by examining the
addresses on the messages themselves. You need to look at what the addresses
say and how they are handled. Use PMDF TEST to check out the addresses as
far as PMDF is concerned. Then look at any forwarding in VMS MAIL. You
also need to check any SET TRANSPORT settings you have, especially on whatever
account you run PMDF under (usually SYSTEM).

Since PMDF things don't seem to have changed the problem is most likely
somewhere in VMS MAIL itself, where checking to see if something has
changed is nearly impossible.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: PMDF TEST /X400 /FROM_MR=
From: Bob Tinkelman <bob@camb.com>
Date: 09 Oct 1992 16:32:33 -0400 (EDT)
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 09 Oct 1992 16:32:33 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: TINKELMAN@Eisner.DECUS.Org
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPQVXRY6HU8WVZGF@INNOSOFT.COM>
X-Vms-To: IN%"info-pmdf@innosoft.com"
X-Vms-Cc: TINKELMAN
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Is there a way to test new FROM_MR.DAT_NEW and TO_MR.DAT_NEW files before
making them into the *.DAT files used in the live configuration?
From: pern@db1.cc.rochester.edu (Jack Pernice)
Newsgroups: vmsnet.mail.pmdf
Subject: Are you still there?
Date: 16 Oct 92 01:20:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Oct 1992 21:20 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPZJS4KQEQ984IQ2@INNOSOFT.COM>
X-Vms-To: IN%"info-pmdf@innosoft.com"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

This is a test message to the PMDF information list.  I usually get 10
to 12 messages a day from the list.  I haven't received anything in days.

----------
Jack Pernice				 BitNet:    PERN@UORDBV
VMS Systems				 InterNet:  pern@db1.cc.rochester.edu
University of Rochester			 Voice:     (716) 275-7160
Rochester, NY  14620
USA
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: File create errors.
Date: 15 Oct 92 18:39:43 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Oct 1992 11:39:43 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPZ5QOAKR68WXQAR@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"SETH@speech.mit.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> %MAIL-E-SENDERR, error sending to user audiodev@cbgrle.mit.edu at
> -PMDF-E-FCRT, File create error, Pascal status = 2, VMS statuses = 99684 and 0
> -PMDF-I-TEXT, cannot create channel queue entry

This error, 99684, corresponds to

   $ exit 99684
   %RMS-F-IFI, invalid internal file identifier (IFI) value

Your users are probably
mixing foreign protocols in a single VMS MAIL session; e.g., sending mail to
IN% and then SMTP% or vice versa.  They must only use one of these in any given
MAIL session.   Also, if someone has set their forwarding to xx% then this
problem may be triggered.  The only work around is to only use one foreign
protocol interface if at all possible.  Given that you have PMDF, there's no
need for them to be using things like SMTP%, JNET%, etc.  If you'd prefer to
not re-educate your users, you can always define executive mode logicals of
the form

   $ define/system/exec mail$protocol_smtp pmdf_mailshr
   $ define/system/exec mail$protocol_jnet pmdf_mailshr

etc.

Both TGV and Innosoft is aware of this problem and have tracked it down to a
bug in RMS.  Despite being reported numerous times, DEC has refused to fix this
bug.

Dan
Newsgroups: vmsnet.mail.pmdf
Subject: Reverse-rewriting an empty From:-header
From: Bob Tinkelman <bob@camb.com>
Date: 06 Oct 1992 23:48:11 -0400 (EDT)
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 06 Oct 1992 23:48:11 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPN4ASCDAQ9TCNER@INNOSOFT.COM>
X-Vms-To: IN%"info-pmdf@innosoft.com"
X-Vms-Cc: TINKELMAN
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I sometimes see ``service messages'' from Message Router which produce
mail with empty From:-headers.  My first thought was to rewrite such
empty From:-headers so that the mail came from the postmaster.

(1) Is this a good idea?
(2) If so, can I do it with the REVERSE mapping?  I haven't been able to
    figure it out so far.
(3) Is there some way to prevent this ``empty From:-header'' situation
    from arising in the first place?
(4) What's the prospect on standardization on the format of these
    Service messages?

Attached is one such message.
Newsgroups: vmsnet.mail.pmdf
Subject: Handling broken From:-addrs with PMDF-MR
From: Bob Tinkelman <bob@camb.com>
Date: 09 Oct 1992 17:10:08 -0400 (EDT)
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 09 Oct 1992 17:10:08 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: postmaster@aaunix.aa.wpafb.af.mil, TINKELMAN@Eisner.DECUS.Org
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPQX90KRPU8WVZGF@INNOSOFT.COM>
X-Vms-To: IN%"info-pmdf@innosoft.com"
X-Vms-Cc: IN%"postmaster@aaunix.aa.wpafb.af.mil",TINKELMAN
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

It appears that the way I have configured PMDF-MR it bounces messages which
arrive from the Internet with invalid From:-headers (at least those ones
with syntax errors, given the attached example).  Is this something that's
hardwired into PMDF-MR, or is it something that I control with
configuration options?  [I didn't attach my to_mr.txt file, but could send
it to you if it turns out I broke something there.]

I can see a number of possible courses of action when msgs are received with
invalid From-addrs:

1. Bounce the message.  [I guess this sounds like the safest, but it seems
   violate the ``be liberal in what you accept'' philosophy.]
2. Pass the message, mapping the From:-addr to something that will reverse
   map back (when a REPLY is done) to the same (invalid) address.
3. Pass the message, translating the From:-addr into one that is
   syntactically correct, but (admittedly) has little chance of being
   a symantic equivalent, with a warning msg (of course) that this has
   happened.  [This seems like a very bad idea to me.]
4. Send the message on as an `enclosure' in a msg from the postmaster,
   with a note of what the problem was.  [This is what I'd do manually
   today, if I had the time...]

If I had all the above choices available, I think I'd choose 2.
---
Bob Tinkelman <bob@camb.com>
Newsgroups: vmsnet.mail.pmdf
Subject: Stuck BITNET Mail
From: Rick Millhollin <rickm@oregon.uoregon.edu>
Date: 07 Oct 1992 16:34:21 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 07 Oct 1992 16:34:21 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPO9SN1NEA8WWU4P@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

I've got four files in my BIT_GATEWAY queue that appear to be stuck.  When I
manually run MASTER on the channel, it runs BN_GATEWAY but produces no output,
even though I have debug enabled.  It's as though the program doesn't even see
the files in the queue.  Also, I ran SYNCH_CACHE just for drill, but no
difference.  Help?
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: WATERLOO.EDU changed to UWATERLOO.CA ???
Date: 12 Oct 92 19:22:29 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Oct 1992 12:22:29 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPV1KVKBK28WXCU1@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"mls@SLAC.STANFORD.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

This situation is indeed illegal -- an MX record has to point at something
with an A record. Only a single level of indirection is allowed in an
MX record.

An MX pointing at an MX effectively isn't there. A system with only MXes of
this sort and no A records of its own is therefore a name with no address.
Names with no associated address aren't valid destinations for mail and
messages to them should be bounced, and this is precisely what PMDF does.

Changing domain names is fine, but you shouldn't attempt to change the
underlying information at the same time. Doing so leads to precisely this
sort of situation. If this basic principle isn't written down somewhere it
sure should be.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: ccMail and Dates
From: Ned Freed <ned@innosoft.com>
Date: 08 Oct 1992 21:22:00 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Oct 1992 21:22:00 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPPY1VPSOY8WX1FZ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"MAC@gvg47.gvg.tek.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

This problem was fixed in PMDF V4.1-12. Contact iii@innosoft.com if you
want to arrange to get this version.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: "MESSAGE DAMAGED IN TRANSIT" messages
From: Ned Freed <ned@innosoft.com>
Date: 10 Oct 1992 11:26:20 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 10 Oct 1992 11:26:20 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPS5SVT2XU8WX3M2@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"SMITH%NYUMED.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

As I stated previously, it means that something interrupted the process
of writing the message into the PMDF queue. The entry is incomplete and
improprly formed; the message you see is simply an indication of this.

It has nothing to do with commas; I don't even know what this means.

				Ned
From: greenbjb%snyoneva.bitnet@ymir.claremont.edu (Jim Greenberg)
Newsgroups: vmsnet.mail.pmdf
Subject: Tracking Messages
Date: 8 Oct 92 14:40:21 GMT
Organization: from SUNY College at Oneonta, NY 13820
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Oct 1992 10:40:21 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPP55EASRM8WWY0Q@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"ipmdf@ymir.bitnet"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

PMDFers,

Can you point me to a section in the 4.1 manual that might discuss how, why and
when you get messages back from each node (hop) when you send mail.  You know
what messages I mean, the ones that say things like:

        MAIL>
(SNYONEVA) - Sent file 6718 on link SNYBUFVA to SNYBUFVA BROWNRN
MAIL>
(SNYBUFVA) - File (6718) spooled to BROWNRN -- origin SNYONEVA(GREENBJB)
10/08/9
2 10:17:15 EDT

I need to understand the details of these messages better so I know why we
sometimes get them and sometimes don't.

Thanks.


Jim Greenberg
SUNY College at Oneonta

P.S.  Are any of you running PROCESS software with PMDF and JNET?  I have
a few questions about this set up.
From: gareth@lucifer.latrobe.edu.au (Chief Smeghead)
Newsgroups: vmsnet.mail.pmdf
Subject: %SYSTEM-F-PROTOCOL, network protocol error
Date: 7 Oct 92 06:31:42 GMT
Organization: La Trobe University


PMDF Guru's.

I have this anoying problem with the UCX/PMDF server. I have searched
the UCX manuals and the PMDF manuals but cannot find the answer.

Upon shutting down my VAX's (VAXstation 3100's) I get the following OPCOM
message...

%%%%%%%%%%%  OPCOM   5-OCT-1992 09:00:33.60  %%%%%%%%%%%
Message from user SYSTEM on ATR1
UCX/PMDF server, UCX_SMTPD exit with: %SYSTEM-F-PROTOCOL, network protocol error

Software:
	 VMS V5.4
	 UCX V1.3A
	 PMDF V4.1

Any help appreciated.

Many thanks,

Gareth.
-- 
gareth@lucifer.latrobe.edu.au
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: QUEUE_CACHE.DAT and my performance problem
Date: 15 Oct 92 22:27:36 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Oct 1992 15:27:36 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPZDOSQWBM8WXO5K@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"tkslen@ubvmsb.cc.buffalo.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Why is the queue_cache file extending instead of reusing it's allocated blocks?

It is just the way indexed files work. Empty buckets from deleted records
aren't generally eligible for reuse until you reclaim them using
CONVERT/RECLAIM. Unfortunately this requires exlclusive access and therefore
can only be done during slack times. The basic idea is that the file grows and
grows during the day and gets reclaimed each evening. This will release those
blocks for reuse the next day.

It is possible that someone cleverer than I with these RMS things could come up
with a way to get more reclamation during actual use -- it may be possible to
do this using clever tricks with multiple areas. If someone knows how to do
this I'd love to hear about it. If possible at all it should be doable via an
FDL file, I believe. Practically everything in RMS can be controlled with
an FDL file.

> If the file must extend should innosoft or the user create an FDL file so that
> the file is created with a big allocation so the file doesn't become
> fragmented?

Yes, I already recommended doing this in my original response. Alternately, you
could use the RMS tuning stuff (EDIT/FDL/SCRIPT=OPTIMIZE/NOINTERACTIVE for
instance) to tune the whole thing using whatever intelligence Digital has coded
in there.

RMS has loads of analysis, tuning, and performance optimization facilities --
it always amazes me that VMS users don't take more advantage of all this stuff.
The ability judicious use of these existing facilities was the primary reason
for making the queue cache an RMS file instead of inventing our own structure.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Tracking Messages
From: Ned Freed <ned@innosoft.com>
Date: 08 Oct 1992 21:28:23 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 08 Oct 1992 21:28:23 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPPYO1WNR68WX1K1@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

I bow to John's obviously superior assessment. I loathe the silly messages
myself and news that modern NJE implementations feel this way is most
welcome personally. Speaking as a developer, it has proved quite difficult
to provide an environment that maximizes the likelihood that these messages
will be produced and directed properly. Neverthless, we have been obliged to
do so since so many people actually seem to like the messages. We will
continue to support this as a goal until such time as it becomes totally
pointless to do so.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: PMDF TEST /X400 /FROM_MR=
From: Ned Freed <ned@sigurd.innosoft.com>
Date: 09 Oct 1992 15:56:24 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 09 Oct 1992 15:56:24 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPR107IIN68WX4LL@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"bob@camb.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Define the logical names PMDF_*_MR_DATABASE locally in your process to point
at your new files.

				Ned
Newsgroups: vmsnet.mail.pmdf
Subject: RE: %SYSTEM-F-PROTOCOL, network protocol error
From: "Kevin V. Carosso" <kvc@summer.innosoft.com>
Date: 09 Oct 1992 23:32:29 -0800 (PST)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 09 Oct 1992 23:32:29 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GPRGW05IS28WX6K8@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"gareth@lucifer.latrobe.edu.au"
X-Vms-Cc: info-pmdf
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Upon shutting down my VAX's (VAXstation 3100's) I get the following OPCOM
> message...
>
> %%%%%%%%%%%  OPCOM   5-OCT-1992 09:00:33.60  %%%%%%%%%%%
> Message from user SYSTEM on ATR1
> UCX/PMDF server, UCX_SMTPD exit with: %SYSTEM-F-PROTOCOL, network protocol
error

That is normal, the detached process that handles incoming SMTP connections
under UCX has exited because you've run the UCX$SHUTDOWN procedure.  Because
of problems we used to have with reliability of that detached process, it runs
in a DCL procedure which restarts the server automatically and sends that
notice to OPCOM.  You should ignore it.

	/Kevin Carosso
	 Innosoft