[comp.os.cpm] Posting Binaries

W8SDZ@SIMTEL20.ARPA (Keith Petersen) (11/18/87)

Binaries or source code should not be posted to Info-Cpm.  Arpa/Milnet
readers should instead send a message to Info-Cpm-Request@SIMTEL20.ARPA
asking for instructions on how to use FTP to submit files to the
SIMTEL20 archives.

--Keith

kenw@noah.arc.CDN (Ken Wallewein) (11/19/87)

>>I have been asked to post the binary for interrupt driven terminal program fo
r
>>CP/M Kaypros.  What is the policy concerning such postings in this newsgroup?
>>
>>                                Jeff Wieland
>>                                abp@j.cc.purdue.edu

>Binaries or source code should not be posted to Info-Cpm.  Arpa/Milnet
>readers should instead send a message to Info-Cpm-Request@SIMTEL20.ARPA
>asking for instructions on how to use FTP to submit files to the
>SIMTEL20 archives.
>
>--Keith


** FLAME ON!!! ***

  This is a most frustrating, Arpanet-chauvinistic attitude! Only a fraction
of the people who recieve this newsgroup have the capability of performing FTP
access to the massive SIMTEL20 archives. This summer, SIMTEL20 shut down their
mail server, so that's out too... but I guess those on Arpanet don't care
about that. If they want to use SIMTEL20, fine, but DON'T go telling the rest 
of the group not to post binaries! Come ON!!!

** FLAME OFF **.

  I'm sure Keith didn't think his answer through before replying, or perhaps
it was a stock answer formulated back when things were different, or
something. He's been too generous with us, myself included, in the past. 

  However, the point needs making. I can neither submit not retrieve files 
from SIMTEL20. This is not an idle complaint - I would do both if I could.

  There _is_ a mail server on the network: listserv@rpicicge.bitnet (the
contact appears to be "John S. Fisher" <FISHER@RPICICGE.bitnet>). It has taken
over a large chunk of SIMTEL20's CPM mail service, for those who have access
to BITNET. Of course, it's not quite current and has limited "bandwidth", but
deserves a lot of support. I believe it's download-only at the moment. 

  I suggest that binary postings to the net use either HEX or UUENCODE format. 
There are public domain programs available to work with both; HEX is easier to 
get the software for, but I understand that UUENCODE does some compression.

/kenw
Ken Wallewein                                                    A L B E R T A
                                                               R E S E A R C H
kenw@noah.arc.cdn                                                C O U N C I L

bill@sigma.UUCP (William Swan) (11/20/87)

In article <KPETERSEN.12351593221.BABYL@SIMTEL20.ARPA> W8SDZ@SIMTEL20.ARPA (Keith Petersen) writes:
>Binaries or source code should not be posted to Info-Cpm.  Arpa/Milnet
>readers should instead send a message to Info-Cpm-Request@SIMTEL20.ARPA
>asking for instructions on how to use FTP to submit files to the
>SIMTEL20 archives.

Info-Cpm, fine... but what about posting to comp.os.cpm (or how about 
comp.{sources,binaries}.cpm)? Some of us out here in the net.boonies
don't have FTP access to the SIMTEL20 archives...

-- 

W8SDZ@SIMTEL20.ARPA (Keith Petersen) (11/20/87)

If the posting of binaries starts on Info-Cpm I will shut off the
Usenet and CsNet gateways from this mailing list.  There are other
ways of distributing binaries other than a mailing list.

I am the one who must wade through all the mailer rejections that are
caused by mailing list recipients exceeding their alloted disk space
and by angry system administrators who have deliberate message size
limits because they have to PAY for every byte that they receive.

The Info-Cpm mailing list handler presently has a limit of about 50k.
If binary postings start I will ask the system administrator to reduce
it to 10k.  I don't have the time to read all the rejections.

Instead of talking about posting binaries perhaps a discussion should
be started about a file server for CsNet and Usenet.  There are a
number of hosts that are on both the Arpanet and one of those two
nets.

--Keith Petersen <Info-Cpm-Request@SIMTEL20.ARPA>

FISHER@CICGE.RPI.EDU.UUCP (11/20/87)

I think it is really unfair to flame at Simtel20 and/or the internet
at large just because they have something and "you cannot get it".
The fact is that just about everything in the Simtel20 archives
(at least for CP/M) is available through alternate means.  There
are the public BBS's and the information network services and the
marketeers of public domain software collections.

Granted, those aren't quite free, but the cost is actually modest.
Mail over the networks isn't quite free, either, by the way.  You
may not see any direct chargeback for mail sent and received, but
some of us do.  And we all pay in some sense for any unnecessary
load placed on the networks.

Please do not construe my comments as "dog-in-the-manger"
(if that is the right analogy) just because I now have FTP access to
Simtel20 and you don't.  I joined this group before I had FTP and
before Simtel20 started the mail-based archive service.  I did not
think that I had any "inherient right" to be able to access the Simtel20
archives then, nor when the mail service was cancelled, nor now.

By the way, the file server at RPICICGE.Bitnet can also be addressed
via CICGE.RPI.EDU on the internet.  Eventhough targeted to service
the Bitnet Info-CPM people, mail requests from other networks are
supported as long as the server can figure out how to send back a
reply.  It won't work for everyone, but there are at least some
requests it has processed for people in UUCP-land and on mail-only
Arpanet sites.

abc@BRL.ARPA (Brint Cooper) (11/20/87)

Ken Wallewein writes:

>   This is a most frustrating, Arpanet-chauvinistic attitude! Only a fraction
> of the people who recieve this newsgroup have the capability of performing FTP
> access to the massive SIMTEL20 archives. This summer, SIMTEL20 shut down their
> mail server, so that's out too... but I guess those on Arpanet don't care
> about that. If they want to use SIMTEL20, fine, but DON'T go telling the rest 
> of the group not to post binaries! Come ON!!!
> 

Keith Peterson responds:

> I am the one who must wade through all the mailer rejections that are
> caused by mailing list recipients exceeding their alloted disk space
> and by angry system administrators who have deliberate message size
> limits because they have to PAY for every byte that they receive.
> 
> The Info-Cpm mailing list handler presently has a limit of about 50k.
> If binary postings start I will ask the system administrator to reduce
> it to 10k.  I don't have the time to read all the rejections.

It is ironic that this dialog arrived in my mailbox on "Graham-Rudman
Day."  SIMTEL20.arpa is funded by your tax dollars and mine.  The
official justification for even having CPM archives on this machine is
that there are still a number of CPM workstations in government
laboratories and offices which are made more useful and efficient (as
are their human users) by having public domain CPM software readily
available.

In various times and places, we have all heard pleadings to keep down
the volume of traffic flowing through UUCP links in order to keep down
the long distance telephone bills of the individual users.  Similarly,
we are seeing problems in internetworking to Bitnet and to the
UK community because host resources are overworked and funds are not
forthcoming to upgrade gateways.

Well, folks, the U.S. government is in the same boat as the rest of us.
Keith Peterson and many other folks on Arpanet/MILNET machines are not
paid to distribute public domain software to the world at large.  Their
kind extensions of their work time into their personal lives and time
represents a "second mile" not always noticed or appreciated.

I agree with Keith:  Servers on Bitnet and "the UUCP net" are needed to
complement SIMTEL's service.  Such a server,  APPLE2-L, runs under
something called LISTSERV at BROWNVM.  Also, a UseNet group,
comp.binaries.cpm, might be useful.  Conceivably, it could be gatewayed
with a Bitnet server.

But if the folks in the U.S. REALLY desire some governmental austerity,
they're all going to have to allow their own oxen to be gored just a
little.

Cheers,

_Brint

DISCLAIMER:  I usually don't issue these things.  However, for the
record the foregoing, and EVERYTHING ELSE I EXPRESS, are my own opinions
and my own ideas.  

bandy@well.UUCP (Andrew Scott Beals) (11/20/87)

Well, I don't know if they would let us poor old 8-bit people get
away with a newsgroup.

However, the cheapest method of distribution is still good old U.S.
Mail.  

For example, I have a "centipede" program that I wrote one weekend
years ago for my Osborne.  I've been thinking about cleaning it up
and giving it away to people, but how many folks could use it?

It seems that we shall always get the short end of the stick, so
I'd suggest that we rely on SIG/M and our local BBS sysops for
the bulk of PD programs.

I think that it should be okay to post source on the net, but binaries
are a little unwieldly.

Keith, I know that one can get UUCP for TOPS-20 systems, how about
you set up a few dialin ports and let people who want access set up
uucp accounts and turn on the server for them?  That way they pay
the shipping costs off-site and *everyone* gets access to the
SIMTEL20 archives again.

	andy
-- 
Andrew Scott Beals
bandy@lll-crg.arpa or {lll-crg,hoptoad,hplabs,apple}!well!bandy

berger@clio.las.uiuc.edu (11/22/87)

That works both ways.  If submission and acquisition of programs is
strictly via FTP, then you'll lose a good part of the program sub-
missions from the rest of the world.

			Mike Berger
			Center for Advanced Study
			University of Illinois 

			berger@clio.las.uiuc.edu
			{ihnp4 | convex | pur-ee}!uiucuxc!clio!berger

W8SDZ@SIMTEL20.ARPA (Keith Petersen) (11/22/87)

Ken, please try the file server that John Fisher is running.

[Note: In the following discussion, if you are not on BITNET
substitute the address LISTSERV@CICGE.RPI.EDU for the address shown.]

--Keith Petersen <Info-Cpm-Request@SIMTEL20.ARPA

---forwarded message---
Date: Friday, 23 October 1987  11:48-MDT
From: John S. Fisher <FISHER@CICGE.RPI.EDU>
To:   INFO-CPM@SIMTEL20.ARPA
Re:   CP/M software file server on Bitnet

I have made a few radical changes to the CP/M file server on Bitnet.
I will describe the changes first, then, for many of the newer people
on this list who never heard of the server, I'll review its use.

(1)  The server has been redesigned to use a disk "cache" for keeping
     only the most recently/frequently requested files online.  Requests
     for files not in the cache are deferred for overnight processing.
     The offline-to-online procedure is automated, but subject to
     delays; if a request cannot be satisfied in 5 days, the request
     is abandoned.

(2)  The archive is now more current than the former collection
     (which was dated 17 July 1987).  I will try to keep my server
     up to date with Simtel20, at least within a week or two.  This
     means very new files on Simtel20 will not be immediately available
     on my server, and the reverse for recent deletions.  Synchronizing
     my server with Simtel20 is a manual process I'll perform on a
     best-efforts basis.

(3)  THE SERVER IS STILL EXPERIMENTAL, AND INFORMATION ABOUT IT SHOULD
     STILL BE KEPT CONFIDENTIAL TO THIS GROUP.

(4)  The /PDDIR command is available for getting directory listings.

(5)  As before, if you have any comments, questions or problems with the
     server, direct them to FISHER@RPICICGE.BITNET (me), and not the
     Info-CPM mailing list.

*****************************************************************
*           Help information for the PDGET command.             *
*****************************************************************
     Selected portions of the SIMTEL20 public domain software
archives are available at RPICICGE.BITNET.  At present the
collections include the following directories:

     PD:<CPM.*>     -- The Info-CPM archive (CP/M machines).
     PD:<SIGM.*>    -- The SIG/M User Group archive (CP/M machines).
Planned:
     PD:<CPMUG.*>   -- The CP/M User Group archive.

Any of the files in these collections are available from the file
server LISTSERV@RPICICGE.BITNET.  The server responds to two commands.
/PDDIR requests a directory listing of files available in an archive,
and /PDGET requests a file from an archive.  The file server accepts
commands in both interactive messages or RFC822-style mail.  (On
VM and MVS Bitnet hosts, TELL LISTSERV AT RPICICGE... can be used to
send an interactive message.  Other Bitnet systems may have similar
facilities.  People on non-Bitnet systems must use the mail interface,
and must insure that the From: header represents a valid return path.)

****Note:  The server actually responds to many, many other commands,
           but none of them have anything to do with the archives.

The two commands have the following form:

      /PDGET  <format>  simtel.filename  < ( encoding >
      /PDDIR  simtel.pattern

The <...> mark things that are optional.

* "simtel.filename" specifies the name of a file to be delivered to the
    user.  Names are usually of the form "PD:<dir.subdir>name.type"

* "simtel.pattern" specifies a search pattern used in generating a
    directory listing.  The form of the pattern is like the filename
    mentioned above, but asterisks (*) may be used freely in the
    subdir, name, and type parts as wild cards (but not in the dir field.)

* "format" specifies the method of transmission to be used:

    NETDATA  -- suitable for transfer to Bitnet hosts that can accept
                files in IBM Netdata format.
    PUNCH    -- suitable for transfer to Bitnet hosts that can accept
                files but cannot decode the Netdata format.  Files
                are sent as 80-byte card-images.
    MAIL     -- suitable for transfer to hosts that can accept only
                mail or are accessible to Bitnet only through gateways.
                Large files sent via mail are split into several
                smaller files that the recipient must reassemble.
    If the format is omitted, NETDATA is assumed for Bitnet hosts
    and MAIL for all others.

* "encoding" specifies any special encoding of the file data:

    ASIS     -- suitable for hosts that can receive binary data.  The
                file is sent exactly as it is stored on my system:
                CP/M sector images, binary mostly.  ASIS may be used
                only with format NETDATA.
    UUENCODE -- suitable for hosts that cannot receive binary data.
                The file is sent uuencoded.
    TRANSLATE -- suitable for any host, but only when the file actually
                represents readable text.  The file is translated into
                character data format.
    If the encoding is omitted, files are sent ASIS if the transmission
    format is NETDATA, and UUENCODEd otherwise.

/PDDIR Examples:
================
(1)  The user is looking for the LASM program.
            /PDDIR  PD:<CPM.*>LASM.*

(2)  The user wants a listing of the full CPM collection.
            /PDDIR  PD:<CPM>

/PDGET Examples:
================
In each of the following examples the user wants the CPM.CRCLST file to
examine on his host and the UNARC16.ARK file to download to his micro,
both from the CPM collection.  Note that none of the examples have a
closing parenthesis!

(1)  The user is on an IBM host directly connected to Bitnet:
           /PDGET  NETDATA  PD:<CPM>CPM.CRCLST  (TRANSLATE
           /PDGET  NETDATA  PD:<CPM.ARC-LBR>UNARC16.ARK

(2)  The user is on a non-IBM host directly connected to Bitnet and can
     receive Netdata files:
           /PDGET  NETDATA  PD:<CPM>CPM.CRCLST  (TRANSLATE
           /PDGET  NETDATA  PD:<CPM.ARC-LBR>UNARC16.ARK  (UUE

(3)  The user is on a non-IBM host directly connected to Bitnet and can
     receive punch files:
           /PDGET  PUNCH  PD:<CPM>CPM.CRCLST  (TRANSLATE
           /PDGET  PUNCH  PD:<CPM.ARC-LBR>UNARC16.ARK  (UUE

(4)  The user is on some host somewhere:
           /PDGET  MAIL  PD:<CPM>CPM.CRCLST  (TRANSLATE
           /PDGET  MAIL  PD:<CPM.ARC-LBR>UNARC16.ARK  (UUE