HDTenEightyP/NetNews huggingface dataset:
From: gram@aim1.aztec.co.za (Graham Wheeler)
Subject: Re: Dell SVR$ (and Dell hardware) total lack of success on Postscript
Organization: Aztec Information Management
Date: Mon, 27 Jul 1992 09:07:28 GMT

pcg@aber.ac.uk (Piercarlo Grandi) writes:

>Dell in particular make it very clear that unless the customer buys a
>complete system integrated by them they do not take responsibility for
>system integration problems. They do not even represent that the Unix
>they sell will work *at all* with any non Dell hardware. All expense of
>system integration rests with the purchaser of their Unix product.

And this is their mistake. Probably because of Eric's FAQ, Dell UNIX has got
a lot of free publicity on the net, and judging by the increase in postings
over the last six months, a large increase in sales. While originally Dell
UNIX may have been a UNIX port available as a `perk' in the Dell hardware
marketing strategy, it is clear that Dell UNIX is rapidly becoming a product
in its own right. Dell could make the most of this success by dropping their
attitude of `if your hardware isn't ours, we're not interested', and instead
marketing Dell UNIX as a competitive product to SCO, ESIX, etc, and providing
better support to those of us who already had the hardware and just wanted the
software.

-- 
Graham Wheeler                     | "That which is weak conquers the strong,
Software Systems Engineer/Student  | that which is soft conquers the hard."
Aztec Information Management/UCT   | 		Lao Tzu - Tao Te Ching Ch. 78
gram@aim1.aztec.co.za / gram@cs.uct.ac.za 
Xref: sparky comp.unix.sysv386:12530 comp.unix.questions:9480 comp.unix.programmer:3955
From: wp@orion.erls01.siemens.de (Wolfgang Prediger)
Newsgroups: comp.unix.sysv386,comp.unix.questions,comp.unix.programmer
Subject: Re: What causes this ld error?
Date: 28 Jul 92 11:45:26 GMT
Reply-To: wp@orion.erls01.siemens.de
Followup-To: comp.unix.sysv386
Organization: SIEMENS AG, AUT 482, Nbg-M
X-Newsreader: Tin 1.1 PL4

guru@camelot.bradley.edu (Jerry Whelan) writes:
: I'm building a debugged version of MoNet (a network monitor
: program) on the following system:
: 
: AT&T 386-33 w/ 16 meg of RAM and 32 meg of swap.
: AT&T SVR4 2.0.1
: X11r5 pl13
: gcc 2.2.1
: 
: 
: When I do the final link stage for certain programs
: (xmonet for example) I get this error:
: 
: ld: xmonet: libelf error:  Memory error: output file space elf_update: 
: 
[ ... ]
Some months ago, I've got the same error installing (linking) some
executables of Oracle rdbms on SVR4 (SNI MX500-90).
I could fix it by increasing the DAT- and VMMLIM to the maximum value
(see /etc/conf/cf.d/{m,s}tune).

This part in my stune:

SVMMLIM         0x7FFFFFFF
HVMMLIM         0x7FFFFFFF
SDATLIM         0x7FFFFFFF
HDATLIM         0x7FFFFFFF

Maybe, these values are too big, but who can afford the time
to build a lot of kernels to find out real 'good' ones ?!

Hope this helped you

 - Wolfgang
--
Name : Wolfgang Prediger
Email: wp@orion.erls01.siemens.de
Snail: Siemens AG, AUT 482, Gleiwitzer Str. 555, 8500 Nuernberg Germany
Voice: +49 911 895 3155 (work)
 --- "Beam me up, Scotty, there's no intelligent life down here !" ---
Newsgroups: comp.unix.sysv386
From: kasab@luther.che.wisc.edu (John J. Kasab)
Newsgroups: comp.unix.sysv386
Subject: Using GhostScript as a filter for HP-DeskJet 500 (DELL SVr4)
Date: 28 Jul 92 02:42:34 GMT
Organization: University of Wisconsin - Madison
Originator: kasab@luther.che.wisc.edu

I have recently successfully compiled GhostScript on my PC, which is running
DELL's SVr4, and I am eager to start printing PostScript files on my
HP DeskJet 500.  I did include the djet500 device driver in the compilation
of GhostScript.

From looking around, it seems as if I'd need to run the lpfilters program,
and set up a "dummy" name for the GhostScript-driven DeskJet (e.g., hpdjgs).
Is this correct?  If anyone else has done this, I'd appreciate their input,
especially on common pitfalls.  I'm nervous about tinkering too much with my
machine, and I'd appreciate the "hand-holding."

Please e-mail replies, and if there is interest, I'll post the results.

Thanks a bunch,
JK
-- 
-------------------------------------------------------------------------------
  John Kasab                             "I rarely speak in absolutes."
Arpanet: kasab@cae.wisc.edu              (alt: kasab@luther.che.wisc.edu)
      The NSF and UW--Madison don't speak for me, nor I for them.
From: fsg@holos0.uucp (Frank Glass)
Newsgroups: comp.unix.sysv386
Subject: Re: Dell SVR4 and Postscript ANSWER (from the NET of course)
Date: 23 Jul 92 16:14:40 GMT
Distribution: na
Organization: Holos Software, Inc.

Two questions:

1.  Why didn't you expect the answer to come from HP rather than Dell?
It seems that if you purchase pieces from two different sources you should
expect to have difficulty with interface problems with possibly nowhere to
turn.  As has been pointed out, this is what VARS and dealers are for.

2.  Where _is_ the behavior of postio and related programs documented?
In our $1000 or so worth of SYSV documentation from NCR, AT&T and others
I haven't found documentation.  I ended up writing code from scratch to
get a postscript printer to run across a network using a named pipe to
capture the output of postio.  A real kludge born of lack of documentation.
-- 
Frank Glass
Holos Software, Inc. 
Atlanta, Georgia  USA
uucp: gatech!holos0!fsg
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.unix.sysv386
Subject: Re: Fun with uugetty (ISC)
Date: 22 Jul 92 21:36:16 GMT
Article-I.D.: iecc.9207221736.AA12691
Organization: I.E.C.C.

I don't understand why they still ship uugetty.  As of ISC 2.2, you don't
need it.  You put regular old getty on /dev/ttyd00 and dial out on
/dev/acu0.  The kernel does all the locking.  It works great.  I've been
using this approach with 2.2 and now 3.0 for about two years.

You can also use FAS, in which case you dial out on /dev/ttyF00 and put
the getty on /dev/ttyFM00.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
From: fr@compu.com (Fred Rump from home)
Newsgroups: comp.unix.sysv386
Subject: Re: WHEN TO TURN OFF MY MACHINE?
Date: 29 Jul 92 14:56:57 GMT
Organization: CompuData Inc.

jfh@rpp386.lonestar.org (John F. Haugh II) writes:

>This machine has been on continuously since September, 1987.  The main

>I =do= want a new machine.  A 16MHz 386DX isn't anything worth bragging
>about any longer.  But it's hard to argue with a machine that just doesn't
>give me any trouble.

I had one of those until a couple weeks ago. (The old junk always filters in my 
direction)

But I wanted more memory and the old Intel board with the 512KB base memory 
and the $1500 add-on board to give me a grand total of 2Mb seemed to be a bit 
passe. I bought a board (386/40 magitronics) that now advertises for $155 in 
Computer Reseller (Liuski), stuck some RAM and a 387/40 chip in there and I 
have an absolute screamer comparatively speaking. It's basically my news/mail 
machine but what a difference for so little dollars. Obviously none of the 
above made by Intel but that's life in a competitive world.

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: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Dell Unix..
Organization: Texas Instruments, Inc
Date: Sun, 26 Jul 1992 04:24:46 GMT

In article <3635@randvax.rand.org> edhall@rand.org (Ed Hall) writes:
>
>Actually, both of my experiences with ESIX tech support were quite
>satisfactory.  That might be a fluke.  The recent display of bad attitude
>by a Dell support person on the net might be a fluke, too.

Uh, that was no support person, that was a developer.  Some people
have apparently lost sight of this (and yes, there IS a distinction
:-)).

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.unix.sysv386
From: larry@trauma.rn.com (Larry Snyder)
Subject: Re: Dell Unix..
Organization: Gator Conferencing Systems - 219-289-0777 - 6 lines
Date: Sat, 25 Jul 1992 18:30:05 GMT

edhall@rand.org (Ed Hall) writes:

>Actually, both of my experiences with ESIX tech support were quite
>satisfactory.  That might be a fluke.  The recent display of bad attitude
>by a Dell support person on the net might be a fluke, too.

We purchased ESIX SVR4.  It wouldn't install from a SCSI tape.  After
calling ESIX -- they informed us that we needed to download patches
from their BBS.  We asked for them to mail us the patches -- and they
said they would need to charge it to our Fed Ex account.  They mailed
the patches and we couldn't get the tape to install.  The tape ended
up being defective.  We called ESIX -- and they said a replacement tape
would be send COD for shipping charges unless we again supplied a Fed
Ex account number.  Get real -- you spend $1000 for software and still
have to supply the Fex Ex account number for shipping.   What a crock

They didn't even bother to include the "patches" with future shipments.
One would think they would have patched the distribution master keeping
it current before making the tapes since they didn't mass produce the
tapes (according to ESIX)

-- 
Larry Snyder                                    internet: larry@gator.rn.com
4950 Estero Blvd, Ft. Myers Beach, FL            uucp: uunet!rde!nstar!larry
Newsgroups: comp.unix.sysv386,comp.unix.i386
From: kss@laphroaig.cs.hut.fi (Kati Susanna Suominen)
Subject: rshd problems in Interactive 3.0
Reply-To: kss@nharju.fi
Organization: /u/users5/ohterwise/kss/.organization
Distribution: comp
Date: Tue, 28 Jul 1992 07:29:57 GMT


	I bumped into a strange error message while using rsh or rcp
	in my Interactive 3.0. The message apparently comes from rshd
	and says: 

	Logins currently disabled

	I couldn't find this in my rshd manual page and my local
	Interactive vendor had never come across such a message.
	Otherwise the tcp/ip works fine (rlogin and telnet work and we
	have the appropriate /etc/hosts.equiv-entries).

	If you have any suggestions (other than reinstalling the
	tcp/ip -package), please mail them to me as I can't read this
	newsgroup regularly.


	Thanks,

	- Kati -
Newsgroups: comp.unix.sysv386
From: wright@jpl-devvax.jpl.nasa.gov (Steve Wright)
Subject: Horrible Video Mode
Keywords: dell, video, boot
Organization: Jet Propulsion Laboratory (NASA)
Date: Tue, 21 Jul 1992 18:46:37 GMT


    I'm running Dell SVR4 on a 486/50 EISA machine with a Diamond 
    Speedstar 24.  The setup is set for VGA.  When it starts the boot 
    process it displays messages something like:

	Booting the Unix ...
	Starting Unix ...
    
    It then changes video modes and starts printing a bunch of copywrite info
    in what looks like CGA color mode and stays in that mode.  It's horrible.

    Does anybody know whats happening and what to do about it.

    Thanks in advance
    Steve Wright
    wright@jpl-devvax.JPL.NASA.GOV
From: davidsen@ariel.crd.GE.COM
Newsgroups: comp.unix.sysv386
Date: 18 Jul 92 00:21 MDT
Subject: Re: Does SCO SYSV3.4 or SYSV3.2 has job
Nf-ID: #R:1992Jul15.201913.27297@cmcl2.nyu:-285472103:1992Jul17.202117.28754@crd.ge.co:-1071235273:001:914
Nf-From: ariel.crd.GE.COM!davidsen    Jul 18 00:21:00 1992


In article <1992Jul15.201913.27297@cmcl2.nyu.edu>, wuwei@acf3.nyu.edu (Wei Wu) writes:
|> I am using SCO SYSV3.4 and SCO ODT at work. One annoying thing about
|> SCO is that there is no job control capability. I am used to BSD style
|> of job control.  
|> Does SCO has job control build into the kernel ? Or is it shell's
|> responsibility to impliment it ?   Is it posible to get it under SCO
|> Unix ?

  Works fine in our ODT 2.0, don't know about the older versions, can't
find one on our net. I never tried sh, but ksh works fine. You may want
to use stty to redefine the susp character if you're used to ^Z. I
neither know nor care what csh does.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	It never ceases to amaze me that otherwise rational people, able to
	understand calculus, compound interest, and the income tax form, can
	continue to believe that poker is a game of chance.

Newsgroups: comp.unix.sysv386
From: larry@trauma.rn.com (Larry Snyder)
Subject: Re: Dell Unix..
Organization: Gator Conferencing Systems - 219-289-0777 - 6 lines
Date: Wed, 22 Jul 1992 17:56:17 GMT

rmk@rmkhome.UUCP (Rick Kelly) writes:

>I guess you could always buy ESIX, MST, or Consensys.  Support won't be an
>issue.  There won't be any.

That is a very good way to put things...  

-- 
Larry Snyder                                    internet: larry@gator.rn.com
4950 Estero Blvd, Ft. Myers Beach, FL            uucp: uunet!rde!nstar!larry
Xref: sparky comp.unix.sysv386:12231 comp.os.linux:6364
From: shite@sinkhole.unf.edu (Stephen Hite)
Newsgroups: comp.unix.sysv386,comp.os.linux
Subject: Warning about Diamond Speedstar 24
Date: 22 Jul 92 04:31:22 GMT
Organization: Univ. of North Florida


   I recently ordered a Diamond Speedstar HIColor and the manual called it
the Diamond Speedstar 24.  Are these the same card?  If so, then they've
changed something since the beginning of '92 because you can't get the
dot clocks so X386 can set your monitor into modes about 640x480.
This is because X386 1.2E reports:

     25 28 0 0 0 0 0 0 13 14 0 0 0 0 0 0  (the 13 may be a 12, forgot)

The report in the mode X386 database gives dot clock values for the 
Diamond Speedstar HIColor but I'm thinking this person had an older
card that didn't have these programmable dot clocks (VCO chip???)

I wanted to warn people about this card because even though it's an et4000
chipset, it's no good if you can't get at or program the dot clocks so
we can use it for X386 1.2E work.  Also because I had recommended it to
this group based on the knowledge of what was in the mode X386 database
(the database reports dot clocks so I'm very confused here) and everybody's 
high praise on the net over the last year for their Diamond Speedstar line 
of cards.  I apologize.  I'm paying my just deserts now for having to 
send it back and take the hit on the 15% restocking fee.  :-(

 

Steve Hite
shite@sinkhole.unf.edu
Xref: sparky comp.unix.sysv386:12368 comp.os.linux:6601
From: oklein@smallo.bo.open.de (Olaf Klein)
Newsgroups: comp.unix.sysv386,comp.os.linux
Subject: Re: What the 17" monitor reviews never tell you
Date: 23 Jul 92 22:16:55 GMT
Organization: smallo.bo.open.de Fido-SubNet-Gate : 2:245/5800.12

shite@sinkhole.unf.edu (Stephen Hite) writes:


>   I just wanted to let anyone who is deciding to purchase a 17" monitor
>for X386 work to be be cautious when making their decision.  I just
>bought one of the highest rated monitors in the $1100 price range
>(the Nanao 550i) and the one  I got has a tremendous problem with this
>"rainbow effect" at 1024x768.  There's a term for it that starts with the
>letter 'm' that I can't remember but the "look" is akin to a magnetic field
>pattern.

I have an Eizo (which is the nanao in german) 9080i with the same
symptoms. I gave it back to get a new monitor, but got a letter from
Eizo, which said, that these 'moire' (thats the word with 'm' :-) )
pattern are a characteristic for 17" monitors. My solution is to have
a 'cornflowerblue' root window...

Bye, Olaf

-- 
Olaf Klein	smallo.bo.open.de	2:245/5800.12
From: debra@wsinis07.info.win.tue.nl (Paul De Bra)
Newsgroups: comp.unix.sysv386
Subject: Re: Wanted: SysV Text User Interface Builder
Date: 28 Jul 92 07:11:28 GMT
Reply-To: debra@info.win.tue.nl
Organization: Eindhoven University of Technology, the Netherlands

In article <1992Jul27.035409.3072@escape.vsse.in-berlin.de> felix@escape.vsse.in-berlin.de (Felix the double Helix) writes:
>sells@cs.umn.edu (Chris Sells) writes:
>... but under system v.4 you have
>FMLI (Forms and Menu Language Interpreter). iit's really a great tool
>for creating nice a nice curses-style gui and as easy to program as a
>shell script (instant guis ;-)
>
>before you actually *pay* for such a tool, i'd rather suggest
>getting system v.4.

Chris is running AT&T SysV 3.2 which already has FMLI.
I don't know whether AT&T added FMLI only to their own product or
whether third party vendors got it and decided to drop it,
but it's there allright.
And so is the system administration package based on it of course.

Not 100% identical to the one in SysV 4.0 but close enough.
So no need to move to SysV 4.0 just to get FMLI.

Paul.
From: shite@sinkhole.unf.edu (Stephen Hite)
Newsgroups: comp.unix.sysv386
Subject: Re: esix 4.0.4 experiences
Date: 30 Jul 92 11:46:41 GMT
Organization: University of North Florida, Jacksonville

In article <Bs5DGG.BE1@gator.rn.com> larry@gator.rn.com (Larry Snyder) writes:
>shite@sinkhole.unf.edu (Stephen Hite) writes:
>
>>  I've got 4.0.3a and am also waiting for more net feedback before mushing 
>>ahead.
>
>what does 4.0.3a fix over 4.0.3 ?
>
>-- 
>Larry Snyder                                    internet: larry@gator.rn.com
>4950 Estero Blvd, Ft. Myers Beach, FL            uucp: uunet!rde!nstar!larry

  It's the same thing.  It's similar to what Everex did with their
SysV 3.2.  They'd have release A, B, C, D.... So, they tacked the 'a'
on the end of 4.0.3 with the anticipation that a new release at the same
level would be a 'b' and so forth.  Everex went from one release of
4.0.3 right to 4.0.4 so the 'a' is insignificant.

Steve Hite
shite@sinkhole.unf.edu
Newsgroups: comp.unix.sysv386
From: neese@adaptx1.UUCP (Roy Neese)
Subject: Re: sector remapping woes with 1542A/SCO Unix
Organization: Adaptec Inc., Texas
Date: Wed, 29 Jul 1992 20:29:43 GMT

In article <467@wurtel.hobby.nl> paul@wurtel.hobby.nl (Paul Slootman) writes:
> The problem is this: if I disable the two "standard" disks in the CMOS
> setup of the machine, the Adaptec SCSI controller properly sees the
> SCSI disk and installs it as C:. If I put DOS on it, there's no problem,
> I can boot from it, run apps, etc.: everything works ok. The SCSI BIOS
> remaps the sectors to 318 cylinders of 64 heads, 32 sectors, giving me
> 318 MB, which is right.
> 
> However, when I access it from UNIX by installing SCO Unix 3.2.2, SCO
> tells me it's a disk with 1272 cylinders, 16 heads, 32 sectors, also
> giving me 318MB. However, after installing everything, I can't boot from
> it ("NO OS").
> 
> What is my problem? Why does SCO Unix do this? What part of the kernel
> to I have to patch? :-) Is it my "old" 1540A? I would be grateful for
> *any* hints or suggestions anyone has.

Sounds like someone has replaced the BIOS on the 1540A adapter to
upgrade it from the original 16 head translation to get the BIOS to do
64 head translation, but didn't change the firmware.
UNIX drivers decide which translation to use by reading a configure byte
from the firmware.  This tells the driver which translation to use.
Now, SCO use to have the provision to alter the translation or mapping
before the partition table was created.  If you just edit it that table
and insert the numbers DOS came up with, you will be okay as these funny
head/sector numbers aren't really used by SCO excpet during partition
creation time.
---

			Roy Neese
			Adaptec Senior UNIX/SCSI Software Engineer
			UUCP:	convex!egsner!adaptex!neese
			Inet:	neese%adaptex@cirr.com
Newsgroups: comp.unix.sysv386,biz.sco.general
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: diffs to net/2 fingerd for SCO 3.2v2
Organization: Kithrup Enterprises, Ltd.
Date: Mon, 27 Jul 1992 11:08:55 GMT

Here are some diffs to make the Net/2 fingerd compile and run under SCOnix,
with logging via syslog.  (That was about the major extent of the changes,
actually.)  Use at your own risk; I have tested somewhat, but not
extensively.  If you find any bugs, please let me know, but don't expect me
to rush to fix them 8-).

Diffs for the net/2 finger in the next posting.

-- snip snip --
*** fingerd/Makefile.~1~	Sun Jul 26 13:54:08 1992
--- fingerd/Makefile	Sun Jul 26 14:00:01 1992
***************
*** 4,10 ****
  MAN8=	fingerd.0
  OBJS=	fingerd.o
  CC=	gcc
! CFLAGS=	-g
  
  fingerd:	$(OBJS)
  	$(CC) $(CFLAGS) -o fingerd $(OBJS) $(LIBS)
--- 4,11 ----
  MAN8=	fingerd.0
  OBJS=	fingerd.o
  CC=	gcc
! CFLAGS=	-g -DLOGGING
! LIBS=	-lsocket
  
  fingerd:	$(OBJS)
  	$(CC) $(CFLAGS) -o fingerd $(OBJS) $(LIBS)
*** fingerd/fingerd.c.~1~	Sun Jul 26 13:10:04 1992
--- fingerd/fingerd.c	Sun Jul 26 19:55:30 1992
***************
*** 43,49 ****
--- 43,84 ----
  
  #include <stdio.h>
  #include "pathnames.h"
+ #ifdef LOGGING
+ # include <syslog.h>
+ # include <sys/types.h>
+ # include <netinet/in.h>
+ # include <sys/socket.h>
+ # include <netdb.h>
+ #endif	/* LOGGING */
  
+ static char *
+ remote_hostname (struct sockaddr_in laddr) {
+   union {
+     unsigned long ul;
+     struct {
+       unsigned char uc[4];
+     } s;
+   } ip_addr;
+   static char ip_name[50];
+   char *name;
+   struct hostent *hp;
+ 
+ /*  ip_addr.ul = ntohl(laddr.sin_addr.s_addr); */
+   ip_addr.ul = laddr.sin_addr.s_addr;
+   if ((hp = gethostbyaddr ((char *)&laddr.sin_addr,
+ 			   sizeof (laddr.sin_addr),
+ 			   AF_INET)) == 0) {
+     sprintf (ip_name, "[%d.%d.%d.%d]",
+ 	     ip_addr.s.uc[3],
+ 	     ip_addr.s.uc[2],
+ 	     ip_addr.s.uc[1],
+ 	     ip_addr.s.uc[0]);
+     name = ip_name;
+   } else
+     name = hp->h_name;
+   return name;
+ }
+ 
  main()
  {
  	register FILE *fp;
***************
*** 54,60 ****
  	char **ap, *av[ENTRIES + 1], line[1024], *strtok();
  
  #ifdef LOGGING					/* unused for now */
! #include <netinet/in.h>
  	struct sockaddr_in sin;
  	int sval;
  
--- 89,95 ----
  	char **ap, *av[ENTRIES + 1], line[1024], *strtok();
  
  #ifdef LOGGING					/* unused for now */
! 	char *tline, *cp, *tcp;
  	struct sockaddr_in sin;
  	int sval;
  
***************
*** 65,70 ****
--- 100,119 ----
  
  	if (!fgets(line, sizeof(line), stdin))
  		exit(1);
+ 
+ #ifdef LOGGING
+ 	openlog ("fingerd", LOG_PID, LOG_DAEMON);
+ 	setlogmask (LOG_UPTO (LOG_DEBUG));
+ 	tline = alloca (strlen (line) + 1);
+ 	strcpy (tline, line);
+ 
+ 	for (cp = tline; *cp; cp++) {
+ 	  if (*cp == '\n' || *cp == '\r')
+ 	    *cp = ' ';
+ 	}
+ 	syslog (LOG_INFO, "%s:  `%s'", remote_hostname(sin), tline);
+ 	closelog ();
+ #endif	/* LOGGING */
  
  	av[0] = "finger";
  	for (lp = line, ap = &av[1];;) {
-- 
Sean Eric Fagan  | "My psychiatrist says I have a messiah
sef@kithrup.COM  |  complex.  But I forgive him."
-----------------+              -- Jim Carrey
Any opinions expressed are my own, and generally unpopular with others.
From: john@rhutch.uucp (John Strittmatter)
Newsgroups: comp.unix.sysv386
Subject: Re: ESIX won't install
Date: 29 Jul 92 10:23:49 GMT
Distribution: na
Organization: Rabbit Hutch

jon@hitachi.uucp (Jon Ryshpan) writes:
: I can't install ESIX on a clone using ufs style file systems.  No
: trouble installing it using s5 style file systems.  Any ideas about 
: the trouble?  Could it be the disk controller?  The details:


I had a similar problem installing Esix 3.2D on my system with an Adaptec
SCSI controller.  After low-level formatting the drive I turned the 
computer off for 30 seconds, and then I installed Esix.  You might give
it a try.

Why ask why!

John
Newsgroups: comp.unix.sysv386