HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.nodmgt-l
Date:         Thu, 1 Oct 1992 03:01:00 PDT
From:         Leonard D Woren <LDW@USCMVSA.BITNET>
Subject:      Re: 300k file limit

On Wed, 30 Sep 1992 14:11:34 PDT, john riehl <RIEHL@USCVM.BITNET> said:
> On Wed, 30 Sep 1992 09:03:59 IST Hank Nussbacher said:
> >If and when the limit is changed *every* BITSEND exec will have to have
                                                              ~~~~~~~
> >its limits changed inside the EXEC

I don't understand this statement.  If BITSEND *isn't* changed, won't
the only adverse effect be that files will be sent in more sections
than necessary, and only when BITSEND is used to send them?

> >as well as many SMTP servers that limit
> >file size.  It will take a good year until everyone changes upward. :-(

Right.  But getting the SMTP limit changed isn't actually relevant to
Bitnet.  Files from one Bitnet node to another don't go through SMTP.

> >Hank
>
> the bitsend exec should be changed, but as long as nodes change the limit
> on rscs or smtp, people can send larger files.  the presence of an old
> version of the bitsend exec will not stop people from sending larger files.

I think there are very few sites (probably none in the core) who are
enforcing the 300K limit.  This is good, because I have a server that
sends out something which is >300K which be very difficult to split
up.  Not many copies have been sent out, but I haven't gotten
complaints that the file wasn't received.

> Furthermore, if it will take so long to get everyone to change, start now.
> if we delay some months or years, it will still take time to institute the
> change, so why not start the change now?  Delaying wont make the situation
> better, only increase the frustration of those hampered by the limit.
               ~~~~~~~~~~~~~~~~~~~~~~~~

I agree.  Another reason which hasn't been mentioned (recently) is
MIME.  "Mail" files may get *much* larger with MIME.  And a complete
MIME implementation provides sender-initiated-no-password-required
file transfer, since 8 bit binary may be encoded in a standard way,
and theoretically extracted by a simple user agent command.  If that's
available on the Internet, and MIME is crippled on Bitnet, then
Bitnet's demise will be hastened.

> jr
> (219 days and counting)

You'd think he's in a hurry to get out of here...  :-)


/Leonard
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Drexel University
Newsgroups: bit.listserv.nodmgt-l
Date:         Fri, 2 Oct 1992 09:59:47 EDT
From:         Richard Varenas <VARENAS@DUVM.BITNET>
Subject:      Spool Usage policy

I would like to hear from * some * other sites on how their spool space
is managed. We have a very liberal policy here where spool files get purged
after 35 days. This wasn't a technical decision of course but rather a
political one. Anyway we currently have +20,000 spool files and that's
15,000 too many for me.

The BIG problem seems to be mailing lists. We all know how active some of
them tend to be.

-Rich
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.nodmgt-l
Date:         Fri, 2 Oct 1992 10:41:24 EST
From:         TW@UMAB.BITNET
Subject:      Spool Usage policy

     We leave private mail alone for 30 days, listserv mail for 10 days.

- Tom
+----------------------------------------------------------------------------+
| "It could probably by shown by facts and figures that there is no          |
|  distinctly native American criminal class except Congress."               |
|                                                            - Mark Twain    |
| Bitnet: TW@UMAB     Internet: TW@UMAB.UMD.EDU     Phonenet: (410)328-4134  |
| SnailNet: 100 N. Green Street, Baltimore, MD  21201                        |
+----------------------------------------------------------------------------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Clarkson University
Newsgroups: bit.listserv.nodmgt-l
Date:         Fri, 2 Oct 1992 10:53:17 EDT
From:         "Richard Seifert, Jr." <MAINT@CLVM.BITNET>
Subject:      Re: Spool Usage policy

     I do a blanket purge of all spool files that are more than 14 days old.
I do make certain exceptions for people that are going to be out for extended
periods of time, as well as a few other 'political' excpetions.

Rich


Richard Seifert, Jr                    BITNET---MAINT@CLVM
Systems Programmer/Postmaster/NAd      INTERNET-MAINT@CLVM.CLARKSON.EDU
Educational Resources Center
Clarkson University
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Newsgroups: bit.listserv.nodmgt-l
Date:         Wed, 30 Sep 1992 09:03:59 IST
From:         Hank Nussbacher <HANK@VM.TAU.AC.IL>
Subject:      Re: 300k file limit
Comments: To: NODMGT-L%UGA.BITNET@ricevm1.rice.edu
              29 Sep 1992 09:55:23 EDT from <JBC%BITNIC.BITNET@ricevm1.rice.edu>

If and when the limit is changed *every* BITSEND exec will have to have
its limits changed inside the EXEC as well as many SMTP servers that limit
file size.  It will take a good year until everyone changes upward. :-(

Hank
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: University of Connecticut Computer Center
Newsgroups: bit.listserv.nodmgt-l
Date:         Fri, 2 Oct 1992 12:17:51 EST
From:         John Hammond <MAILMNT@UCONNVM.UCONN.EDU>
Subject:      Re: Spool Usage policy

   We purge files daily on the following basis:
     Listserve mail is old after 5 days
     an OUTPUT file is old after 6 days
     general file is considered old after 8 days
     PROFS mail, CMS NOTEs, or non-Listserve MAIL is old after 15 days.

   The values may change depending on the time of year.  For instance,
during the summer we may keep personal mail for 22 days, OUTPUT files
for 8 days, Listserve mail for 8 days, and general files for 10 days.
   LISTSERV mail is identified by reading a HELP file whose contents are
the result of a LIST GLOBAL command issued to a backbone LISTSERV on a
monthly basis.  If the filename of the mail file matches a LISTSERV list
name and the distribution matches the nodename of the LISTSERV and the
filetype is MAIL, we treat the file as having come from a LISTSERV list.
   MVS output can be identified by its filetype of OUTPUT.
   PROFS mail and CMS NOTEs can be identified by their filetype.  In the
case of PROFS it is the nodename in the case of CMS NOTEs it is NOTE.
The assumption about the filetype of MAIL may change depending on how
SMTP and MAILER are configured.
Newsgroups: bit.listserv.nodmgt-l
From: schafer@is.rice.edu (Richard Alan Schafer)
Subject: Re:      Spool Usage policy
Organization: Rice University
Date: Fri, 2 Oct 1992 17:54:15 GMT

We do two things:  

1. Attempt to recognize email and print it for campus hardcopy mail delivery
   after 7 days. (The user can change that number from 0 to 30.)  When
printed,
   the listing includes a mention of any non-mail files found.

2. Purge any spool file over 30 days old.
-- 
Richard
From: B19141@ANLVM.CTD.ANL.GOV (Barry Finkel)
Newsgroups: bit.listserv.nodmgt-l
Subject: Peru and Iceland
Date: 5 Oct 92 15:43:35 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

I few weeks ago Henry Nussbacher wondered about unconnected sites in Peru
and Iceland.   As part of my BITNET2 TOPOLOGY file project, I am currently
reviewing all of the sites that I consider unconnected.  I have not yet
finished my study, which will appear as a new page at the end of my file.
I will send an updated BITNET2 TOPOLOGY file to NETSERV as soon as I can do
some rearranging of the Paris pages, where there has been some reorganization
per the 9211 database.  My file already has information on unconnected nodes
at connected sites.

The reason for this note is that I found one interesting site - Southeast
Missouri State University, nodename SEMOVM.  Its neighbor MIZZOU1 routes
traffic via non-BITNET node SEMO.  Node SEMOVM is not defined at SEMO.  If
the nodename for the site is really SEMO, then the BITEARN database should
be changed.  What would happen if another BITNET site defined SEMO as one of
their nodenames!!
----------------------------------------------------------------------------
Barry S. Finkel
Computing and Telecommunications Division
Argonne National Laboratory               BITNET:   B19141@ANLVM
9700 South Cass Avenue                    Internet: B19141@ANLVM.CTD.ANL.GOV
Building 221, Room B223                   Phone:    (708) 252-7277
Argonne, IL   60439-4844                  Facsimile:(708) 252-5983
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.nodmgt-l
Date:         Fri, 2 Oct 1992 10:40:42 EST
From:         TW@UMAB.BITNET
Subject:      Spool Usage policy

+----------------------------------------------------------------------------+
| "It could probably by shown by facts and figures that there is no          |
|  distinctly native American criminal class except Congress."               |
|                                                            - Mark Twain    |
| Bitnet: TW@UMAB     Internet: TW@UMAB.UMD.EDU     Phonenet: (410)328-4134  |
| SnailNet: 100 N. Green Street, Baltimore, MD  21201                        |
+----------------------------------------------------------------------------+
From: OPRNAD@SAUPM00.BITNET (Iyad A.M. Al-Bukhari)
Newsgroups: bit.listserv.nodmgt-l
Subject: UNEDO
Date: 6 Oct 92 21:56:23 GMT
Organization: King Fahd University of Petroleum and Minerals, S.A.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Acknowledge-To: <OPRNAD@SAUPM00.BITNET>

Dear folks,
did anybody hear about UNEDO dBases or networks ?
Please can you send any information about it or refer me to someone who
knows.
Thanks for any help you offer........

------------------------------------------------------------------------
 BEST REGARDS
  Node Administrator of GulfNet at KFUPM
  Iyad A. M. Al-Bukhari               E-Mail : OPRNAD @ SAUPM00
  P.O.Box 773 Dhahran 31261                    OPRIAB @ SAUPM00
  K.F.U.P.M.                          Tel.#  : (966-3) 860-3917 Off.
  Saudi Arabia                                 (966-3) 860-8828 Res.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Virginia Polytechnic Institute
Newsgroups: bit.listserv.nodmgt-l
Date:         Wed, 30 Sep 1992 13:02:48 EDT
From:         Valdis Kletnieks <VALDIS@VTVM1.CC.VT.EDU>
Subject:      Re: 300k file limit

On Wed, 30 Sep 1992 09:03:59 IST Hank Nussbacher said:
>If and when the limit is changed *every* BITSEND exec will have to have
>its limits changed inside the EXEC as well as many SMTP servers that limit
>file size.  It will take a good year until everyone changes upward. :-(

All the more reason to get started now... ;)

                                  Valdis Kletnieks
                                  Computer Systems Engineer
                                  Virginia Polytechnic Institute
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: NODMGT-L@nic.SURFnet.nl, xmailer@nic.SURFnet.nl
Newsgroups: bit.listserv.nodmgt-l
Date:         Thu, 1 Oct 1992 14:19:58 CET
From:         Hans-Ulrich Giese <U001212@NIC.SURFNET.NL>
Subject:      new/del nods for 9211
Comments: To: xmailer@nic.SURFnet.nl, NODMGT-L@nic.SURFnet.nl

friends,

it's again time for new tables, so here comes the list of new/del
nodes for 9211 :

new nodes:
ACADEM01 0713 MX BITNET
UTPVM1   2052 PA BITNET
IUAZURE  0794 US BITNET
LBDRSCS  0799 US BITNET
NIHCOCC  0817 US BITNET
NIHOD31E 0833 US BITNET
PSUBEH1  0914 US BITNET
PSUEDVAX 0992 US BITNET
PSULEPSJ 1296 US BITNET
PSULEPS5 1660 US BITNET
RIGEL    1661 US BITNET
TAHOMA   1686 US BITNET
TCUFVMS  1745 US BITNET
WISCPS   2061 US BITNET
CNEIPH51 0112 CH EARN
DHDIBMIP 0204 DE EARN
EARNCC   0351 FR EARN
IRMICMAT 0467 IT EARN
IRMRETI  0623 IT EARN
SUYARS   0712 SU EARN

deleted nodes:
BKNLVMS  BNLVMA    BNLVMXA   BUCKNELL  CGEHCU61  CORNELLE  CORNELLF
DBNPIB5  DHDIBM1B  DM0MPB51  FRORL01   GBGBOX    IPDUNIV   PRATT
PSULEPSI PSULEPSR  QCVAX     SFBSYS    TUFTS     UGACDC1   UGA205
UTORDAIS VPIVAX6   VTELLIPS  VTHOBBES  VTNFNITY  VTYR
From: B19141@ANLVM.CTD.ANL.GOV (Barry Finkel)
Newsgroups: bit.listserv.nodmgt-l
Subject: Traffic From Unknown Nodes
Date: 2 Oct 92 20:59:59 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

During September we logged at ANLOS NJE traffic from the following NJE nodes
that are not defined to BITNET:
       BSCVM     ???
       NSCL01    ???
       UTCHPC    ???
       CUCHMS    (connected to CUCHEM)
       CYCVAX    (part of MSUNSCL cluster)
       VIXEN     (part of MSUNSCL cluster)
       GALLUA1   (connected to GALLUA)
       UCLAC1    (part of UCLACH cluster)
       UCLAC2    (part of UCLACH cluster)
       UCLAC3    (part of UCLACH cluster)
----------------------------------------------------------------------------
Barry S. Finkel
Computing and Telecommunications Division
Argonne National Laboratory               BITNET:   B19141@ANLVM
9700 South Cass Avenue                    Internet: B19141@ANLVM.CTD.ANL.GOV
Building 221, Room B223                   Phone:    (708) 252-7277
Argonne, IL   60439-4844                  Facsimile:(708) 252-5983
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.nodmgt-l
Date:         Tue, 29 Sep 1992 18:11:25 +0100
From:         Eric Thomas <ERIC@SEARN.BITNET>
Subject:      Re: 300k file limit
              29 Sep 1992 10:00:45 EDT from Node Management <NODMGT-L@UGA>

EARN never had any formal file size  limit, much to my chagrin. However I
did  manage to  get *recommendations*  on file  sizes approved,  and with
easily configurable line monitors it ended  up being enforced at a number
of major hubs. We did not purge files unless they were unreasonably large
(say, 10M or more while the limit  was 780k); we just held them until the
weekend. But when I see a site behind a 56k line with an automatic purger
for files larger than 300k, I really wonder how far bureaucracy can go in
creating problems which need not exist.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.nodmgt-l
Date:         Fri, 2 Oct 1992 15:56:00 PDT
From:         Michael Stein <CSYSMAS@UCLAMVS.BITNET>
Subject: RE: Spool Usage policy

> On Fri, 2 Oct 1992 18:06:00 -0300 Alberto Courrege Gomide said:
> >
> >One of the NAD's here in Brazil wrote a routine for IBMs that returns
> >the mail to the sender after 12 days. It works very well.
> >--
>
> PLEASE PLEASE PLEASE !!!!!!!!
>
> If the above function is still working - KILL IT !!!!!!
>
> I have enough to do without handling returned mail from someone who is
> either on vacation or too lazy to manage their correspondence.
>
> Just purge the stuff or something, don't clutter the net, my mailbox,
> or my system spool with 'dead mail'.

It's worse than just some extra bandwidth usage.  Two of these
could (WILL!) keep each other busy send the same message back and
forth every 12 days...

There isn't a TTL field in E-mail!
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.nodmgt-l
Date:         Tue, 29 Sep 1992 11:45:30 PDT
From:         john riehl <RIEHL@USCVM.BITNET>
Subject:      Re: 300k file limit

well, let me spew  $.02:

I agree that 300k is retentive, but with caveats:

1. there are still sites out there that use 9.6k lines.  3 of my links
   are still that way.  the way that i am getting them to upgrade is
   to face them with the fact that i am dropping support for their lines.
   this takes time. I dont know how many sites use this type of speed.
   given the proliferation of internet, i suspect the number is relatively
   small.

2. how many sites would have a problem with a larger limit?  just because
   you only have a 9600 baud line doesnt mean you cant support an amount
   larger than 300k.  In my case, two of the three links are 'very busy'.
   average time in queue for a file (fifo) over 24 hours seven days is
   twelve minutes for one link, 34 for the other.  if the larger file
   size increases traffic overall (unlikely to be causal), there could
   be a problem.  if this just changes bucket size, no problem.

3. are there sites where other limitations affect the size?  a few of the
   sites to which i connect are microvaxes/vaxes, which have had system
   failures caused by the sending of a large file (5 megabyte). I suspect
   there are, but i suspect these could still handle a larger size than
   300k.

fyi, i enforce a 37,500 line limit.  i have had problems with someone
who would repetitively send files up to 276000 lines (about 37M), in addition
to aforementioned problems.  note that these are orders of magnitude past
what eric suggested.

transmission technology changes are not the only reason for the advancement
of the limit, but topology changes also are.  mail from arizona to princeton
no longer goes through ucla and ucbcmsa.  the ring has shortened the routes,
decreasing the amount of traffic intermediate nodes need to carry.  ucbcmsa
no longer handles east bound usc area traffic and so forth.  by cutting out
middlemen, the aggregate amount of work for a set of files to be transmitted
has been decreased.  thus, more resources become available for other tasks.

okay, tell me i'm wrong.

jr
(john riehl)
(220 days and counting)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.nodmgt-l
Date:         Tue, 29 Sep 1992 21:47:17 +0100
From:         Eric Thomas <ERIC@SEARN.BITNET>
Subject:      Re: 300k file limit
              29 Sep 1992 11:45:30 PDT from Node Management <NODMGT-L@UGA>

On Tue, 29 Sep 1992 11:45:30 PDT john riehl <RIEHL@USCVM> said:

>1. there are  still sites out there  that use 9.6k lines. 3  of my links
>   are still that way.

I understand that.  For the record, the  site I am most  worried about is
behind a 56k line which just reported  a queue of 1 file in one direction
and 0 in the other.

>2. how many sites would have a problem with a larger limit? just because
>   you only have a 9600 baud line doesnt mean you cant support an amount
>   larger than 300k.

The problems with large files have been  described to death in the memo I
mentioned. There are 3 major problems:

1. This was  mostly before multi-streaming was available.  While the huge
   file is being sent, mail is  not making it through. No longer relevant
   (people still running RSCS V1 get what they deserve).

2. For  any given  line, there  is a file  size for  which you  stand 90%
   chances  of getting  a non-recoverable  error  in the  middle of  your
   transmission and having  to restart from the beginning  later on. With
   the 9.6k international analog lines we  were using, this file size was
   somewhere  around 20-50k  records. With  high-speed digital  lines and
   TCP,  this is  no longer  relevant, but  then not  everyone uses  that
   technology (in particular, the EARN line to Poland goes down dozens of
   times  a day,  for  several seconds).  Files  which are  statistically
   unable to cross the link must indeed be removed, but I seriously doubt
   300k files fall into this category in the US.

3. Then there is the problem that,  while the big file is being sent, the
   stream for  "large" files is  still being  held. Running 7  streams in
   parallel  on a  9.6k line  is not  practical. People  with "reasonably
   large"  files get  to  wait hours  behind the  50k  records file.  One
   solution is  to use  LMON to  hold files until  the night  or weekend,
   based on the size.

In any case, purging a file without giving it a chance is not something I
consider  legitimate,  unless  it   falls  into  the  "statistically  not
transmittable" category  and wastes precious  bandwidth, or of  course if
some idiot sent so many copies that your spool is near full.

>3. are there sites where other limitations affect the size? a few of the
>   sites to which i connect  are microvaxes/vaxes, which have had system
>   failures caused by the sending of a large file (5 megabyte).

I assume  these are MicroVAX II's  - they come  with a grand 70M  of disk
space. In any case  the problem is most probably due  to the total amount
of "spool" space, rather than the actual file size.

>fyi, i enforce a 37,500 line limit.

This is  not unreasonable  at all  for 9600bps lines.  I would  hope this
doesn't affect files transiting the core, though.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Portland Community College
Newsgroups: bit.listserv.nodmgt-l
Date:         Fri, 2 Oct 1992 14:43:03 PDT
From:         "Russell N. Hathhorn, VM Systems Support" <SYSMAINT@PCCVM.BITNET>
Subject:      RE: Spool Usage policy

On Fri, 2 Oct 1992 18:06:00 -0300 Alberto Courrege Gomide said:
>
>One of the NAD's here in Brazil wrote a routine for IBMs that returns
>the mail to the sender after 12 days. It works very well.
>--

PLEASE PLEASE PLEASE !!!!!!!!

If the above function is still working - KILL IT !!!!!!

I have enough to do without handling returned mail from someone who is
either on vacation or too lazy to manage their correspondence.

Just purge the stuff or something, don't clutter the net, my mailbox,
or my system spool with 'dead mail'.

+---------------------------------------------+-------------------------------+
|   Russell N. Hathhorn                       |  Bitnet: SYSMAINT@PCCVM       |
|   VM Systems Programmer/Analyst             |  Compu$erve: 76636,1036       |
|   Portland Community College                |  Voice: (503) 244-6111 x 4705 |
|   12000 S. W. 49th Avenue                   |  Fax:   (503) 324-7010        |
|   Portland, Oregon  97219-0990              |  "     Just say NO to OCO   " |
+---------------------------------------------+-------------------------------+
| "No free man shall ever be debarred the use of arms... The strongest reason |
|  for people to retain the right to keep and bear arms is, as a last         |
|  resort, to protect themselves against tyranny in government."              |
|  Thomas Jefferson - Proposal Virginia Constitution, June 1776               |
|  Thomas Jefferson Papers, 334 (C. J. Boyd, Ed., 1950).                      |
+-----------------------------------------------------------------------------+
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.nodmgt-l
Date:         Tue, 29 Sep 1992 10:00:45 EDT
From:         Jim Conklin <JBC@BITNIC.BITNET>
Subject:      Re: 300k file limit

Eric,
  Does EARN still have the 300KB file limit?
                                            Jim

P.S.:  I had passed your earlier note to the CREN TAC, and they've been
debating the issue, also.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.nodmgt-l
Date:         Fri, 2 Oct 1992 16:33:13 EDT
From:         Scott Hammer <SCOTH@WMVM1.CC.WM.EDU>
Subject:      Re: Spool Usage policy

On Fri, 2 Oct 1992 09:59:47 EDT Richard Varenas said:
>I would like to hear from * some * other sites on how their spool space
>is managed. We have a very liberal policy here where spool files get purged
>after 35 days. This wasn't a technical decision of course but rather a
>political one. Anyway we currently have +20,000 spool files and that's
>15,000 too many for me.
>
>The BIG problem seems to be mailing lists. We all know how active some of
>them tend to be.
>
>-Rich
>
Here at WM, we're still running VM/SP, with its 9900 spool file limit.  Due
to this limit, we enforce the following limits on users:

         Console logs are purged after  7 days
         E-Mail files are purged after 14 days
         Other files are purged after  30 days

This seems to work ok for us.  Users don't gripe (too much) and we seldom
carry any more than 4000 spool files at a time

Scott Hammer
VM Systems Engineer
College of William and Mary
(804) 221-2971  BITNET SCOTH@WMVM1   Internet: scoth@wmvm1.cc.wm.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU