Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!smoke!bzs@bu-cs.bu.EDU
From: bzs@bu-cs.bu.EDU (Barry Shein)
Newsgroups: net.unix-wizards
Subject: Unix on IBM Mainframes & Clones
Message-ID: <3162@brl-smoke.ARPA>
Date: Tue, 19-Aug-86 19:03:53 EDT
Article-I.D.: brl-smok.3162
Posted: Tue Aug 19 19:03:53 1986
Date-Received: Thu, 21-Aug-86 21:03:49 EDT
Sender: news@brl-smoke.ARPA
Lines: 113


I tried IX/370, first on our 3081 and later on our 3090/200.

I will say that the IBM developers spoke with me about my reactions
and were very receptive, so some of the criticisms below (none of
which are horribly fatal) were noted and may very well be getting
fixed as we speak.

Good points:

It is SYSVR1, pretty much complete.

On my system (see above) it was *FAST*. I'm talking about doing
C compiles and having the prompt come back so fast I thought it
must have somehow missed the command, really! I had to check!
I measured over 31,000 dhrystones which remains in the recent
listing the fastest result. It may be faster than that, there
were over 150 users on the system when I got that result.

They handled the base-register problem a little more elegantly
than the C/370 system we had previously been using. This means
that a base register on an IBM can only handle 4K offset, so larger
things w/in a C program need to allocate more base registers and
its hard to predict on the fly (I guess, never looked closely.)
IX/370 would just automatically re-start with more base registers
(or the user can request more in, eg, a make file.) As noted above
about speed, this is adequate (at least you don't have to understand
the problem, I do, but our students never do.)

UUCP existed (hey, that's progress for a 370.)

I had very little trouble moving random things that make our user
environment a little nicer. Of course, this is partly due to the
fact that we had already moved a lot of this to our 3B5 so it had
been cleaned up once, and that the 370 architecture is by and large
compatible in philosophy with Suns, Vaxes and 3Bx's (32 bit words
etc etc.)

Bad points due to the implementation:

It was SYSVR1 (which is why it didn't have mailx as another poster mentioned.)
I am sure it will move ahead in releases, so this should be a minor complaint.

It did not and could not integrate with WiscNet (IBM's TCP/IP) which in
our environment is a major negative, but perhaps not yours. This, however,
was a point of agreement between us and the developers so I expect it to
be fixed.

There was no general way to access VM objects, particularly spools so
you could do something like punch to another user's reader spool which
would be a way to effect mail in the IBM way to a CMS user. Again, noted,
agreed. Note that you can configure in printers, it's just the general
case that was weak.

They were loathe to provide sources even for a price. We would have
been more than willing to provide access to the needed DIAGNOSE's
to do some of the above and design the syscall interface to be UNIXish.
I think that philosophy is a mistake on the part of IBM, we really could
stand on each other's shoulders on things like this.

The Series/1 is an ancient way to provide a terminal front-end, this
should be re-thought and the current implementation scrapped (noted,
agreed.)

There should be general 327x support and DIAL support (or equivalent),
noted, agreed.

I think that IN stuff they threw in was unnecessary, I'd prefer
if they concentrated on other areas. It's supposed to be 'user-friendly'
but none of us could figure out how to use it. They should be more
aware that in this day and age people know UNIX, or learn it and
have to use it on other systems. These user interface oddities are
rarely worth the effort when something that worked fine existed already.
If it ain't broke, don't fix it!

They should look into more efficient ways to create processes taking
more advantage of the stand-alone'ness of the VM environment (noted,
no comment other than 'interesting', there are more details here.)

The manuals have been re-organized to be more 'user-friendly' (which I
think just means using larger fonts...ok, ok, just kidding.) I
explained that in doing so they have obviated the possibility of
on-line manuals (and, most importantly, on-line tools to data-base the
manuals.) There were no on-line manuals offered. Noted, soft moans of
pain, they thought we would love this new format and had worked very
hard on it, I didn't, sorry, go back to the old format PLEASE, and
give us on-line manuals PLEASE!


Bad points not due to the implementation (ie. inherent in SYS/V):

No disk quotas may be fine for little machines, but our 3090 has
around 15,000 users and around 20GB of disk. With that kind of
community you can't just send out friendly little "please clean
up your disk area" notes, you need some administrative tools that
work. (noted, agreed in principle, but nothing promised.)

Predictably, we would like some 4.xbsd kernel support, such as
ptys, sockets (I guess streams would be ok), job control etc.
(noted, but SYSVness re-iterated, oh well, I asked for sources
again at that point.)

-----

Summary: I have no experience with UTS so I cannot compare. By and
large it was a fine job but I'd like to see some firmer commitment to
solving most of the above problems. The disk quota problem FOR US is
severe enough to make us hesitate to commit to it, but again, that's
largely because we run a student system with such a huge community, it
may not matter much to you.  If you like SYSV you will like probably
this product.

	-Barry Shein, Boston University