sources-request@mirror.UUCP (10/27/86)
Submitted by: root@cuae2.ATT.COM Submitted by: thos@cca.ucsf.edu Mod.sources: Volume 7, Info 6 Archive-name: new_archives [ This message announces a new archive site at the University of San Francisco, and the availability of "anonnymous" UUCP access to the archives maintained at site cuae2 in Chicago. Thanks to both genetlemen for their assistance. A complete list of mod.sources archives is published with the index, twice per volume; it will now also be posted in net.sources until that group disappears. -r$] ------------------------------------------------------------------------ NEW ARCHIVE SITE AT UCSF ------------------------------------------------------------------------ I will be glad to respond to requests for material but this does not represent an ongoing commitment for the installation. Anyone requesting material via mail should supply a path from ucbvax. Anyone requesting tape should contact me first. Thos Sumner (thos@cca.ucsf.edu) (...ucbvax!ucsfcgl!cca.UCSF!thos) ------------------------------------------------------------------------ ANONYMOUS UUCP ACCESS AVAILABLE AT CUAE2 ------------------------------------------------------------------------ This file explains how to get files from the mod.sources archive being maintained by the AT&T Application Engineering Division in Lisle, IL. This is not an official service of AT&T and may be discontinued at any time. The contents of the mod.sources archive have been donated by the submitters of the files to the Usenet mod.sources moderator for free availability throughout the community. AT&T assumes no responsibility for the contents of these files, including the suitability for their use in any application on any hardware. (Some of the material, for example is known not to run on systems sold by AT&T.) Any questions about suitability, problems with the software or documentation, or anything else related to the contents of the files should be directed to the persons who submitted the material originally (usually the authors). (Now that I think I've covered my behind sufficiently...) The mod.sources archives are currently resident on an AT&T 3B20A computer running UNIX System V Release 2.1. This system is used for real work during working hours on weekdays, as well as a little bit evenings and weekends. (We're kinda nuts.) To be able to separate and control access to the mod.sources archives from uucp accesses related to our actual jobs, I have configured the UUCP (HDB) system to provide what looks like a machine named "cuaepd" (for bldg CU, Application Engineering, Public Domain material) to caller machines that log in with the login "pduucp". This also lets us move the archives to a separate machine, if we want to later, without disrupting too many people. The following description of how to set up your system's uucp config files is based on the Honey DanBer UUCP (AT&T Basic Networking Utilities) implementation, as it's the only one I've used that made any sense. You may have to adjust what I say to fit your system's requirements. The phone number for "cuaepd" is (currently) 1-312-964-3773. There are two lines hunted on that number. The modems will answer at 1200bps with a "login:" prompt. (We intend to expand the number of lines, upgrade them to 1200/2400bps, and change the phone number in the next couple of months.) In response to the login prompt, your system should send the login id, "pduucp". There is no password associated with this id. All this is turned off between about 6 a.m. and 6 p.m. Chicago time Monday through Friday, so we can get our real work done, so don't bother trying it during those periods. (Chicago has Daylight S.T.) The Systems file entry for doing this looks something like: (for HoneyDanBer UUCP users) cuaepd Wk1830-0530,Sa,Su ACU 1200 chicago9643773 in:--in: pduucp (for Old UUCP users) cuaepd Any1830-0530 ACU 1200 chicago9643773 in:--in: pduucp Once you have your system set up to place an outgoing UUCP call to "cuaepd", you can retrieve material from the archives. This file is file cuaepd!~/netnews/mod.sources/howto.snarf. The current directory of what is stored in the mod.sources archives is found in the file cuaepd!~/netnews/mod.sources/directory. To get either of these, execute a command like: uucp cuaepd!~/netnews/mod.sources/howto.snarf !~/MYNAME/ uucp cuaepd!~/netnews/mod.sources/directory !~/MYNAME/ The directory is simply the output from "ls -sRxF" on the mod.sources archive disk hierarchy. It is updated just before 6 p.m. every day. Here is a sample from the directory. ----------- total 15 0 directory 1 make.dir* 2 vol1/ 1 vol2/ 3 vol3/ 3 vol4/ 1 vol5/ 2 vol6/ 1 vol7/ 1 vol8/ ./vol1: total 941 16 ANSI.C.Z 12 C-Kermit.ann 41 Digest.Z 12 NIC 13 Smail.Z 1 UK-1.1/ 1 Xlisp1.4/ 20 bed.Z 1 bourne/ 1 cforth/ 14 checkin 120 compress 57 cpg+mdep.Z 1 cpp/ 26 cshar.Z 49 cxref.Z 15 diffc 29 digest.Z 19 dynamic 8 expire.8 7 getopt 13 lbgm.Z 14 newshar.Z 13 newsweed 57 patch1.3.Z 1 pcurses/ 13 readnews.1.Z 160 rfc_882 1 rn/ 1 rpc/ 43 sendmail.cf.Z 1 sent 17 uucpanz.S5.Z 16 uucpanz.V7.Z 9 uuque 1 vnews/ 14 vnews.1.Z 41 vstr.Z 43 xfernews.Z 20 xref ./vol1/UK-1.1: total 105 4 Anno 48 Part1.Z 31 Part2.Z 22 Part3.Z ---------- This sample shows part of the first volume of mod.sources. The entries with a slash "/" at the end of their names are directories, whose contents are detailed below (e.g. UK-1.1). The number preceding each name is the approximate size of the file in 512 byte blocks. Entries whose name ends with a ".Z" have been compressed by the program compress 4.0, which can be found (in uncompressed form) in volume 2. Multi-part distributions typically are set up with all parts in a subdirectory of the volume directory. This means you can snarf just the parts you've missed, instead of having to get the whole thing. Old versions are not yet being deleted with any regularity, so be sure to look carefully to be sure you are getting the latest version available. Also, look for "index" files that have more information on the contents of the various packages. NOTE: Please be aware that uucp commands asking for file names containing wild cards will almost certainly not work. This is because the implementations I know of submit a uux job to the remote system asking it to run "uucp" on the wild card filename. Systems logging in with "pduucp" are prohibited from executing "uucp" or other commands via "uux". So, be sure to ask for each file separately. If you can't figure out why it doesn't work, re-read this file. If you still have trouble, talk with your system administrator. If you are the system administrator, send electronic mail to me and I'll see what I can do. Suggestions are always welcome. Compliments and thanks are even more so. Ron Heiby. heiby@cuae2.ATT.COM