HDTenEightyP/NetNews huggingface dataset:
From: dwex@cbnewsj.cb.att.com (david.e.wexelblat)
Newsgroups: comp.unix.sysv386
Subject: Re: X386 1.2E (X11R5) binaries for AT&T SVR3.2.3?
Date: 25 Aug 92 23:47:41 GMT
Article-I.D.: cbnewsj.1992Aug25.234741.4510
Organization: AT&T

In article <17dv69INNr8g@agate.berkeley.edu> ilan343@violet.berkeley.edu (Geraldo Veiga) writes:
> In article <TJWU.92Aug25125952@e40-008-11.mit.edu> tjwu@athena.mit.edu (Thomas J Wu) writes:
> >
> >The FAQ for this group neglects to mention where these binaries can
> >be found.  Please e-mail or post any anon. FTP sites or other places
> >to find them.  Thanks.
> >
> 
> I understand that the reason the binaries for SVR3.2 systems are not
> available is the lack of support for R3.2 shared libs (the binaries
> will be huge).  Are there any plans of changing this in
> future releases of X386 1.2E?  How hard is it to create shared libs
> under SVR3.2?  We, poor 3.2 holdouts, are the ones that need X386 1.2E
> the most.  Maybe is about time to take the jump and switch to SVR4, but
> I am still waiting to see what R4.2 products are going to look like.


This is basically the case.  The binaries are quite large, and no one had
volunteered the disk space on an FTP archive.  There's been talk of
doing SVR3 shared libraries, but no one has come up with them yet.  From
what I understand, it's a lot of work.  SGCS and MetroLink do have them
in their commercial offerings.  If someone wants to step up and volunteer
(either disk space or to work on SVR3 shared libs) send email to
x386@physics.su.oz.au


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
David Wexelblat             | dwex@mtgzfs3.att.com  | Somebody get me a
AT&T Bell Laboratories      | ...!att!mtgzfs3!dwex  |   cheeseburger!
200 Laurel Ave - 4B-421     |                       |      
Middletown, NJ  07748       | (908) 957-5871        | --Steve Miller Band
Newsgroups: comp.unix.sysv386
From: peter@ferranti.com (peter da silva)
Subject: Re: Dell SVR4 (and Dell hardware)
Organization: Xenix Support, FICC
Date: Tue, 25 Aug 1992 17:17:02 GMT

In article <rvdp.714568017@yam.sow.econ.vu.nl> rvdp@sow.econ.vu.nl (Ronald van der Pol) writes:
> Dell SVR4 is probably the best Unix you can buy for a PC, but I think
> SunOS is a by far a more complete operating system.

That depends. In many ways that are important to me, SVR3.2 is a better
system. After installing a few Sparcstations I was ready to scream. Make
a mistake in a package installation and you often have to start over from
scratch: you can't just remove the package and try again.

Now if you're a Sun guru that's probably not that big a deal... you don't
make that sort of mistake. But people in general buy systems to *use*, not
for the joy of hacking on them.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
Xref: sparky comp.unix.sysv386:13675 comp.unix.xenix.sco:2750
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.sysv386,comp.unix.xenix.sco
Subject: SCO support - a success story
Date: 27 Aug 92 13:25:40 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Followup-To: poster
Organization: GE Corporate R&D Center, Schenectady NY


  Back in May I reported problems with Xenix cron dying after heavy use.
I had reported it to SCO and they had no ready fix. Well SCO didn't quit
on the problem, they first suggested workarounds, and then started
sending me new binaries to try.

  Since the failures were after some days, and SCO didn't have a machine
with the proper peripheral to run our code (a coal fired power plant),
this whole process has been lengthly, not through lack of interest or
effort on the part of SCO, but because it really slow to debug stuff by
looking at dumps you get once a week.

  In the end, success! We have a version which seems totally stable and
can get on with providing the electrons the net needs. Think of it, half
the electrons in the message were provided by GE turbines and
generators!

  I mention this because various vendors have been getting heat in
several groups about support. Even though only one customer reported
this problem, SCO stuck with and fixed it. Thanks folks!

  SCO says it will be fixed in the next release, so I guess that's a
committment that there will /be/ a next release of Xenix, something I
wouldn't have considered certain.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Newsgroups: comp.unix.sysv386
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: SCO support (was: How to replace disk driver in SCO Unix ?)
Organization: Kithrup Enterprises, Ltd.
Date: Wed, 02 Sep 1992 04:09:35 GMT

In article <1992Sep02.005250.5201@anomaly.sbs.risc.net> kd1hz@anomaly.sbs.risc.net (Michael P. Deignan) writes:
>I've had a problem with SCO's named dumping core for over a year now.
>Do I have a fix? No. 

Workaround:  use the '-n' option with netstat.

I'm *told* that there is a fix in 3.2v4 aka ODT 2.x, but I'm not running
that yet, so I don't know.  (Hmm.  Maybe I could try extracting named from
the tape, and check that out?  Hmm....)

-- 
Sean Eric Fagan  | "You can't get lost in one room, no matter how
sef@kithrup.COM  |  little effort you make to learn your way around."
-----------------+    -- William E Davidsen (william@crd.GE.COM)
Any opinions expressed are my own, and generally unpopular with others.
Newsgroups: comp.unix.sysv386
From: det@hawkmoon.mn.org (Derek Terveer)
Subject: Re: SAS: bad ioctl 0x00004B3E on SVR4
Organization: Demi-Public System (One of the Eternal Champions); Eagan, MN, 55123-2507, USA
X-Newsreader: Tin 1.1 PL4
Date: Thu, 3 Sep 1992 12:17:02 GMT

smith@compound.se (Bjorn Smith) writes:
: We are having a strange problem when using SAS 1.25 tty driver on our
: SVR4 (Consensys).

Ditto for SVR4 (Esix 4.0.3A)

: I have also noticed that when loging in the following message comes out
: on the console:
: 	SAS: bad ioctl 0x00004B3E

Hmmm, I have not noticed this for logging in/out but have seen this when
using kermit.  (Of course I don't mean to imply that logging in/out does
not generate these errors, but I don't notice them much because i am
always in Xwindows).  I get:

	SAS: bad ioctl 0x00006689

: The configuration is the following:
: 	crw-rw-rw-   1 root     root      12, 83 Sep  1 09:05 /dev/ttyF04
: 	crw--w--w-   1 root     tty       12,211 Sep  1 07:52 /dev/ttyFM04

hawkmoon$ ls -l /dev/modem
total 0
crw--w--w-   1 root     news      54,209 Sep  2 18:23 wb-in
crw-rw-rw-   1 root     root      54, 81 Sep  3 07:09 wb-out

: In inittab anf gettydefs:
: 	FM04:23:respawn:/sbin/getty ttyFM04 19200Z
: 	19200Z# B19200 HUPCL # B19200 CS8 SANE HUPCL TAB3 ECHOE IXANY \
: 	#login: #19200Z

00:23:respawn:/etc/getty -t 120 modem/wb-in 38400
38400# B38400 OPOST ONLCR TAB3 BRKINT IGNPAR IXON IXANY PARENB ISTRIP \
ECHO ECHOE ECHOK ICANON ISIG CS7 CREAD HUPCL # B38400 OPOST ONLCR TAB3 \
BRKINT IGNPAR IXON IXANY PARENB ISTRIP ECHO ECHOE ECHOK ICANON ISIG \
CS7 CREAD HUPCL #(38400)login: #38400

: In /etc/ap/chan.ap:
: 	12     0        255          ldterm ttcompat

    5     -1       0            char ansi ldterm ttcompat
    3     0        207          ldterm ttcompat
    54    0        255          ldterm ttcompat

: The modem has HW flow control and the port is running at 19200 cps.
: Dialing out with both cu and uucp works fine.

Yup, except it is running at 38400 (WB).

derek
-- 
Derek Terveer   Work:	derekt@stpaul.gov	+1 612 292 6009
		Play:	det@hawkmoon.mn.org	+1 612 683 0413
"Big business and big government distract us with entertainment;
 they manufacture our consent while we destroy the environment."
From: evan@telly.on.ca (Evan Leibovitch)
Newsgroups: comp.unix.sysv386
Subject: Re: What 'stune' parameters do you use for X386?
Date: 2 Sep 92 12:56:27 GMT
Organization: Somewhere just far enough out of Toronto

In article <BtLt5w.3xD@eis.com> dvb@eis.com (David Van Beveren) writes:
>dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:

>: I expect that I will be moving to SVR4.2 from some other vendor.  Buying
>: it new will probably been cheaper than Microport's upgrade.
>: [...]
>: Which is a real shame, because they're a great bunch of guys.
>
>This (their being a 'great bunch of guys') is, of course, a prime
>factor used in determining a products quality, right?

>Party loyalty is alive and well. Sheesh.

The accessability of  not only technical support, but senior product
management at a company certainly does influence a choice on the
suitability of a product. If I know I can participate in not only the
technical side, but also the marketing side of a product, then I know
that not only the present, but future, directions of the product will be
in line with where I'm going.

Compare the above situation described above for Microport, with the
popular conceptions about Consensys (just the reverse -- great price,
user-hostile support).  The perception that Consensys is not a "great
bunch of guys" has certainly hurt its reputation (witness Eric's moaning
about his conversations with Consensys people, which negatively affects
his opinion of the product in his Buyers' Guide).

Bad people can hurt a product, having good people can help. It's
not the be-all and end-all, but it is certainly part of the package one
should consider when making a purchase.

-- 
 Evan Leibovitch, Sound Software Ltd., located in beautiful Brampton, Ontario
         evan@telly.on.ca / uunet!utzoo!telly!evan / (416) 452-0504
   "This Used To Be My Playground" -- Madonna, singing about mens' washrooms
From: larry@gator.rn.com (Larry Snyder)
Newsgroups: comp.unix.sysv386
Subject: SVR4 4.0 kernel size and setcfg
Date: 26 Aug 92 20:52:33 GMT
Organization: The Gator Public Access Unix Site - 219-289-3745

Earlier we were talking about kernel size and 3.2 being smaller than
the SVR4 4.0 kernel -- thanks to karl@ddsw1 I found the setcfg utility
which enabled be to disable lots of the drivers in the kernel (I thought
just setting the Y flag to N in /etc/conf/sdevice.d/<driver> would 
remove the driver -- but it didn't -- anyhow the kernel size here dropped
from 1.8 megs down to 1.5 megabytes -- after turning off the various 
drivers I didn't use -- mind you I still use SLIP, NFS, ethernet,
multiport cards, X11R5, full TCP, etc..  I would say considering all
the SVR4 4.0 "extras" like Xenix support, 3.2 support, BSD, DFS, PCI,
RPC, etc. that a kernel of 1.5 megs isn't bad -- heck -- my kernel was
1.5 megs back when I was running ISC 3.2 2.2.

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry
Newsgroups: comp.unix.sysv386
From: bill@unixland.natick.ma.us (Bill Heiser)
Subject: Re: Dell SVR4 (and Dell hardware)
Organization: Unixland Public Access Unix  (508) 655-3848
Date: Fri, 4 Sep 1992 00:58:56 GMT

dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>> 
>The obstacle, from my understanding, is that there's no documentation
>whatsoever on HOW to add a new filesystem to this wonderful fancy-shmancy
>virtual filesystem switch stuff.  You have to have the source.  And it's
>obviously not simple, even with source, or I'm quite certain that Dell
>or Microport or Esix would have done it by now.  This has got to be the
>single biggest complaint about SVR4 that we here - no CD-ROM file system.
>They can't be ignoring it.

Well, if Mr and Mrs Jolitz can do it by themselves, surely DELL can
figure it out/

-- 
bill@unixland.natick.ma.us                      ESIX Mailing List Moderator
Public Access UNIX/USENET/E-MAIL!  UUCP Accounts Available!  (508) 655-3848
5 lines  -  Located in Natick, MA   USA    Supporting V.32/PEP/V.42bis, etc.
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.sysv386
Subject: Re: FAS 2.10 async driver, part 5/5
Date: 27 Aug 92 12:40:25 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1448@frackit.UUCP>, dave@frackit.UUCP (Dave Ratcliffe) writes:

| This is one of those cases where most of us will call it an ok thing to
| do. If you needed a FAS driver I think you would agree. Considering the
| tone of your message you don't need one and could care less. Sorry. It
| doesn't happen every day. 

  Actually if someone is getting a long distance feed they better be
using FAS, because the time saved in reducing retransmissions will
easily pay for the effort to install. And of course the cost of a fast
modem will drop out in a short time if the feed is expensive.

  I saw some figures on the savings from going from PEP of V.32bis to
superPEP based on US rates, and it looked like the payback was under a
year for just mail and a few groups.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Newsgroups: comp.unix.sysv386
From: steph@demesne.uucp (Steph Marr)
Subject: Re: Ethernet Cards -- Questions
Organization: Demesne Computing
Date: Sat, 22 Aug 1992 21:38:57 GMT

   stevea@i88.isc.com (Steve Alexander) writes:

   >larry@gator.rn.com (Larry Snyder) writes:
   >>I would like to know if under Unix there is a noticable difference
   >>between a 8 and 16 bit card?  Does the driver in the kernel actually
   >>do 16 bit data transfers from the buss (assuming a 16 bit board)?

   >If you have the right driver, it will access the board 16 bits at a time.
   >This can lead to quite a throughput improvement (I've measured this as
   >almost twice as fast when just pumping packets to the ethernet driver 
   >directly).

Actually, in a -well written- driver, either card can push frames out at
a rate which can nearly saturate an ethernet.  Some of the latest drivers
from SCO can do this.  The real difference is in how much system time is
needed to transfer the frame(s) to the card.  Obviously, an 8-bit card
requires twice as many I/O instructions, which means the system can't go
off and do something more useful while the transfer takes place.  Using a
16-bit card makes for less time spent in the kernel copying the frame to
or from the card, which means more CPU power left over for getting something
more useful done.  I'd try running your tests again with the newer drivers,
and see what comes of it.

   >The other advantage of the 8013 over the 8003 is that it has a 16K onboard 
   >packet buffer, which lets you use 8K NFS reads, and larger TCP windows (I 
   >use 24K around here).  It also lets you use full length TCP segments (1460 
   >vs 1024), which when combined with the larger window makes things run a lot 
   >faster.  On the 8K card, you only have 5 or 6 K of input packet buffers,
   >which is not a lot when you're trying to keep up with a SparcStation or
   >a 386/33.

This is indeed the real win.  The more RAM there is on the card, the larger
you can make the recieve window, and the more frames you can have outstanding
on the card waiting for transmission.  As Steve points out, this can enable the
card to receive multiple frames and the kernel can pull all of the available
frames off the card during a single interrupt service.  Since there's a real
amount of overhead to service each interrupt, getting more done per interrupt
is a win (albeit not a huge one).  I've generally found 16KB to be the minimum
magic number.

   >The last time we bought an 8013 it was ~$170.  Well worth the money if you
   >care about performance.

There are a number of really good 16-bit cards out there for money minded,
performance oriented people.  The WD/SMC stuff works on a lot of platforms,
but then, they aren't the only game in town.  You should be able to get
something pretty cool for well less than US$200.00.

Cheers,
-- 
Steph Marr
...!uunet!sco!demesne!steph
/* This is MY house, and MY machine.  I'll say what I please. */
Newsgroups: comp.unix.sysv386
From: ed@maxed.amg.com (Ed Whittemore)
Subject: Re: Ethernet Card Advice for ISC Unix 3.0
Organization: American Micro Group, Ft. Lee  NJ
Distribution: usa
Date: Sun, 30 Aug 1992 00:44:34 GMT

In article <1992Aug25.220235.22429@rtsg.mot.com> beirne@rtsg.mot.com (Michael G Beirne) writes:
>In article <BtJowr.52H@maxed.amg.com> ed@maxed.amg.com (Ed Whittemore) writes:
>>In article <BtFIo5.5u1@maxed.amg.com> ed@maxed.amg.com (Ed Whittemore) writes:
>>>In article <1992Aug20.140753.9039@uwm.edu> peter@miller.cs.uwm.edu (Peter J Diaz de Leon) writes:
>>>>
>>>>I am in the process of selecting ethernet (16 bit 10base-T) cards for our
>>>>Unix box which runs ISC Unix Version 3.0
>>>>Does anyone have any recommendations on which of the many
>>>>peter@miller.cs.uwm.edu
>>>The new SMC versions of the WD80(x)3 cards work for 10baseT, but have
>>>broken the AUI/BNC interface.
>>
>>Let me be more specific: The SMC ELITE COMBO boards have a problem
>>with ISC 3.0 drivers originally designed for the WD 80(x)3 boards,
>>and only the 10baseT interface seems to work.
>
>I installed one in a Gateway 2000 386/33 running ISC 3.0 and jumpered
>for INT10 and it worked fine using the BNC connector with NFS mounted
>filesystems from an RS6000 and Suns. I would regularly run remote X
>programs(emacs, rlogin xterm) without any problems.
>
>What problems did you have?
>
We used ezsetup and nothing, just nothing for base2 or 5, but 10 was
OK.

-- 
Ed Whittemore   uunet!maxed!ed   ed@maxed.amg.com
American Micro Group, Inc.   201-944-3293
From: micha@veeble.han.sub.org (Michael Zuelsdorff)
Subject: Re: X386 1.2E (X11R5) binaries for AT&T SVR3.2.3?
Newsgroups: comp.unix.sysv386
Date: Sun, 30 Aug 92 10:45:36 GMT
Reply-To: micha@veeble.han.de (Michael Zuelsdorff)
Organization: veeble Hannover, Germany

In article <1992Aug27.155633.10735@hp1.holl.com> dave@hp1.holl.com (David Vrona) writes:
>In article <17dv69INNr8g@agate.berkeley.edu> ilan343@violet.berkeley.edu (Geraldo Veiga) writes:
>>
>>I understand that the reason the binaries for SVR3.2 systems are not
>>available is the lack of support for R3.2 shared libs (the binaries
>>will be huge).  Are there any plans of changing this in
>>future releases of X386 1.2E?  How hard is it to create shared libs
>>under SVR3.2?  We, poor 3.2 holdouts, are the ones that need X386 1.2E
>>the most.   ...stuff deleted...
>
>Bravo!  I'm sure there are many people like myself that are in the same
>situation.
>
>Has anyone been able to tackle this problem?
>
Logo, Herr Roell! ;-)

... es springt das Reh, es lacht sein Herz,
Goodbye PD -- Hello Commerz .

micha
From: fr@compu.com (Fred Rump from home)
Newsgroups: comp.unix.sysv386
Subject: Re: SCO support (was: How to replace disk driver in SCO Unix ?)
Date: 25 Aug 92 15:44:11 GMT
Organization: CompuData Inc.

jochen@mrz.sub.org (Jochen Fahrner) writes:

>I don't have another way to tell SCO about bugs, than through our
>distributor.

What's wrong with support@sco.com? Will they not acknowledge a bug report? 
We've been doing this for years (the bugs are still there, though). :-)

Seriously, we've been going around on this for a long time and have our own 
long list of things that don't work as per standard or normal expectations. It 
just so happens that SCO may not think the same way about what we report as a 
bug. Sometimes they call it a feature. At other times they really have no 
control over the matter. And still, at other times, the priorities are so low 
that you might as well forget about a fix - ever - and simply continue to use 
whatever workaround exists.  

>Support people also have to know about unix and C.
>It is not enough to know, how to use a pencil and a paper.
>If support people don't understand my problem, I could tell it directly
>to SCO developers and do not need these guys.

I still don't agree that support needs to involve C knowledge at the
distributor level. Not all resellers are also developers where they would have 
intimate knowledge of code hacking etc. It should be enough to pass such 
questions up the line to SCO itself. In this sense a reseller needs to be well 
connected netwise so that support can function back and forth between customer 
and manufacturer.

fred

-- 
W. Fred Rump 	office:	   fred@COMPU.COM     'mans feet have grown/so big 
26 Warren St.   home: fred@icdi10.compu.com  that he/forgets his littleness'
Beverly, NJ. 08010                          		Don Marquis 
609-386-6846    bang:uunet!cdin-1!icdi10!fr   
Newsgroups: comp.unix.sysv386
From: heiko@Harpo.Chemie.FU-Berlin.DE (Heiko Schlichting)
Subject: Re: Looking for u386mon v3.41 or above
Organization: Free University of Berlin, Dept. of Chemistry
Date: Fri, 4 Sep 1992 01:17:28 GMT

sam@csi.compuserve.com (Sam Neely) writes:

>Could someone point me to the sources to u386mon version 3.41 or above?

ftp.zrz.tu-berlin.de:/unix/u386mon/u386mon-3.41.tar.Z

Heiko
-- 
Heiko Schlichting                     | Freie Universitaet Berlin
heiko@groucho.chemie.fu-berlin.de     | Institut fuer Kristallographie
From: mike@pacsoft.com (Mike Stefanik)
Newsgroups: comp.unix.sysv386
Subject: Re: Single-user mode boot on SCO UNIX - not a solution
Date: 30 Aug 92 06:50:29 GMT
Organization: Pacific Software Group, Riverside, Ca.

In an article, sef@kithrup.COM (Sean Eric Fagan) writes:

[ about SCO charging an end-user because they forgot their root password ]

>Clue number two:  SCO charges for it for one of a couple of reasons.  First
>is that they want to make sure it's not some random person trying to break
>into the machine.  Second is that they may have to make up a floppy (or pair
>of floppies) and it costs money to do that, as well as to send it.

[ As I climb up on my soapbox ... ]

This is bogus.  SCO could absolutely care less about "some random person 
trying to break into the machine".  They charge $100 because they know that
the poor end user is over a barrel, and they can get away with it.  And
as long as that person had the original installation disks, SCO would not
have to send anything in the mail.  In this particular case, the user
obviously has the install floppies (the whole point is that he wants to avoid
a re-install if possible) ... it would have taken all of about 15 minutes
(if that) to walk him through what needed to be done.  IMHO, there is no 
difference between SCO charging this poor fellow $100 to get into his system
and someone selling ice for $60 a bag in southern Florida.  Oh, and the
argument that he "got himself into this mess" doesn't wash -- the issue is
service to the customer -- not assigning blame.

[ Whew, I feel better now! ]

-- 
Mike Stefanik  mike@pacsoft.com  ...!uunet!pacsoft!mike
Pacific Software Group, Riverside, CA
From: jjones@ssdc.UUCP (Jeff Jones)
Newsgroups: comp.unix.sysv386
Subject: Re: Consensys and serial ports
Date: 4 Sep 92 00:58:40 GMT
Reply-To: jjones@ssdc.UUCP (Jeff Jones)
Organization: Sterling Software  Vienna, VA.

>Have you tried the Streams ASY driver -- SAS?
>Larry Snyder                                    internet: larry@gator.rn.com
>keeper of the Gator                                  uucp: uunet!gator!larry

Where is this SAS driver??  Is it part of the release or is it a driver some
one else put out?????  Thanks in advance.   


-- 
Jeff Jones                  uunet!ssdc!jjones
Newsgroups: comp.unix.sysv386
From: dold@unislc.uucp (Clarence Dold)
Subject: Standard SCO UNIX Compressed tar ?
Organization: Unisys Corporation SLC
Date: Thu, 3 Sep 1992 15:41:11 GMT

Is compression available on SCO UNIX tar?
The Norton Utilities for UNIX mumbles something during install about the
distribution diskettes being compressed, and requiring a certain revision
of SCO in order to work.
Sure enough, a "tar xv" from the command line yields 1880K from a 1.2MB
diskette.  doing a "tar cvf /tmp/junk ." yields a 1660K archive.

-- 
---
Clarence A Dold - dold@unislc.slc.Unisys.COM
               ...pyramid!ctnews!tsmiti!dold