From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.lang.c,comp.unix.misc
Subject: Re: Giles' (Manual) Mania (getting longuish)
Date: 9 Sep 92 01:21:12 GMT
Followup-To: comp.unix.misc
Organization: CWI, Amsterdam

First off, I have extensive exposure to Scope and NOS/BE (since about 1973
until the beginning of this year when the last CDC I did use was decommisioned).
Also I do have extensive exposure to Unix (since about 1979 with Unix V6,
followed by V7, different versions of BSD, some System III, and now a mixture
of BSD plus clones and System V plus clones).
So I think I am in a reasonable position to compare the two.  (And I have
also had fairly extensive exposure to Cray's COS and Unicos.)

And secondly, this does not make sense at all in comp.lang.c.  I have
cross-posted this to comp.unix.misc and redirected followups to that
newsgroup.

(For those in that newsgroup that did not read (some of) the base articles,
the discussion is about the respective merits of CDC's Scope and Unix.
Jim Giles maintains that the two have about the same functionality and
that Scope is easier to learn.  In response to earlier claims (also by
Jim) I showed quite a few inconsistencies and difficulties with Scope.
Ted Powell followed up that reading my article provoked some bitter
reminiscences of Scope.)

In article <who needs this?> jlg@cochiti.lanl.gov (Jim Giles) writes:
 >                       In short: the designers assumed (respectively) 
 > that (Scope) only one Fortran program will run before certain things 
 > were cleared and (UNIX) only one program will fail as the result of a 
 > single execution of a batch file (shell script).
First off, there is an obvious difference in the design of Scope and Unix.
Scope was primarily intended for batch (punched card) use with interactive
use hacked in later (Intercom).  Unix was primarily intended for interactive
use.  Comparing a Scope batch file with a Unix shell script does not make
sense.  When comparing you should compare the CCL procedure with a shell
script.  In the original version of Unix there is no comparative to
batch files.  (With some Unices providing NQS or some other queuing
system that is different of course.)  And yes, when a Scope batch job fails
I would get a print-out of a core dump, although in most cases I did not
need it at all.  And when I needed it the error would most likely be a
jump to address 0, where the address the jump came from would also be 0
(MODE ERROR=0, the address was in bits 47-30 of RA+0 if I remember right).
Pretty useless.  No possibility at all for a traceback.
 > 
 > Another example was the loss of files in Scope which you didn't 
 > explicitly save.  Well, the conventional method in UNIX for temporary 
 > files is to create a file (while opening it), destroy the file, but 
 > keep it open (so there's still a link).  This will automatically 
 > destroy the file when the process terminates - and there's nothing 
 > you can do to save it!  Since this is the conventional UNIX `idiom',
 > I've lost countless files this way - even when the process terminated
 > abnormally (ie. when you want *all* context saved so that you can
 > try to diagnose the problem).
That is *not* the conventional Unix 'idiom'.  The conventional 'idiom' is
to do that *if* you are not interested in that temporary file, whatever
the case may be.  The conventional 'idiom' is to put a trap statement in
your script that removes your temporaries.  If you write it correctly no
temporaries are removed if your program goes wrong.  Compare that to
Scope where you have to mention explicitly that you want to save something:
	REQUEST,FILE,*PF.
and have to explicitly save it afterwards!
 > 
 > Scope *was* a lot smaller and easier to use than UNIX and provided more
 > features in the kernel for the use of hardware capabilities (like 
 > asynchronous I/O).
Did the PDP-5 provide asynchronous I/O?  Asynchronous I/O makes sense
only on some processors, and if the manufacturer does his work well he
will provide it in the Unix environment.  I think Cray does, but I never
needed it (because most of my programs on the Cray have only one bit of
output, the number is prime or not).  I think also that Convex has it.
It can be put in the Unix OS without problems.
 >                     For messing with text filters, UNIX has more
 > power than Scope did - for most other things, UNIX does not.
That is an understatement, Scope had no power at all, you had to write
your own text filters.  Now please define "most other things".
Interactive editing?  EDITOR was a joke.  After the umpteenth time
that EDITOR gave up with
	MUJ SYSTEM ERROR 0(FATAL)
which meant that you lost everything you had done during the edit session
I decided to write my own editor.  I know that has occurred at numerous
places.  At least when Unix crashes while you are in an edit session you
can retrieve most changes you have made during the edit session (and with
my editor for NOS/BE that was also true).  But many people in my department
(numerical mathematics) in this institute have made the transition from
NOS/BE to Unix.  When confronted to Unix there is a learning curve some
people initially do not want to take, but I do not think the people think
the system they use now is comparative to Scope, some think it vastly superior.
What they did initially learn is how to edit files (with vi, a full screen
editor, no such thing in Scope, and if you call NOS's FSE a full screen editor
I'll scream; basic commands only), how to remove files, how to compile their
programs, some rudimentary knowledge of make, some useful things about the
Korn shell (history etc.), and that's about it.  With that they can do about
everything you can do under Scope, and more.
 >                                                               And,
 > the UNIX environment is *much* larger and harder to learn.
It is larger, true, but that is because it provides more, not less.
(Ob. joke, some provide both more and less.)
 >                                                             Due to
 > its checkered past, UNIX is also home to more (and more subtle)
 > inconsistencies.
There are many more inconsistencies in Scope than in Unix.  Unix has
only one command to copy a file.  Scope has: COPYBF, COPYCF, COPY,
COPYSBF, COPYRAN.  Now can you quickly explain what
	COPYCF,IN,OUT,1,15
does do and what the difference is with
	COPYBF,IN,OUT,1,15
and with
	COPYCF,IN,OUT,,16
and
	COPYCF,IN,OUT
and why you can write:
	COPYCF,I=IN,O=OUT
but cannot reorder the other parameters?

Why is it that many utilities disagree about the exact format of a
Z-type record formatted file?  (For the ignoramus, Z-type record files
are basic text files.  A line is terminated with a (60 bit) word
containing 12 zero's in the low order 12 bits of a word.  The Scope
utilities maintain three different philosofies about the exact format:
1.  The word terminating the line should be filled with 6-bit spaces
    until the 12-bit line terminator.
2.  The word terminating the line need not be filled with spaces.
3.  If a line for some reason has only 9 characters in the last word
    it can be filled with zero bits, followed by a zero word line terminator.
When a program using philosofy 3 creates a file that is subsequently read
in by a program using philosofy 1 chances are big that the 6 zero bits in
the last word but one are replaced by a colon.  And it could even be more
circumspect: write a file in Pascal with a line of 9 symbols; read it in
EDITOR; you will see no difference; write it back; read it back, and now
the colon is visible.  I will not mention of course that the different
NOS's for CDC have 4 different 6-bit character sets and 3 different ASCII
character sets.  In its latest incarnation my editor supported them all.)
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland
dik@cwi.nl
Newsgroups: comp.lang.c