Nebula/nebula.bin/Newsletters/GEnieUnixNews/unxnl-12.91

Text File | 1993-01-27 | 29KB | 624 lines

          _  _  _   _  _   _
         // // //| // // \//     N E W S
        //_// // |// //  /\\     Vol 2, Issue 6 - December 1991
      R o u n d T a b l e (tm)

   Items of interest to participants of the GEnie Unix RoundTable

      The RoundTable SysOps are:
      Andy Finkenstadt....ANDY       Rick Mobley.........LRARK
      Gary Smith..........GARS       Brian Riley.........DELPHI
                  All Unix SysOps.....UNIXSYSOPS$
   We strongly encourage you to contact any or all of us if you have -ANY-
 comments or suggestions. This is -YOUR- RoundTable. We are here to make
 your participation as pleasant and beneficial as possible.

 ED: editor notes - net notes (GARS) Gary Smith
 --

   Recently, for a very short time, GEnie posted a survey to determine
 the level of interest in a GEnie gateway to internet.  I hope all of you
 responded to this survey who could.  Whether you voted 'yes' or 'no' is
 important; but more important IMHO is informed opinion from those GEnie
 users most likely to understand and appreciate the implications that such
 global connectivity as access to internet grants. There is also an added
 burden of personal responsibilty I hope will not escape consideration by
 management and user alike.

   The Unix community is tightly bound to internet having spawned this tool
 in response to a need, which seems to be the underlying thread that is the
 essence of all Unix tools. Should GEnie include internet access in their
 growing list of services it is the Unix RoundTable users who will be looked
 toward to set the standard for conduct.

   The Unix RoundTable has long recognized internet as an extension of the
 operating system and has from the beginning provided bulletin board areas
 and library files to support this concept.  If for some reason you have not
 had a need or desire to avail yourself of the mail and information access
 internet affords I invite you to examine the many tutorials available in
 our library as a first step toward global communication.  I applaud GEnie
 for considering this additional service and for soliciting comment.  We of
 the Unix RoundTable stand ready to assist should GEnie management swing open
 the gate.
 ---------

 UUCP/UseNet: (GARS) Gary Smith
 -----------
  If you have not explored Usenet and are considering doing so, the
  following files are HIGHLY RECOMMENDED READING.:

 Number: 68  Name: INTERNET.ARC
 Address: J.JIMENEZ                Date: 891202
 Approximate # of bytes: 32760
 Number of Accesses: 197  Library: 1
 Description:
 I guess this is sort of a novice's intro to Internet. Interesting file.
 Keywords: INTERNET,INTRODUCTION,NOVICE
 ---------

 Number: 268  Name: NEWS_GROUPS.11.89
 Address: GARS                Date: 900211
 Approximate # of bytes: 17640
 Number of Accesses: 50  Library: 15
 Description:
 list of news groups available on Usenet as of Nov 1989.
 Keywords: news,groups,usenet
 ---------

 Number: 921  Name: DOMAIN.INF
 Address: D.KOZINN                Date: 900809
 Approximate # of bytes: 7560
 Number of Accesses: 77  Library: 15
 Description:
 This file was originally written by myself as an explaination for
 some GEnie folks about how "net" mail gets from place to place. If
 you already know something about the internet, uucp, and domains,
 this file is probably too basic for you, but if you've ever wondered
 "What kind of an address is monymsys![e-mail]", this may help
 you to understand.
 Keywords: domain,uucp,internet,pathname,mail
 ---------

 Number: 1393  Name: NEWSMAN.ZIP
 Address: GARS                Date: 910112
 Approximate # of bytes: 54180
 Number of Accesses: 96  Library: 15
 Description:
 Usenet User's Manual, with access information, news
 groups, reading and posting, conventions ad etiquite.
 Keywords: usenet,yser,manual,access,use,reading,sending,news,groups
 ---------

 Number: 2376  Name: E-MAIL.GUIDE
 Address: GARS                Date: 911115
 Approximate # of bytes: 18688
 Number of Accesses: 42  Library: 4
 Description:
 John Chew's excellent guide, tutorial and reference for using
 various e-mail systems and how to gateway between them.
   Excellent and recommended.
 Keywords:
 e-mail,internetwork,gateway,guide,internet,
 CIS,MCI-Mail,Western,Union,peacenet
 ---------
 ---------

 Upload Contest Winner Announced   (ANDY) Andy Finkenstadt, lead SysOp
 And new upload contest begins
 -------------------------------

 The Unix RoundTable is proud to announce the winners of the
 November 1991 upload contest.

 Roy Bernstein posts his frequently updated source of information
 about the upper management of technical companies: where to reach
 them, who they are, what their phone numbers and fax numbers are,
 and the like. This is a valuable resource during the job hunt and
 for making contacts in other companies which may be doing the
 same kinds of things as you do in your daily job.  Because Roy
 won both the "most bytes uploaded" and the "most files uploaded"
 contests, he will be awarded two free days of time in the Unix
 RoundTable for his enjoyment, days to be picked at his option.

 And the upload contest continues fresh in December.  Here's your
 chance to win one or two days of totally free time in the Unix
 RoundTable.  The file CONTEST.RULES contains the complete rules
 and regulations for the contest; it's only 5000 bytes and is a
 text file so you can look at it, download it, and print it out
 for safe keeping without requiring any other archiving programs.

 Let the best person win.
 ---------
 editor's note:
 If you wish to enjoy some free access time on GEnie, all you have to
 do is start sharing some of your public domain files. Non-prime time
 uploads are free time themselves - so share!
         Gary
 ---------

 EVENTS events worth noting
 ------

  Upcoming subjects for Unix RoundTable Conferences
  -------------------------------------------------

 Each week the Unix Roundtable Sysops are available in a real-time
 conference on Tuesday evenings at 9:30pm Eastern Standard Time
 for about an hour.  Starting at the end of December we will be
 having specific subjects set aside as the topic for conversation
 and transcripts will be available from the library of the
 discussion. (The Unix RT Conference Transcripts can be found in
 the software library on page 160 item 2.)

  Tue Dec 31:   New Years Predictions for Unix: where is it going to
                go in 1992?

  Tue Jan 07:   What's in a shell? (Bourne shell, C-shell, Korn
                Shell, Born-again Shell, etc.)

  Tue Jan 14:   General Help, Question & Answer Sessions.
                Concentration: communications to/from Unix computers.

  Tue Jan 21:   Writing portable programs for all versions of Unix,
                and even MS-DOS.

  Tue Jan 28:   General Help, Question & Answer Session.
                Concentration: coding practices in C.

  Tue Feb 04:   Using commercial applications under Unix.
                (WordPerfect, Oracle, Lotus 1-2-3, XTree, and others)

  Tue Feb 11:   General Help, Question & Answer Sessions.
                Concentration: getting information from the world,
                Usenet and other topics.

  Tue Feb 18:   Building and installing your first Unix System.
                Experiences in making inexpensive computers.

  Tue Feb 25:   General Help, Question & Answer Sessions.
                Concentration: installation and upgrading Unix
                systems, disk drives, and modems.
 ---------

 FAST and NASTY, DOWN  and  DIRTY:  quick  fix scripts that do something
 --------------------------------

 Automating anonymous ftp: (GARS) Gary Smith

 The following script was snarfed off of UseNet comp.unix.shells, and gives
 a nice crisp way to automate ftp even further:

 In article <[e-mail]> [e-mail] (Dr K. V. Rao) writes:
 >I am looking for a shell that automate the following sequence every day
 >at a set time -
 >ftp to a site with a fixed userid and pw
 >upload a specified file from a directory
 >then quit ftp
 >edit the file to delete the text and save the file with one line.
 >
 >Repeat the process next day and every day at a given time.
 >
 >Thanks for your help in this regard. Please forward your replies to
 >[e-mail] and I'll post the shell if there is sufficient
 >interest.
 >
 >K. V. Rao

 Nuts, it's far too short for summarizing and far too useful..

 This little script has been posted previously (part of FAQ, anyone?) hence
 the post.

 Usage: ftpget <file>

 #! /bin/sh
 # ftpget -- script to automatically invoke ftp and get specified file
 PATH=.:$HOME:/usr/local/bin:/usr/ucb:/bin:usr/bin export PATH
 ftp -n <host> <<EOF
 user anonymous <passwd>
 binary
 cd path
 get $1
 EOF
 exit 0

 --
 G. Roderick Singleton ([e-mail]),
 System and Network Manager, JTS Computers
 ---------

 Peripherally Speaking:  Telebit setup (ANDY) Andy Finkenstadt
 ---------------------

  -- Synopsis --

 Setting up the Telebit T2500 family modems for use with UUCP,
 Zmodem downloading, Xmodem uploading and downloading, and normal
 usage really is doable.  Here's how.

  -- Theory --

 The T2500 from Telebit Corporation (1-800-TELEBIT) is an
 excellent quality modem designed for fast data transfers between
 Unix (and many other) computers while providing backward
 compatibility for the more traditional modems using 2400 baud and
 below.  In addition, the T2500 provides V.32 and V.42
 capabilities which encompass some of the latest international
 standards for modem communications.  V.32 is a "modem tones" 9600
 baud standard, and V.42 is a link-layer error correction and
 detection software (but usually implemented in the hardware of
 the modem) standard.  Two newer standards have recently been
 approved by the CCITT,the international telecommunications agency
 in charge of such things, called V.32bis and V.42bis.  'bis'
 means 'more' in latin, and indeed these protocols are more than
 their former predecessors.  V.32bis encompasses "modem tones"
 with a modulation rate of 14,400 baud, and V.42bis encompasses
 two compression software standards including the MNP-5 (Microcom)
 and LAP-M (Hayes) ones.  The new Telebit T3000 implements these
 newest standards but drops one important capability: PEP mode.

  -- Telebit's PEP --

 Years before the CCITT came out with the draft (before-approval)
 standards the engineers at Telebit created a new method of
 transmitting data across normal voice-quality phone lines, called
 PEP mode.  PEP stands for Packetized Ensemble Protocol and was
 (and still is) quite an advancement over the state of the art in
 modem communications for that time.  PEP operates by using as
 much of the quality part of a phone line as it can and ignoring
 the unusable portions of it, whereas V.32 has just one way of
 transmitting data and cuts back on transmission speed to
 compensate for a poor quality phone line.  A typical PEP
 connection will net about 14,500 bits per second of throughput,
 compared to 9,600 bits per second with V.32 and 14,400 bits per
 second with V.32bis - before compression.  Both PEP and the V.32
 standards benefit from the software data compression in MNP5,
 LAP-M, V.42, and V.42bis.

 Because only Telebit modems can use PEP without a license from
 Telebit Corporation (the PEP technique is patented), Telebit went
 one long step farther and added internal support for various file
 transfer protocols which allowed the modem to "spoof" the two
 connected computers into thinking the other computer is really
 fast and that it's okay to send more data to the other computer.
 The Telebit modem then talks to the other Telebit modem in its
 own faster method and sends the data across the phone line
 without errors.  This results in orders of magnitude faster
 response time and file transfers - and since time is money when
 calling long distance, the modem pays for itself over the long
 term.

  -- The assumptions --

 First, I run an Interactive UNIX 386 platform with 16 megabytes
 of RAM, 1,500 megabytes of disk storage, and a 24-port Equinox
 Megaport serial board.  Because the Megaport handles high-speed
 serial communications excellently, I have chosen to fix (or lock)
 the transmission rate between the modem and the computer at
 19,200 baud regardless of the actual modem connection rate.  This
 requires either software (Control-S/Control-Q) flow control or
 hardware (CTS/RTS) flow control; flow control is designed to
 throttle back on the rush of data to match the effective
 transmission speed rather than the actual speed.

 Second, I use Chuck Forsberg's (GEnie mail: CAF) excellent serial
 communications package Pro-YAM which implements a full-featured
 script language (indeed, Chuck's bulletin board Telegodzilla is
  written entirely in Pro-YAM's script langauge) and many file
 transfer protocols including Xmodem, Ymodem, Zmodem, Kermit, CIS
 Quick B and B+, and many forms of ASCII transfer.  Commands that
 I demonstrate below reflect usage of Pro-YAM.

 Third, I connect daily with GEnie via a local telephone call,
 with UUNET (Falls Church, VA) twice daily via a long distance
 call, and with a local BBS every month or so.

  -- Setting up the modem --

 The first step to gaining 100% connectivity is to establish the
 settings in the non-volatile RAM of the Telebit modem.  Using a
 program such as cu or tip (supplied with most versions of Unix)
 or Chuck Forsberg's Pro-YAM for Unix establish a connection with
 the Telebit modem.

   $ yam
   Yet Another Modem by Chuck Forsberg
   Copyright 1990 Omen Technology Inc All Rights Reserved
   386/ix Unix Pro-YAM Version 1.2 TurboDial 2.33 Rev 10-11-90 S/N: 75232
   <<<: port ttyaX                      (my modem lives on port 24)
   <<<: sp 19200                        (and talks fast)
   Using ttyaX at 19200 b.p.s.
   <<<: t                               (talk to the modem)

 The first step is to reset the modem and set some parameters to
 reflect our setup:
   *  19200 baud fixed rate
   *  RTS/CTS hardware flow control
   *  Use compression during MNP connections
   *  Allow non-MNP connections
   *  Allow 60 seconds to connect to the remote computer
   *  Make the modem be quiet except when responding to commands
      (important for incoming calls)

   <<<: t
   AT&F1                                (reset to factory defaults)
   OK
   AT E0 V1 W0 X3 T Q4 S1=1 S7=60 S51=5 S52=2 S66=1 S68=3 S92=1 S95=2 S131=1 &W
   OK

Now everything is ready except for the unix connection
information.

  -- Setting up the Unix computer --

 Using the sysadm command (or modifying /etc/inittab by hand)
 establish a uugetty on the modem port (if you want incoming calls
 answered) with a gettydefs definition for 19200 baud.  Make sure
 to use the -r option otherwise you will never be able to call out
 - the uugetty will have already locked the modem down.

 Now, starting with the /usr/lib/uucp/* files, make sure the
 following lines occur in the corresponding files:

   #/usr/lib/uucp/Devices
   # automatic call unit, ttyaX is the port, ",M" says ignore the modem control
     lines
   # until after connection to the remote, use 19200 baud, use the tbfast
     Dialer, and
   # all tbfast needs is the phone Token.
     ACU ttyaX,M - 19200 tbfast \T

   #/usr/lib/uucp/Dialers
   # establish UUCP spoofing in the modem, the following line is ALL ONE LINE
   tbfast =,-, "" \M\dA\pA\pA\pAT\r\c OK\r \
       ATS68=0S111=30S7=60S50=255S58=0DT\T\r\c CONNECT \m\c

 Now edit your /usr/lib/uucp/Systems file to contain the correct
 entry for the remote uucp system and that's all there is to it.

  -- In conclusion --

 Setting up the Telebit modem takes some work, forethought, and
 understanding of asynchronous communications - but it is possible
 to have a heterogenous setup which works adequately with both
 dial up, dial out, and computer-to-computer communications.

 If you find that there are questions raised from this article,
 please feel free to drop by the Unix RoundTable's Bulletin Board
 Category 7: Communications and ask your questions in a topic
 there.
 ---------

 Telebit and the 3B1 (GARS) Gary Smith
 -------------------

 The 3B1 OBM (On-board modem) and a Telebit TrailBlazer+ are a notoriously
 bad mix. The tone generated by the 3B1 OBM and the TB+'s phase locking
 mechanism work at odds with one another. In response to help on the bug,
 by M. R. Murphy came this super fix that all 3B1 users should file and
 save "JUST IN CASE".

 >[Friend has difficulty between 3B1's OBM and trailblazers]

 This C program, in addition to setting the line to tone dial (mine won't
 thru "normal" channels for some reason, sets PIOCOVSPD on the modem which
 permits it to talk to trailblazers.

 #! /bin/sh
 # This is a shell archive.  Remove anything before this line, then feed it
 # into a shell via "sh file" or similar.  To overwrite existing files,
 # type "sh file -c".
 # The tool that generated this appeared in the comp.sources.unix newsgroup;
 # send mail to [e-mail] if you want that tool.
 # Contents:  phfix.c
 # Wrapped by clewis@ecicrl on Mon May  6 00:57:58 1991
 PATH=/bin:/usr/bin:/usr/ucb ; export PATH
 echo If this archive is complete, you will see the following message:
 echo '          "shar: End of archive 1 (of 1)."'
 if test -f 'phfix.c' -a "${1}" != "-c" ; then
   echo shar: Will not clobber existing file \"'phfix.c'\"
 else
   echo shar: Extracting \"'phfix.c'\" \(1136 characters\)
   sed "s/^X//" >'phfix.c' <<'END_OF_FILE'
 X/*     Sample program for bashing the OBM into tone dial and
 X       setting PIOCOVSPD to permit talking to certain modems
 X       (particularly telebits).
 X       The documentation mentions 2.3% speed change for PIOCOVSPD.
 X       That's all I know.
 X
 X       You are free to do whatever you wish with this code, but
 X       please leave this comment in.
 X
 X       Chris Lewis, [e-mail], Jan 2 1991.
 X */
 X#include <stdio.h>
 X#include <fcntl.h>
 X#include <sys/phone.h>
 X
 Xmain(argc, argv)
 Xint argc; char **argv; {
 X    int f;
 X    struct updata upd;
 X    f = open("/dev/ph1", O_RDWR | O_NDELAY, 0);
 X    if (f < 0) {
 X       perror("/dev/ph1");
 X       exit(1);
 X    }
 X    ioctl(f, PIOCGETP, &upd);  /* retrieve Phone parameters */
 X    upd.c_lineparam &= ~PULSE; /* reverse the sense to set to pulse dial */
 X    upd.c_lineparam |= DTMF;   /* reverse the sense to set to pulse dial */
 X
 X#ifdef NEVER
 X    upd.c_feedback |= SPEAKERON;
 X    upd.c_feedback |= LOUDSPK;
 X    ioctl(f, PIOCDISC, &upd);  /* apply PIOCOVSPD for talking to some modems*/
 X#endif
 X
 X    ioctl(f, PIOCOVSPD, &upd); /* apply PIOCOVSPD for talking to some modems,
 X                                  eg: Telebits */
 X    ioctl(f, PIOCSETP, &upd);  /* set phone parameters */
 X}
 END_OF_FILE
   if test 1136 -ne `wc -c <'phfix.c'`; then
     echo shar: \"'phfix.c'\" unpacked with wrong size!
   fi
   # end of 'phfix.c'
 fi
 echo shar: End of archive 1 \(of 1\).
 cp /dev/null ark1isdone
 MISSING=""
 for I in 1 ; do
     if test ! -f ark${I}isdone ; then
         MISSING="${MISSING} ${I}"
     fi
 done
 if test "${MISSING}" = "" ; then
     echo You have the archive.
     rm -f ark[1-9]isdone
 else
     echo You still must unpack the following archives:
     echo "        " ${MISSING}
 fi
 exit 0
 --
 Chris Lewis, Phone: [phone], Domain: [e-mail]
 UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
 ferret-request@eci386; Psroff (not Adobe Transcript) enquiries:
 psroff-request@eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!

 Here is an interesting follow-up from Chris regarding implementation of PHFIX
 (the C progarm above) and comments about phfix and HDB on a 3B1...

 Dave Snyder wrote:
 |>[Mike Murphy's friend's failure to connect to a locked Telebit from the OBM]
 |I asked the same question about six months ago.  Anyway, the bottom line is...
 |the OBM on a 3B1 will not connect to a Telebit if the modem is using locked
 |interface speeds.  The only way for an OBM to connect to a Telebit is to have
 |the Telebit allow auto-bauding.

 Bruce Lilly wrote:
 |This is a well-known problem with Telebit modems (at least the TB+) when
 |operated with the interface speed locked. The Telebit puts out a
 |non-standard signal, which causes the 3B1's built-in modem to receive
 |garbage (the 3B1's OBM is rather intolerant of non-standard signals).
 |Telebit refers to this bug as "bit-shaving".

 |Your options are:
 |1)    don't operate the Telebit's with interface speed locked
 |2)    try to get Telebit to fix the problem (1-800-TEL-EBIT) (good luck)
 |3)    trade in the Telebits for another brand of modem
 |4)    use an external modem on the 3B1 which will accept the Telebit's
 |    non-standard timing

 The phfix program I just posted solved Mike's friend's problem - I just
 got e-mail from him thanking me for it.  I've been using it to connect to my
 feed (a Sun with a locked speed T2500) for about 5 months.The principle trick
 is the PIOCOVSPD ioctl.About 6 months ago someone posted something about a OBM
 utility that he was writing but hadn't finished and mentioned the PIOCOVSPD
 ioctl in passing, which is where I got the idea to try it.  Thank you whoever
 you were.

 Phfix was written without docs (so I had to guess at the invocations) to
 solve the TB problem as well as for some reason the builtin software could
 no longer set the modem to tone dial.  It could use some cleanup by someone
 who knows the right ioctl invocations.  On my system I've installed the
 invocation of phfix in the /etc/rc near the end.  It seems to work
 "permanently" - ie: it only has to be invoked once on boot.

 However, I seem to remember someone telling me that phfix will not work
 with HDB UUCP on the 3b1 because HDB clobbers the setting each time it
 starts.  However, I've experimented a bit, and have found that you
 can invoke phfix *during* the uucico run to clear the problem.  Ie:
 you start up uucico, and you notice that it's starting to alarm out -
 at this point you can invoke phfix and the uucico will resync and continue
 normally.  So, you might be able to kludge in a mechanism by which
 phfix is invoked a fixed time after you've fired up uucico. Alternately, you
 could modify phfix into a "daemon" to sit quiescent, stat'ing (or access())
 the LCK* file[s] for the TB sites every 30 seconds or so.  Once it notices a
 LCK file for the site[s] that has the locked speed TB, then it starts
 PIOCOVSPD'ing the OBM every 10-15 seconds for 2 minutes.  That oughta fix it
 without putting too much load on the machine.  Alternately, those guys
 who seem to like doing binary debugging might want to work out a binary
 patch for HDB.

 I'll be installing HDB one of these days, so maybe I'll get to
 kludge phfix.

 Further, it may very well be that phfix will work "normally" even with
 HDB for incoming calls - because the uucico on the receiving side is
 unlikely to be as "violent" with its ioctls.

 If anybody alters phfix.c into a HDB daemon, or simply cleans it up, please
 let me know.

 BTW: My feed has informed me that he's set his TB to lock at 1200
 when it calls my 3b1.  He doesn't remember why he did that.  But it
 is certainly locked at 9600 (or is it 19200 I disremember) when I call
 his TB.
 --
 Chris Lewis, Phone: [phone], Domain: [e-mail]
 UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
 ferret-request@eci386; Psroff (not Adobe Transcript) enquiries:
 psroff-request@eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!
 ---------

 Why Modems Go Worng ..er.. wrogn: Comm humour (LRARK) Rick Mobley
 --------------------------------       snarfed off Usenet

 Traffic and the time to read it has been slow for me this month,
 but I did run across a couple of interesting notes to share with
 all of you. Read on:

 Geoff's Top Ten Causes of Lost Data in High Speed Modems:

 (Please forgive that this is in reverse order from 'normal' top 10 lists)

 (1) RTS/CTS handshaking not enabled in the modem.
 (2) RTS/CTS handshaking not enabled in the terminal program.
 (3) XON/XOFF handshaking not disabled in the modem.
 (4) XON/XOFF handshaking not disabled in the terminal program.
 (5) Cable does not support pins 4 and 5.

 (These next 3 are apply to PC-compatible systems only)

 (6) Swapping a 286 between real & protected mode causes lost IRQs.
 (7) Perstor ARLL controllers shut off IRQs during long transfers.
 (8) DOS 'multitasking' swaps comm program's serial driver out of memory
     (and can't put it back before another byte arrives).

 (9) Slow CPU or heavily loaded system can't handle incoming data rate.

  ... and, of course, the ultimate excuse:

 (10) God has decided that those computers talk just too damned fast.

 --
 Geoffrey Welsh                  606-66 Mooregate Crescent
 Operator, Izot's Swamp BBS      Kitchener, Ontario, Canada N2M 5E6
 Data: [phone]            Voice: [phone]
 [e-mail], or [xenitec.on.ca|m2xenix.psg.com|nstar.rn.com]!zswamp!root
 A standard is a device by which we cause many things to fail in the same way.
 ---------
 ---------------
   REMINDER - This newsletter is being sent to you 'by request'. If you do
 not wish to keep receiving it, e-mail a stop notice to GARS. On the other
 hand, we would very much appreciate it if you would pass the word that we
 do distribute this item near the tenth (10th) of the month of issue to any-
 one on GEnie who requests it, and will gladly add any name that is requested
 via the same route... e-mail to GARS.
   P L E A S E  also remember contributions are most welcome. Please e-mail
 items and/or suggestions to GARS.

 (EOF)

  Trademark and Copyright notices:
  Unix is a Trademark of UNIX System Laboratories, Inc.; GEnie, LiveWire, and
  RoundTable are Trademarks of General Electric Information Services  Company;
  Xenix and ms-dos are Trademarks of  Microsoft  Corporation;

 The contents of this newsletter are copyright (c) 1991 and may be copied whole
 or in part only if  original  credit is included. The GEnie UNIX RoundTable is
 not affiliated with AT&T or UNIX System Laboratories, Inc.