W8SDZ@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen) (01/06/89)
Here is info on the server at RPICICGE. Notice the various options
and limitations depending on the operating system of your host.
Usenet users should use a path to the nearest backbone site that is
also on the Arpanet. Example: ucbvax!vm.ecs.rpi.edu!listserv
Another example: uunet!vm.ecs.rpi.edu!listserv
--
Keith Petersen
Maintainer of the CP/M & MSDOS archives at wsmr-simtel20.army.mil [26.0.0.74]
DDN: w8sdz@wsmr-simtel20.army.mil
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
---forwarded message---
From: "John S. Fisher" <FISHER@VM.ECS.RPI.EDU>
To: Info-Cpm@WSMR-Simtel20.Army.Mil
Subject: More up-to-date info on the server at RPICICGE.BITNET
The following is a more up-to-date collection of information about
using the server at RPICICGE.BITNET (aka VM.ECS.RPI.EDU). Two notes
first, though: For non-Bitnet users connectivity continues to be a
problem. The server uses the From: header in mail messages to derive
the return path, and it does this without the aid of a domain name
server. Hosts not in the SRI hosts tables are typically unreachable.
Also, there have been some performance problems with the gateway
between Arpanet and Nysernet (where VM.ECS.RPI.EDU is to be found).
The ability of the server to satisfy file requests has been hampered.
--------------
RPICICGE File Server Documentation and Usage Notes
The RPICICGE File Server gives users on Bitnet hosts nearly up-to-date
access to the collossal public domain software collection stored on
WSMR-SIMTEL20.ARMY.MIL. The server runs on an IBM VM/SP system and is
built on top of popular mail/file server, Revised LISTSERV. However,
since the server handles files directly from WSMR-SIMTEL20.ARMY.MIL,
the normal VM/SP and LISTSERV concepts do not apply.
WSMR-SIMTEL20.ARMY.MIL is a DEC Tops-20 system, and file naming
therefore follow Tops-20 conventions. For this server, file names
always conform , to the following layout:
diskname:<directoryname.subdirectoryname>filename.extension
The diskname identifies the physical disk device where the file is
stored. The software archives are all kept on the disk named PD.
The directoryname identifies in which archive the file is stored.
The server provides access to the following archives:
CPM -- Info-CPM software archives.
MSDOS -- Info-IBMPC software archives.
SIGM -- SIG/M software archives.
PC-BLUE -- PC-Blue software archives.
MISC -- Miscellaneous software archives.
The subdirectorynames partitions the archive into categories, and the
categories vary from archive to archive. The filename is generally
some descriptive name for the file; the extentionname indicates its
type. For example,
PD1:<MSDOS.STARTER>UUDECODE.BAS
is a BASIC source program that does uudecoding. It is located in the
STARTER (for starter-kit) subdirectory of the MSDOS archive. When
requesting files from the server you must specify the file's fully
qualified name using the Tops-20 notation.
(Note: The design of the server does not allow for getting files
at the top level directory, e.g. PD2:<CPM>CPM.CRCLST is not available.
However, since the files at the top level are generally directory
listings, the need for them is superceded by the /PDDIR command.)
Requests are sent to LISTSERV@RPICICGE.BITNET either as RFC822-style
mail, or as interactive messages. Two commands are supported by the
server. The /PDDIR command requests a directory of available files,
and the /PDDIR command requests a specific file.
*********************
The /PDDIR command. *
*********************
The /PDDIR command is used to list the names of files that match some
pattern. The command has several forms. They are:
/PDDIR
/PDDIR PD1:<directory>
/PDDIR PD1:<directory.subdirectory>filename.ext age
The first form lists the names of all the archives known to the server.
At present these are CPM, SIGM, PC-BLUE, MSDOS, and MISC. The second
form lists the names of all the subdirectories in a particular archive.
(The directory name must be one of the known archives: CPM, SIGM, etc.)
The third form lists the names of files in the archive. The age
parameter limits how old a file in the archive may be and still be
considered. If omitted, the default is 30, meaning 30 days old.
The directory name must be one of CPM, SIGM, PC-BLUE, MSDOS, or MISC.
The subdirectory, filename, and ext may include asterisks ('*') as
"wild-card" characters. The following are examples.
/PDDIR PD1:<MSDOS> --Lists all subdirectories in the MSDOS archive.
/PDDIR PD2:<SIGM.*>*.* --Lists files added in the last 30 days.
/PDDIR PD1:<MISC.VAXVMS>*.* 9999 --Lists VAX/VMS related files.
/PDDIR PD2:<CPM>UUDECODE*.* 9999 --Lists uudecode software for CP/M.
*********************
The /PDDIR command. *
*********************
The /PDGET command is used to request specific files. No pattern-
matching is allowed. The syntax for this command is as follows:
/PDGET format simtel.filename ( encoding
The format specifies how the file is to be transmitted. Allowed
values are NETDATA, PUNCH, and MAIL.
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.
The encoding specifies any special translation for the file data:
ASIS -- suitable for hosts that can receive binary data. The
file is sent exactly as it is stored on the server:
binary images of the file data. 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 to
EBCDIC. (If you are on an ASCII machine, then your
system should automatically translate to ASCII when
the file arrives.) TRANSLATE applied to a binary file
will yield trash.
If no encoding is specified, then ASIS is assumed for NETDATA, and
UUENCODE for the others.
*** Note: Users on non-IBM hosts should remember that with the
NETDATA/ASIS server defaults, binary data is put on an
EBCDIC network (viz. Bitnet). The normal action of most
non-IBM networking software is to do EBCDIC/ASCII trans-
lation on incoming data. This will render most files
from the server useless. Non-IBM users should either
use one of the other encoding options or receive the
a file without translation. (Jnet has this capability.)
In each of the following examples the user wants the UUDECODE.HEX and
the UNARC16.ARK file to download to a CP/M micro.
(1) The user is on an IBM host directly connected to Bitnet:
/PDGET NETDATA PD2:<CPM.STARTER-KIT>UUDECODE.HEX (TRANSLATE
/PDGET NETDATA PD2:<CPM.ARC-LBR>UNARC16.ARK
(2) The user is on a non-IBM host directly connected to Bitnet and can
receive Netdata files, but not binary:
/PDGET NETDATA PD2:<CPM.STARTER-KIT>UUDECODE.HEX (TRANSLATE
/PDGET NETDATA PD2:<CPM.ARC-LBR>UNARC16.ARK (UUE
(3) The user is on some host somewhere:
/PDGET MAIL PD2:<CPM.STARTER-KIT>UUDECODE.HEX (TRANSLATE
/PDGET MAIL PD2:<CPM.ARC-LBR>UNARC16.ARK (UUE
*********************
Additional remarks: *
*********************
(1) If the server is unable to satisfy a request for a file from
Simtel20 in three days, the request is rejected.
(2) The server limits /PDGET and /PDDIR request by number and by size.
The limits are adjusted periodically to regulate network load.
(3) The server refreshes its directory listings of files at Simtel20
about every two days. Therefore, there is a window during which
requests for recently deleted files are accepted by the server
and requests for recently added files are rejected.
(4) The server is EXPERIMENTAL. It is supported on an as-time-is-
available, best-efforts basis.
(5) The primary mission of the server is to support the Info-CPM
community on Bitnet. General availability will continue as
long as that mission is not compromised, and as long as disk
space, system load, and network load are not a problem.
(6) Problems regarding the service should be sent directly to
FISHER@RPICICGE, and not to anyone at Simtel20 or its associated
interest groups.