HDTenEightyP/NetNews huggingface dataset:
Errors-to: epmdf@YMIR.BITNET
Organization: Cambridge Computer Associates, Inc.
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"NED@SIGURD.INNOSOFT.COM"
X-VMS-Cc: IN%INFO-PMDF,TINKELMAN
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 2 Sep 92 17:52:09 GMT
From:         Bob Tinkelman <bob@CAMB.COM>
Subject:      RE: `Disconnected' remote PhoneNet dial-in processes
X-To:         NED@SIGURD.INNOSOFT.COM
X-cc:         ipmdf@INNOSOFT.COM
Newsgroups: bit.listserv.pmdf-l

> It is stuff coming out of the slave process. The way this works in PMDF is
> that SLAVE exits and then SLAVE.COM stops the process. If, for instance, you
> have SET VERIFY enabled, there will be noise from the command file that will
> go out on the line.

OK.  I understand that now.  We explictly do a SET NOVERIFY in our SYLOGIN.COM,
just before we quit if the user is a PMDF PhoneNet channel.  So I don't think
that's the problem (unless it broke, of course :-).

> No, I mean connect to one of those disconnected processes by logging in to the
> PMDF account and then explicitly reconnecting to one of those disconnected
> processes out there. I expect that some output should pop out and the job will
> then log out. The output that appears is what's important.

I'll try that the next time I see them.  However, I'll have to reset the
account from it's current setting of DisReconnect.  That couldn't be the
problem, could it?  I set that at one point because the scripts I'm using
at the MASTER end couldn't deal with the unexpected prompt when there were
disconnected processes.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"SMITH%NYUMED.BITNET@ymir.claremont.edu"
X-VMS-Cc: IN%"service@innosoft.com",IN%"ipmdf@ymir.claremont.edu"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 1 Sep 92 00:09:11 GMT
From:         Portia Shao <PORTIA@INNOSOFT.COM>
Subject:      RE: Problems with multiple messages to the cc:Mail gateway.
X-To:         SMITH@NYUMED
X-cc:         service@INNOSOFT.COM, ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

>I have been having some problems with the cc:Mail channel that we are trying
>to get to work.  A series of messages sent to the ccmail channel should yield
>an output file with the messages being sent appended to oneanother.  What is
>happening is that the first file is created ('cc_output.dt' in this case)
>just fine (see first log). But the output file seems not to be being created
>by cc_master in the second case (see second log file: I put in the DIR to see
>whether there is a new file there: there isn't).  This has got to be a silly
>mistake somewhere.  I changed the names of the in and out files in the option
>file just to be sure I had not picked a silly name: same effect.
>
>This is V4.1-10, with the cc_master.exe re-linked.

cc_slave needs to be relinked also in V4.1-10.

Please check your master.com, you should have the following in the cc:Mail
section, there was a line which could be missing.

$   if f$search("pmdf_root:[queue.''channel_name']*.%%;") .nes. ""
$   then
$     if f$search(ccoutfile) .nes. "" then -
        rename/log 'ccoutfile' 'ccoutfile'-tmp-save
$     define/user option_file        pmdf_root:[table]'channel_name'_option.

Did you have the above line? it was missing in some earlier versions of
master.com (and it did not show up in your log file)

$     run pmdf_root:[exe]cc_master.exe

>
>--------------- Option file ------------------------------------------
>CC_OUTPUT_FILE_NAME=SYS$APPLE:[SMITH]CC_OUTPUT.dt
>CC_INPUT_FILE_NAME=SYS$APPLE:[SMITH]CC_INPUT.dt

I assume you also have the CC_GATEWAY_NAME line in your option file.


                /portia
                portia@innosoft.com     (714)624-7907
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Fri, 28 Aug 92 17:25:50 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject: RE: Help: Any status returned by $ PMDF SEND command in 4.1?
X-To:         DMPM@DUKEMC, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> 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 *)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Duke University Medical Center, Durham NC, USA
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf@ymir"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 28 Aug 92 15:41:16 GMT
From:         "James Dryfoos - Postmaster" <DMPM@DUKEMC>
Subject: Help: Any status returned by $ PMDF SEND command in 4.1?
X-To:         ipmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Cambridge Computer Associates, Inc.
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"NED@SIGURD.INNOSOFT.COM"
X-VMS-Cc: IN%"info-pmdf",TINKELMAN
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 2 Sep 92 03:34:14 GMT
From:         Bob Tinkelman <bob@CAMB.COM>
Subject:      RE: `Disconnected' remote PhoneNet dial-in processes
X-To:         NED@SIGURD.INNOSOFT.COM
X-cc:         ipmdf@INNOSOFT.COM
Newsgroups: bit.listserv.pmdf-l

Thanks for responding so quickly.

> It sounds to me like your slave jobs are chattering on the terminal port as
> they shut down. There should be no output at all between the time that the
> PhoneNet end command arrives and the session logs out completely. It therefore
> should not matter if the port gets disconnected or not since this will not
> affect the proper termination of the job.

I'm confused.  It's at the slave end that I'm seeing the disconnected
processes.  You're saying that once the slave job receives the `end'
it should always ``log off'', independent of what happens to the line.
What does that have to do with ``chattering on the terminal port''?  Is
this chattering something you picture coming from the slave computer or
going to the slave computer?

> You might want to try to connect to one of these things and see what output
> they produce. I can think of no simpler way to find out what's stuck in the
> buffers.

By that do you mean I should dial into the slave computer, log into the
PhoneNet account, and pretend to be the master end of the connection?
If so, I guess I can figure out how to do that, after making sure that
there is nothing queued at the master end for transmission.

> > The remote system is running 4.1-9 and this system is running 4.1-6.
>
> This should be the same even if you were running PMDF V2.4.

You know, I used to do just that!
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ECF_STBO%JHUVMS.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 1 Sep 92 03:52:44 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Postmaster bounces 4.1-10
X-To:         ECF_STBO@JHUVMS, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

I don't think you understand the purpose of errsendpost -- this keyword
causes a postmaster copy of the message to be generated ONLY IF the
message originator cannot receive a copy for some reason (usually because
the originator address is bogus).

We also do plan to act on your suggestions on changes to PMDF logging. We
just don't plan to make this behavior the default.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Sun, 23 Aug 92 10:21:21 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: pmdf v4.1-1 and slow delivery
X-To:         tkslen@ubvms.cc.buffalo.edu, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

Since PMDF V4.1 is more efficient in almost every way than V4.0 was
(usually performance just about doubles or better) I seriously doubt that
this phenomenon is something in PMDF itself. The first thing you should
figure out is what messages are holding in what queues and more
importantly where they are coming from. For example, if messages are
coming in from PhoneNet and not getting proper immediate processing
you may well have a cache ownership problem. There are dozens of
other possibilities, however, and the only thing that makes sense for
you to do is start looking at the specifics of the problem itself.
Poring over your configuration is likely to simply be an exercise
in frustration and will probably not get your anywhere very quickly.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Tue, 1 Sep 92 21:43:31 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject: RE: Help. list.exe going crazy?
X-To:         DMPM@DUKEMC, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

Your problem is that your homebrew channel isn't working properly. It must
remove the entries for the messages it processes from the queue cache. When
you don't remove the entries LIST (and everything else in PMDF) has no
way of knowing that the entries are gone. As such you are left with the
list of all messages that have ever been processed on the channel, and the
list will continue to grow without limit over time.

You need to either rewrite your channel to use PMDF's QU routines (this is
the way to do it that we can possibly support) for dequeuing or you can
use the OS routine os_qu_delete_outbound to delete the entries as you
process them.

The reason why I say that the QU routines are the only reasonable way to
do this is that the queue format PMDF uses is subject to change without
notice. It changed fairly substantially in PMDF V4.1 (I bet you didn't
realize this) and is very likely to change even more in the future. Programs
written to the old format sort of work because the new format is only
used in some cases and is backwards compatible. But this may not be
true in the future.

The reason why you don't always see the huge list of messages is simply
the difference between immediate processing jobs and periodic jobs.
Immediate jobs only process the messages they were queued to deal with. Older
messages are invisible in this case, so you don't see all the phantoms. But
if a periodic job runs it sees all queued messages and that's when the
huge list appears.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Organization: Indiana University of Pennsylvania
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: NetMail%"DMPM%DUKEMC.BITNET@ymir.claremont.edu"
X-VMS-Cc: IN%"info-pmdf@ymir.claremont.edu"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 29 Aug 92 08:00:42 GMT
From:         "Mark_Strawcutter" <MJSTRAW@GROVE.IUP.EDU>
Subject:      RE: (UNIVSCVM) - DMTAXM121E User MAILER not authorized to receive
              file?
X-To:         DMPM@DUKEMC
X-cc:         info-pmdf@YMIR
Newsgroups: bit.listserv.pmdf-l

>(UNIVSCVM) - DMTAXM121E User MAILER not authorized to receive file?
>
>Any idea what this is telling me?  Is it something on my side?

Not your side.  Looks like they (incorrectly) have RSCS set to reject files
to MAILER.

----------
Mark J Strawcutter                           BitNet:    MJSTRAW@IUP
Director, Systems and Communications         DNS (mx):  mjstraw@grove.iup.edu
Indiana University of Pennsylvania           Voice:     (412) 357-4000
Indiana, PA   15705                          "you can't nail jello to a tree"
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Cambridge Computer Associates, Inc.
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf"
X-VMS-Cc: TINKELMAN
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 1 Sep 92 17:07:56 GMT
From:         Bob Tinkelman <bob@CAMB.COM>
Subject:      `Disconnected' remote PhoneNet dial-in processes
X-To:         ipmdf@INNOSOFT.COM
Newsgroups: bit.listserv.pmdf-l

I often have a half dozen disconnected processes (sometimes more) from
the same remote site which dials into our node for PhoneNet msg transfer.
Nothing really goes wrong, but these disconnected processes are eating
some resources while they hang around waiting to time-out.

The scripts all end with `go' and `end' lines.  Examining, at the other
end, the di_<channel>_master.trn files shows them sending the `end'.

I vaguely remember seeing something about this a long time ago.  A bug?
A bug that was fixed in some release?

The remote system is running 4.1-9 and this system is running 4.1-6.

Thanks
--
Bob Tinkelman <bob@camb.com>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"gdha@se.alcbel.be"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 27 Aug 92 20:25:00 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: UUCP bang style addresses
X-To:         gdha@se.alcbel.be, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

The $! control sequence has nothing at all to do with UUCP paths. It
is used to extract a part of a domain specification.

The handling of bang paths is detailed in section 3.2.4.1 of the
manual (page 3-10). This is simply part of the overall strategy PMDF
uses to handle addresses; there is no special facility for handling these
sorts of addresses.

If you have a specific goal in mind (rather than the intent to use some
particular feature) please explain it in greater detail. Bang path
addresses work just like any other address format in PMDF; unless you're
trying to produce them for a UUCP connection there should be no reason
to handle them specially.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"cvm@NAUVAX.UCC.NAU.EDU"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 23 Aug 92 11:10:20 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Changing To: header on alias list
X-To:         cvm@NAUVAX.UCC.NAU.EDU, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

Use the BULLETIN channel that's provided with PMDF and BULLETIN. This is
much more efficient and clean than the approach you're trying to use.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Cambridge Computer Associates, Inc.
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: CCA::TINKELMAN
X-VMS-Cc: IN%"info-pmdf"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 3 Sep 92 21:02:56 GMT
From:         Bob Tinkelman <bob@CAMB.COM>
Subject:      RE: `Disconnected' remote PhoneNet dial-in processes
Newsgroups: bit.listserv.pmdf-l

Ned, I took your suggestion.  I modified the PhoneNet account (PMDF_xx)
temporarily, removing the DisReconnect flag, and then tried connecting
to the process myself.  Attached is the resulting [Kermit] log file
(edited only to remove the phone number and login name).  There doesn't
seem to be anything waiting to be emitted by the disconnected slave
process except for ``logged out'' msg.

The connection process is
 (1) Dial into a tcp/ip terminal server, a Bridge (now 3com) cs/100.
 (2) Connect to the VAX (called `red')
 (3) Log in as PMDF_xx

Could it be something to do with the terminal-server-to-VAX interaction?

Any ideas?









cds >
cds >d1-xxx-xxx-xxxx-L
dial tone
dialing: 1-xxx-xxx-xxxx-L...........
#3Welcome to CCA!
#4Welcome to CCA!
puffin>c red
Querying Primary Name Server...
Connecting... session 1 -- connected to red


Welcome to VMS V5.3-1

Username: PMDF_xx
Password:
    You have the following disconnected process:
Terminal   Process name    Image name
VTA2902:   PMDF_xx         RED$DUA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Connect to above listed process [YES]: Y

  PMDF_xx      logged out at  3-SEP-1992 11:48:12.74
session 1 -- disconnected f
   rom red( 140.186.064.001 )...No response
puffin>lo
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"HELMKE@CRF.CUIS.EDU"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 4 Sep 92 01:55:44 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      RE: Using PMDF to deliver printer files
Newsgroups: bit.listserv.pmdf-l

>    We have a number of small satellite VAX/VMS systems all over the
>    USA that we remotely support via dialup logins and PMDF e-mail.
>
>    We are investigating the possibility of setting up a home grown
>    implementation of something that acts like DQS, but uses PMDF
>    (dialup PhoneNet) and DELIVER instead of a DECNet connection to
>    transfer print files.  We are facing the fact that even a modest
>    file (without any graphics--just line printer ASCII of 200-1000
>    blocks) will take many minutes to transfer so we must consider a
>    data compression utility as well.
>
>    Has anyone "pushed the envelope" with PMDF and associated
>    utilities to deliver files to remote printer queues?  Any
>    suggestions for implementation (or pit falls)?

Actually several people have done things like this using PMDF and DELIVER.  For
instance, Ned had a mechanism set up which would allow him to typeset a theatre
program and then have it printed on a printer back in Oklahoma where members of
the community theatre he worked with could then pick it up.

Probably the best way to do this with DELIVER is:

   (1) Set up a command procedure which does the following:
       (a) LZW compress the file and then
       (b) mail it to an account running DELIVER on the remote system
   (2) PhoneNet delivers it to the remote system
   (3) MAIL.DELIVERY for the account on the remote system then executes a
       command procedure which does the following:
       (a) decompress the message body and then
       (b) print the resulting file

You can embed printing information into the message body or you can try using
a Comment: header and use a 1, 2, or 3 DELIVER action to extract that header.
Using the comment header is risky though.  While PMDF doesn't strip Comment:
headers other mailers sometimes do.  Also, another Comment: header my get
added along the way.

If the files may be large, then you can consider using the message
fragmentation support so as to break the message into smaller units.  By doing
this you avoid the problem whereby a phone line glitch kills the message half
way through its transmission and you then PhoneNet has to start sending the
message again from scratch.  The /MAXBLOCKS qualifier to PMDF SEND may be used
or you can use a maxblocks keyword on the PhoneNet channel itself.

It is unfortunate that MIME does not have a compression scheme since that would
have simplified your life greatly.  However, the working group did not come to
closure in time on a compression scheme.

Dan
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Sun, 23 Aug 92 21:52:43 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      RE: pmdf v4.1-1 and slow delivery
X-To:         tkslen@ubvms.cc.buffalo.edu, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> 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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU