HDTenEightyP/NetNews huggingface dataset:
From: jrsalb1!tgn@brspyr1.brs.com (Tim Northrup)
Newsgroups: biz.sco.general
Subject: Re: Shell script poser (expr oddness ...)
Date: 13 Dec 92 01:07:50 GMT
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Cc: davidf@golem.waterloo.on.ca (David J. Fiander)
Precedence: bulk

> >while read Line ; do
> >	First=`expr "${Line}" : '\(.\).*' | tr '[a-z]' '[A-Z]'`
> >	Rest=`expr "${Line}" : '.\(.*\)' | tr '[A-Z]' '[a-z]'`
> >	echo "${First}${Rest}"
> >	done
> >
> 
> You were lucky that you didn't pass it a file which had a line
> beginning with one of the words 'match', 'substr', 'length', or
> 'index', because then you would have got
> 
> >	expr: syntax error
> >	expr: syntax error
> 
> - David

Wow ... I have never seen this before.  Easily fixed by switching to:

> >	First=`expr "X${Line}" : '.\(.\).*' | tr '[a-z]' '[A-Z]'`
> >	Rest=`expr "X${Line}" : '..\(.*\)' | tr '[A-Z]' '[a-z]'`

But what do these keywords do?  What *is* their proper syntax?
And why are they not documented (at least in my Xenix doc set)?

Very strange ...

	-- Tim
-- 
  Timothy G. Northrup                     | JRS Clinical Technologies, Inc.
 -----------------------------------------| RD 2 Box 49, Rock Road
  ...!rutgers!brspyr1!jrsalb1!tim         | Berne, NY  12023-9607
From: mike@pacsoft.com (Mike Stefanik)
Newsgroups: biz.sco.general
Subject: Performance degradation under SCO UNIX
Date: 20 Dec 92 09:04:57 GMT
Organization: Pacific Software Group, Riverside, CA

This posting is on behalf of a friend of mine who is having a problem
with an SCO UNIX upgrade.  A customer of his originally had a 486/33
with 16M of memory and a 1G SCSI drive.  Recently, the system was upgraded
to a 486/50 with 32M of memory and an additional 1G drive was added. The
upgrade was principally done because the customer wanted to network their
existing PCs with the UNIX box (using PC-Interface by Locus) so that
their business could be put "under one roof". Unfortunately, the system
is now crawling along at a snail's pace.

Oh, yes, before I forget, it's a pretty standard box. UNIX 3.2v4.1,
has a Bustek SCSI, and I believe a couple of Equinox 24-port boards.
They currently have about 30 or so dumb terminals, about 15 PCs and
around 8 printers (HPLJs and CI line printers).

I've taken a brief look around, and things seem to be in order. They've
got all of their UNIX stuff on one disk, and all of their DOS stuff on
the other. The "standard" kernel paramters seem to be reasonable (NBUF,
NHBUF, NINODE, etc.) and sar never seems to show anything outrageous
(cpu time, cache hits, etc.) and the system has never swapped any processes
out. However, users are complaining that when they start some applications
(the most frequent complaint is about Lotus 123) -- even when there are
very few people using the machine, such as on the weekend -- things will
periodically slow to a crawl.  There haven't been any panics or warnings,
just lethargy.  A reboot seems to clear things up temporarily.

His next step is to "camp out" on the box, but I thought that I would
ask you good folks for any and all suggestions. I seem to (fuzzily) recall
a discussion about poor system performance when memory was increased, but
I don't know if it applies here.  Your input is greatly appreciated, and
may help Rob from getting any more gray hairs. :-)

-- 
Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike  (909) 681-2623
Pacific Software Group, Riverside, CA
Newsgroups: biz.sco.general
From: alex@tsmnet2.uucp (Alex Mason)
Subject: Rdist for SCO
Organization: E-Systems, Melpar Division
Date: Wed, 16 Dec 1992 17:53:04 GMT

Can anyone tell me where there is more documentation on rdist that came 
with TCP 1.2 other than the man page (woefully short) :-{. Does rdist talk to
a daemon? Does it require certain versions of TCP on the remote hosts? Does
rdist use remote commands to do its work?

I get the following message trying to rdist from a ODT 2.0 system to a 3.2.2
system

rdist: connection failed: version numbers don't match


Thanks in advance,


-- 
Alex Mason
E-Systems, Melpar Division
UUCP:       ..uunet!melpar!amason
Internet:   amason%melpar@uunet.UU.NET
Newsgroups: biz.sco.general
From: harris@scorch.apana.org.au (Michael Brown)
Subject: Re: Creating tar archive of large numbers of files...
Organization: Craggenmoore public Unix system , Newcastle , Oz
Date: Wed, 16 Dec 1992 21:08:14 GMT

doublec!billk@uunet.UU.NET (William K. Karwin) write

|Under Unix, I use /etc/mvdir, but I guess that isn't available on Xenix.

       I'm not so sure about that . I have /etc/mvdir in  my  copy  of
       xenix.

-- 
 .-------------------------------------------------------------------------.
 |             Michael  Brown  at Craggenmoore Public Access Unix          |
 |     harris@scorch.apana.org.au             Good Luck on your mission.   |
 |"Mother please, is it just a disease, that has them breaking all my laws.|
 |    Check if you can disconnect the effect and i'll go after the cause. "|
 `--------------------------------------------- Peter Gabriel -------------'
Newsgroups: biz.sco.general
From: briank@ars2.uucp (D. Brian Kimmel)
Subject: Re: Shell script poser
Organization: Automated Retail Systems, Seattle, Wa
Date: Mon, 14 Dec 1992 22:10:46 GMT

In <9212131822.AA01323@jpradley.jpr.com> Jean-Pierre Radley <jpr@jpradley.jpr.com> writes:

>Anthony P Lawrence writes:

>> davidf@golem.waterloo.on.ca (David J. Fiander) writes:

>> : According to Tim Northrup <jrsalb1!tgn@brspyr1.brs.com>:

>> : >:
>> : >while read Line ; do
>> : >	First=`expr "${Line}" : '\(.\).*' | tr '[a-z]' '[A-Z]'`
>> : >	Rest=`expr "${Line}" : '.\(.*\)' | tr '[A-Z]' '[a-z]'`
>> : >	echo "${First}${Rest}"
>> : >	done

>> : You were lucky that you didn't pass it a file which had a line
>> : beginning with one of the words 'match', 'substr', 'length', or
>> : 'index', because then you would have got

>> : >	expr: syntax error
>> : >	expr: syntax error

>> His script was not using awk, and wouldn't object to those
>> (awk) keywords.  

>Have a look around the local landscape, Tony; those four words are also
>'expr' keywords...

I saved the script to a file, test.sh, and executed it after editing
out the non-script portion.  I did sh test.sh and also ksh test.ch.
I get no expr errors in the execution.

When I replaced the first line ':' with '#' and did csh test.sh, I
got a syntax error on the 'while' which is hardly surprising.

My man page for expr says nothing about 'match', 'substr', 'length', or
'index'.  It does, however, mention that the ':' is the match character.

Are there perhaps two implementations of 'expr' involved here?
How about the shells involved; are they sco's sh and ksh?

What gives?  When two experienced SCO users post opposite results,
something must be very misleading indeed.

Hoping to learn how to write more portable software,
Brian
-- 
D. Brian Kimmel           /    briank@ars2.UUCP   \   The Emerald City....
Director of R & D        \  Voice  (206) 325-8922  / Seattle, Washington.
Automated Retail Systems  \  Fax  (206) 325-9127  / Standard disclaimer(s).
From: darkshot@rock.concert.net (Michael B Garrett -- Chudys)
Newsgroups: biz.sco.general
Subject: Ok, I give up.
Date: 19 Dec 92 04:06:58 GMT
Distribution: usa
Organization: Wait, I had it here somewhere...

Ok. My kernel is tuned to an RCH, buffer space is fine, I have plenty
of RAM (16 MB) and just 4 users max o ODT 2.0, but:

Every odd now-and-again I get "Panic: kernel mode trap 00000000x00000000
and it dumps its guts into the swap.

If you don't turn the machine off before trying a reboot, it does the
same thing when it tries to startup scologin. USUALLY this does no harm,
but is always annoying- and twice it's blown the whole system.

I've run scsibadblk, booted under dos and run Q&A Plus for 20 hours straight
looking for marginal RAM problems- and nothing shows itself. It HAS to be in
the hardware; I've got ODT 2.0 running on >10 machines; this is the only one
that does it. 

Stream space is fine, too. ANybody ever seen this happen before? I'm at a loss.
Thank whatever gods there be that it's mine, and not a client's....B-)

'Shot
Newsgroups: biz.sco.general
From: frank@hact.hact.de (Frank Hoerper)
Subject: ScoMail question
Organization: Halstenbach ACT GmbH
Date: Tue, 15 Dec 1992 12:55:21 GMT


Hi,

system is ODT2.0 with smail3.1 .
If I remove /usr/mmdf/* and try to send mail with scomail the 
From: line becomes incorrect:


From ralfpc.hact.de!frank Tue Dec 15 13:15:18 1992
Return-Path: <frank@ralfpc.hact.de>
Received: from ralfpc.hact.de by hact.hact.de with smtp
	(Smail3.1.26.7 #9) id m0n1bBF-0001wlC; Tue, 15 Dec 92 13:15 MEZ
Received: by ralfpc.hact.de (Smail3.1.26.7 #11)
	id m0n1bAL-0000KxC; Tue, 15 Dec 92 13:14 MEZ
Message-Id: <m0n1bAL-0000KxC@ralfpc.hact.de>
From: frank@(null) (Frank Hoerper)
      ^^^^^^^^^^^^	
To: frank@hact
Subject: test
X-Mailer: ScoMail 1.0
Date: Tue, 15 Dec 1992 13:14:20 +0100 (MEZ)
Status: RO

test

------------------------------------

 
Is it possible to tell scomail to generate a correct
"From:" line ?

bye
 Frank
Newsgroups: biz.sco.general
From: piet@icce.rug.nl ()
Subject: Re: Telnet kicks me off! Why?
Organization: The ICCE Experience
Date: Sun, 13 Dec 1992 10:39:20 GMT
Keywords: telnet, routing, latency

As far as I have seen and solved this problem it has nothing to do
with any network related hard- or software.
Instead, the trouble is with the NBLK.... streams kernel parameters.
To see your current kernel parameters, start crash and use the command
strstat, which lists streams statistics.
If the last column, 'FAIL' has a non-zero value, you'll have to
increase the NBLK parameter for which it occurred.
I've been doing this for months now, and I beleive the system is relatively
stable now.
To configure kernel parameters, go to /etc/conf/cf.d (or the other way
around, I always forget), start ./configure and select item 11: streams
kernel parameters. And: don't forget to read the chapter tunable
kernel parameters in the administration guide. (and the release notes
which tell you what kernel parameters you should NEVER change).
After configure completed and you changed something, the kernel must be
linked (assumes the link kit installed) by typing ./link_unix. Answer y
to all the questions.

The process is iterative: as soon as you've increased one, another starts
overflowing. This one has to be increased, which
lets yet another overflow, etc. There is, however, an end to this iteration.

Note that a FAIL will occur if 80% resp 90% of the available buffers is
allocated. These percentages are set by other kernel parameters:
80% for low priority requests, 90% for medium priority requests.

Hope this helps,

Piet Plomp.
-- 
Piet W. Plomp, ICCE, Groningen University
Internet: piet@icce.rug.nl, piet@asterix.icce.rug.nl 
-- 
                      The ICCE usenet account
                   providing access to usenet news
                      for the ICCE Experience 
               _WERKEN_AAN_DE_GRENZEN_VAN_HET_KUNNEN_
Newsgroups: biz.sco.general,biz.sco.opendesktop,comp.unix.sysv386
From: darkshot@rock.concert.net (Michael B Garrett -- Chudys)
Subject: Re: HELP. Why does "talk" say "machine to confused"
Organization: Not so's you'd notice..
Date: Mon, 14 Dec 1992 03:27:01 GMT


Did you try "talk username@originatingmachinename?" I really dunno much
about SCO's implementation of "talk" (we have ODT 2.0 but never "talk")
but if experience with other SCO stuff counts, I bet it will work.

'Shot
From: fredh@teal.csn.org (Fred Harris)
Newsgroups: biz.sco.general
Subject: SLIP/CU
Date: 16 Dec 92 02:36:25 GMT
Distribution: biz
Organization: Colorado SuperNet, Inc.

Newsgroups: biz.sco.general
Subject: slip/cu
Summary: 
Followup-To: 
Distribution: biz
Organization: Colorado SuperNet, Inc.
Keywords: SLIP cu

I am attempting to establish a remote SLIP connection between two machines
using SCO Opendesktop 1.1.  Does anyone know if it is possible
to use the standard SCO cu program, while running the slip interface, to 
to remotely login into other systems? My goal is to connect my
SCO ODT 1.1 UNIX system to another system running SLIP that will
serve as a gateway to the 'Net'. 
Any and all assistance is greatly appreciated.
fredh
From: jpr@jpradley.jpr.com (Jean-Pierre Radley)
Newsgroups: biz.sco.general
Subject: Re: Tape drive on floppy controller, no fun for crowbar+restore
Date: 19 Dec 92 20:37:59 GMT
Reply-To: jpr@jpr.com
Organization: [resent by] The SCOGEN gateway and Propagation Society
Resent-From: mmdf@xenitec.on.ca
Submit-To: scogen@xenitec.on.ca
Content-Type: text
Content-Length: 1527
Precedence: bulk

Mark Saltzman writes:
> >
> >If you are like us, and use CTAR, the compression will recoup some of the
> >area for you, depending on your file types.

> Is CTAR really necessary?  We do this:
> tar cvf - <files> | compress -c > /dev/rjt0
> Or with gnu tar:
> gtar -cvf /dev/rjt0 +compress <files>

There's a world of difference between an archive of compressed files,
and a compressed archive of files.

While the space savings might be similar, the compressed archive is
vulnerable to one bad byte on the medium making everything thereafter
useless.  And a collection of distinct compressed files also lets you
retrieve any single one without having to decompress megabytes.

CTAR, besides, can be set to not bother to compress files below a
user-desired size threshhold, and to not waste time compressing
executable files, whatever their size.

In my experience, your command "tar cvf - files | compress ..." will
create a useless archive; including the 'v' flag to tar means you're
jumbling tar messages into your compressed file; tar has the unfortunate
property of writing its messages to stdout, not stderr.

[Teenswy-weensy flame: while we're discussing compression, I feel your
post was too long, in that you quoted every single line of the prior
post, even down to Willey's multi-line signature, in order to finally
make a point about just one thought in Bob's posting.
Quote less liberally, please. My CPU will then bless you. :-)]

-- 
Jean-Pierre Radley   Unix in NYC   jpr@jpr.com   jpradley!jpr   CIS: 72160.1341
Xref: sparky biz.sco.general:4701 comp.unix.programmer:5720 comp.unix.sysv386:17472
From: karish@pangea.Stanford.EDU (Chuck Karish)
Newsgroups: biz.sco.general,comp.unix.programmer,comp.unix.sysv386
Subject: Re: sigaction() and rescheduling interrupted system calls
Date: 17 Dec 1992 06:48:15 GMT
Organization: Mindcraft, Inc.
NNTP-Posting-Host: pangea.stanford.edu
Summary: Do it the hard way
Keywords: sigaction system call sco reschedule

In article <1992Dec16.100827.10097@dd.dk> wes@dd.dk (Mads Westermann) writes:
>I'm running SCO ODT 2.0 (SCO Unix 3.2.4) and have run into the problem
>of rescheduling an interrupted system call after a signal has occured.

[ SVR4 and ULTRIX 4.2 provide flags for sigaction() to have interrupted
  system calls re-started]

>My SCO manual doesn't know of any such thing - It seems like the only
>possibility is to manually check the return code and the errno from the
>system call and manually restart the system-call if errno equals EINTR.
>
>Has anybody solved the problem ? Is there a way to solve it ?

sigaction() is an extended version of the BSD sigvec() function,
as standardized in POSIX.1.  POSIX.1 does not require that
implementations support automatically restarting inerrupted
system calls, so there's no standard flag for sigaction()
to cause this to happen.

Checking the return and errno yourself will work on all systems
that report the interesting failures reliably.  Unless and until
automatically restarting system calls is universally supported,
that's the only way to solve the problem if you only want to code
it once.
--

    Chuck Karish          karish@mindcraft.com
    (415) 323-9000 x117   karish@pangea.stanford.edu
From: bob@consult.UUCP (Bob Willey CDP)
Newsgroups: biz.sco.general
Subject: Re: Tape drive on floppy controller, no fun for crowbar+restore
Date: 19 Dec 92 13:59:05 GMT
Reply-To: bob@consult.UUCP (Bob Willey CDP )
Organization: CCS Enterprises, Inc. - Easton, MD

In article <Z2J1VB2w165w@zswamp.UUCP> geoff@zswamp.UUCP (Geoffrey Welsh) writes:
>> Next time you'll likely buy a different tape drive.
>
>   I think that it's worth emphasizing this: the Jumbo tape drives from 
>Colorado Memory Systems work well, provided that you buy the separate 
>controller card (to get away from the floppy controller conflict, as you 
>mentioned in your article), the UNIX software, etc... and, by the time you've 
>bought all of the pieces, you've spent a significant fraction of the money it 
>would have cost to put in a QIC-02 tape drive of higher capacity... and Jumbo 
>tapes need to be preformatted (a slow process not shared by QIC-02 tapes)! 

Yes, they can work successfully.  It does require a little bit of
tinkering and making sure you have the JTAPE driver software from
Colorado.

However, One BIG NOTE of WARNING!!!

For those uninformed, the Colorado 120mb is actually a 60mb unit uncompressed,
and the Colorado 250mb is actually a 120mb uncompressed.  If you use tar
you are limited to 60mb/120mb respectively.

If you are like us, and use CTAR, the compression will recoup some of the
area for you, depending on your file types.

-- 
>.. Bob Willey, CDP          ..  |  ..  uunet!consult!bob  bob@ccs.com   ..<
>.. CCS Enterprises, Inc.    ..  |  ..   Office: (410) 820-4670          ..<
>.. P.O. Drawer 1690         ..  |  ..      FAX: (410) 476-5261          ..<
>.. Easton, Maryland 21601 ......|......... BBS: (410) 476-5098 ...........<
Newsgroups: biz.sco.general,comp.mail.uucp,comp.unix.sysv386
From: bernie@metapro.DIALix.oz.au (Bernd Felsche)
Subject: Re: SCO Unix 3.2.4 MMDF UUCP to SMTP gateways ???
Organization: MetaPro Systems, Perth, Western Australia
Date: Thu, 17 Dec 92 04:38:15 GMT

In <1992Dec08.012707.348@golem.waterloo.on.ca>
   davidf@golem.waterloo.on.ca (David J. Fiander) writes:

>According to rac@sherpa.UUCP (Roger Cornelius):

>>> The TLS uucp channel supports confstr parameters which allow
>>> you to set the maximum number of address that UUCP hosts on the
>>> channel can process.  See the documentation for details.

>Well, I worked on the code, not the documentation.

>>MCHN uucp, ..., ap=822, naddr=10, mod=imm....

>Close.  Try confstr="naddrs=#"

Standard mmdf2 distribution I have has naddrs= #ifdef'd out.
-- 
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.--._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355
Newsgroups: biz.sco.general
From: scottso@panix.com (Liquid Light)
Subject: tar problems
Summary: tar won't unpack file on HD
Date: Sun, 20 Dec 1992 15:27:46 GMT
Organization: Panix, (Home of the overflowing ashtray )


I downloaded a program to monitor our system bottlenecks (thanks Ed)
but now I'm having problems getting tar to unpark the thing.  We're
running Xenix 3.2.4 I think (sorry, my involvement with all this is
limited) on a 386.

When I try to run tar -xvf monitor.tar all it does is show me the
tape blocks.  What are we missing here or does the copy of tar have
problems? Should I try to unpack it from a copy on the tape drive?

I ran tar on it here on panix and it seemed fine and onlt failed in
part due to the fact that I don't have permission to write to 
directories like ./lib...

Any ideas?


-- 
    		   **************************************
  		   *This space intentionally left bland.*
      		   * Scottso (liquid light) Connor.     *
      		   **************************************
Newsgroups: biz.sco.general
From: doc@magna.com (Matthew J. D'Errico)
Subject: Re: sco's efs list
Organization: Magna Software Corporation
Date: Sun, 13 Dec 1992 15:42:36 GMT

In article <9212122145.aa04159@compuli.compuli.UUCP> bld@compuli.UUCP (Bruce Dustman user account) writes:
>Could anyone having a current listing of the efs's available from sco please 
>mail me the list.

Current listings are available on sosco...  Just uucp there like you
would to retrieve any update, but get the file:

	sosco!~/EFS/info

The same is true for SLS's and TLS's...  As well as general info :

	sosco!~/info
	sosco!~/SLS/info
	sosco!~/TLS/info

Regards --

-- Doc
From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: biz.sco.general
Subject: Re: Tape drive on floppy controller, no fun for crowbar+restore
Date: 19 Dec 92 05:06:46 GMT
Organization: Izot's Swamp

edhew@xenitec.on.ca (Ed Hew) writes:

> Next time you'll likely buy a different tape drive.

   I think that it's worth emphasizing this: the Jumbo tape drives from 
Colorado Memory Systems work well, provided that you buy the separate 
controller card (to get away from the floppy controller conflict, as you 
mentioned in your article), the UNIX software, etc... and, by the time you've 
bought all of the pieces, you've spent a significant fraction of the money it 
would have cost to put in a QIC-02 tape drive of higher capacity... and Jumbo 
tapes need to be preformatted (a slow process not shared by QIC-02 tapes)! 

   It may cost you a few more bucks, but in this case it's worth sticking to 
the old standard ways.

  Geoffrey Welsh, 7 Strath Humber Court, Islington, Ontario, M9A 4C8 Canada
geoff@zswamp.uucp, [xenitec.on.ca|m2xenix.psg.com]!zswamp!geoff (416)258-8467
                Now I've lost everything, I give to you my soul
           And the meaning of all that I believed before escapes me
                  In this world of none, no thing, and no one
                            - Genesis, _Afterglow_
From: bob@consult.UUCP (Bob Willey CDP)
Newsgroups: biz.sco.general
Subject: Re: Tape drive on floppy controller, no fun for crowbar+restore
Date: 20 Dec 92 14:21:00 GMT
Reply-To: bob@consult.UUCP (Bob Willey CDP )
Organization: CCS Enterprises, Inc. - Easton, MD

In article <1gvl7rINN9i@usenet.INS.CWRU.Edu> ak751@cleveland.Freenet.Edu (Mark Saltzman) writes:
>>>   I think that it's worth emphasizing this: the Jumbo tape drives from 
>>>Colorado Memory Systems work well, provided that you buy the separate 
>>>controller card (to get away from the floppy controller conflict, as you 
>>mentioned in your article), the UNIX software, etc... and, by the time you've 
>>Yes, they can work successfully.  It does require a little bit of
>>tinkering and making sure you have the JTAPE driver software from
>>Colorado.
#>However, One BIG NOTE of WARNING!!!
#>For those uninformed, the Colorado 120mb is actually a 60mb unit uncompressed,
#>and the Colorado 250mb is actually a 120mb uncompressed.  If you use tar
#>you are limited to 60mb/120mb respectively.
#>
#>If you are like us, and use CTAR, the compression will recoup some of the
#>area for you, depending on your file types.
>Is CTAR really necessary?  We do this:
>tar cvf - <files> | compress -c > /dev/rjt0
>Or with gnu tar:
>gtar -cvf /dev/rjt0 +compress <files>

NO, CTAR is not required.
You can do what you are doing to reclaim some of the space on
the Colorado drives.
We do require all of our sites to have CTAR because of the recovery
process.  When you are using tar, the recovery process is more complex,
since you do not backup many of the file (char/block devices, fifos, etc...),
and with CTAR, we have everything in one piece of software, complete backup,
compression, verification, and an automatic creation of a set of diskettes
to recover the system in the event of disaster.  (Not that this really every
occurs.... ha ha ha...)

Note of disclaimer:  We are not affilliated with Microlite/CTAR other
than being a very satisfied reseller of their products.  Above comments
are meant to be informative and not a commerical post.

-- 
>.. Bob Willey, CDP          ..  |  ..  uunet!consult!bob  bob@ccs.com   ..<
>.. CCS Enterprises, Inc.    ..  |  ..   Office: (410) 820-4670          ..<
>.. P.O. Drawer 1690         ..  |  ..      FAX: (410) 476-5261          ..<
>.. Easton, Maryland 21601 ......|......... BBS: (410) 476-5098 ...........<