The issue of maximum file size is not on the agenda for the Sept 22 CREN
Board meeting,  as there is no specific recommendation to present to the Board.
There was concern expressed by member(s) of CREN's Technical Advisory Committee
(I don't remember how many, or whether it was expressed at a meeting or in
mail) about the impact of such a change on those at the end of slow, and
sometimes packet-based, lines, and there has been no recommendation from the
CREN TAC (or from others that I recall, though I may have forgotten) to
present to the Board.
  A clear agreement as to both the desirability and the specifics of
any recommendation is necessary in order for board action.
 Is a discussion on NODMGT-L appropriate?  I believe, personally, that LSTOWN-L
may be too small a forum, though I may be incorrect.
  CREN TAC, do you care to enter the fray?
                                          Jim
 
On Wed, 16 Sep 1992 10:50:24 +0200 you said:
>A number of people are leading a "why stay on BITNET" campaign, and again
>the stupid 300k limit is being used  for this purpose. Will this issue be
>addressed at the next board meeting?
>
>  Eric
>
>*---------------------- Original message follows -----------------------*
>
>Eric Thomas <[log in to unmask]> writes:
>
>> Try FTP-ing  something from anywhere  in Europe  to Germany and  you will
>> understand immediately.  We're talking about  a dozen retries to  get the
>> package you wanted, and each time over a hundred keystrokes. Of course if
>> you only FTP locally, or from  dedicated machines on the T3 backbone, you
>> may never have noticed  how convenient FTP is if the line  is just a tiny
>> bit unstable or overloaded.
>
>  While I've never tried moving a file between two European hosts, I can
>say that performance has been very good between those hosts and my system
>here in the US.
>
>> FTP can't even  transfer a VMS saveset unless both  systems run Multinet.
>> SEND/FILE/VMSDUMP works.
>
>  I beg to differ. The homebrew FTP client and server I run on my VAX handle
>this format quite well (they're written to the public specification developed
>by the TGV (MultiNet) folks. I believe that CMU/TEK and several other TCP's
>support this format as well.
>
>  As you've pointed out, /VMSDUMP is a proprietary format of the Jnet software
>and they aren't to eager to give the specification out. Before anyone points
>out (incorrectly) that VMS BACKUP is a proprietary format, and thus the Jnet
>bit doesn't matter, I'll say that I can read and write VMS BACKUP savesets on
>VMS (obviously), RSTS/E (also by DEC), Unix (by BBC) and MS-DOS (by me). These
>systems can also run TCP/IP (except RSTS/E, the development work isn't done
>yet).
>
>> SENDFILE is  limited to 4G  columns, or maybe 2G,  I'd have to  check the
>> code carefully, who  cares anyway.
>
>  True, who cares? The maximum BITNET file size is 300K, which is smaller than
>most GNU software these days. I also get my BITNET files delivered to me at
>the lightning fast speed of over nine thousand bits per second! With FTP there
>is no limit on file size and they arrive over a 56Kb line.
>
>  Yes, SENDFILE has its advantages. However, these things are being developed
>for Internet hosts (possibly by BITNET users who miss them). Just last week I
>retrieved a version of an RFC-compliant SEND program. While hosts that support
>it are scarce at the moment, all of our (SPC) hosts will, and I expect it to
>catch on. Likewise for sender-controlled file transfer.
>
>> I am on BITNET and I can TELNET around. I must have missed something.
>
>  But that's an Internet service. Having BITNET doesn't affect it at all.
>
>Nick Laflamme <[log in to unmask]> writes:
>
>> If I use FTP to retrieve a package, I can't do anything with that
>> session until the file is retrieved.  If there's a slow TCP/IP link
>> between me and the FTP server, that can take a while, leaving me to
>> twiddle my thumbs unless I'm using a multi-tasking OS, which excludes
>> CMS for now.
>
>  Way back when we ran VM/370 and later VM/SP3, we had a package called
>"screen" (I think) which would let you flip between various virtual sessions
>by using one of the unused function keys. With something like that it should
>be easy to start up a background FTP session. I can't see such a useful util-
>ity not being ported to newer versions of the operating system.
>
>        Terry Kennedy           Operations Manager, Academic Computing
>        [log in to unmask]     St. Peter's College, Jersey City, NJ USA
>        [log in to unmask]    +1 201 915 9381