Why no job control in 386/ix?

[overhead]

In article <251 at ndla.UUCP> platt at ndla.UUCP (Daniel E. Platt) writes:
>In article <3880 at amelia.nas.nasa.gov>, izen at amelia.nas.nasa.gov (Steven H. Izen) writes:
>> The C-shell which was included with 386/ix (a system V UNIX for 386 boxes)
>> does not support job control.  Is this because
>> 	1) The kernel is missing something required to support it,
>> 	2) ISC was too lazy to implement it, or
>> 	3) other?
>The answer is closer to option 1) (please forgive verbosity... I need to fill
>space to get this through the news filter...)
Change the >'s to #'s.

>The Job Control features are based on Berkely xx.xx (pick your version).  The
>C Shell (csh) sends SIGSTOP and SIGCONT.  These Berkely functions are not
>available on SysV (AT&T Unix), and most of the other Unixen supported on
>i386 boxes. 

OK, I'm getting tired of reading how 386/ix doesn't have Job
Control (JC).  As a developer, I've been running an inhouse
version of JC for some time.  386/ix has JC starting with
2.1[.0].  386/ix 2.2[.0] will be released soon (I think there has
been an announcement).  Starting with 2.1, 386/ix supports POSIX
1003.1, and FIPS 151-1.  This requires JC.

386/ix 2.2 should be pretty stable, judging by my pre-release 2.1
system.  My Compaq 386/25 has been running without problems - up
for the last 14 straight days.  I believe I brought it down a
couple weeks ago to run native MSDOS briefly (it was quicker than
installing VP/ix, considering I don't use DOS on this machine
"ever").  I haven't had a crash in quite some time.  I use the
machine extensively.  I understand that the changes for 386/ix 2.2
involve bug fixes and making it run on some strange
configurations of hardware.  ISC spends alot of time making
386/ix run on strange hardware.  If we could just use (say)
Compaq's, life would be pretty easy.

Reasonably massive kernel & utility changes were required for JC
under an SVr3 system.  ISC listens to their customers.  I'd like
to thank the IEEE P1003.1 committees for putting Job Control into
the POSIX specification (as an option).  I'd like to thank the US
Government for stating in no uncertain terms (FIPS 151-1) that
they want Job Control.  The US Government is a buyer with absurd
buying power.  If they said, "we'd like pretty flowers on the
screen during startup", the very next version of 386/ix would
have it.  Further, it would be out in record time.  For the
record, the US has made no such request.

If I had the choice of running 386/ix 1.0.6 (pre Fast File System
(HPDD/FFS)) with JC, and running 386/ix 2.0.2 (last release
without JC, but has HPDD/FFS) I would go with the Fast File
System every time.  I'm used to JC, but with training, I can get
myself to put things into the background at command invocation.
The Fast File System increases disk performance by a factor of 10
to 15 (given good hardware - track buffering & 1:1 interleave).
UNIX systems are often disk bound.  I thought that speeding up
the disks would make 386/ix CPU bound.  False.  System throughput
increased by a factor of 10 to 15.  The system still waits for
the disks or the users.  X windows can be used as a poor man's
JC.  Virtual screens can be used as a poor man's JC.  Nothing
can replace a high speed file system.

Oh, I recall someone complaining about not having manual pages.
I believe 386/ix 2.2 will also have on-line manual pages.  I'd
like to blame the AT&T license for this fiasco.  First they let
you have them, then they didn't, now they'll let us have them
again.  If you ever get a set on line - i'd keep them on a tape
somewhere.  If AT&T changes their mind again - you may not have
up to date man pages - but you'll still have some.  It's legal -
you paid for them!

Stephen Uitti
Interactive Systems Corp
suitti at haddock.ima.isc.com
DISCLAIMER: I don't speak for INTERACTIVE, I speak for me.
Please pardon my header, I'm still trying to get nntp to work right.