info-3b2@lamc.UUCP (Info-3b2 Mailer) (03/01/89)
Info-3b2 Digest, Number 63 Tuesday, February 28th 1989 Today's Topics: Re: 3b2 Questions - Answers Appreciated u3b.sources UUCP bug not in SVR3.0. Re: 3b2 Questions - Answers Appreciated ---------------------------------------------------------------------- From: rich@jolnet.Orpk.IL.US (Rich Andrews) Subject: Re: 3b2 Questions - Answers Appreciated Date: Sat, 25 Feb 89 11:17:47 CST > > Forwarded message: > > Subject: 3b2 Questions - Answers Appreciated > Date: 23 Feb 89 15:30:58 GMT > Organization: Cornell Theory Center, Cornell University, Ithaca NY > > We have several 3b2/310's running System 5 version 3.1 > with WinTCP 1.1, net card, 30meg drive, floppy and a > 4serial/1parallel card. All systems were originally > 3b2/300's that were upgraded by ATT technicians at our > site. We have a list of questions that we can't, as yet*, > find answers to, so if anyone can help in all or in part, > please respond by reply, e-mail direct to me or phone, > which ever is easiest for you. > > * We have asked our resident ATT expert, ATT sales reps > and perused the manuals rather thoroughly (we think) > trying to answer the questions posed. > > Questions: > > 1; Is there a way to make a bootable floppy system > so we can try to salvage systems that are having a problem > without doing the 'Essential utilities, partial restore' > route? Essentially a kernal with mount, fsck, makedev > etc so we can boot, fsck the hard drive and mount it. Running a Standalone Shell on a 3B2 Stephen J. Friedl V-Systems, Inc. April 25, 1988 NG: the procedures described here require substantial knowledge of UNIX and entail a significant risk of causing loss of data. The obvious disclaimers apply here, so use at your own risk. Please be careful. Introduction AT&T has developed some very simple, automated procedures for doing just about everything required to administer a 3B2 computer. They do this with the help of detailed, step-by-step manuals and some pretty decent sysadm menu software. The difficulty is that there are some things that just can't be done easily via the menus; fixing a dead machine is one of them. This document is an introduction to operating your 3B from a standalone /unix. Even with inoperable hard drives, it is possible to insert the boot floppy (Essential Utilities Disk 1), say some magic words, and receive a # prompt. At this point you can do major surgery on the failing machine, often recovering a drive previously thought to be lost. Our style is informal and we'll use lots of examples to illustrate the points at hand. We have been using standalone shells for quite some time and have learned a great deal; we hope to pass this information on to you. Please read this document carefully before trying the methods described here, and if possible have a wizard around when giving it a go. This can be dangerous business: as has been said before, it is a time where experience and informed courage count for much. All of these notes were derived by looking at disks, picking apart little programs, and generally by running into problems we were bound and determined to solve. We are not a source code licensee, and as such, we have made certain assumptions about some of the pieces of this puzzle, those assumptions possibly having limited correspondence with reality. Those with more enlightenment are encouraged to fill us in on changes. - 1 - Conventions Throughout this document, sample usage sessions will be shown indented, with user input in bold. To make it easier to distinguish between a multiuser UNIX shell and a standalone one, we will show multiuser UNIX's root prompt as ## and the standalone prompt as #. >>> Back up your boot disks b-> This cannot be emphasized enough. Your boot floppies are the key to your machine, and without them the machine is down. Early in our experiences with standalone shells, our primary boot floppies became corrupted early on a Saturday, and we had to wait until Monday morning for AT&T to provide us a spare; it was as embarrassing as it was frustrating. It is mandatory that you have at least three copies of your boot disk before you begin these procedures. While it is easy to have too few backups, it is hardly possible to have too many. The most efficient method for copying an entire floppy is with the dd(1) command. First, read a copy of the entire floppy into a single file under /tmp. Be sure that room for the entire filesystem -- 1435 blocks -- is available on the hard drive. ## dd if=/dev/rdiskette of=/tmp/disk.copy bs=9b 158+0 records in 158+0 records out This reads from the boot disk into the file /tmp/disk.copy, using the floppy's optimal blocksize. The command will take somewhat over two minutes, and the input/output statistics shown above are normal. Now, insert a formatted floppy into the drive and do: ## dd of=/dev/rdiskette if=/tmp/disk.copy bs=9b 158+0 records in 158+0 records out Notice that the `if' and `of' options are the only changes, signifying the reversal of copying direction. This second command can be used repeatedly to make as many copies of the disk as desired. Do remember to remove the /tmp/disk.copy file after all copies have been made. Why do you want a standalone /unix? The most compelling reason for a standalone shell is when the primary drive has gone down and must be recovered. While working from a standalone /unix is slow and tedious, it can often save an entire hard disk with minimal data loss. - 2 - Case in point: a friend called in a panic. He had done a dd(1) onto his hard drive improperly and had overwritten the drive's partition tables, rendering it unbootable. He was able to boot a standalone /unix from a floppy, manually initialize the partition tables, and get his drive back with not a byte lost. All it cost was a cross-country phone call and a half an hour of time (plus a nice dinner next time he's in town). We have also used this standalone shell to repair a corrupt /etc/inittab, to fix /etc/passwd, to restore a /bin/login that had been removed, and to install new bootstraps on the hard drive. With a standalone boot disk in hand, a host of possibilities presents itself. What is on your boot disk? Before booting this floppy, take some time to explore its contents, as the disk has a filesystem on it that can be mounted and perused. To do this, insert a copy of the Essential Utilities Floppy 1 (from now on, "the boot floppy") into the drive with a write-protect tab. Now, ## mount /dev/dsk/c0d0s5 /install -r Because this disk has a boot partition that resides on the first cylinder, the more commonly used /dev/diskette (slice 6) is replaced by /dev/dsk/c0d0s5 (slice 5). The `-r' flag asks that the filesystem be mounted readonly. The /install directory may now be visited like any other, but remember that a floppy-based filesystem responds much slower than one based on the hard drive. With this in mind, it is helpful to insure that the current directory appears at the tail end of the shell's search $PATH when exploring a floppy. Because boot floppies vary from release to release, it would be most helpful to simply get a listing of the contents of your particular boot floppy. Do this by: ## cd /install ## ls -lRFab | pr | lp This sends a formatted listing of the entire disk to the printer; keep it handy. The next step is to examine the particular installation procedure used by this version of the boot floppy. Look in /install/etc/inittab for the name of the program that does the work, and on our disks (SVR2.0.4) the file is /inst/etc/instf (which is found in /install/inst/etc/instf if the floppy is mounted on the hard drive). This installation script is fairly verbose, and tracking down just what it is doing should be - 3 - straightforward and enlightening. Once finished, the floppy must be unmounted: ## cd / ## umount /dev/dsk/c0d0s5 Never remove a mounted floppy filesystem without first unmounting it, especially a boot disk. Doing this may leave the filesystems's status flag in an "active" state and prevent the boostrap from recognizing it. The umount operation insures that the disk is properly updated before it is closed. When the green drive light goes off, remove the floppy and return it to its proper home. "Open Sesame" To give standalone a try, first shut the machine down to firmware mode. From multiuser UNIX, warn the users that the machine will be unavailable, and run the following from the system console: ## cd / ## /etc/shutdown -i5 This brings the machine into init state 5, which is firmware mode. The shutdown program will verify your intentions, send a notification to all logged-on users, and bring the machine to firmware mode in one minute. Assuming the machine is now in firmware mode, put a copy of the boot disk into the drive. Note that some versions of the operating system (Sys V Release 2, at least) require that the boot floppy be write-enabled (i.e., no write-protect tab); it is this requirement that mandates multiple backups of the boot floppy. UNIX will be updating the disk while it runs -- the superblock, access times, etc. -- and if the machine crashes at the wrong time it simply will not boot again without an fsck. Be careful. Type in your firmware password and boot /unix from the floppy drive (Option 0, named `FD5') instead of the hard drive (Option 1, named `HD30' or `HD72'). It can take several minutes for UNIX to boot, but when it does, the familiar menu will be displayed: 1) Full Restore 2) Partial Restore 3) Dual-Disk Upgrade 4) Release Upgrade - 4 - Selection? [1, 2, 3, 4, quit, help] At this point, type the phrase magic mode The system recognizes this special option and responds: Poof! Selection? [1, 2, 3, 4, quit, help, shell, copy] Notice the new options? Now type shell, then RETURN, and you will be greeted with the familiar # prompt. You are now running a standalone shell on the floppy. A few reminders here: a floppy filesystem is not able to hold much data, and many common utilities are unavailable. When dealing with the standalone shell, one must learn alternatives to these utilities. For example, echo * can replace ls(1), and cat > file can serve as a poor replacement to ed(1). One must become remarkably resourceful when working in an environment as restricted as this. We will see later how we can enhance this confined environment with additional tools. Standalone devices The floppy's /dev directory contains a host of entries, some of them referring to partitions on the hard drive. While a particular partition may have several names, we generally use the following devices to refer to the hard disk: Partition What it is (on the hard disk) ----------- ----------------------------- /dev/idsk00 / filesystem /dev/idsk01 swap area /dev/idsk02 /usr filesystem /dev/idsk06 the entire disk /dev/idsk07 boot partition /dev/idsk08 optional filesytem (/u or /usr2) These also have names of the form /dev/dsk/c1d0s0, but we prefer using the shorter names because they tend to be less confusing. In addition, each block device mentioned has a corresponding character (raw) device entry of the form /dev/ridsk00 (note initial `r'). Generally, we use the block devices where a choice exists. The cartridge tape drive is not available in standalone mode because the floppy is not large enough to hold /unix with the CTC drivers. Because of this, there are no device entries in /dev that correspond to any tape drives. There are intermediate - 5 - solutions to this problem but they are beyond the scope of this document and not usually necessary. Mounting the hard drive onto the floppy To gain access to the primary hard drive, partitions of interest are mounted onto directories on the floppy. The device names are selected from the table in the previous section. Before mounting a partition, we recommend running the filesystem check fsck(1m) first. The mount command will fail if the the superblock is not in order -- this is often the case after a crash. In addition, it gives a convenient verification of the device status and the the filesystem's name and volume. # /etc/fsck /dev/idsk00 While some errors are to be expected while checking the root partition, a total failure is a very serious error. Our experience defines "total failure" as an indication by fsck that it cannot find any possible traces of a filesystem. In particular, "CAN NOT READ: BLK 1" is one of the more ominous messages we have seen. It indicates either (A) the partition tables have been destroyed, (B) there are hardware problems with the drive, or (C) the boot floppy is bad. If the same message is printed from different boot floppies, and it remains after checking the drive cables, call AT&T for help. The message "hard disk: Bad sanity word in VTOC on drive 0" is a virtual guarantee of corrupted partition tables, and the procedures for their repair are dangerous, intricate and beyond the scope of this manual; call AT&T for help. Once fsck grants the filesystem a clean bill of health, it is ready to be mounted. Rather than take up space for a handful of common commands, AT&T has rolled several of them into one: fsys. It is undocumented and appears to only be used on the boot floppy. Fsys takes a handful of options, not all of which are interesting to us in standalone mode. Used in the install scripts for a handful of filesystem-related duties, we will use it simply as a replacement for mount(1m) and umount(1m). To mount the hard disk's root filesystem onto the floppy's /install directory, do: # fsys -m /install /dev/idsk00 Fsys will complain on an error, and this brings us to a serious bug in this program: if either the mount directory or the partition's device name are invalid for any reason, the error message will always point to the partition device name. This can - 6 - be, to put it lightly, "misleading". Anecdote: we were running a standalone boot on a machine whose main drive had just come back from the shop. We were being very cautious, having already had an exceedingly unpleasant experience with hardware failure on this customer's machine. When trying to mount the hard drive onto the floppy, we did: # fsys -m /mnt /dev/idsk00 fsys: /dev/idsk00: no such file or directory A hard-disk based UNIX on a 3B2 usually has a /mnt directory used as a floppy mount point, but the floppy UNIX does not have one (/install should be used instead). At this point, however, we were not aware of the nature of our mistake. Since the device name /dev/idsk00 was indeed found in /dev, the above error message led us to believe that the drivers could not find the hardware and the drive itself was in very bad shape (again). Ten panicky minutes later we realized that the error message was wrong, and mounting onto /install instead of /mnt worked as expected. With the hard drive's root filesystem mounted on /install, it is now fully part of the standard directory tree. While the floppy has no editor or many of the helpful tools, the root partition does, and these can be exploited. When beginning an extended standalone session on the primary drive, we have found it helpful to extend the shell's search path: # PATH=/install/bin:/install/etc:$PATH ; export PATH Now the familiar ls, ed, (but not vi) and many other commands are available. Since they will be loaded from the hard drive, execution is much faster. As an example, assume that the root password has been forgotten and the machine is basically closed. The solution suggested by AT&T's documentation (in the System Administration Utilities Guide) is to do a partial restore. The difficulty with this approach is that many important system files -- /etc/passwd, /etc/inittab, /etc/gettydefs, and others -- are overwritten in the process. Even with a full backup, this can be an unpleasant undertaking. An alternate approach will use the standalone shell. The general strategy is to mount the hard drive, edit the password file, and boot multiuser UNIX. The full procedure is: (boot standalone /unix) # fsck /dev/idsk00 # fsys -m /install /dev/idsk00 # /install/bin/ed /install/etc/passwd (edit the file in the standard way) - 7 - w q # fsys -u /dev/idsk00 At this point, the root drive is now unmounted and the system may be rebooted. We are not sure of the best way to do this, so we usually sync the disk and return to firmware with: # sync # /etc/uadmin 2 2 Uadmin(1m) is documented in the manual (you must also refer to the uadmin(2) manual page) -- the above does a normal return to the monitor (i.e., firmware). WARNING: uadmin(1m) is available from full UNIX as well but is very dangerous. Use it with extreme caution and only if you really know what uadmin does. Making a standalone boot disk ================== WARNING ================== Only do this on backup copies of the disks, NEVER to the main Essential Utilities Disk. ================== WARNING ================== The Essential Utilities Disk 1 contains many files needed by the automatic restore/upgrade procedures, but for standalone work, many are not needed. After working with these disk for some time, we were able to narrow down what is helpful to have on the disk and what is not. The following procedure (run from multiuser mode, signified by the ## prompt) will convert an Essential Utilities disk to a standalone boot disk. (from hard disk UNIX) ## fsck /dev/dsk/c0d0s5 ## mount /dev/dsk/c0d0s5 /install ## cd /install/inst/bin ## mv fsys pdinfo swap ttyset ../../bin ## cd /install ## /bin/rm -rf inst ## cp /bin/ed /install/bin ## cp /etc/fsdb /install/etc ## cat > /install/inittab is:s:initdefault: sh:s:respawn:/bin/sh < /dev/console > /dev/console 2>&1 ^D ## cd / ## umount /dev/dsk/c0d0s5 - 8 - While there may be other files on this floppy that are not needed, we have operated on the principle of least customization. It has been our experience that keeping the procedure simple allows it to be done on-the-fly (say, at a customer site) and minimizes the exploration required when a new operating system disk is released. In addition, it is not wise to pack the disk too tightly. The editor requires adequate space under /tmp, so an almost-full disk precludes editing all but the smallest files; this applies whether the file being edited resides on the hard drive or the floppy. Once this is done, the new disk will come up in standalone mode without the need for magic mode. In addition ed(1) and fsdb(1m) are available. The other tools mentioned (pdinfo, swap, ttyset) are helpful but not required by the basic procedures. Over time, the resourcefull standalone booter will likely develop tools that help repair damaged UNIX systems; these can often go onto these boot floppies. Remember to strip(1) files before putting them onto the disk, because the symbol table is useless and wastes precious space. It has been our experience that any version (SVR2, SVR3) of boot disk can be used with any version of hard disk UNIX without difficulty for doing simple operations such a performing filesystem checks or editing /etc/passwd. For more complex operations, such as repartitioning the hard drive or restoring the bootstraps, higher version compatibility is required. Security Considerations It should be apparent that knowledge of these standalone methods is tremendously powerful. In addition to being able to rescue a foundering machine, an unrestricted path to root has been provided as well. While all the standard rules about physical security of the computer apply here, an additional step may be taken to thwart a would-be interloper. The responsible system administrator of a machine in a hostile environment will generally change the computer's firmware password. This magic word is required before the monitor on the 3B2 motherboard will boot from a floppy, and lack of this password prevents a malicious user from simply pulling the power plug to enter firmware mode. In addition to changing the firmware password, the floppy key floppy should itself be secured. When the computer is restarted with this disk in the drive, it will clear the non-volatile RAM (NVRAM) and restore the default parameters. Because the firmware password is included in these "default - 9 - parameters", this disk should be kept out of non-trusted hands. Conclusion For those comfortable with its use, a standalone shell can be a time/lifesaver and can obviate the need for many partial and full restores. Those wishing to use the methods described here are encouraged to explore them prior to their need. The experience gained by a relaxed hour or two of investigation will be more than repaid when the machine crashes and the procedures are no longer "optional." In addition, the layout of a standard boot disk varies somewhat from release to release. While the general approach to a standalone boot remains similar, some preliminary examination may forestall unpleasant surprises when the machine conditions are less hospitable. We solicit bug reports, comments, and suggestions on this document. Please direct them to: V-Systems, Inc. 39 Brookhollow Drive Santa Ana, CA 92705-5440 (714) 545-6442 Attn: Steve Friedl Internet: friedl@vsi.com AT&T Mail: attmail!vsi!friedl Usenet: {backbones}!vsi.com!friedl - 10 - #------------------------- cut here ------------------------------------ > > 2; "WARNING: niwrite: ni_send failed - ret code=8" > We keep getting this network error repeated about every > thirty seconds that we can't track down and > after swapping several boards it is still there so I see it > as a software or protocol problem. We have one system > directly on the net (h4000 xcvr---->3b2) that doesn't > ever show it but any system on our delnii does; > (h4000------->DELNII------>3b2) - other systems on the DELNII > show no problems (uVaxII, Kinetics FastPath) > Network performance and connections don't seem to be affected. > Routed and tftpd are turned off. It is vexing. > What are the proper diagnostics to run on the net interface > and where is the info on them? sorry i cannot help you with that question.... > 3; Hard drive questions; > a; Do the 3B2's use a standard configuration hard drive? > ie: What will fit and how much is it? The thing you need to order so that you can low level format your disks is: "AT&T 3B2 Computer Maintenance Reference Manual" Select Code: 305-395 ..... Issue 2 You should be able to order it from wherever you got your existing system and doc's. If not try: 1-800-247-1212 (USA) 1-201-953-7554 (elsewhere) This manual gives pretty good service procedures for the 3b2 line 300's through 600's. Also for SCSI and XM stuff. You will also get comcodes for most of the replaceable parts. The DEVTOOLS diskette is now known as the idtools (lower case) diskette and is included in the back of the manual. I think the cose is either $50 or $100. > b; What does it take to mount a second hard drive either > in the 3b2 chassis or outside. We have a couple of > spare 30meg drives that we would like to put in > place of the floppies on a couple of systems. Can that > be done? - It looks like the cables to the hard drive > port in the back could just be pulled off and connected > to another drive, except for the little 2 wire cable > from the port to the internal drive. Also what drive > selects to use? > > c; Is there a place that rebuilds the drives at an effective > cost? > > 4; Maintenence Questions; > a; Does ATT have a mail in program analogous to DEC's > DECMAILER program? not that I know of...they do have a carry in service though althought you can order parts via mail.....call 1800-222-part > b; Is there an independent repair facility for 3b2 > board level repairs? if there is do not trust them...... > c; Are there any hardware manuals available for the 3b2/310? > > 5; Software questions; > a; Is there an 'rdump' around that will allow you to dump > to a remote (Ultrix) system. > > b; Is NFS available? try mailing to postmaster@laidbak and see if you can get an answer to that > c; Is there a csh or csh like environment available? > try ksh.....it really is nice. > > -- > Hurf Sheldon Network: hurf@ionvax.tn.cornell.edu > Lab of Plasma Studies Bitnet: hurf@CRNLION > 369 Upson Hall, Cornell University, Ithaca, N.Y. 14853 ph:607 255 7267 > I sold my Elan, got a job in science; Now, no one takes me seriously. > > -- > rich andrews rich@jolnet.orpk.il.us (yes this is a 3b2/400) ------------------------------ Date: Sun, 26 Feb 89 07:18:49 est From: len@netsys.COM (Len Rose) Subject: u3b.sources Greetings.. I hope to create u3b.sources soon,and would like to ask everyone to submit things that have been ported to the 3B2 series of systems.. Things I envision posting would be a recent release of sendmail,TeX, and other hard to port software. I have contacted someone about TeX, but haven't found anyone who has hacked sendmail (a recent version). I have tried to reach the people who were in the process of porting gcc to the machine, but haven't received any replies. At this point, any source,diffs,scripts,etc will be welcome. I don't think the u3b source news group would need to be moderated. We are all professionals within this group. If you are not receiving the u3b distribution, contact your news admin If he or she cannot help you, and you need a feed , contact me. I am in the process of conducting a propigation analysis with u3b, and will be posting the connectivity data in u3b.config as soon as the sys files stop coming in. So far, it looks great. As I expected it's being extremely well distributed within AT&T. <smile> Len -- len@netsys.com {ames,att,rutgers}!netsys!len ------------------------------ From: uunet!mcvax!acsdk!tonny Date: Sun, 26 Feb 89 09:06:31 +0100 Subject: UUCP bug not in SVR3.0. > Situation: When dialing other sites that have multiple Systems > line entries,with different baud rates,uucico fails > on the second entry because it doesn't set the baud > rate correctly in the second Systems entry. > > I.E. Anysite Any ACU 2400 etc etc etc > Anysite Any ACU 1200 etc etc etc <-- fails to set line at 1200 We are using UNIX System V Release 3.0 on a AT&T 3B2/300 and uucico works fine here. So maybe an upgrade will do ? Tonny Andersen / Advanced Computer Software / Denmark mcvax!dkuug!acsdk!tonny ------------------------------ Subject: Re: 3b2 Questions - Answers Appreciated Date: Sun, 26 Feb 89 17:30:46 GMT From: Graham Glen (Technical Manager) <qukmips!graham> Here I go in feet first as always :-) > > Questions: > > 1; Is there a way to make a bootable floppy system > so we can try to salvage systems that are having a problem > without doing the 'Essential utilities, partial restore' > route? Essentially a kernal with mount, fsck, makedev > etc so we can boot, fsck the hard drive and mount it. > Yup. Start off by copying the "Essential Utilities" disk 1. This is a bootable disk with almost everything you need on it. If you boot of the "Essential Utilities" disk you get 4 options (from memory), instead of entering 1-4 if you enter "Magic Mode" (it may be "magic mode" it's a while since I've done this), you will be put into a shell. However, the shell has almost nothing set in its environment. Some things go under different names on the Essential Utilities disk, "mount" for example is "fsys". A good precaution is to mount an Essential Utilities (EU) disk on a running machine (device /dev/dsk/c0d0s5) and hunt through for all the executables. I modified a copy of the EU disk so that instead of trying to give you the menu, it would fsck the root partition on the hard disk, mount it and then copy all of the really important files which might be corrupt to backup names and then overwrite them. So things like /etc/passwd & /etc/inittab would all be replaced by minimal entries to get the system back up. The copied EU disk would then unmount the hard disk and call /etc/uadmin to re-boot the machine. If it's only your kernel that is trashed, from firmware you could try re-booting from /etc/system, or if that fails you can boot from /boot/KERNEL. > 2; "WARNING: niwrite: ni_send failed - ret code=8" > We keep getting this network error repeated about every > thirty seconds that we can't track down and > after swapping several boards it is still there so I see it > as a software or protocol problem. We have one system > directly on the net (h4000 xcvr---->3b2) that doesn't > ever show it but any system on our delnii does; > (h4000------->DELNII------>3b2) - other systems on the DELNII > show no problems (uVaxII, Kinetics FastPath) > Network performance and connections don't seem to be affected. > Routed and tftpd are turned off. It is vexing. > > What are the proper diagnostics to run on the net interface > and where is the info on them? As a guess, might you have a damaged or somehow below spec transceiver drop cable? To run diagnostics on the NI card, go to firmware and boot dgmon. The "Systems Administrators" manuals should give you enough to get started on this one, but not much more. Of course, the diagnostics are probably written so they never test for any REAL error conditions. :-) > > 3; Hard drive questions; > a; Do the 3B2's use a standard configuration hard drive? > ie: What will fit and how much is it? You should be safe with fitting any ST506 drive into a 300,310 or 400. I don't know what sort of prices AT&T charge over there, but over here things like disk upgrades (supplied by Olivetti) are frighteningly expensive. So much so that it's cheaper to buy and fit the drives yourself, and if every drive went bang and you had to replace it with a new one you'd still end up paying less. I can't help with any of your other questions I'm afraid, but I'm sure somebody else out there will be able to. Graham -- Graham Glen | Voice +44 1 371 5755 Quadratron Systems (UK) Ltd. | +44 836 380006 (mobile) --------------------------------------+---------------------------------------- {quad1,qnorth,qswiss,ukc,attunix!uel}!quaduk!graham ------------------------------------- To join this group or have your thoughts in the next issue, please send electronic mail to Ken Davis at the following address; {pacbell,netsys,hoptoad,well}!lamc!info-3b2-request The views expressed in Info-3b2 Digest are those of the individual authors only. ********************* End of Info-3b2 Digest *********************