home *** CD-ROM | disk | FTP | other *** search
/ Garbo / Garbo.cdr / pc / doc_net / listserv.inf < prev    next >
Text File  |  1989-05-29  |  26KB  |  551 lines
  1. ------------------------------------------------------------------------
  2.  
  3.                 Accessing the SIMTEL20 archives from BITNET
  4.  
  5.                                                 Updated 30 March 1989
  6. ------------------------------------------------------------------------
  7.  
  8.      This document describes a method for users of systems connected to
  9. BITNET to obtain files from selected archives kept at the MILNET node
  10. WSMR-SIMTEL20.ARMY.MIL.  The information applies specifically to the
  11. file servers installed at NDSUVM1 and RPIECS (formerly RPICICGE).  (A
  12. similar service is provided to EARN by a set of servers collectively
  13. known as "TRICKLE"; those servers accept similar, but not identical,
  14. commands.)
  15.  
  16. ------------------------------------------------------------------------
  17. Background
  18. ------------------------------------------------------------------------
  19.  
  20.      The US Army maintains a huge collection of public domain (and
  21. "shareware") software and information on WSMR-SIMTEL20.ARMY.MIL, a
  22. DECsystem-20 machine running the Tops-20 operating system at White Sands
  23. Missle Range, New Mexico.  The collection covers a spectrum of
  24. interests, including files of interest to CP/M and MSDOS users.
  25.  
  26.      The collection is "open to the public"; anyone may obtain copies
  27. of the files using the Internet file transfer protocol, FTP.  The bad
  28. news is that FTP is not a protocol available over BITNET.  BITNET users
  29. can not directly obtain files from the SIMTEL20 collection.  The good
  30. news is that there are several file servers located  throughout BITNET
  31. that will accept requests for SIMTEL20 files and perform the appropriate
  32. file transfer on the requestor's behalf.  However, please understand
  33. that...
  34.  
  35.      The BITNET servers that provide access to the SIMTEL20 archives
  36.      have no affiliation with the US Army nor with White Sands Missle
  37.      Range.  Also, the BITNET servers are made available in the true
  38.      spirit of volunteerism (both of the institutions where they are
  39.      installed and of the individuals that support them) without any
  40.      outside sponsorship for the service.
  41. Also...
  42.      Due to the large number of files available, neither the archive
  43.      archive maintainers at SIMTEL20 nor the server maintainers in
  44.      BITNET can possibly attempt to validate the proper operation of
  45.      the various programs.  When a program bug is reported to an
  46.      archive maintainer, immediate action is taken to either correct
  47.      the error or remove the offending program from the archives.
  48.      Still, users must understand that archive programs are offered
  49.      AS-IS, and the archive maintainers and server maintainers
  50.      specifically disclaim any liability should these programs
  51.      malfunction or cause damage, incidental or otherwise.  When
  52.      testing ANY software, be certain that all information stored on
  53.      disk is backed-up before you start so that you can recover if files
  54.      are damaged or erased.  This is particularly true if you have a
  55.      hard disk, in which case malfunctions can be spectacularly
  56.      disasterous.
  57.  
  58.      The BITNET servers provide access to the following subset of the
  59. software archives residing at SIMTEL20:
  60.  
  61. CPM     Software and information for CP/M system users.  Contributions
  62.         are gathered from a variety of sources, including the members
  63.         of the Info-CPM electronic mail discussion group.  This archive
  64.         is updated very frequently.
  65.  
  66. MSDOS   Software and information for PC-DOS and MSDOS system users.
  67.         Contributions are gathered from a variety of sources, including
  68.         the members of the Info-IBMPC electronic mail discussion group.
  69.         This archive is updated very frequently.
  70.  
  71. PC-BLUE Software and information for PC-DOS and MSDOS system users.
  72.         The archive contains the files distributed by the PC-Blue Users
  73.         group.  New files are added as they become available.
  74.  
  75. SIGM    Software and information for CP/M system users.  The archive
  76.         contains the files distributed by the SIG/M Users group.  New
  77.         files are added as they become available.
  78.  
  79. MISC    Software and information for miscellaneous systems (mostly
  80.         large systems like IBM/370 and DEC VAX).  Contributions are
  81.         gathered from a variety of sources.
  82.  
  83.  
  84.  
  85. ------------------------------------------------------------------------
  86. SIMTEL20 path names, file names and file types
  87. ------------------------------------------------------------------------
  88.  
  89.      The Tops-20 operating system supports a hierarchical file system
  90. structure not unlike that found on Unix, Vax/VMS, and even MSDOS
  91. systems.  At SIMTEL20, the software collection is divided into
  92. individual archives by category, each with its own file system
  93. directory.  The archives are subdivided by topic into sub-directories.
  94. The following example is a typical path name for a SIMTEL20 file:
  95.  
  96.           PD:<MSDOS.STARTER>UUDECODE.BAS
  97.  
  98. Here, PD is the name of the disk where the archives reside.  (Well,
  99. actually it is an alias for a group of disks PD1, PD2, and so on.)
  100. MSDOS is the name for the archive; STARTER is a sub-directory containing
  101. generally useful programs and information.  UUDECODE.BAS is the name for
  102. one such file in the STARTER sub-directory.
  103.  
  104.      File names of files in the SIMTEL20 archives generally conform to
  105. the conventions of the target system (e.g. CP/M and MSDOS).  From the
  106. example above, UUDECODE.BAS is a uudecode program written in BASIC.
  107. (MSDOS.STARTER also contains UUDECODE.PAS and UUDECODE.C, versions of
  108. the same program written in Pascal and C, respectively.)  The model of
  109. "name.extension" should be familiar to most.  Extensions of DOC, HEX,
  110. INF and ASM are associated with ASCII text files; COM and EXE, with
  111. binary executables.  However, in an effort to reduce the online storage
  112. required by the files, and to organize software into packages, most of
  113. the files at SIMTEL20 have been through some flavor of data compaction
  114. and/or library utility.  The file extensions used for such beasts may
  115. be less familiar to some:
  116.  
  117. ARC   a collection of related files compacted and collected together
  118.       into a single package, and called an ARChive.  An un-archive
  119.       utility is needed to extract individual files from the package.
  120.  
  121. ARK   exactly the same as ARC.  ARK is used in preference to ARC in
  122.       the CP/M archives.
  123.  
  124. LBR   a collection of related files compacted and collected together
  125.       into a single package, and called a LiBRary.  An un-library
  126.       utility is needed to extract individual files from the package.
  127.  
  128. xQx   a file that has been compacted using a Huffman encoding method
  129.       known as sQueezing.  The extension is derived from that of the
  130.       original file with the letter Q substituted in the middle.  (An
  131.       ASM file that was squeezed would be stored as AQM.)  An
  132.       un-squeeze utility is needed to recover the original file data.
  133.  
  134. xZx   the same as xQx except that an LZW-variant method known as
  135.       crunching has been used.  An un-crunch utility is needed to
  136.       recover the original file data.
  137.  
  138.  
  139. Most of the software for MSDOS systems are stored in the ARC format.
  140. All four formats are used in the software for CP/M systems.  (ARK and
  141. ARC represent the same thing, but ARK is the more commonly used name.)
  142. Only a  few "first-time-user" type files (like UUDECODE.BAS) are stored
  143. in their raw form.  The section below titled "Getting Started" gives
  144. some guidance about handling them.
  145.  
  146. ------------------------------------------------------------------------
  147. Using the BITNET Servers
  148. ------------------------------------------------------------------------
  149.  
  150.      In the United States, there are two BITNET servers that provide
  151. access to the SIMTEL20 archives:
  152.  
  153.           LISTSERV@NDSUVM1   North Dakota State University.
  154.           LISTSERV@RPIECS    Rensselaer Polytechnic Institute.
  155.  
  156. --------Note--------Note--------Note--------Note--------Note-----------
  157.      In Europe, there are many EARN servers.  However, the information
  158. provided here is specifically for the BITNET servers.  The EARN servers
  159. have a similar user interface and may accept the same set of commands,
  160. but information about using them is beyond the scope of this document.
  161. The locations of the EARN servers and the principle contact person for
  162. each are:
  163.  
  164.           TRICKLE@TREARN    ("Turgut Kalfaoglu"   <TURGUT@TREARN>)
  165.           TRICKLE@IMIPOLI   ("Marco Gandolfi"     <MARCO@IMIPOLI>)
  166.           TRICKLE@BANUFS11  ("Michel Daulie"      <DAULIE@BANUFS11>)
  167.           TRICKLE@AWIWUW11  ("Gustaf Neumann"     <NEUMANN@AWIWUW11>)
  168.           TRICKLE@DB0FUB11  ("Wolfram Fassbender" <EARNIE@DB0FUB11>)
  169.           TRICKLE@EB0UB011  ("Oriol Robert"       <ZCCBORR@EB0UB011>)
  170. --------Note--------Note--------Note--------Note--------Note-----------
  171.  
  172.  
  173.      Requests may be sent to a server as RFC822-style mail.  The
  174. commands to the server must appear in the body of the message, not the
  175. Subject: line.  The server uses the From: header to determine how to
  176. address the files to be returned.  The From: header must therefore
  177. specify a valid, reachable network address from the server's point of
  178. view.  Mail received from outside BITNET, particularly from UUCP, often
  179. have unusable return addresses.
  180.  
  181.      Requests may also be sent as interactive BITNET messages if your
  182. system supports such a facility.  On an IBM system, this service is
  183. provided by the TELL command, as in
  184.  
  185.           TELL LISTSERV AT nodename  servercommand
  186.  
  187.      The server does enforce some limits on how much can be requested
  188. by whom and from where.  Requests from EARN are not accepted; they must
  189. be delivered to the nearest TRICKLE server in EARN.  For others, the
  190. server restricts how many files and how many bytes of data a user may
  191. request per day.  It also restricts how many files and how many bytes
  192. a host system may request per day.  The limits are changed on occasion, they are
  193. but they are in the neighborhood of
  194.  
  195.      3 files/user/day            10 files/host/day
  196.    100 Kbytes/user/day          300 Kbytes/host/day
  197.  
  198. There are some files that are larger than the per-day limit for a user
  199. (or host) would permit, so the server does allow the first request from
  200. a user (or host) on any given day to exceed the byte limit.  Also, the
  201. "host" in this context means what appears after the at-sign (@) in the
  202. return address.  Mailed requests that pass through a gateway usually
  203. appear to be from that gateway host, and so the server applies its host
  204. limits accordingly.
  205.  
  206. --------Note--------Note--------Note--------Note--------Note-----------
  207.      Although requests are sent to the LISTSERV address, the requests
  208. are actually processed by userid TRICKLE.  Files sent back to you will
  209. be from TRICKLE.  Do not let this mislead you, though:  Your requests
  210. must go to LISTSERV, and not to TRICKLE at either NDSUVM1 or RPIECS.
  211.  
  212.      In EARN, LISTSERV is not used, and TRICKLE does accept requests
  213. from users.  NOT IN BITNET.  Your requests must go to LISTSERV.
  214. --------Note--------Note--------Note--------Note--------Note-----------
  215.  
  216.  
  217. THE /PDDIR COMMAND
  218.  
  219. The /PDDIR command is used to list the names of files that match some
  220. pattern.  The command has several forms.  They are:
  221.  
  222.         /PDDIR
  223.         /PDDIR  PD:<directory>
  224.         /PDDIR  PD:<directory.subdirectory>filename.ext  age
  225.  
  226.      The first form lists the names of all the archives known to the
  227. server.  At present these are CPM, SIGM, PC-BLUE, MSDOS, and MISC.  The
  228. second  form lists the names of all the subdirectories in a particular
  229. archive.  (The directory name must be one of the known archives: CPM,
  230. SIGM, etc.)  The third form lists the names of files in the archive that
  231. match a particular pattern.  The age parameter limits how old a file in
  232. the archive may be and still be considered.  If omitted, the default is
  233. 30, meaning 30 days old.  The directory name must be one of CPM, SIGM,
  234. PC-BLUE, MSDOS, or MISC.  The subdirectory, filename, and ext may
  235. include asterisks ('*') a "wild-card" characters.  The following are
  236. examples.
  237.  
  238.         /PDDIR PD:<MSDOS>  --Lists subdirectories in the MSDOS archive.
  239.         /PDDIR PD:<SIGM.*>*.*   --Lists files added in the last 30 days
  240.         /PDDIR PD:<MISC.VAXVMS>*.* 9999  --Lists VAX/VMS related files.
  241.         /PDDIR PD:<CPM.*>UUDECODE*.* 9999  --Lists uudecoders for CP/M.
  242.  
  243.  
  244. THE /PDGET COMMAND
  245.  
  246. The /PDGET command is used to request a specific file.  No pattern-
  247. matching is allowed.  The syntax for this command is as follows:
  248.  
  249.         /PDGET  format  simtel.filename  encoding
  250.  
  251.      The format specifies how the file is to be transmitted.  Allowed
  252. values are NETDATA, PUNCH, and MAIL.
  253.  
  254.      NETDATA  -- suitable for transfer to BITNET hosts that can accept
  255.                  files in IBM Netdata format.
  256.  
  257.      PUNCH    -- suitable for transfer to BITNET hosts that can accept
  258.                  files but cannot decode the Netdata format.  Files
  259.                  are sent as 80-byte card-images.
  260.  
  261.      MAIL     -- suitable for transfer to hosts that can accept only
  262.                  mail or are accessible to BITNET only through gateways.
  263.                  Large files sent via mail are split into several
  264.                  smaller files that the recipient must reassemble.
  265.  
  266. If the format is omitted, NETDATA is assumed for BITNET hosts and MAIL
  267. for all others.
  268.  
  269.      The encoding specifies any special translation for the file data:
  270.  
  271.      ASIS     -- suitable for hosts that can receive binary data.  The
  272.                  file is sent exactly as it is stored on the server:
  273.                  binary images of the file data.  ASIS may be used
  274.                  only with format NETDATA.
  275.  
  276.      UUENCODE -- suitable for hosts that cannot receive binary data.
  277.                  The file is sent uuencoded.
  278.  
  279.      TRANSLATE -- suitable for any host, but only when the file actually
  280.                  represents readable text.  The file is translated to
  281.                  EBCDIC.  (If you are on an ASCII machine, then your
  282.                  system should automatically translate to ASCII when
  283.                  the file arrives.)  TRANSLATE applied to a binary file
  284.                  is treated as if UUENCODE were specified.
  285.  
  286. If no encoding is specified, then ASIS is assumed for NETDATA, and
  287. UUENCODE for the others.
  288.  
  289. --------Note--------Note--------Note--------Note--------Note-----------
  290.      In the actual archives at SIMTEL20 there are a few files stored in
  291. the top-level directory.  (For example, PD:<MSDOS>FILES.IDX is a file
  292. listing the names of all the files in the subdirecotries of the MSDOS
  293. archive.)  The design of the BITNET server does not permit access to any
  294. of these files.  However, since the files at the top-level directory
  295. generally contain directory information, the need for them is superceded
  296. by the /PDDIR command.
  297. --------Note--------Note--------Note--------Note--------Note-----------
  298.  
  299. ------------------------------------------------------------------------
  300. Getting Started
  301. ------------------------------------------------------------------------
  302.  
  303.      Before all else, something you absolutely must have available is
  304. a method for getting files from your host system to you micro computer.
  305. It would be preferable if this method included support for transferring
  306. binary files as well as normal text files.  If you do not already have
  307. a way to communicate with your host and transfer files, consider getting
  308. the appropriate Kermit implementations available from the KERMSRV file
  309. server at CUVMA.
  310.  
  311.      Once that minor detail has been addressed, then you should consider
  312. what additional utility programs you will need or that will be helpful.
  313. Most files are in an archive format, so you will need a de-archive
  314. utility or two.  You may also need a uudecode program, depending on your
  315. ability to receive binary files on your host and your ability to
  316. download binary files to you micro computer.
  317.  
  318.      This last point requires some explanation.  The server stores all
  319. files from SIMTEL20 as-is in 128 byte sector image blocks.  They are
  320. bit-for-bit identical to how they should appear on your micro computer.
  321. The server makes no attempt to interpret the files; it simply sends them
  322. on demand out through BITNET.  BITNET, though, is fundamentally an
  323. EBCDIC network, and your micro computer is fundamentally an ASCII
  324. machine.  This gives rise to two places along the path from server to
  325. micro where the file data might be misinterpreted or corrupted.
  326.  
  327.      If your host system is ASCII-based (as are most non-IBM systems)
  328. it will translate incoming BITNET files from EBCDIC to ASCII.  If your
  329. host is EBCDIC-based, your communications software will translate files
  330. you download from EBCDIC to ASCII.  But the files from the server do not
  331. contain EBCDIC data.  You must either find a way to disable the
  332. translations or encode the data in such a way that the original file
  333. can be recovered.
  334.  
  335.      There are suggestions given later for specific host machines to
  336. disable the translations.  For now assume data encoding is required.
  337. You can ask the server to send files in encoded from.  If you request
  338. encoding, the file is encoded using a technique know as uuencoding.
  339. Uuencoded data is preserved through most of the EBCDIC/ASCII
  340. translations the file might encounter.  So, all you need is a program
  341. for you micro computer that decodes a uuencoded file.
  342.  
  343.      There are several decoders available from SIMTEL20.  The only
  344. problem is how do you get the program to your micro computer.  Catch-22.
  345. Well, you can ask the server to send ASCII text files in translated
  346. form.  If you request translation, a file is first translated to EBCDIC
  347. before it is sent.  This is not recommended as a standard option since
  348. there may be some loss of information, but for getting started it may
  349. be essential.
  350.  
  351.      If you need a program for CP/M to decode uuencoded files, send the
  352. following command to the server:
  353.  
  354.         /PDGET PD:<CPM.STARTER-KIT>UUDECODE.HEX  TRANSLATE
  355.  
  356. The file contains the CP/M hex data for the program.  Download it.  Use
  357. the CP/M commands LOAD and SAVE to create an executable program.  You
  358. should end up with UUDECODE.COM, the desired program.
  359.  
  360.      If you need a program for MSDOS to decode uuencoded files, send the
  361. following commands to the server:
  362.  
  363.         /PDGET PD:<MSDOS.STARTER>UUDECODE.xxx  TRANSLATE
  364.         /PDGET PD:<MSDOS.STARTER>UUENCDEC.DOC  TRANSLATE
  365.  
  366. Replace "xxx" with either BAS, C, or PAS depending on which source
  367. language you would prefer (BASIC, C, or Pascal, respectively).
  368.  
  369.      Next, you should consider requesting which ever of the following
  370. files you feel appropriate for your micro computer system:
  371.  
  372. For PC-DOS and MSDOS machines:
  373.      PD:<MSDOS.STARTER>ARCE31C.COM       Un-archive utility.
  374.      PD:<MSDOS.STARTER>ARCE31C.DOC       ..and the documentation.
  375.      PD:<MSDOS.STARTER>UUDECODE.EXE      Compiled uudecode utility
  376.  
  377. For CP/M machines:
  378.      PD:<CPM.STARTER-KIT>DELBR11.COM     Un-library utility.
  379.      PD:<CPM.STARTER-KIT>UNARC.COM-Z80   Un-archive utility, Z-80 only.
  380.      PD:<CPM.STARTER-KIT>UNARCA.COM-8080 Un-archive utility.
  381.      PD:<CPM.STARTER-KIT>UNARC.DOC       ..and the documentation.
  382.      PD:<CPM.STARTER-KIT>UNCR-Z80.COM    Un-crunch utility, Z-80 only.
  383.      PD:<CPM.STARTER-KIT>UNCR8080.COM    Un-crunch utility.
  384.      PD:<CPM.STARTER-KIT>UNCR8080.DOC    ..and the documentation.
  385.      PD:<CPM.STARTER-KIT>USQ120.COM      Un-squeeze utility.
  386.      PD:<CPM.STARTER-KIT>USQ120.DOC      ..and the documentation.
  387.  
  388. There are many other useful utilities in these and other archive
  389. directories.  Remember, though, if you need the server to UUENCODE the
  390. files you request, you should explicitly ask for it.
  391.  
  392.      You may find two other files useful.  PD:<MSDOS.FILEDOCS>SIMIBM.ARC
  393. and PD:<CPM.FILEDOCS>SIMCPM.ARC contain one-line descriptions for many
  394. of the  other files in their respective archives.  Not all files are
  395. described, but it does contain enough valuable information to help you
  396. find other software.
  397.  
  398.  
  399. IBM System Users.
  400.  
  401. If your host is an IBM system running either VM or MVS, you can avoid
  402. the need for uuencoding.  Files received from BITNET will not be
  403. translated, since the IBM is an EBCDIC machine.  Most down-load methods
  404. support binary transfer, so you can defeat the translation that would
  405. otherwise take place there.  For example, with CMS Kermit the command
  406. SET FILE BINARY is all the is required before initiating a download.
  407. If you are using a 3270 emulator and IND$FILE for file transfers, by
  408. default no translation takes place.
  409.  
  410.  
  411. VAX/VMS Users.
  412.  
  413. If your host is a DEC VAX system running VMS, with Jnet as your network
  414. software, you can avoid the need for uuencoding.  You can tell the Jnet
  415. software to bypass the usual EBCDIC/ASCII translation, but there are a
  416. few additional steps needed before downloading a file.
  417.  
  418.     *  Receive the file with the Jnet command RECEIVE/BINARY.  The
  419.        BINARY modifier suppresses the normal EBCDIC/ASCII translation.
  420.        For the sake of discussion, assume that the file is now named
  421.        SOFTWARE.FIL.  This file, as received, is almost correct; but
  422.        there may be an error in how VMS interprets the records.
  423.  
  424.     *  Generate an FDL file for SOFTWARE.FIL using the command
  425.  
  426.           ANALYZE/RMS/FDL  SOFTWARE.FIL
  427.  
  428.     *  Edit the FDL file with the command
  429.  
  430.           EDIT/FDL  SOFTWARE
  431.  
  432.        Examine the CARRIAGE_CONTROL setting.  Change it to NONE.  Exit
  433.        from the editor.
  434.  
  435.     *  Use the edited FDL to correct carriage control interpretation
  436.        errors in the original SOFTWARE.FIL.
  437.  
  438.          CONVERT/FDL=SOFTWARE.FDL  SOFTWARE.FIL  FIXED_SOFTWARE.FIL
  439.  
  440.     *  Download the FIXED_SOFTWARE.FIL as a binary file using any
  441.        reliable means.  (For VAX Kermit, use the SET FILE TYPE BINARY
  442.        command before starting the download.)
  443.  
  444.  
  445. ------------------------------------------------------------------------
  446. Common Problems
  447. ------------------------------------------------------------------------
  448.  
  449. Q. I downloaded this program to my micro, but when I run it, my machine
  450.    hangs (or I get the message "Out of Memory" or ...).
  451.  
  452. A. Either the file became corrupted in transit (perhaps one of those
  453.    nasty EBCDIC/ASCII translations), or the file was uuencoded and you
  454.    have not decoded it.
  455.  
  456.  
  457. Q. I downloaded an archive to my micro, but the de-archive utility
  458.    would not process it.  I get messages like "File not an archive" or
  459.    "Cannot extract member".
  460.  
  461. A. Same comments as above.
  462.  
  463.  
  464. Q. I really, really need to get these special files that I absolutely
  465.    must have, but the server limits how much I can request per day.  Is
  466.    there any way I can get around these limits for this one special case
  467.  
  468. A. No.
  469.  
  470.  
  471. Q. I am trying to get a file from the (top-level of the) MSDOS
  472.    directory.  /PDDIR won't list it, /PDGET claims it can't find it,
  473.    but I know it is there.
  474.  
  475. A. It may well be there at SIMTEL20.  However, the BITNET server is not
  476.    capable of handling any request for a file from the top-level of an
  477.    archive.  Generally, though, the files stored at the top level list
  478.    the contents of the archive.  The /PDDIR command can be used to get
  479.    a directory listing.
  480.  
  481.  
  482. Q. I have been requesting this same file repeatedly.  Each time the
  483.    server tells me my request has been "queued for processing," then a
  484.    few days later it sends me a message that it has "abandoned" my
  485.    request.  Other requests it has been handling just fine.
  486.  
  487. A. The server does maintain a large "cache" of recently requested files.
  488.    Many requests are satisfied from this cache.  However, for all the
  489.    rest the server must fetch it directly from SIMTEL20 using the
  490.    Internet file transfer protocol, FTP.  "Directly" really is not
  491.    all that direct since the path between server and SIMTEL20 includes
  492.    many network segments and gateways.  To complete a transfer, an
  493.    error-free connection must be maintained for the duration of the FTP
  494.    transaction.  This is not always possible, whether it be from some
  495.    dysfunction along the path or heavy network load.  The server will
  496.    retry a failed FTP transaction, but if it continues to fail, the
  497.    server eventually gives up.
  498.  
  499.  
  500. Q. I keep sending requests to the server.  I never hear anything back.
  501.  
  502. A. The server responses in some way to everything it receives.  Your
  503.    requests may not be arriving, possibly because you are miskeying the
  504.    server's network address.  Perhaps you are sending your requests to
  505.    TRICKLE rather than LISTSERV.  Your requests may be arriving, but
  506.    with an unusable "From:" field in the mail header, so the response
  507.    never gets back to you.
  508.  
  509.  
  510. Q. Gee, this public-domain/shareware stuff is the greatest.  How do I
  511.    go about adding my own contributions?
  512.  
  513. A. Remember, the archives are actually kept at SIMTEL20.  The servers
  514.    only provide access to them.  Contributions must be sent to the
  515.    people there.  Send an electronic mail message to:
  516.  
  517.      "Keith Petersen"  <W8SDZ@WSMR-SIMTEL20.ARMY.MIL>
  518.  
  519.    Be sure to tell him what it is you have and what it is for.  After
  520.    he verifies he does not already have it, you and he can negotiate
  521.    methods for submitting the software.
  522.  
  523.  
  524. Q. Hey, I have FTP on my system.  How do I go about connecting to
  525.    either RPIECS or NDSUVM1 and fetching the SIMTEL20 files?
  526.  
  527. A. Two points about the servers have been missed.  (1) The servers are
  528.    there to provide access to the SIMTEL20 archives for people WITHOUT
  529.    FTP capability.  Users on hosts that do support FTP have the
  530.    privilege of connecting directly to WSMR-SIMTEL20.ARMY.MIL.  (2) The
  531.    servers do not actually have a complete collection of the archives;
  532.    only a varying set of recently requested files are stored locally.
  533.    If you have FTP access to the Internet, connect to
  534.    WSMR-SIMTEL20.ARMY.MIL and use anonymous login.
  535.  
  536.  
  537. Q. Who do I contact with suggestions or unsolvable problems?
  538.  
  539. A. Depending on which server you normally use:
  540.  
  541.      "John Fisher"     <FISHER@RPIECS>
  542.      "Marty Hoag"      <INFO@NDSUVM1>
  543.  
  544.    DO NOT send your comment or question about the server to the people
  545.    at WSMR-SIMTEL20.ARMY.MIL.  However, if you wish to report program
  546.    bug or something similar about a SIMTEL20 file, you may send it to
  547.  
  548.      "Keith Petersen" <W8SDZ@WSMR-SIMTEL20.ARMY.MIL>
  549.  
  550.  
  551.