[comp.unix.questions] Returned mail: Unable to deliver mail

MAILER-DAEMON@aqua.whoi.edu (Mail Delivery Subsystem) (05/19/88)

   ----- Transcript of session follows -----
<<< RCPT To:<reilly@aqua.whoi.edu>
<<< DATA
554 sfgets: timeout on read (mailer may be hung)
451 collect: 1fe5b80 unexpected close: Connection reset by peer
421 aqua.whoi.edu Lost input channel

   ----- Unsent message follows -----
Received: from dccs.upenn.edu (1fe5b80) by aqua AA01318; Thu, 19 May 88 01:36:26 edt
Received: from SUPER.UPENN.EDU by dccs.upenn.edu
	id AA01979; Tue, 17 May 88 06:59:09 EDT
Received: by super.upenn.edu
	id AA22640; Tue, 17 May 88 06:58:07 EDT
Resent-From: INFO-UNIX@brl.arpa
Resent-Message-Id: <8805171058.AA22640@super.upenn.edu>
Return-Path: <info-unix-request@sem.brl.mil>
Received: from SEM.BRL.MIL by wharton.upenn.edu via TCP; Tue May 17 06:52 EST
Received: from SEM.BRL.MIL by SEM.brl.ARPA id ab21854; 17 May 88 3:01 EDT
Received: from sem.brl.mil by SEM.BRL.ARPA id aa21839; 17 May 88 2:46 EDT
Date: Tue, 17 May 88 02:46:20 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request@brl.arpa>
Subject: INFO-UNIX Digest  V5#040
To: INFO-UNIX@brl.arpa
X-Vms-To: INFO-UNIX@BRL.ARPA
Reply-To: INFO-UNIX@brl.arpa
Resent-Date: Tue, 17 May 88 06:57 EST
Resent-To: reilly@wharton.upenn.edu
Message-Id:  <8805170246.aa21839@SEM.BRL.ARPA>

INFO-UNIX Digest          Tue, 17 May 1988              V5#040

Today's Topics:
                          Re: SUN date problem
                     Curses problem on PC monitors
                          Need info about RIP
                       Question about lex itselff
           Re: wanted: Sun 386 Workstation (Road Runner) info
                     background (hidden) processes
          Writing a loop in csh (was: file renaming facility).
           Re: wanted: Sun 386 Workstation (Road Runner) info
         Re: Guessing buffer size needed for sprintf beforehand
  Using a Sun386i for DOS application development (was: Sun 386 info)
                         Printer Driver wanter
 Re: <defunct> processes (was Re: Trouble killing processes in SysV/AT)
                     HOW DO I MAKE A SHELL ARCHIVE?
              Re: Interface between UNIX and a FAX machine
                           Re: bad filenames
           Re: wanted: Sun 386 Workstation (Road Runner) info
               VI and MAILX (was: Re: question about vi)
                Re: CSS Lab Motherboard + SCO Xenix 386
             Re: whither /dev/CDisk?? [ WORMs vs. CD-ROMs ]
                       perl compilation problems
                               cref & pr
           Re: wanted: Sun 386 Workstation (Road Runner) info
                Re: CSS Lab Motherboard + SCO Xenix 386
           Re: wanted: Sun 386 Workstation (Road Runner) info
                         Re: question about vi
                        Re: unix on the ibm pc?
                           Re: Broken curses?
         Re: Guessing buffer size needed for sprintf beforehand
                        Re: unix on the ibm pc?
                       vpix and Xenix/386, part 2
                   Re: Curses problem on PC monitors
         Re: Guessing buffer size needed for sprintf beforehand
                        BACKQUOTES - BACKGROUND
-----------------------------------------------------------------

From: aglew@urbsdc.urbana.gould.com
Subject: Re: SUN date problem
Date: 13 May 88 03:27:00 GMT
Nf-ID: #R:brl-smoke.ARPA:7811:urbsdc:29500024:000:611
Nf-From: urbsdc.Urbana.Gould.COM!aglew    May 12 22:27:00 1988
To:       info-unix@brl-sem.arpa


>>>Is it possible that the capacitator is not matched to the battery correctly?
>>                         ~~~~~~~~~~~
>>Is this computer literacy?
>
>| Yes, although my inductative logic tells me that people have a high
>| resistatance to looking up words in a dictionary.

This has gone far enough. In my copy of "Everyman's Wireless Handbook",
published in England in the Twenties, the term "capacitator" is used
as synonymous with the British "condensor", Yank "capacitor".

And you can mock me all you want for not being sure whether the
British word is spelled "condensor", "condenser", or "condensator".

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

From: Dave Hammond <daveh@marob.masa.com>
Subject: Curses problem on PC monitors
Date: 13 May 88 14:49:20 GMT
To:       info-unix@brl-sem.arpa


Re: Curses output on PC monitors

When displaying standout() text on a CGA or Mono monitor, if the
standout() text is the last text on the line, the standend() routine
does not end standout() mode. All blank space and lines until the next
non-blank text appears in reverse. A typical example is:

    move(0,30);
    standout();
    addstr("A STANDOUT TEXT STRING");
    standend();
    /* ... move to other lines, add more text */
    refresh();

Preceeding or following the standend() with a clrtoeol() does not help
(and is often undesireable, especially if the window is boxed :-).
Please note, this only occurs if the standout() text is the last text on the
line. If any non-blank characters follow the standend(), everything works as
expected.

The environment is a 286 box running SCO Xenix 2.x.

Has anyone experienced the same? Can any suggestions be offered as to
workarounds, or perhaps a more proper use of the Curses function?

Thanks in advance for any advice.

Dave Hammond
DSI Communications, Inc.
 --------------------------------
UUCP:   ...!marob!daveh
VOICE:  (516)872-3535
USMAIL: 333 W. Merrick Rd.
        Valley Stream, NY 11580

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

From: Chang-Hsin Chang <chc@sam.cs.cmu.edu>
Subject: Need info about RIP
Date: 13 May 88 23:00:52 GMT
Sender: netnews@pt.cs.cmu.edu
Keywords: Routing
To:       info-unix@brl-sem.arpa


Can somebody please point me to documentation on the routing
information protocol (RIP) used by UNIX systems?
Thanks

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

From: Michael T Sullivan <sullivan@vsi.uucp>
Subject: Question about lex itselff
Date: 13 May 88 16:33:58 GMT
Keywords: lex, bad, rewrite
To:       info-unix@brl-sem.arpa

I have a question or two about lex.  I hear in the office and on the net
people moaning about how horrible lex is.  My questions are:

Just what is so horrible about lex?  For the little things I have been
using it for it seems just fine and a speedy way to get a scanner done.
Mail me this answer.

If lex is so horrible, and everybody thinks it's horrible (is this an
incorrect assumption?) then why hasn't it been rewritten by now?

-- 
Michael Sullivan		{uunet|attmail}!vsi!sullivan
				sullivan@vsi.com
HE V MTL			Anybody out there remember Max Webster?

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

From: Stefan Mochnacki <stefan@helios.toronto.edu>
Subject: Re: wanted: Sun 386 Workstation (Road Runner) info
Date: 11 May 88 16:52:46 GMT
Keywords: sun 386 Roadrunner
To:       info-unix@brl-sem.arpa

Some people are asking "Who will buy the Sun 386i ?" In this moderately-
sized Astronomy Department (about 22 faculty ...) we are likely to buy
THREE right away. We have 3 Sun-3 100-series machines already, and direct
access to several others including a Sun 4. However, many of us have PC's,
particularly portable ones or desktops kept at home, and the 386i provides
a fusion of the PC and SUN / UNIX worlds very nicely, as well as providing
computing power for our students via terminals connected to terminal
servers.

As I've said before on a different newsgroup, the Sun 386i is competitively
priced when compared with other 386 systems because it includes many
features which are necessary in a distributed academic environment but
which have to be bought separately as add-ons to "street-market" PC's.
Furthermore, the UNIX situation for 386 PC's is messy because there are so
many hardware "standards" (sic) which no generic offering of UNIX can
support. << There's a great opportunity for someone to start up a new
software company: a Drivers Galore factory ! There's a fortune to be made
writing drivers for all the display adapters and disk controllers on the
market which generic offerings of UNIX and OS/2 cannot hope to support
 ...>>.   Another aside : there are discounted marketing channels for Suns
and many organizations can buy Suns with deep discounts.

[ I have no connection with Sun Microsystems. Opinions are my own ]

-- 
Stefan W. Mochnacki          INTERNET - stefan@helios.physics.toronto.edu
Astronomy, U. Toronto        UUCP - {uunet,pyramid}!utai!helios!stefan
+1 (416) 884-9562            BITNET - mochnacki@utorphys.bitnet 

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

From: Rich Andrews <rich@jolnet.uucp>
Subject: background (hidden) processes
Date: 12 May 88 06:19:38 GMT
To:       info-unix@brl-sem.arpa


I have been running accounting here and have yet to see any sort of activity
(ps -ef) and yet i know that every time a command is entered it is logged to the
appropriate disk file.

        What is the mechanism involved here and how does it "hide" from the
ps -ef output?

rich andrews

--
 ------------------------------------------------------------------------------
Any opinions expressed are my own.  Now, for a limited time, they can be yours
too, for the incredible price of only $19.95.  Simply send $19.95 (in Alterian

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

From: Tony Olekshy <tony@oha.uucp>
Subject: Writing a loop in csh (was: file renaming facility).
Date: 14 May 88 00:17:41 GMT
To:       info-unix@brl-sem.arpa

A discussion of how to rename a set of files from the csh user prompt has
recently been carried out in this newsgroup.  This is really a specific case
of operating over each item in a group with a command.  Unfortunately, the csh
looping construct is messy and does not admit to the operation of the history
mechanism.  I use the csh as an interactive shell but use sh for scripts.
Since I am therefore familiar with the sh syntax, I use the following looping
mechanism from the csh prompt:

    %sh -cx 'for i in 1 2 3 4 5; do cp /dev/null $i.a; done'

    %sh -cx 'for file in ?.a; do mv $file `basename $file .a`.b; done'

If you know or can learn a little sh syntax, this works like a charm.  The -x
option gives you a running log of what is going on.  History-based editing
works unexpectedly well, because the whole looping command is a single
string, ie, !!:2 is

    'for file in ?.a; do mv $file `basename $file .a`.b; done'

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

From: Charles L Ditzel <benoni@ssc-vax.uucp>
Subject: Re: wanted: Sun 386 Workstation (Road Runner) info
Date: 14 May 88 04:41:30 GMT
To:       info-unix@brl-sem.arpa

in article <226@pvab.UUCP>, robert@pvab.UUCP (Robert Claeson) says:
> In article <10928@jade.BBN.COM>, mlandau@bbn.com (Matt Landau) writes:
>> What do I really think about the Sun 386i?  I like it.  A lot.  It's about
>> the only machine I can imagine wanting to buy for my home.  If I were 
>> still doing consulting, I could easily recommend it to lots of people.  
> 
> It is too expensive for those who are mainly looking for a faster PC.
> Those who already have Sun's have a lot of software invested in Sun-3
> and/or Sun-4 software, and would probably not like to invest a lot of
> money in the same software for the 386i architecture. A 386i is
> somewhat faster than a Sun-3, but not quite as fast as a Sun-4.
> And there's a lot more software out there for the Sun-3 series of
> workstations.
> So, what customers do Sun think will buy 386i's, and what customers
> think they will buy a 386i?
Hmm...I think you have it backwards.  The 386i adds alot of 
MS-DOS software (yes I know about co-processors - co-processors
are an additional expense and lack an AT-bus) to the Sun line.
Having also seen the machine, i too was
impressed...what Sun did in it's bridge to MS-DOS...Apple was unable to
do with their A/UX-MacOS bridge.  That Sun has created an elegant
bridge the melds the Unix/MS-DOS environments so that users can live
confortably within a structure that permits multiple DOS and Unix
windows (and finders for that matter), filesharing and cut/paste tools.
Apple's Mac II AUX people should talke a close
look at the 386i and try to perform a similar job on the Mac II so that
running a Mac OS application  from within Unix is as transparent.
The current implementation is *weak* with regards to window management,
filesharing - between Unix and MacOS partitions -
and performs the regretable act of turning Unix into a single viewable
process when a *working*  (not all of them work) MacOS program is invoked.

A week or so ago PCWeek had an interesting comparison of 
Sun 386i-Compaq 386-PS/2 machines, price-wise the Sun won hands down.  
(Not to mention that the overall Sun environment has a number of software 
features missing in the other two machines)

I guess to answer your question : *anyone* considering buying a 386 Compaq
or PS/2 OR Mac II/AUX are probably easy sales given the pricey-ness of
all three when comparably configured.

______
Naturally My Opinions Are My Own.

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

From: Patrick Powell <papowell@attila.uucp>
Subject: Re: Guessing buffer size needed for sprintf beforehand
Date: 14 May 88 15:34:44 GMT
Sender: news@umn-cs.cs.umn.edu
Posted: Sat May 14 10:34:44 1988
To:       info-unix@brl-sem.arpa

In article <7768@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes:
>As quoted from <136@insyte.uucp> by jad@insyte.uucp (Jill Diewald):
>+---------------
>| One solution is to fprintf into a file opened to be /dev/null.
>| This requires two calls to the c print fuctions, one to get the
>| size and the second to actually print.  Since the first call
>| goes to dev/null it should be faster since it doesn't really
>| write anything? (Is this true?  For all UNIXs?).  This won't
>| work for VMS though.
>+---------------

(Brandon talks about v?printf).
>++Brandon
>-- 
>	      Brandon S. Allbery, moderator of comp.sources.misc
>	{well!hoptoad,uunet!marque,cbosgd,sun!mandrill}!ncoast!allbery
>Delphi: ALLBERY						     MCI Mail: BALLBERY

I suggest using the handy dandy little function,
snprintf( int count, char *buffer, <varargs stuff about format, etc.> )

This was proposed as a part of the "Standard C Library".  It was reject
for various reasons that I am not privy to.
I have reached the stage where I have re-implemented a portable version of
this that I use wherever I must do SPRINTF.

The lack of range and bound checking versions of 'standard'
routines in the library routines has been an obstacle to producing
portable and bombproof code.

Patrick Powell
Prof. Patrick Powell, Dept. Computer Science, 136 Lind Hall, 207 Church St. SE,
University of Minnesota,  Minneapolis, MN 55455 (612)625-3543/625-4002

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

From: Robert Claeson <robert@pvab.uucp>
Subject: Using a Sun386i for DOS application development (was: Sun 386 info)
Date: 13 May 88 22:58:26 GMT
Followup-To: comp.sys.misc
Keywords: sun 386 Roadrunner
To:       info-unix@brl-sem.arpa

In article <10928@jade.BBN.COM>, mlandau@bbn.com (Matt Landau) writes:

> It would be a really nice software development environment, for other Suns
> or for PC's.  [The company I used to work for did PC development by using
> a VAX- or Pyramid-based cross-compiler.  It would have been nice to be 
> able to use a Sun-based cross-compliler and test/debug the software right
> in another window.]  

Can I use Sun's SunOS C compiler and compile to DOS format with a special
switch or so (like the Xenix C compiler)?

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

From: Gareth Husk <gareth@comp.lancs.ac.uk>
Subject: Printer Driver wanter
Date: 13 May 88 13:28:09 GMT
To:       info-unix@brl-sem.arpa


Friday 13th May.

Greetings folks,
	I'm writing for a little bit of help, that might save
	someone here some work and enanle us to make use of
	our printers properly.

	Has anyone written a printer driver for a brother M-4018
	dot matrix printer so that it understands nroff? This driver
	is then compiled as an entry in /usr/lib/term.

	Any help gratefully received.

	Please e-mail responses as I don't normally read these groups.


	Gareth Husk.


-- 
" I am a doughnut "  JFK

UUCP:  ...!seismo!mcvax!ukc!dcl-cs!gareth
DARPA: gareth%lancs.comp@ucl-cs	  JANET: gareth@uk.ac.lancs.comp

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

From: Bob Lenk <rml@hpfcdc.hp.com>
Subject: Re: <defunct> processes (was Re: Trouble killing processes in SysV/AT)
Date: 12 May 88 20:26:09 GMT
To:       info-unix@brl-sem.arpa

> I have noticed a similar phenomenon with BSD4 - I wrote a program once that
> did lots and lots of popen("command", "w") calls. I fired it up background,
> and a minute later did a "ps ag" to see what was happening. My process was
> there, but so were about 40 processes marked STAT == Z, COMMAND == <defunct>.

Lots of folks have correctly explained that the parent must call
wait(2) or an equivalent to clean up zombies.  It's important to note
that the way to do this following popen(3) is with pclose(3).

		Bob Lenk
		{ihnp4, hplabs}!hpfcla!rml
		rml%hpfcla@hplabs.hp.com

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

From: Dave Decot <decot@hpisod2.hp.com>
Subject: Re: <defunct> processes (was Re: Trouble killing processes in SysV/AT)
Date: 13 May 88 19:10:42 GMT
To:       info-unix@brl-sem.arpa

> P.S. In response to all those that replied to my questions Re: <defunct>
> processes, I discover the solution is simple. After every fclose(fp), where
> fp is the FILE * I got from popen, I do a wait(&j), and the zombies go away.

I'm surprised nobody mentioned to you that the routine pclose() (and not
fclose()) is supposed to be called to close stdio streams obtained
from popen().

Among other things, pclose() calls wait() to pick up the status of the
finished process and get rid of the zombie.

Pclose() is usually documented on the same page as popen(), so I don't
understand how everybody could have missed this.

Dave Decot
Hewlett-Packard Company
decot%hpda@hplabs.hp.com

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

From: Asian Culture Liaison <alexlau@thoth6.berkeley.edu>
Subject: HOW DO I MAKE A SHELL ARCHIVE?
Date: 15 May 88 00:19:57 GMT
Sender: usenet@agate.berkeley.edu
Expires:
To:       info-unix@brl-sem.arpa

I've got some neat stuff that I want to keep together while posting,
and I've heard of a shell archive being able to do that sort of thing.
Of course, arc can do that too, but I think that requires uuencode in
order to post or mail.

So, how do I make a shell archive?  Answers by E-MAIL ONLY, please,
I'm not a consistent reader of this newsgroup.  Thanks in advance,
and Happy Hunting!

acl    {ihnp4,backbones}!ucbvax!bartleby.berkeley.edu!alexlau
"Numerous newsgroups have felt the wrath of THE NICKNAMELESS ONE!"

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

From: Jon Zeeff <zeeff@b-tech.uucp>
Subject: Re: Interface between UNIX and a FAX machine
Date: 15 May 88 01:26:48 GMT
Keywords: Is it possible?
To:       info-unix@brl-sem.arpa

In article <307@cmtl01.UUCP> mdorion@cmtl01.UUCP (Mario Dorion) writes:
>
>I was wondering if it was possible to send faxes from a unix machine. Is there

While I haven't done it (yet), ATTMAIL offers this service.  You can get
and account and a uucp connection and then just mail to a fax number.

Their voice phone number is 1-800-367-7225.

--Jon

-- 
Jon Zeeff           		Branch Technology,
uunet!umix!b-tech!zeeff  	zeeff%b-tech.uucp@umix.cc.umich.edu

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

From: David Goodenough <dg@lakart.uucp>
Subject: Re: bad filenames
Date: 12 May 88 14:07:59 GMT
To:       info-unix@brl-sem.arpa

From article <10777@steinmetz.ge.com>, by davidsen@steinmetz.ge.com (William E. Davidsen Jr):
> Is there a better way to get rid of a file with a '/' in the name
> than diddling the directory? "rm -i *" sure doesn't work here!

Since this is a UNIX (tm) group I'm going to ask "how was a file with a '/'
in it's name created?" I *_CANT_* do it here (BSD 4.3).

And regarding it's removal, "rm -i *" will fail because * expands, and
rm gets a name with a '/' in it, so unlink(2) starts looking for sub-
directories. Even an "rm -ir ." may well fail, because the string that
gets handed to unlink(2) (and presumably namei()) still has a '/' in it.

(If this is a SYS V problem then some of what I have said may be wrong -
I have never worked with SYS V - just BSD 4.X)
-- 
	dg@lakart.UUCP - David Goodenough		+---+
							| +-+-+
	....... !harvard!adelie!cfisun!lakart!dg	+-+-+ |
						  	  +---+

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

From: Ken Lee <klee@daisy.uucp>
Subject: Re: wanted: Sun 386 Workstation (Road Runner) info
Date: 14 May 88 19:45:24 GMT
To:       info-unix@brl-sem.arpa

I can't stand MSDOS and would never buy a machine just because it ran MSDOS.
I'd still buy a Sun 386i machine because:

	1.  it's really fast (I've tried it)
	2.  it has decent big-screen, 8 bit, frame buffer graphics
	3.  it runs real UNIX and NFS
	4.  you can install 16MB of RAM
	5.  there are lots of 3rd party software vendors
	6.  it runs X11 and NeWS windows
	7.  it's real cheap for what you get

These are very popular features and there are no other machines like this.
Unfortunately, RAM and 386 chips are scarce, so these machines may be hard
to get.

Ken
-- 
uucp:  {atari, nsc, pyramid, imagen, uunet}!daisy!klee
arpanet:  atari!daisy!klee@ames.arc.nasa.gov

STOP CONTRA AID - BOYCOTT COCAINE

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

From: "Wolf N. Paul" <wnp@dcs.uucp>
Subject: VI and MAILX (was: Re: question about vi)
Date: 15 May 88 07:36:54 GMT
To:       info-unix@brl-sem.arpa

In article <730001@hpfelg.HP.COM> lls@hpfelg.HP.COM (Lauri Schaaf) writes:
 >
 >When using mailx and writing a memo...
 >you can use " ~v " -- this will put
 >you into vi mode for your memo....
 >When your done just :wq! or ZZ and 
 >memo is ready to be sent -- this is
 >better documented in your manual.

 UNIX SysV mailx requires you to press Control-D after quitting
 VI in order to send the message.
-- 
Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101
UUCP:     ihnp4!killer!dcs!wnp                 ESL: 62832882
INTERNET: wnp@DESEES.DAS.NET or wnp@dcs.UUCP   TLX: 910-280-0585 EES PLANO UD

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

From: "Jack F. Vogel" <jack@turnkey.tcc.com>
Subject: Re: CSS Lab Motherboard + SCO Xenix 386
Date: 15 May 88 09:57:36 GMT
Keywords: CSS, SCO
To:       info-unix@brl-sem.arpa

In article <193@milhow1.UUCP> how@milhow1.UUCP (Mike Howard) writes:
>Is anyone running (or know of anyone running) SCO Xenix 386AT
>(system V 2.2.x) on a 'CSS Labs' 386 motherboard?
 
Mike,
	TCC is a close neighbor (geographically) to CSS Labs and we have
sold a couple of their systems to clients running Xenix386. Overall I have
high recommendations for their systems (or motherboards). Here are a few
items for consideration:

	1) The motherboard holds up to 4Meg with an 8Meg expansion board
	board available. They use 256X4 static column rams instead of simms.
	One problem with this is the shortage of chips at the moment, but then
	this applies to simms as well.

	2) If you specify that it will be running Xenix, they will burn the
	system in running Xenix. I know as I have visited the plant and seen
	the motherboards set up running shell script programs under Xenix386.

	3) The present released motherboard does not have caching, this may be
	a disadvantage but I am not totally convinced about that. I have been
	told by associates that the CSS 386 20Mhz empirically performs better
	than the Compaq 386/20 but this is just hearsay. It is certainly much
	less expensive. Sometime this summer CSS is said to be releasing a new
	motherboard that will implement the Intel cache controller and cache.

	4) The only difference between the 16 and 20Mhz boards are the rating
	of the CPU and a jumper on the motherboard. You could conceivably buy
	a 16Mhz version and later buy a 80386-20 and just change the jumper to
	upgrade to a 20Mhz version. This assumes, of course, that you insist
	on 80nsec ram on the motherboard (something which I recommend anyway).

Overall, I would recommend CSS. Sure, you could buy a 'hotter' system like the
Compaq 386/20 or the new Everex 386-20, but you will pay for the difference and
I have yet to be convinced that UNDER XENIX you are really getting your money's
worth. CSS is a very friendly company in my experience, they have gone out of
their way to help in problems and as I said, your system will actually run
SCO Xenix before it leaves the plant. How many others can say that??

Disclaimer: I in no way represent CSS, I am only a VAR that has done business
and is satisfied with their product.

					Hope this helps,



-- 
Jack F. Vogel
Turnkey Computer Consultants, Costa Mesa, CA
UUCP: ...{nosc|uunet}!turnkey!jack 
Internet: jack@turnkey.TCC.COM

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

From: Matt Taylor <matt@frisbee.uucp>
Subject: Re: whither /dev/CDisk?? [ WORMs vs. CD-ROMs ]
Date: 12 May 88 21:51:38 GMT
Keywords: WORM vs CD-ROM
To:       info-unix@brl-sem.arpa

[ Sorry to cross post this, but I wanted to generate some thought on this
  subject. I've yet to hear some good discussion on where optical technology
  fits and where it doesn't. ]

In article <13212@brl-adm.ARPA>, PAAAAAR%CALSTATE.BITNET@cunyvm.cuny.edu writes:
> The logical place for optical disk technology is to use
> it in place of Magnetic tapes
> (1) for distribution.
>   A CD-ROM is smaller, lighter, offline printable,
>   stores a vast amount of data,
>   and is very hard for the Postal Services to erase or damage.
> 
> (2)Write-Once-Read-Mostly Optical technology is an excelent replacement for
>   archival magnetic tape - about the speed I believe but better
>   volume and much harder to erase or accidently overwrite. I even think
>   that someone has a plug compatable Mag Tape replacement
> 
> Dick Botting (doc-dick)

Those are two very good, astute observations.  The standard misconceptions
are present however.  One of the more difficult things the general public
has yet to discern is the real, applicable difference between CD-ROM and
WORM (Write-Once-Read-Many. Yes, it used to be Read-Mostly but not any
more).

Barring the obvious technological differences, the CD-ROM has the
advantage of cheap, mass replication of data.  The WORM has the advantage
in flexibility and portability.  What??? portability you ask?  Yes.  True
portability implies the capability to exist and function through OS or
hardware changes.  "The data usefully outlives the machine that produced
it".  For example, that means taking your database originally created
under DOS (cringe), and "transparently" mounting it on something like a
Sun, Mac, VAX, etc.

Both types of media have a distinct and separate position in the market
place.  One needs to restrain from taking a new technology and forcing it
where it doesn't belong.  "Gee! Lets put our monthly financial records on
CD-ROM" or "Hey! Lets put our annual financial statement on a WORM and
make 10,000 copies for our shareholders".  Wrong.  It may seem obvious in
the extreme examples above, but it sometimes gets very confused by the
consumer and the manufacturer.  On the other hand, experimentation with
the technology in the market place is vital and needs to continue.

What does all of this have to do with the above quote?  (Finally!).  Well,
there seems to be some misconceptions between magnetic tape and WORM.  The
new 5 1/4" WORM products are extremely efficient and fast.  The typical
benchmarks show data reads being 92-97% of a 28ms hard disk.  Writes are
somewhat slower (the verify pass slows you down) and come in around
62-78%.  Combine that with the WORM's high density along with an
efficient, transparent OS interface and you have a really good, useful
product.  The key word here is useful.  If it's not useful, nobody (okay,
typically nobody) will use the damn thing. (Something to be aware of, disk
space efficiency is one of THE major components and usually the hidden
gotcha!).

Now we have a technology we can all use.  By looking at both WORM and
CD-ROM technologies and using them where they fit and avoiding using them
where they don't, you can achieve the maximum benefit of both.

Standard disclaimer:  I have nothing to do with WORMs except design and
write file systems for them and use them in my garden.

-- 
Matt Taylor @ Maximum Storage, Inc.    
Colorado Springs, CO.  303-531-6888   
{cbosgd,handel,hao,hplabs}!hp-lsd!frisbee!matt

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

From: Stan Brown <stan@sdba.uucp>
Subject: perl compilation problems
Date: 15 May 88 16:47:10 GMT
Posted: Sun May 15 12:47:10 1988
To:       info-unix@brl-sem.arpa

Subject: perl compilation problem
Newsgroups: comp.sources.d
Distribution: na

Hi;

	I am having a problem getting perl to compile on my machine.
For information sake the machine that I am working on is a Fortune 32:16
(a 68000) box.  The error that I am geting occcurs during the compliation
of perl.c and is something lik:

	./perly.c lin 2807 compiler error no table entry fo SASG

The lines of code of interest are:



	for (j = 1; ; ) {
	    arg[j++] = node[1];
	    ^^^^^^^^^^^^^^^^^^^
	    if (j >= i) {


	However I suspect that the problem may actuly lie in the 
for statement.

	Anybody have any thoughts on this one ?


-- 
Stan Brown	S. D. Brown & Associates	404-292-9497
gatech!sdba!stan
	"vi forever"

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

From: Stan Brown <stan@sdba.uucp>
Subject: cref & pr
Date: 15 May 88 16:52:32 GMT
Posted: Sun May 15 12:52:32 1988
To:       info-unix@brl-sem.arpa


	Does anyone know of a PD version of cref ?  My basic problem
is that ythe version that comes with my machine (a Fortune 32:16 
(a 68000 box)) aparently execs() pr for printing th source file(s).
This would be fine except that the version of pr that comes with
this machine gives a page length shorter than 66 lines if invoked
in a pipline.  I have fixed this for other places by alliasing
pr to pr -l66 & using the same synatx in all shell scripts that
use pr.

	Upon rfelction maybe what I need is a PD pr or a method
to convince pr that it is really pr -l66 when invoked from
cref (environmet variable maybe ?)

	Any thoghts would be appreciated

Cheers
Stan


-- 
Stan Brown	S. D. Brown & Associates	404-292-9497
gatech!sdba!stan
	"vi forever"

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

From: Stan Brown <stan@sdba.uucp>
Subject: Re: wanted: Sun 386 Workstation (Road Runner) info
Date: 15 May 88 17:07:57 GMT
Posted: Sun May 15 13:07:57 1988
To:       info-unix@brl-sem.arpa

> Some people are asking "Who will buy the Sun 386i ?" In this moderately-
> sized Astronomy Department (about 22 faculty ...) we are likely to buy
> THREE right away. We have 3 Sun-3 100-series machines already, and direct
> 
	** STUFF DELTED ****

> As I've said before on a different newsgroup, the Sun 386i is competitively
> priced when compared with other 386 systems because it includes many
> features which are necessary in a distributed academic environment but
> which have to be bought separately as add-ons to "street-market" PC's.
> Furthermore, the UNIX situation for 386 PC's is messy because there are so
> many hardware "standards" (sic) which no generic offering of UNIX can

	We too are looking at buying a couple.  We are a small controls 
system engineeriing co. & do a lot of in house work on a UNIX9tm)
machine.  However we are being forced to fo more & more software
development to run on DOS target machines.  In addition we presently
us a 12 MHZ AT clone for AutoCad(tm) work.  

	The Sun's will allow us to integrate all of these diverse
needs into a networking environmet where everyone will have acess
to the latest version of all data.

	The DOS compatbilty (while retainig a _real_ -:) operating
system for our users & developers) is the key here also.


-- 
Stan Brown	S. D. Brown & Associates	404-292-9497
gatech!sdba!stan
	"vi forever"

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

From: Larry Dighera <root@conexch.uucp>
Subject: Re: CSS Lab Motherboard + SCO Xenix 386
Date: 15 May 88 04:22:12 GMT
Followup-To: comp.unix.xenix
To:       info-unix@brl-sem.arpa

In article <193@milhow1.UUCP> Mike Howard writes:
>Is anyone running (or know of anyone running) SCO Xenix 386AT
>(system V 2.2.x) on a 'CSS Labs' 386 motherboard?
>I am attempting to go from brain dead to 386 w/o killing my
>piggie bank - one way to go involves replacing the mother in my
>clone with one of these.
>Mike Howard
>uunet!milhow1!how


The newer version of the CSS Lab's '386 system-board that is able
to be populated with up to four MB of RAM is known to run SCO Xenix 386 without 
any problem.  This is a good choice for users who want take advantage of the
increased clock rate (their 16 MHz system is switchable 20 MHz too!) and the 
linear address space, at a reasonable cost.  CSS Lab's makes a very 
reliable and well designed product.  Unfortunately, they are experiencing
difficulty obtaining 1 MB RAM chips.  As a result, they will only sell
their systems with a maximum of one MB of RAM installed, but as a temporary
measure you can use your old 16-bit RAM expansion card.
 
Users who can afford a to spend a little more should consider the purchase
of a system that supports RAM caching circuitry.  CSS is due to release
their new caching system-board this summer.  They won't reveal what
size the cache will be, but for multiuser/multitasking operating systems that 
will be running many processes (thus requiring a good deal of RAM), a
large cache (on the order of 256 K bytes) is superior to the 64 K 
RAM caches currently available on most '386 system boards.  

Everex is the only manufacturer I am aware of that offers caching 
circuitry of this size.  

Disclaimer: I am both a CSS Lab's and Everex dealer.  I don't sell
other than that in which I have complete confidence.


-- 
USPS: The Consultants' Exchange, PO Box 12100, Santa Ana, CA  92712
TELE: (714) 842-6348: BBS (N81); (714) 842-5851: Xenix guest account (E71)
UUCP: conexch Any ACU 2400 17148425851 ogin:-""-ogin:-""-ogin: nuucp
UUCP: ...!ucbvax!ucivax!icnvax!conexch!root || ...!trwrb!ucla-an!conexch!root

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

From: Stan Brown <stan@sdba.uucp>
Subject: Re: wanted: Sun 386 Workstation (Road Runner) info
Date: 16 May 88 13:23:48 GMT
Posted: Mon May 16 09:23:48 1988
To:       info-unix@SEM.BRL.MIL

> I can't stand MSDOS and would never buy a machine just because it ran MSDOS.
> I'd still buy a Sun 386i machine because:
> 
> 	1.  it's really fast (I've tried it)
> 	2.  it has decent big-screen, 8 bit, frame buffer graphics
> 	3.  it runs real UNIX and NFS
> 	4.  you can install 16MB of RAM
> 	5.  there are lots of 3rd party software vendors
> 	6.  it runs X11 and NeWS windows
> 	7.  it's real cheap for what you get
> 
> These are very popular features and there are no other machines like this.
> Unfortunately, RAM and 386 chips are scarce, so these machines may be hard
> to get.
>	FYI, our local SUn offcie quotes delivery (as of last week) as
	2-3 weeks.

 
-- 
Stan Brown	S. D. Brown & Associates	404-292-9497
gatech!sdba!stan
	"vi forever"

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

From: Norm Strong <strong@tc.fluke.com>
Subject: Re: question about vi
Date: 16 May 88 16:49:32 GMT
Sender: news@tc.fluke.com
To:       info-unix@SEM.BRL.MIL

In article <647@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes:
}In article <730001@hpfelg.HP.COM> lls@hpfelg.HP.COM (Lauri Schaaf) writes:
}...
}...
}...
}...When using mailx and writing a memo...
}...you can use " ~v " -- this will put
}...you into vi mode for your memo....
}
}Actually, it invokes whatever is defined for the environmental variable
}VISUAL.  I happen to use emacs.
Is there a way of invoking vi whenever you call the mail program, so you don't
have to type ~v each and every time?


-- 

Norm   (strong@tc.fluke.com)

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

From: Ken Seefried iii <ccastks@pyr.gatech.edu>
Subject: Re: unix on the ibm pc?
Date: 16 May 88 16:23:44 GMT
To:       info-unix@SEM.BRL.MIL

In article <1321MLWLG@CUNYVM> MLWLG@CUNYVM.CUNY.EDU writes:
>I have asked been asking around if anybod.CUNY.EDU writes: