Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!snorkelwacker!bloom-beacon!eru!luth!sunic!compuram!pgd
From: pgd@bbt.se (P.Garbha)
Newsgroups: comp.unix.xenix
Subject: Re: Problems with SCO Unix/Xenix
Message-ID: <1990Jun11.071618.209@bbt.se>
Date: 11 Jun 90 07:16:18 GMT
References: <4664@minyos.xx.rmit.oz> <1990Jun9.135124.16301@bbt.se> <715@n4hgf.uucp>
Organization: The Bhaktivedanta Book Trust
Lines: 52

In article <715@n4hgf.uucp> wht@n4hgf.UUCP (Warren Tucker) writes:
>Obviously, you have little or no experience in producing large
>software systems :-) :-/. I would leave that as enough said, since
>those who have had such experience would understand the one liner.
>However, for you I will elaborate:  Since your kernel came up and
>you created users and loged on, a great deal must be right.  In fact,
>the w and uptime programs are minor, minor problems compared with
>those persisting with many other systems in the world, from UNIX 386
>implementations to multi-million dollar systems.

In fact i DO have quite some experiences of computer programming.
Probably not as much as you though, since i only had been working with
computers for 15 years. :-) 
Besides i complained about the "ps" program, not w and uptime. 
Someone else was complaining about w and uptime. 

ps is quite important if you have 20 incoming lines and you are system
manager for that system.
"I would leave that as enough said, since those who have had such
experience would understand the one liner." :-)

I have not seen the source code for the xenix ps, but i have seen the
binary code. The program sometimes used to say "seek error", when
running it. (It was ALWAYS saying seek error on an emacs-process)
The fix was to remove the error check after a lseek(). After that it
works. After a lseek() you expect something like:
	if (lseek(....) == -1)
		error("Seek Error");
But instead i found some kind of dibbling with the low byte of the
returned value.

>
>As for fsck, bleat all you want, but you can get around the rare root
>partition fsck wont handle at startup by answering the
>  Root file system [has problems] fix?
>with no.  Go to single user state. Do a fsck -rr /dev/root
>and it will do the work.  You may or may not have to reboot
>when fsck terminates.

I am sorry if i said that it was on the root partition fsck failed. It
is not. It is on another partition. The program dies after 15 seconds
without any message, except for the "***** checking blocks and sizes ****" 
message. Now, fsck is not an essential program either, since the
system runs without it (if you patch away the "dirty" bit in your "rc"
file). But i would for sure appreciate to have it working.

This way we can aliminate 90% of the programs of unix as "not
essential", and therefore they need not to be working. "We have more
important things to fix than non-essential programs" :-)

ps. i am soon moving from Xenix 2.3.1 to 2.3.2, hoping that it is
working better.