grinberg@bimacs.BITNET (Dennis Grinberg) (08/21/89)
A few weeks ago a bunch of Borland utilities were posted. The only ones that we received were the hercules and vga256 drivers. We are therefore missing the font editor, a description of creating BGI drivers, and maybe something that I've already forgotten. If someone could please send these things, I would greatly appreciate it. (ao@infovox.se - thanks, but my mail to you bounced) Thanks in advance, -- Dennis Grinberg, Math & CS Department, Bar-Ilan University, Ramat-Gan ISRAEL BITNET: grinberg@bimacs.bitnet INTERNET: grinberg@bimacs.biu.ac.il CSNET: grinberg%bimacs.bitnet%cunyvm.cuny.edu@csnet-relay ARPA: grinberg%bimacs.bitnet@cunyvm.cuny.edu UUCP: ...!uunet!mcvax!humus!bimacs!grinberg SNAILNET: Dennis Grinberg, 13 Hava Lutzki St., Rehovot, ISRAEL
w8sdz@smoke.BRL.MIL (Keith Petersen) (08/21/89)
In article <1046@bimacs.BITNET> grinberg@bimacs.BITNET (Dennis Grinberg) writes: >A few weeks ago a bunch of Borland utilities were posted. The only ones >that we received were the hercules and vga256 drivers. We are therefore >missing the font editor, a description of creating BGI drivers, and >maybe something that I've already forgotten. The entire Borland BGI package is available from SIMTEL20. You can order the files you need from your nearest TRICKLE server. The files are in the PD1:<MSDOS.BORLAND> directory. Keith -- Keith Petersen Maintainer of SIMTEL20's CP/M, MSDOS, and MISC archives Internet: w8sdz@WSMR-SIMTEL20.Army.Mil [26.2.0.74] Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
grinberg@bimacs.BITNET (Dennis Grinberg) (08/24/89)
>The entire Borland BGI package is available from SIMTEL20. You can >order the files you need from your nearest TRICKLE server. The files >are in the PD1:<MSDOS.BORLAND> directory. > >Keith Unfortunately there are still many of us out there in net land (or should I say net world?) that can't remote ftp to anything except the coumputer in the next room. How would I go about finding my nearest TRICKLE server? What is a TRICKLE server? Dennis (P.S. this was not a flame!! thanks for the info!!) -- Dennis Grinberg, Math & CS Department, Bar-Ilan University, Ramat-Gan ISRAEL BITNET: grinberg@bimacs.bitnet INTERNET: grinberg@bimacs.biu.ac.il CSNET: grinberg%bimacs.bitnet%cunyvm.cuny.edu@csnet-relay ARPA: grinberg%bimacs.bitnet@cunyvm.cuny.edu UUCP: ...!uunet!mcvax!humus!bimacs!grinberg SNAILNET: Dennis Grinberg, 13 Hava Lutzki St., Rehovot, ISRAEL
conway@hpdtl.HP.COM (Daniel F. Conway) (09/01/89)
grinberg@bimacs.BITNET (Dennis Grinberg) writes: | How would I go about finding my nearest | TRICKLE server? What is a TRICKLE server? I'll second the request. I've never seen any mention of this on the net. | Dennis | | (P.S. this was not a flame!! thanks for the info!!) Likewise. Dan Conway dan_conway@hplabs.hp.com
w8sdz@smoke.BRL.MIL (Keith Petersen) (09/03/89)
>| How would I go about finding my nearest >| TRICKLE server? What is a TRICKLE server? TRICKLE is the BITNET file server. If your host is on the Internet you should use FTP direct to SIMTEL20. It is much faster than netmail and places a lot less load on the network and host resources. In the information below if you are NOT on BITNET you should use the address listserv@vm1.nodak.edu, or if your mailer requires bang paths then use vm1.nodak.edu!listserv. Usenet readers may get to the server by including your nearest backbone site that is also on the Internet. See my signature for examples. One path that works (but may be expensive for your host because uunet charges for data it transfers) is: uunet!vm1.nodak.edu!listserv. ------------------------------------------------------------------------ Accessing the SIMTEL20 archives from BITNET Updated 28 April 1989 ------------------------------------------------------------------------ This document describes a method for users of systems connected to BITNET to obtain files from selected archives kept at the MILNET node WSMR-SIMTEL20.ARMY.MIL. The information applies specifically to the file servers installed at NDSUVM1 and RPIECS (formerly RPICICGE). (A similar service is provided to EARN by a set of servers collectively known as "TRICKLE"; those servers accept similar, but not identical, commands.) ------------------------------------------------------------------------ Background ------------------------------------------------------------------------ The US Army maintains a huge collection of public domain (and "shareware") software and information on WSMR-SIMTEL20.ARMY.MIL, a DECsystem-20 machine running the Tops-20 operating system at White Sands Missle Range, New Mexico. The collection covers a spectrum of interests, including files of interest to CP/M and MSDOS users. The collection is "open to the public"; anyone may obtain copies of the files using the Internet file transfer protocol, FTP. The bad news is that FTP is not a protocol available over BITNET. BITNET users can not directly obtain files from the SIMTEL20 collection. The good news is that there are several file servers located throughout BITNET that will accept requests for SIMTEL20 files and perform the appropriate file transfer on the requestor's behalf. However, please understand that... The BITNET servers that provide access to the SIMTEL20 archives have no affiliation with the US Army nor with White Sands Missle Range. Also, the BITNET servers are made available in the true spirit of volunteerism (both of the institutions where they are installed and of the individuals that support them) without any outside sponsorship for the service. Also... Due to the large number of files available, neither the archive archive maintainers at SIMTEL20 nor the server maintainers in BITNET can possibly attempt to validate the proper operation of the various programs. When a program bug is reported to an archive maintainer, immediate action is taken to either correct the error or remove the offending program from the archives. Still, users must understand that archive programs are offered AS-IS, and the archive maintainers and server maintainers specifically disclaim any liability should these programs malfunction or cause damage, incidental or otherwise. When testing ANY software, be certain that all information stored on disk is backed-up before you start so that you can recover if files are damaged or erased. This is particularly true if you have a hard disk, in which case malfunctions can be spectacularly disasterous. The BITNET servers provide access to the following subset of the software archives residing at SIMTEL20: CPM Software and information for CP/M system users. Contributions are gathered from a variety of sources, including the members of the Info-CPM electronic mail discussion group. This archive is updated very frequently. MSDOS Software and information for PC-DOS and MSDOS system users. Contributions are gathered from a variety of sources, including the members of the Info-IBMPC electronic mail discussion group. This archive is updated very frequently. PC-BLUE Software and information for PC-DOS and MSDOS system users. The archive contains the files distributed by the PC-Blue Users group. New files are added as they become available. SIGM Software and information for CP/M system users. The archive contains the files distributed by the SIG/M Users group. New files are added as they become available. MISC Software and information for miscellaneous systems (mostly large systems like IBM/370 and DEC VAX). Contributions are gathered from a variety of sources. ------------------------------------------------------------------------ SIMTEL20 path names, file names and file types ------------------------------------------------------------------------ The Tops-20 operating system supports a hierarchical file system structure not unlike that found on Unix, Vax/VMS, and even MSDOS systems. At SIMTEL20, the software collection is divided into individual archives by category, each with its own file system directory. The archives are subdivided by topic into sub-directories. The following example is a typical path name for a SIMTEL20 file: PD:<MSDOS.STARTER>UUDECODE.BAS Here, PD is the name of the disk where the archives reside. (Well, actually it is an alias for a group of disks PD1, PD2, and so on.) MSDOS is the name for the archive; STARTER is a sub-directory containing generally useful programs and information. UUDECODE.BAS is the name for one such file in the STARTER sub-directory. File names of files in the SIMTEL20 archives generally conform to the conventions of the target system (e.g. CP/M and MSDOS). From the example above, UUDECODE.BAS is a uudecode program written in BASIC. (MSDOS.STARTER also contains UUDECODE.PAS and UUDECODE.C, versions of the same program written in Pascal and C, respectively.) The model of "name.extension" should be familiar to most. Extensions of DOC, HEX, INF and ASM are associated with ASCII text files; COM and EXE, with binary executables. However, in an effort to reduce the online storage required by the files, and to organize software into packages, most of the files at SIMTEL20 have been through some flavor of data compaction and/or library utility. The file extensions used for such beasts may be less familiar to some: ARC a collection of related files compacted and collected together into a single package, and called an ARChive. An un-archive utility is needed to extract individual files from the package. ARK exactly the same as ARC. ARK is used in preference to ARC in the CP/M archives. LBR a collection of related files compacted and collected together into a single package, and called a LiBRary. An un-library utility is needed to extract individual files from the package. xQx a file that has been compacted using a Huffman encoding method known as sQueezing. The extension is derived from that of the original file with the letter Q substituted in the middle. (An ASM file that was squeezed would be stored as AQM.) An un-squeeze utility is needed to recover the original file data. xZx the same as xQx except that an LZW-variant method known as crunching has been used. An un-crunch utility is needed to recover the original file data. Most of the software for MSDOS systems are stored in the ARC format. All four formats are used in the software for CP/M systems. (ARK and ARC represent the same thing, but ARK is the more commonly used name.) Only a few "first-time-user" type files (like UUDECODE.BAS) are stored in their raw form. The section below titled "Getting Started" gives some guidance about handling them. ------------------------------------------------------------------------ Using the BITNET Servers ------------------------------------------------------------------------ In the United States, there are two BITNET servers that provide access to the SIMTEL20 archives: LISTSERV@NDSUVM1 North Dakota State University. LISTSERV@RPIECS Rensselaer Polytechnic Institute. --------Note--------Note--------Note--------Note--------Note----------- In Europe, there are many EARN servers. However, the information provided here is specifically for the BITNET servers. The EARN servers have a similar user interface and may accept the same set of commands, but information about using them is beyond the scope of this document. The locations of the EARN servers and the principle contact person for each are: TRICKLE@TREARN ("Turgut Kalfaoglu" <TURGUT@TREARN>) TRICKLE@IMIPOLI ("Marco Gandolfi" <MARCO@IMIPOLI>) TRICKLE@BANUFS11 ("Michel Daulie" <DAULIE@BANUFS11>) TRICKLE@AWIWUW11 ("Gustaf Neumann" <NEUMANN@AWIWUW11>) TRICKLE@DB0FUB11 ("Wolfram Fassbender" <EARNIE@DB0FUB11>) TRICKLE@EB0UB011 ("Oriol Robert" <ZCCBORR@EB0UB011>) --------Note--------Note--------Note--------Note--------Note----------- Requests may be sent to a server as RFC822-style mail. The commands to the server must appear in the body of the message, not the Subject: line. The server uses the From: header to determine how to address the files to be returned. The From: header must therefore specify a valid, reachable network address from the server's point of view. Mail received from outside BITNET, particularly from UUCP, often have unusable return addresses. Requests may also be sent as interactive BITNET messages if your system supports such a facility. On an IBM system, this service is provided by the TELL command, as in TELL LISTSERV AT nodename servercommand The server does enforce some limits on how much can be requested by whom and from where. Requests from EARN are not accepted; they must be delivered to the nearest TRICKLE server in EARN. For others, the server restricts how many files and how many bytes of data a user may request per day. It also restricts how many files and how many bytes a host system may request per day. The limits are changed on occasion, they are but they are in the neighborhood of 3 files/user/day 10 files/host/day 100 Kbytes/user/day 300 Kbytes/host/day There are some files that are larger than the per-day limit for a user (or host) would permit, so the server does allow the first request from a user (or host) on any given day to exceed the byte limit. Also, the "host" in this context means what appears after the at-sign (@) in the return address. Mailed requests that pass through a gateway usually appear to be from that gateway host, and so the server applies its host limits accordingly. --------Note--------Note--------Note--------Note--------Note----------- Although requests are sent to the LISTSERV address, the requests are actually processed by userid TRICKLE. Files sent back to you will be from TRICKLE. Do not let this mislead you, though: Your requests must go to LISTSERV, and not to TRICKLE at either NDSUVM1 or RPIECS. In EARN, LISTSERV is not used, and TRICKLE does accept requests from users. NOT IN BITNET. Your requests must go to LISTSERV. --------Note--------Note--------Note--------Note--------Note----------- 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 that match a particular pattern. 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 ('*') a "wild-card" characters. The following are examples. /PDDIR PD:<MSDOS> --Lists 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 uudecoders for CP/M. THE /PDGET COMMAND The /PDGET command is used to request a specific file. 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 is treated as if UUENCODE were specified. If no encoding is specified, then ASIS is assumed for NETDATA, and UUENCODE for the others. --------Note--------Note--------Note--------Note--------Note----------- In the actual archives at SIMTEL20 there are a few files stored in the top-level directory. (For example, PD:<MSDOS>FILES.IDX is a file listing the names of all the files in the subdirecotries of the MSDOS archive.) The design of the BITNET server does not permit access to any of these files. However, since the files at the top-level directory generally contain directory information, the need for them is superceded by the /PDDIR command. --------Note--------Note--------Note--------Note--------Note----------- ------------------------------------------------------------------------ Getting Started ------------------------------------------------------------------------ Before all else, something you absolutely must have available is a method for getting files from your host system to you micro computer. It would be preferable if this method included support for transferring binary files as well as normal text files. If you do not already have a way to communicate with your host and transfer files, consider getting the appropriate Kermit implementations available from the KERMSRV file server at CUVMA. Once that minor detail has been addressed, then you should consider what additional utility programs you will need or that will be helpful. Most files are in an archive format, so you will need a de-archive utility or two. You may also need a uudecode program, depending on your ability to receive binary files on your host and your ability to download binary files to you micro computer. This last point requires some explanation. The server stores all files from SIMTEL20 as-is in 128 byte sector image blocks. They are bit-for-bit identical to how they should appear on your micro computer. The server makes no attempt to interpret the files; it simply sends them on demand out through BITNET. BITNET, though, is fundamentally an EBCDIC network, and your micro computer is fundamentally an ASCII machine. This gives rise to two places along the path from server to micro where the file data might be misinterpreted or corrupted. If your host system is ASCII-based (as are most non-IBM systems) it will translate incoming BITNET files from EBCDIC to ASCII. If your host is EBCDIC-based, your communications software will translate files you download from EBCDIC to ASCII. But the files from the server do not contain EBCDIC data. You must either find a way to disable the translations or encode the data in such a way that the original file can be recovered. There are suggestions given later for specific host machines to disable the translations. For now assume data encoding is required. You can ask the server to send files in encoded from. If you request encoding, the file is encoded using a technique know as uuencoding. Uuencoded data is preserved through most of the EBCDIC/ASCII translations the file might encounter. So, all you need is a program for you micro computer that decodes a uuencoded file. There are several decoders available from SIMTEL20. The only problem is how do you get the program to your micro computer. Catch-22. Well, you can ask the server to send ASCII text files in translated form. If you request translation, a file is first translated to EBCDIC before it is sent. This is not recommended as a standard option since there may be some loss of information, but for getting started it may be essential. If you need a program for CP/M to decode uuencoded files, send the following command to the server: /PDGET PD:<CPM.STARTER-KIT>UUDECODE.HEX TRANSLATE The file contains the CP/M hex data for the program. Download it. Use the CP/M commands LOAD and SAVE to create an executable program. You should end up with UUDECODE.COM, the desired program. If you need a program for MSDOS to decode uuencoded files, send the following commands to the server: /PDGET PD:<MSDOS.STARTER>UUDECODE.xxx TRANSLATE /PDGET PD:<MSDOS.STARTER>UUENCDEC.DOC TRANSLATE Replace "xxx" with either BAS, C, or PAS depending on which source language you would prefer (BASIC, C, or Pascal, respectively). Next, you should consider requesting which ever of the following files you feel appropriate for your micro computer system: For PC-DOS and MSDOS machines: PD:<MSDOS.STARTER>ARCE40C.COM Un-archive utility. PD:<MSDOS.STARTER>ARCE40C.DOC ..and the documentation. PD:<MSDOS.STARTER>UUDECODE.EXE Compiled uudecode utility For CP/M machines: PD:<CPM.STARTER-KIT>DELBR11.COM Un-library utility. PD:<CPM.STARTER-KIT>UNARC.COM-Z80 Un-archive utility, Z-80 only. PD:<CPM.STARTER-KIT>UNARCA.COM-8080 Un-archive utility. PD:<CPM.STARTER-KIT>UNARC.DOC ..and the documentation. PD:<CPM.STARTER-KIT>UNCR-Z80.COM Un-crunch utility, Z-80 only. PD:<CPM.STARTER-KIT>UNCR8080.COM Un-crunch utility. PD:<CPM.STARTER-KIT>UNCR8080.DOC ..and the documentation. PD:<CPM.STARTER-KIT>USQ120.COM Un-squeeze utility. PD:<CPM.STARTER-KIT>USQ120.DOC ..and the documentation. There are many other useful utilities in these and other archive directories. Remember, though, if you need the server to UUENCODE the files you request, you should explicitly ask for it. Also, some of the programs listed above may be replaced by newer versions. (For example, ARCE40C.COM replaced the earlier ARCE31C.COM.) If you have trouble with the server claiming "file not found", use the /PDDIR command to list the the appropriate directory. You may find two other files useful. PD:<MSDOS.FILEDOCS>SIMIBM.ARC and PD:<CPM.FILEDOCS>SIMCPM.ARC contain one-line descriptions for many of the other files in their respective archives. Not all files are described, but it does contain enough valuable information to help you find other software. IBM System Users. If your host is an IBM system running either VM or MVS, you can avoid the need for uuencoding. Files received from BITNET will not be translated, since the IBM is an EBCDIC machine. Most down-load methods support binary transfer, so you can defeat the translation that would otherwise take place there. For example, with CMS Kermit the command SET FILE BINARY is all the is required before initiating a download. If you are using a 3270 emulator and IND$FILE for file transfers, by default no translation takes place. VAX/VMS Users. If your host is a DEC VAX system running VMS, with Jnet as your network software, you can avoid the need for uuencoding. You can tell the Jnet software to bypass the usual EBCDIC/ASCII translation, but there are a few additional steps needed before downloading a file. * Receive the file with the Jnet command RECEIVE/BINARY. The BINARY modifier suppresses the normal EBCDIC/ASCII translation. For the sake of discussion, assume that the file is now named SOFTWARE.FIL. This file, as received, is almost correct; but there may be an error in how VMS interprets the records. * Generate an FDL file for SOFTWARE.FIL using the command ANALYZE/RMS/FDL SOFTWARE.FIL * Edit the FDL file with the command EDIT/FDL SOFTWARE Examine the CARRIAGE_CONTROL setting. Change it to NONE. Exit from the editor. * Use the edited FDL to correct carriage control interpretation errors in the original SOFTWARE.FIL. CONVERT/FDL=SOFTWARE.FDL SOFTWARE.FIL FIXED_SOFTWARE.FIL * Download the FIXED_SOFTWARE.FIL as a binary file using any reliable means. (For VAX Kermit, use the SET FILE TYPE BINARY command before starting the download.) ------------------------------------------------------------------------ Common Problems ------------------------------------------------------------------------ Q. I downloaded this program to my micro, but when I run it, my machine hangs (or I get the message "Out of Memory" or ...). A. Either the file became corrupted in transit (perhaps one of those nasty EBCDIC/ASCII translations), or the file was uuencoded and you have not decoded it. Q. I downloaded an archive to my micro, but the de-archive utility would not process it. I get messages like "File not an archive" or "Cannot extract member". A. Same comments as above. Q. I really, really need to get these special files that I absolutely must have, but the server limits how much I can request per day. Is there any way I can get around these limits for this one special case A. No. Q. I am trying to get a file from the (top-level of the) MSDOS directory. /PDDIR won't list it, /PDGET claims it can't find it, but I know it is there. A. It may well be there at SIMTEL20. However, the BITNET server is not capable of handling any request for a file from the top-level of an archive. Generally, though, the files stored at the top level list the contents of the archive. The /PDDIR command can be used to get a directory listing. Q. I have been requesting this same file repeatedly. Each time the server tells me my request has been "queued for processing," then a few days later it sends me a message that it has "abandoned" my request. Other requests it has been handling just fine. A. The server does maintain a large "cache" of recently requested files. Many requests are satisfied from this cache. However, for all the rest the server must fetch it directly from SIMTEL20 using the Internet file transfer protocol, FTP. "Directly" really is not all that direct since the path between server and SIMTEL20 includes many network segments and gateways. To complete a transfer, an error-free connection must be maintained for the duration of the FTP transaction. This is not always possible, whether it be from some dysfunction along the path or heavy network load. The server will retry a failed FTP transaction, but if it continues to fail, the server eventually gives up. Q. I keep sending requests to the server. I never hear anything back. A. The server responses in some way to everything it receives. Your requests may not be arriving, possibly because you are miskeying the server's network address. Perhaps you are sending your requests to TRICKLE rather than LISTSERV. Your requests may be arriving, but with an unusable "From:" field in the mail header, so the response never gets back to you. Q. Gee, this public-domain/shareware stuff is the greatest. How do I go about adding my own contributions? A. Remember, the archives are actually kept at SIMTEL20. The servers only provide access to them. Contributions must be sent to the people there. Send an electronic mail message to: "Keith Petersen" <W8SDZ@WSMR-SIMTEL20.ARMY.MIL> Be sure to tell him what it is you have and what it is for. After he verifies he does not already have it, you and he can negotiate methods for submitting the software. Q. Hey, I have FTP on my system. How do I go about connecting to either RPIECS or NDSUVM1 and fetching the SIMTEL20 files? A. Two points about the servers have been missed. (1) The servers are there to provide access to the SIMTEL20 archives for people WITHOUT FTP capability. Users on hosts that do support FTP have the privilege of connecting directly to WSMR-SIMTEL20.ARMY.MIL. (2) The servers do not actually have a complete collection of the archives; only a varying set of recently requested files are stored locally. If you have FTP access to the Internet, connect to WSMR-SIMTEL20.ARMY.MIL and use anonymous login. Q. Who do I contact with suggestions or unsolvable problems? A. Depending on which server you normally use: "John Fisher" <FISHER@RPIECS> "Marty Hoag" <INFO@NDSUVM1> DO NOT send your comment or question about the server to the people at WSMR-SIMTEL20.ARMY.MIL. However, if you wish to report program bug or something similar about a SIMTEL20 file, you may send it to "Keith Petersen" <W8SDZ@WSMR-SIMTEL20.ARMY.MIL> -- Keith Petersen Maintainer of SIMTEL20's CP/M, MSDOS, and MISC archives Internet: w8sdz@WSMR-SIMTEL20.Army.Mil [26.2.0.74] Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
w8sdz@smoke.BRL.MIL (Keith Petersen) (09/03/89)
If you are in Europe and your host is not on the Internet please use the
RED file servers to get files from SIMTEL20. Here's how:
RED - Listserv Redirector
(C)1988 Turgut Kalfaoglu <TURGUT@TREARN>
What is RED?
RED provides the SIMTEL-20 files, and directory listings, with its own
cache, where it keeps its most recently requested files. It reduces the
network load by providing the cache, and by providing directory listings
locally, instead of through a distant list server.. It is a machine
(process) that runs disconnected from a terminal.
Currently, the seven sites that run this software are called:
In Denmark: TRICKLE@DKTC11
In Turkey: TRICKLE@TREARN
In Italy: TRICKLE@IMIPOLI
In Belgium: TRICKLE@BANUFS11
In Austria: TRICKLE@AWIWUW11
In Germany: TRICKLE@DB0FUB11 or TRICKLE@DTUZDV1
In Spain: TRICKLE@EB0UB011
You are urged to use the one that is closer to your location.
In this tutorial, we will be using 'TELL TRICKLE AT TREARN', but this
can be replaced with 'TELL TRICKLE AT <your location of
preference>'
We also will use the 'TELL' command to send a single line message. It
should be replaced with whatever is appropriate for your system. (Like
XMIT , SEND, etc.) If you are on a node that cannot reach a TRICKLE
directly, for example, a JANET node, then you must send MAIL files to the
server. Simply put the commands, one per line, into the text portion of
your mail. If you are using MAIL, you do not need to put 'TELL TRICKLE
AT TREARN' in front of every command - every line has to begin with a
slash (all valid trickle commands begin with a slash).
You can also place more than one command per command file.
What Does it Provide?
A Milnet node, SIMTEL20.ARMY.MIL at White Sands Missile Range, New Mexico
contains a large selection of public domain and 'shareware' software.
This DECsystem-20 machine, running the Tops-20 operating system provides
many files of interest, especially to CP/M and MSDOS users.
The collection is open to public, anyone may obtain copies of this of the
files using the Internet file transfer protocol, FTP. However, this
protocol is not available to Bitnet, or EARN sites. For this reason, two
servers in The United States, who have a connection both to Milnet and to
Bitnet, provide us with these files. However, since both of these servers
are in The US, the requests of these files puts a burdon on these two
servers. The solution was to create a server here in Europe that could
provide the files requested, send the directory listings, and also keep
the recently requested files, in case someone else wishes to have the
same file.
We, the server operators, would like to stress that we have no
affiliation with the US Army, nor with White Sands Missile Range. These
servers are made available in the true spirit of volunteerism, without
any outside sponsorship for the service.
The Trickle, and The US servers support the following directories:
CPM Software and information for CP/M users. Contributions are gathered
from a variety of sources, including the members of the Info-CPM
electronic mail discussion group. This archive is updated very
frequently.
MSDOS Software and information for PC-DOS and MS-DOS system users. This
archive is updated very frequently.
PC-BLUE Software and information for PC-DOS and MS-DOS system users. The
archive contains files distributed by the PC-Blue Users Group. New
files are added as they become available.
SIGM Software and information for CP/M users. The archive contains the
files distributed by the SIG/M Users Group. New files are added as
they become available.
MISC Software and information for miscellaneous systems (mostly large
systems like IBM/370 and DEC VAX). Contributions are gathered from a
variety of sources.
How does it work?
It provides faster file delivery than LISTSERV@RPIECS because it
holds the most recently requested files, and it also asks its peers, to
find out if any of them has the file.
It has two major commands. /PDDIR and /PDGET.. As the names indicate
, /PDDIR provides the names of the files, and /PDGET delivers files.
How to use /PDDIR:
On IBM/VM systems, you can get a list of the 'major directory' names by
simply typing this command:
TELL TRICKLE AT TREARN /PDDIR
RED should now send you a list of the major directory names. Now, you
can obtain a list of the sub-directories of any of the displayed names by
putting the name between less-than and greater-than symbols.. For
example,
TELL TRICKLE AT TREARN /PDDIR <MSDOS>
RED will mail you a file containing the names of the sub-directories.
Once you choose a subdirectory to examine, type in the main directory
name, a period, then the name of the subdirectory name. For example, if
you chose SYSUTL sub-directory of MSDOS, then you may type this:
TELL TRICKLE AT TREARN /PDDIR <MSDOS.SYSUTL>
RED will first notify you of the number of files found, then will go
ahead and mail you this list.. Once you choose your file(s) to order,
then read on..
How to use the /PDGET command:
Once you have a filename in hand, then tell RED to send you this file
by providing it with the full directory name, and the filename.. If you
wish to order a game called MADMAX.ARC that resides in the <MSDOS.GAMES>
directory, then you may type in this command:
TELL TRICKLE AT TREARN /PDGET <MSDOS.GAMES>MADMAX.ARC
naturally, the above is only an example, and the file may or may not be
present if you send the above command.
Receiving your file in a different format:
Normally, SIMTEL files are sent AS-IS, meaning, ASCII. If you would like
to receive your file in a different format, you may want to append any of
the below to the end of any of your your commands:
(EBC80 Converts the file to 80-Column EBCDIC format
(EBC32 Converts the file to 132-Column EBCDIC format
(UUE uuencodes the file
(OLD Sends the file using DISK DUMP or PUNCH format
(SF Supresses BITSEND, and forces SENDFILE to be used for the transfer.
(MAIL Forces results to be sent via MAILER. (This option is
automatically added for MAIL command files)
(XXE XXDECODES the file that is to be sent to you.
(HEX Turns the file to HEX format - use it if even (XXE doesn't work for
you.
(BTOA BTOA-Encrypts the file. Useful for Unix systems.
You may also wish to combine several options together. For example, to
receive a directory listing in PUNCH format, and UUEncoded,
TELL TRICKLE AT TREARN /PDDIR <MSDOS.C> (OLD UUE
To receive a file in in EBCDIC format, you may enter a command that looks
like this:
TELL TRICKLE AT TREARN /PDGET <MSDOS.GAMES>MADMAX.ARC (EBC80
However, it is not useful at all to receive an .ARC file in EBCDIC
format. The above is not a terribly good example.
Other commands:
/NEWS sends you our 2-page newsletter.
/STAT provides you the statistics of usage.
/HELP sends you this file.
/IMDAT sends the Turkish version of this help file. Note that
this command is only valid for the TREARN server.
/CAC Sends you a list of the files that are stored on its disk right
now. These files can be sent faster than the other files.
/OPS displays the RED operators
/QUO Shows you the RED's quota, and how much of that quotait has
used. Once RED exceeds its quota, it cannot order files, until
it receives some of the requested files.
/SUB <dirnam> Allows you to subscribe to a directory. Whenever a
new listing comes in, RED will send you a file containing the
names of the new files.
/UNSUB <dirnam> is to stop RED from sending you the new files listings.
Please issue this command if you will not use the server anymore.
/NEW <dirnam> nnn This command, displays the files that have arrived
within 'nnn' days, in the 'dirnam' directory. If 'nnn' is omitted, it
defaults to the last time you issued this command, for that directory.
If you are issuing this command for the first time, then it simply
looks for files that are at most a month old.
/POLL forces RED to check its peer servers
Delay Periods:
If the file that you requested already exists in the cache directory,
then you may expect to receive your file within a few hours. However,
the system that RED is running is often slowed down by the other
processes that are running. This negatively affects the response time of
RED. If the file requested does not existin the cache directory, then
RED will have to order this file from its list server.. If this is the
case, the response time of RED is dependent upon the list server. RED
will give up waiting for a file after five to twelve days after its
request.
Sending files to RED:
RED now accepts command files in MAIL, NOTE, or regular file format.
Use your system's (and yours) favorite utility to prepare your command,
and mail it to the server. If you are using MAIL, you may need to place
Reply-To: tag to ensure that the server replies to the address that
you specify, instead of your 'obvious' address.
The command files may contain any number of instructions, one per line.
These lines must all start with a slash, since all server commands begin
with a slash.
The server has a 'likewise' habit, and will MAIL back your files, using
the default UUENCODING, unless you tell it otherwise, if you request
your file via mail. This is done for those of us, who are not on Bitnet,
and keep forgetting to put the (MAIL at the end of the command.
How to DONATE files to Simtel Archives:
Files that you receive from here are sent from another network called
ArpaNet. The person-in-charge for the programs is: Keith Petersen
<W8SDZ@SIMTEL20.ARMY.MIL>. Since it's another network, you will need to
use MAIL to send the message. He urges that you talk to him before you
send in the file, so that he can check where it should be put, if it
already exists, etc. After getting his approval, you need to UUENCODE
your file (perhaps using PDUTIL), then MAIL it to him.
Format of the files that comes with /PDGET command:
For the below chart, we shall assume that you have not placed any
conversion options at the end of your command.
If you have used: You can expect the file to arrive:
-----------------------------------------------------------
'tell' style message: BITSEND, NETDATA format.
-----------------------------------------------------------
MAIL command file: UUENCODED, in numbered pieces.
-----------------------------------------------------------
A regular file, or Just like 'tell' messages,
IBM's NOTE command: replies in BITSEND, NETDATA.
-----------------------------------------------------------
RED will send the files in a NETDATA format, -unless you use the (OLD
option-. On IBM systems, these files can be LOOKed and RECEIVEd, but the
PEEK command cannot handle NETDATA format properly. However, since most
files are ASCII, it is of little use to LOOK at them.
Since SIMTEL (and your personal computer) keeps its files in ASCII format,
so does TRICKLE. So, you may not be able to examine your file on the
VM system. However, some of the description files (recognized by their
names) can be ordered with the (EBC80 or (EBC32 option, if you wish to
look at these files on the VM.
The .ARC format:
ARC is a special compression method that provides substential reduction
on file size. There are one or more files contained within an .ARC
archive. In order to extract the files from an archive, you will need a
utility called ARC or PKXARC. These are available from <MSDOS.ARC-LBR>
directory. The actual file names of these files vary, but you may try:
TELL TRICKLE AT TREARN /PDGET <MSDOS.ARC-LBR>PK361.EXE or: TELL
TRICKLE AT TREARN /PDGET <MSDOS.ARC-LBR>ARC512.EXE If these attempts
fail, it will probably mean that the file version has changed, and so has
the file name. You may wish to try
TELL TRICKLE AT TREARN /PDDIR <MSDOS.ARC-LBR>
and guess the new name of these files.
Once you receive either ARC or PKXARC and an .ARC file, transmit them to
your personal computer and issue the following command:
ARC X <filename.arc>
or
PKUNPAK <filename>
There is also a second utility called ARCUTIL, which runs on the VM
systems, and extracts files. It also provides ASCII to EBCDIC conversion
of the extracted files. To request ARCUTIL, enter:
TELL TRICKLE AT TREARN /PDGET <MISC.IBM-VM>ARCUTIL.LBR
The directories of SIMTEL change often. So, the above files may or may
not be in the same directories as I have indicated. So you may have to
do some searching to find them.. A good place to check would be the
<MSDOS.STARTER> directory, where additional help, and the mentioned
archive managers can be found.
How to use the BITSEND/BITRCV:
From now on, RED is sending its files in a special format called BITSEND
- Unless you include the (SF option while issuing your command.
In this format, the files that are sent are broken into smaller pieces,
if the entire file is too big to be sent. If the file you request is
over the size limit, then the server will first send you a file called
<fn> BITCTRL - this is the control file, where BITSEND has written the
protocol used, the number of pieces that make up that file, etc.
-------------------------------------------------------
Important:
You should NOT 'RECEIVE' any files that have BITCTRL
or just numbers as filetype!
-------------------------------------------------------
If you wait a little longer, the rest of the file will arrive, the
filename will be the same as the <fn> BITCTRL file, but the filetype will
consist of just numbers. Once you have all the pieces that make up that
file, you can then issue the BITRCV command. You must also specify the
'spool ID' of the file that has BITCTRL as filetype. From RDRList, you
can simply type BITRCV in front of the file that has BITCTRL as filetype.
If you get back an error message, saying "UNKNOWN CP/CMS COMMAND" it
simply states that your installation does not have the BITRCV program.
Contact your network manager/system operator.
Note: BITRCV EXEC can be obtained from your country NETSERV as well.
Simply send "GET BITRCV EXEC" to your NETSERV.
-----------------------------------------------------------
VAX users:
There is also an identical file for your installation, however, it is
called 'BITRCV COM', and can be obtained from a NETSERV by issuing GET
BITRCV COM to your country NETSERV.
-----------------------------------------------------------
If you get back an error saying that not all of the file is in the
reader, it simply means that you have to wait a little longer for the
rest of the file to arrive.
How to receive the file that arrives:
Once the file you requested arrives, and is stored on your disk, you will
most likely wish to 'download' this file to your personal computer. There
are many types of mainframe computers, many kinds of personal computers,
so it is impossible for me to give you direct, and precise directions.
However, here are some clues:
* If you have a PC with a 3270 Emulation program, and an IBM mainframe,
you should request your files from the server without options, or with
(SF option, and use the built-in transfer protocol of the emulation
program, without any options again.
* If you have KERMIT at your installation, request your file without
options, or with (SF option, then set the KERMIT's FILE-TYPE to BINARY
before transferring your file.
* Remember that if you send a MAIL command file to the server to request
your file, the file will arrive in UUENCODE format, since the mailer
cannot process binary files - unless you specify (XXE or (HEX in the
command line.
How Does the Cache Work?
Imagine that you ask for a file, and the server brings this file from
United States for you. Thinking that others may wish to have this file as
well, the server keeps this file in an area called 'cache.' When someone
else requests this file, the server simply uses the stored copy of the
file, instead of asking for the file again from overseas. All the servers
that you see on top of this document have different files in their
caches. So, if you wish to see the files they are holding right now, you
will have to issue '/CAC' to each one of them. Note that a file does not
stay in cache forever. As new files arrive, the older ones are deleted to
make room.
The Amazing Life of a /PDGET request:
Once you order your file via /PDGET, the server will first check its
local cache listings. If the file is not there, then it will check the
SIMTEL20 listings to ensure that a such file indeed exists. After this,
the server sends the request to all other servers, asking them if they
have your file in cache. If a server replies 'YES!', then that server has
to send you the file. Everything fails: none of the servers have your
file, or even some servers don't respond. Your server will give up
waiting for a reply in a day, and order your file from the United States.
Once the file requested arrives from there, it will be sent to you, and
put into the cache directory. Quite a trip for one /PDGET command.
Quotas, and Other Ugly Limitations
You may be surprised that even though most TRICKLE servers have some kind
of quota, we still get several hundred requests daily. Without them, this
number may easily rise to thousands. The impact of a such usage rate on
the local computer can be very 'tiring.' So, the following quota schemes
have been implemented:
1) Total outstanding bytes quota: This quota is not really put by the
server's operators. It is the amount that a TRICKLE server can order
from The United States. This is currently set at 10 megabytes for most
servers.
2) Prime times: Some of the servers, do not function during the day, they
record the commands received, and process these commands later, when
the load on the computer is low.
3) User request limitations: Most TRICKLE servers have a limit on how
many requests a user can make on the server per day. The request can
be a simple /OPS command, or a file order via /PDGET. It still counts
as one. The server will warn you that you are approaching the limit,
once you have 3 more commands left.
4) Outstanding files per user: This scheme is also employed by some
servers, and it limits the number of files a user can order from The
United States.
5) Delayed Sendfile: This last scheme is simple: it delays sending your
file until a specified time comes. Usually at night, when the network
load is low. If a site uses delayed sendfile, you will see a '* Your
file will be mailed' notice, instead of '* Your file is being mailed.'
A Last Word on Options:
Some of the options are not compatible, such as (MAIL SF, and should not
be used together - the behavior of the server may be unpredictable. Also,
the (SF option may result in a file that is too large for shipment. If
that is the case, a network control program may detect it, and delete it
before it reaches you. Use (SF carefully.
Also, (SF and (OLD options would be ignored if you send in your commands
in a MAIL file. If you wish to receive your files AS-IS, and still be
able to put your commands in a file, you can either send a NOTE to the
server, or simply create a file using your editor, then send this file
directly to the server, without first going through the mailer.
VAX/VMS Users:
If your host is a DEC VAX system running VMS with Jnet networking
software, you can avoid the need for uuencoding. You can tell the Jnet
software to bypass the usual EBCDIC/ASCII conversion, but there are a few
additional steps needed before downloading a file.
* Receive the file with the Jnet command RECEIVE/BINARY. The BINARY
modifier suppresses the normal EBCDIC/ASCII conversion. Let's assume
that the file is called MYFILE.ARC. This file, as received, is almost
correct; there may be an error is how VMS interprets the records.
* Generate an FDL file for MYFILE.ARC using:
ANALYZE/RMS/FDL MYFILE.ARC
* Edit the FDL file with the command
EDIT/FDL MYFILE
Examine the CARIIAGE_CONTROL setting. Change it to NONE. Exit the
editor.
* Use the edited FDL to correct carriage control interpretation errors in
the original MYFILE.ARC:
CONVERT/FDL=MYFILE.FDL MYFILE.ARC FIXED_MYFILE.ARC
* Download the FIXED_MYFILE.ARC as a binary file using any reliable
means. (For VAX Kermit, use SET FILE TYPE BINARY command before
starting the download.)
Additional Help:
1) A Discussion List
We now have an online discussion list that gives assistance on the
server. To join this list, simply send the following command to
either LISTSERV AT TREARN, or LISTSERV AT DB0FUB11:
SUB RED-UG My-full-name
Remember that you can use MAIL to interact with both TRICKLE and
LISTSERV, and if you do, you need to put the commands in the mail
body, and not in the subject section, like some other servers.
2) Other online documentation on the server
You may request additional documentation on the workings of the
server by issuing:
INDEX RED-UG
to LISTSERV@TREARN. Then order any of the listed files via
GET fn ft
command to LISTSERV@TREARN
3) Human Help
Also, you may get in touch with your local TRICKLE operator. You
can get his network address by using the /OPS command.
We wish you great benefits from using TRICKLE - we know that the software
it provides can accomplish that.
--
Keith Petersen
Maintainer of SIMTEL20's CP/M, MSDOS, and MISC archives
Internet: w8sdz@WSMR-SIMTEL20.Army.Mil [26.2.0.74]
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz