Date : Tue, 24 May 1988 08:36:04 EDT
From : "John S. Fisher" <FISHER@CICGE.RPI.EDU>
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 CICGE.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 CICGE.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
Simtel20.ARPA. 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 Simtel20.ARPA, the normal VM/SP and
LISTSERV concepts do not apply.
Simtel20.ARPA 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,
PD:<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. PD:<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 PD:<directory>
/PDDIR PD:<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 PD:<MSDOS> --Lists all subdirectories in the MSDOS archive.
/PDDIR PD:<SIGM.*>*.* --Lists files added in the last 30 days.
/PDDIR PD:<MISC.VAXVMS>*.* 9999 --Lists VAX/VMS related files.
/PDDIR PD:<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 PD:<CPM.STARTER-KIT>UUDECODE.HEX (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, but not binary:
/PDGET NETDATA PD:<CPM.STARTER-KIT>UUDECODE.HEX (TRANSLATE
/PDGET NETDATA PD:<CPM.ARC-LBR>UNARC16.ARK (UUE
(3) The user is on some host somewhere:
/PDGET MAIL PD:<CPM.STARTER-KIT>UUDECODE.HEX (TRANSLATE
/PDGET MAIL PD:<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.
End of INFO-CPM Digest
******************************