Unix on IBM Mainframes & Clones
Barry Shein
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
Uncle Wayne
>I would like to here about peoples experiences with
>Amdahl UTS and/or IX/370 under VM. Indications of
>implementation quality, efficiency, horror stories,
>price (including maintainance if available), etc.,
>is what I'm looking for.
About 2 years ago, I played with an account on an Amdahl UTS system.
I only had a day or two on it since the systems staff didn't know if
they wanted to run it. There are two things I remember about it.
1) I logged on to the same account at the same time from different
terminals. When I logged off of one of the accounts, UTS
died also.
2) They apparently had csh. One person on the systems staff decided
that sh would be for the everyday users and that csh would be
reserved for the systems accounts. His justification? None
that I know of. He probably just wanted to have something he
could use that the average scum-user couldn't. Yes, that is
the way his attitude was.
I'm sorry I can't give any more specifics about it than that. As I
said, it was 2 years ago and I shouldn't have had access to the account
I had. (UTS was there for testing and I was just an average scum-user.
Wayne Morrison ARPA: tewok@brillig
Parallel Computation Lab UUCP: seismo!umcp-cs!tewok
University of Maryland
(301)454-7690
Dave Tweten
I would like to here about peoples experiences with
Amdahl UTS and/or IX/370 under VM. Indications of
implementation quality, efficiency, horror stories,
price (including maintainance if available), etc.,
is what I'm looking for.
We have been running Amdahl UTS/V version 1.0, under VM version 3, on two
Amdahl 5840s for about a year. We just got the 1.1 and 1.1.1 UTS/V updates,
but will probably hold out for UTS/580 (which is on order). We are also
about to upgrade to VM/HPO version 4. Both flavors of UTS are basically
System V.2.
The good news is that UTS supports a lot of users and a lot of 3380 look-alike
disk. Up to 100 9600 baud RS-232 connections at a time can be made through our
Micom switch and Amdahl 4705E communications controller. We support 50
simultaneous production users, or so, for most of the day, on one virtual
machine, on one of the 5840s. We are developing one of the 5840s as a GIANT
disk server (about 40 Gig, to start) for our ethernet and HyperChannel based
TCP/IP networks, which include a Cray-2.
There is also some bad news:
1. The TCP/IP support on the ethernet had to be added-in (Wollongong), and
we had to roll our own HyperChannel support in UTS (not strictly
necessary anymore) and in VM, to permit virtual machines to share
adaptors (still required).
2. Version 1.0 of UTS had many bugs (so what do you expect from version
1.0?). We did a LOT of bug fixing and Amdahl fix integrating.
Supposedly, version 1.1.1 is much better, but we'll probably never
know.
3. The C compiler occasionally produces some strange code. For a while,
that prevented Unipress EMACS from working in all its glory. It STILL
doesn't work in all its glory, though the latest reason is unknown.
4. Because UTS/V depends upon VM, it is unprepared to deal with all the
perversity of I/O devices in the real world. That can be the source
of some considerable headaches if you want to roll your own drivers for
bizzarre devices (as we did for the HyperChannel). Again, the
advertizements say UTS/580 will make it all better. We'll see.
5. High speed disk I/O through UTS/V is a problem. It seems to do only
sector I/O. The ability to support track I/O would push maximum
sustained I/O rates above their present 2 megabit per second upper
limit. So would cached controllers (for read), or a ramdisk (for the
truely desparate).
On balance, I think we are reasonably satisfied, all but the if-you-have-
EMACS-you-don't-need-a-shell crowd.