HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.relusr-l
Date:         Tue, 12 Jan 1993 00:21:02 EST
From:         Lee Wolfle <WOLFLE@VTVM1.BITNET>
Subject:      211

   Valdis Kletnieks would have you believe that the maximum
number of users allowed on relay was "conveniently" chosen as
211.  Don't believe it for a moment!  211 is a prime number,
and the _only_ prime number that is exactly 12 greater than
the next lower prime number, _and_ 12 less than the next higher
prime number.

   (Of course, any of you [and I issue the challenge] can prove
me wrong.  I was just too lazy to confirm the fact of my
hypothesis.)

                                  Lee Wolfle
                                  Virginia Tech
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: RELUSR-L@NCSUVM.BITNET
X-VMS-To: IN%"RELUSR-L@NCSUVM.BITNET"
Newsgroups: bit.listserv.relusr-l
Date:         Mon, 11 Jan 1993 21:18:00 GMT
Reply-To:     CBTS8001@IRUCCVAX.UCC.IE
From:         Peter Flynn <CBTS8001@IRUCCVAX.UCC.IE>
Subject:      Re: Another Question...

>     What is the maximum amount of general users that are allowed on relay?  I
>have noticed that when relay has approximately 115 or more users, it becomes
>difficult to sign on because relay is full.

I don't think there is an overall maximum, but each channel is normally
limited to 10 people (but Ops can override this). Theoretically you
could have 999 channels (plus channel 0 and channels >1000 [Ops only])
all with 10 users, but as you have noticed, traffic limits useability.

///Peter
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Virginia Polytechnic Institute
Newsgroups: bit.listserv.relusr-l
Date:         Mon, 11 Jan 1993 11:32:51 EST
From:         Valdis Kletnieks <VALDIS@VTVM1.CC.VT.EDU>
Subject:      Re: Another Question...
              11 Jan 1993 10:07:17 EST from <RJACOBS@CCVM.SUNYSB.EDU>

On Mon, 11 Jan 1993 10:07:17 EST Rich Jacobs said:
>     Hi everyone.  It's another week and time for another question.. *smile*
>
>     What is the maximum amount of general users that are allowed on relay?  I
>have noticed that when relay has approximately 115 or more users, it becomes
>difficult to sign on because relay is full.

Well, this is  a difficult question to answer. The  maximum total number
of  users allowed  on RELAY  at one  time is  211(*). However,  there is
*also*  a "maximum  number of  users *per  server*". This  number is  by
default 12, but can be as high as 20 or more, and is set on a per-server
basis.  Thus, the maximum number of users on is mathematically:

min(211,(sum from i=1 to num_connected_servers max_user(server_i)))

Basically, add up the max_user value  for all connected relays, and take
that or 211, whichever is less...

What you're seeing is that when there  are 115 or so users on, that also
correllates to *your* relay being full.  At certain times of the day, it
is not unusual  for 5 or 6 of  the relays to account for 75%  or more of
the users  on, even when there  are 30+ relays connected.  When cornellc
and vtvm2 both have 20 users on, and uiucvmd and ndsuvm1 and yalevm each
have 15, that's 75 users right there.  You can see how things get pretty
crowded pretty quickly.  And of course, the 5 or  6 servers that account
for all the people  are (not surprisingly) also the 5  or 6 servers that
are (a) full and (b) turning people away.

/Valdis

P.S. The value of '211' was chosen mostly because it was a convenient
number to input into the hashing function used by RELAY.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: RELUSR-L@NCSUVM.BITNET
X-VMS-To: IN%"RELUSR-L@NCSUVM.BITNET"
Newsgroups: bit.listserv.relusr-l
Date:         Mon, 4 Jan 1993 16:51:00 GMT
Reply-To:     CBTS8001@IRUCCVAX.UCC.IE
From:         Peter Flynn <CBTS8001@IRUCCVAX.UCC.IE>
Subject:      Re: Another Question

Maledancer writes:

>When I access other relays though I can't signon I can browse, but why is
>it that no matter which other relay I access I get the same exact names listing
>channels, topic list, etc. that appears on Cornell relay?  It seems all the
>information is the same except the relay name.  Of course this only happens
>when the other relays are on line, and not when they are inactive.

This is normal. All relays always list all users everywhere.
That's the whole concept of it being a peered relay system.

///Peter
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Acknowledge-To: <RJACOBS@ccvm.sunysb.edu>
Newsgroups: bit.listserv.relusr-l
Date:         Mon, 11 Jan 1993 10:07:17 EST
From:         Rich Jacobs <RJACOBS@CCVM.SUNYSB.EDU>
Subject:      Another Question...

     Hi everyone.  It's another week and time for another question.. *smile*

     What is the maximum amount of general users that are allowed on relay?  I
have noticed that when relay has approximately 115 or more users, it becomes
difficult to sign on because relay is full.

     Thanks in advance.......

                             Rich Jacobs A.K.A Maledancer
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.relusr-l
Date:         Mon, 4 Jan 1993 09:55:29 EST
From:         Rich Jacobs <RJACOBS@CCVM.SUNYSB.EDU>
Subject:      Another Question

     Hi again everyone.. :)  Just want to say thanks again for all the help
with my last question I posted to the RELUSR-L.  But.... just when you thought
it was safe, I am back with another question.. *smile*

     I am at S.U.N.Y. at Stony Brook.  The only relays we are allowed to
signon to are Cornell and Buffalo.

     When I access other relays though I can't signon I can browse, but why is
it that no matter which other relay I access I get the same exact names listing
channels, topic list, etc. that appears on Cornell relay?  It seems all the
information is the same except the relay name.  Of course this only happens
when the other relays are on line, and not when they are inactive.

     Thanks in advance.

                           Rich Jacobs A.K.A. Maledancer
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"SKIPPER%MEDCOLPA.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Mon, 4 Jan 93 22:24:25 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      RE: Using BITNET (NJE) style address on outbound Email to BITNET
              sites...
Newsgroups: bit.listserv.pmdf-l

> We are a BITNET only site, but are also registerred with the NIC as
> MEDCOLPA.EDU.  Using PMDF, I have our address being rewritten to read
> user@ccc.medcolpa.edu.  This has been working quite well (after a few
> changes to the way we were registerred), until I tried to renew some
> AFD to NETSERV@PUCC.  Since NETSERV is a NJE only server, it will only
> accept mail addresses with NJE syntax (user@medcolpa) and NOT domain style
> addresses.  Is there a way to make PMDF forward a BITNET style return
> address if the outgoing mail is sent to a BITNET only site or server and
> domain style to all others.  It seems that I have seen or read something
> addressing this matter before.  If so, I would be more than willing in
> reading the manual if directed to the appropriate location.

Well, CONFIGURE.COM usually sets things up correctly.  However, you may not
have ever used CONFIGURE.COM.  (Nothing wrong with that; most ancient PMDF
sites have never had cause to run that procedure.)

Anyhow, check to see if there is a local alias on your bit_local channel;
e.g., see if it looks something like

   bit_local ...
   JNET-DAEMON  MEDCOLPA
                ^local alias


If the "MEDCOLPA.BITNET" is missing, then go ahead and add it.  Also, check
your file PMDF_ROOT:[TABLE]BITNET_DOMAINS_DRIVER.COM file (or whatever you use
to drive PMDF_ROOT:[EXE]BITNET_DOMAINS.COM) and see if you define a
BITNET_ALIAS symbol; e.g.,

   $ bitnet_alias = "MEDCOLPA"

After making any changes, be sure to recompile and reinstall your configuration
(assuming that you use a compiled configuration) and restart BN_SLAVE with the
command PMDF RESTART BN_SLAVE.

Now, if both of these items looks okay, then it might have something to do with
your entry in DOMAIN.NAMES or XMAILER.NAMES....  Let us know if this is the
case and we'll take it from there.

Dan
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: University of South Australia
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
X-VMS-Cc: CCAJR
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 12 Jan 93 16:51:46 +1030
Comments:     Warning -- original Sender: tag was CCAJR@LEVELS.UNISA.EDU.AU
From:         Rollo.Ross@LEVELS.UNISA.EDU.AU
Subject:      Empty MAILSERV list causes error message
Newsgroups: bit.listserv.pmdf-l

        I've just noticed that an empty local MAILSERV distribution list
causes PMDF to return an error message to anyone who sends a message to it.
The error message says, for example:

>The message could not be delivered to:
>
>Addressee: PACS-L-FORWARD
>Reason:
>  Illegal host/domain in address "PACS-L-EXPAND"
>  no addressees in

        While I can see some value in warning a human that a distribution
list is empty, in this case the distribution list was a redistribution of
an overseas list. It seems a bit risky to send error messages back to a
list server just because the normal ebb and flow of subscriptions to our
own list had resulted in it being empty at the time. Some list maintainers
can be trigger-happy when it comes to dropping entries from their lists!

        Our local list was set up as:

PACS-L: PACS-L-FORWARD
PACS-L-EXPAND: <PMDF_MAILSERV_MAIL_DIR:PACS-L.DIS, PACS-L-ERROR
PACS-L-REQUEST: MAILSERV
PACS-L-ERROR: POSTMASTER

        Is there some way of arranging that only the local postmaster
gets the error message in this special case of an empty MAILSERV list?
Or do I have to put a dummy address in each DIS file to make sure it
never becomes empty?

                                    Rollo Ross, Network Manager (CLW campuses)

Computer Centre,  University of South Australia, The Levels, SA 5095, Australia
Ph +61 8 302 3158 Fax 302 3385 DTE 505282622004  Rollo.Ross@Levels.UniSA.Edu.Au
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf@ymir.claremont.edu"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 9 Jan 93 01:13:58 GMT
From:         Jody Glasser <glasser@TDYCONT.COM>
Subject:      Where can I find DECUS UUCP?
Newsgroups: bit.listserv.pmdf-l

Does anyone know of an anonymous FTP site where I can get DECUS UUCP?

Jody Glasser

----------------------------------------------------------------------
##                            |\-=
## Jody Glasser          |\   ||\-=      Internet: glasser@tdycont.com
## Teledyne Controls    <)))))))))))))        CIS: 76220,2260
## Director,             |/   ||/-=         Voice: (310)820-4616 x2630
## Software Engineering       |/-=            FAX: (310)820-0183
----------------------------------------------------------------------

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"cheri.weaver@sheridanc.on.ca"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 7 Jan 93 23:47:46 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      RE: pmdf-mr
Newsgroups: bit.listserv.pmdf-l

> I am running PMDF v.4 and PMDF-MR.  I can send mail from Allin1
> to an Ultrix machine (TCP/IP Services for VMS) and it gets delivered
> with no problems.  Unfortunatley I cannot reply to the message.
> I am using sendmail on the ultrix machine and the first "from" in the
> header seems to have the replyable address but the second "from:"
> is being used and it is full of, I believe, x400 gobblygook and
> returns an error.  I can send mail from the Ultrix machine to the
> Allin1 account using what shows up on the from line.
>
> I would appreciate it if someone can give me any ideas as to how I
> should be solving the problem or point me to the right place.

Please be more specific.  Please provide a sample message (a copy of what
you see on the UNIX machine) and a copy of the bounce message (or other
error text).  Send these to service@innsoft.com.

Dan
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
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
Date:         Tue, 12 Jan 93 17:50:58 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: Header processing with NOTES channel
Newsgroups: bit.listserv.pmdf-l

The NOTES channel fully supports the headerbottom and headeromit channel
keywords; you can use those. All the caveats about stripping headers apply,
of course.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-path: uucp@mccall.UUCP
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ipmdf-newsgate@mccall.UUCP"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 7 Jan 93 18:16:25 +1200
From:         gordon@CHMEDS.AC.NZ
Subject:      New Multinet with Old PMDF - Can it be?
Newsgroups: bit.listserv.pmdf-l

Problem: old version of PMDF, new version of Multinet don't get on.

Situation: VMS 5.5, I just installed Multinet 3.1. We are still using
PMDF version 3. I'd like to upgrade, just now that isn't an option as we
haven't the money.  We might be able to later, but the problem is now.

Mail in fails. An opcom message from multinet server indicates that the server
failed, "service SMTP: abort" (that's all, apart from the PID).

The installation process requires that the file multinet:smtp_server.exe
be replaced with the PMDF-supplied version.  I did that; but its an old
.exe file, and may be built with an inappropriate version of the Multinet
libraries.  Rebuilding from the PMDF distribution screws up - it wants a
file [multinet-plus.lib]lib.olb, which of course no longer exists (its an
*OLD* version of PMDF).

The PMDF configuration file is exactly as we had for CMUTEK TCP/IP, with
the obvious change of CTCP to MTCP.

Has anyone got PMDF version 3 running with a modern Multinet? Or any
suggestions to tide things over until we can get PMDF version 4.1?

Cheers
Gordon, terribly perplexed
---
Gordon Findlay,  Computer Scientist, Christchurch School of Medicine


Mail temporarily to chchmeds@otago.ac.nz (their system works!)
From: JOHNSON@NORTHEASTERN.EDU (I am only an egg.)
Newsgroups: bit.listserv.pmdf-l
Subject: RE: immediate vs. periodic
Date: 12 Jan 93 18:58:49 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"ned@innosoft.com",IN%"ipmdf@innosoft.com"
X-VMS-Cc: JOHNSON
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT


   >There is at least one oversight in the immediate job creation logic that
   >can cause messages to slip into the queue without getting processed by
   >an immedate job. This was discussed earlier this month on info-pmdf;
   >please check the original messages on this subject for details. This
   >will be fixed in the next release.
   >
   >It is also possible that your immediate jobs are dying without doing any
   >processing; you'd have to examine your logs to see if this is happening. It
   >is also possible that processing is happening but for some reason the
   >user's mail files are temporarily unavailable. This is a very frequent
   >event on some systems. Again, you'll have to check the logs to tell the
   >specifics. You can usually tell whether or not a message has received
   >some attention by the file name: names beginning with ZZ have not been
   >processed; names beginning with ZY have had one delivery attempt; names
   >beginning with ZX have had two, and so on.

     The logs look ok, no failed deliveries I can either see or don't
understand.  The files in question are ZZ's.  Must be the bug.  As long
as I know it isn't something silly I did and I can get aroud it I'm all
set.

     Thanks.

Chris J.
N.U.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"Rollo.Ross@Levels.UniSA.Edu.Au"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 12 Jan 93 18:41:28 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: Empty MAILSERV list causes error message
Newsgroups: bit.listserv.pmdf-l

In general it seems much riskier to me to fail to warn people that they
are sending to an empty list. It seems like a great way to lose a lot of
mail. You must also remember that lots of postmaster mail is deleted without
ever being read, especially when it looks like a routine send failure of
some kind... Sending such traffic to the postmaster is therefore not an
effective solution in most cases.

It also seems to me that empty expansion lists are something that primary
list maintainers actually _do_ want to know about. True, it may be
inappropriate in some cases to return such information to the primary
list maintainer, but in other cases the primary list maintainer may need
this information to run the list effectively. The risk of the primary list
maintainer acting in an inappropriate fashion seem far less than the risks
of eliminating this information completely.

In any case, it is pretty easy to get PMDF to handle this in whatever
way you like. You can arrange for any alias to override the error return
addresses in a message. Just set things up so that the externally visible
list address sets the error return addresses to either the local
postmaster or <>. This will require another indirect file but that's no
big deal. And the bogus address on the list will eliminate the possibility
of the list ever emptying completely. The bitbucket channel can be used to
process such bogus addresses.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"MIONE%ZODIAC.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 7 Jan 93 17:34:35 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Bug in os_wake_deliver
Newsgroups: bit.listserv.pmdf-l

Yes, there's indeed a tiny window there. I've actually seen in happen once or
twice on a systems that process several thousand messages a day, especially
when certain jobs produce hundreds or thousands of expansions from a large
mailing list. The problem was minimized by some of the queue cache logic,
in that no advance listing of messages is actually created most of the time,
and as such it is quite likely that the first job with the earliest starting
time will pick up messages submitted after it begins to run.

Nevertheless, as you point out, the fix is straightforward, and we'll include
it in PMDF V4.2.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: in%"ipmdf@ymir.bitnet"
X-VMS-Cc: in%hackett
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Mon, 11 Jan 93 15:24:31 GMT
From:         The PMDF Postmaster <MAC@GVG34.GVG.TEK.COM>
Subject:      How is estimated time to send FAX calculated?
Newsgroups: bit.listserv.pmdf-l

One of my users would like to know how

      Estimated duration of the phone call:

is calculated.  I assume that a good guess is made from the size of the file
to be sent to the modem?

Bill

!-----------------------------------------------------------------------!
! Bill MacAllister    MS 8L         !  EMail:     Mac@GVG47.GVG.TEK.COM !
! The Grass Valley Group, Inc.      !                                   !
! P.O. Box 1114                     !  Telephone: 916-478-3201          !
! 13024 Bitney Springs Road         !  FAXphone:  916-478-3187          !
! Grass Valley, California 95945    !                                   !
!-----------------------------------------------------------------------!
From: NED@SIGURD.INNOSOFT.COM
Newsgroups: bit.listserv.pmdf-l
Subject: RE: Another question
Date: 12 Jan 93 01:52:54 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"xu@neuro.psycha.upenn.edu"
X-VMS-Cc: IN%"ipmdf@SIGURD.INNOSOFT.COM"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
              11 Jan 1993 16:07:22 +0000 (GMT)" <104308@netnews.upenn.edu>

This log isn't sufficiently detailed to track down the specifics of the
problem. All it says is that the attempt to open the connection failed with
some sort of temporary error. This could be a problem on the remote host, a
problem with the network, a nameserver problem, or a local host configuration
problem.

You can get more information into the log by enabling master_debug on the
utcp_local channel. You can also test your network connectivity to the
destination host by other means (like telnet, for instance).

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"wilder@NSRSKE.AGR.CA"  "Bill Wilder"
X-VMS-Cc: IN%"ipmdf@SIGURD.INNOSOFT.COM"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Tue, 12 Jan 93 21:12:14 GMT
From:         NED@SIGURD.INNOSOFT.COM
Subject:      RE: Yet another query on VMS-MAIL Linelength (but with a twist)
Newsgroups: bit.listserv.pmdf-l
              11 Jan 1993 16:17:32 -0500 (EST)"
              <00966754.5C3B43A0.16815@NSRSKE.AGR.CA>

SEND/FOREIGN from a foreign protocol interface across MAIL-11 used to work.
Unfortunately, this is no longer the case; DEC appears to have broken it
at some point along the way. It now appears to be subject to the same
constraints that have always applied to record-oriented messages. And since
foreign messages are by definition block-oriented, this means that they fail
in almost all cases.

I have described the problems with the foreign protocol interface and line
length limits in great detail in the past. I won't bore you with a repetition
of them here.

Always keep in mind that /FOREIGN is undocumented and unsupported. MAIL-11's
support for it has always been a bit hokey.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU