tom@mhuxd.UUCP (GLINES) (11/26/84)
> > I work with the Civil and Mineral Engineering Department at the > University of Minnesota which has a 4341 currently running VM/CMS. > We have been trying to get some concrete information from IBM about > VM/IX (System III under VM), but haven't had much luck with anyone > we have talked to. I am hoping there are some people out there who > have direct experience with VM/IX who can help us decide whether we > are wise to attempt to acquire it. > Thanks, Scott (Sheldon) Bertilson > ihnp4!umn-cs!circadia!sheldon From various rumors that I have heard it's a loser. (Anybody care to respond?) I would contact Amdahl if you were seriously interested.
ag5@pucc-k (Henry C. Mensch) (11/27/84)
<<>>
I had also heard that this product is the chief driver on
the loser patrol. Something about sending UNIX commands to a
disconnected virtual machine?? It's been awhile.
Anyway, if the product worked that way, then I think
it'd be useless.
-------------------------------------------------------------------
Henry C. Mensch | User Confuser | Purdue University User Services
{ihnp4|decvax|ucbvax|seismo|allegra|cbosgd|harpo}!pur-ee!pucc-i!ag5
-------------------------------------------------------------------
"Season's Beatings!" ;-}bew@amdahl.UUCP (Brian Weis) (11/30/84)
Have you considered UTS from Amdahl? UTS is a UN*X which runs under
VM, and has been available for the last three years. I'm sure that our
marketing people would love to talk to you. You can call Neil Macklin
at (408)737-5214 if you are interested.
--
Brian Weis
...!{amd,hplabs,ihnp4}!amdahl!bew
"Naturally the opinions expressed here are those of the author only."charliep@v1.UUCP (Charlie Perkins) (11/30/84)
-------------------
Although I have not used it, I don't think that VMIX sends UNIX
commands to a "disconnected virtual machine". It runs in a virtual
machine unto itself, much as CMS itself does. I believe that
also means that multiple VMIXes could be running simultaneously
on the same machine, and coexisting with CMS.
As far as being a loser product, I think it is very fair to
compare VMIX with PCIX if the appropriate adjustments are
made to account for the different machines they run on -- since
the same people developed both products. I have seen the
documentation, and it sure looks similar.
Please don't ask me more since I don't know any more. Ben Settle
is definitely the right person to ask.
Charlie Perkins
PS. As far as I know, this is the FIRST posting to the net from IBM.
Does anyone else know differently?
PPS. It is certainly a pleasure to be back on the net after a long
absence.herbie@watdcsu.UUCP (Herb Chong, Computing Services) (12/01/84)
Extracts from VMSHARE, a community of members of Share who are active
and voting members of the VM Committee. Names have been deleted where
appropriate.
----------------------------------------------------------------
Comment in "Yes, It Runs on Mainframes" by Donald O'Shea, Amdahl
Director of UTS products in ComputerWorld Extra, Sept. 26, 1984: "We
believe, in fact, that there will be only two important operating
systems by 1990 - MVS and Unix."
Reply in VMSHARE: "That's like a choice between death by hanging, or
death by firing squad."
-------------------------------------------------------------
...folks who have used real DEC UNIX don't like it (maybe the same
way we won't like MVS CMS).
-------------------------------------------------------------
Yes we actually have UTS. We have been running it since last August,
and are very pleased with the work done by Amdahl. UTS is Unix version
7, with improvements such as a 3270 editor. We also run Unix V6 with
PWB on a PDP 11/70, Berkeley Unix on a VAX, Bell's System 3 on a couple
of Plexus's (Plexi?). Anyway, all our Unix's are more or less
incompatible with each other (so much for 'portable' opereating
systems).
...Incidentally, many of our UTS users cannot stand DEC Unix.
They often think that VT-100s are very strange terminals compared with
3270s. Other comparisons are interesting; about one in three think
Unix is much better than CMS, one in three think CMS is much better
than Unix, and the rest think that the two systems are almost
identical!
---------------------------------------------------------------
[Running UTS,] the IBM architecture easily outperforms the competition
too; even with VM, a 4341 MG2 is faster than the VAX/780, and response
times are much better (mainly 'cos the DEC screens are so slow).
---------------------------------------------------------------
There are plenty of things wrong with Unix, but they do not seem
inherent in the design. With software suppliers really having to
compete with each other, it should be posible to develop it into an
excellent operating system.
---------------------------------------------------------------
I can see many advantages in UNIX(*) from the point of view of the
professional programmer, but I'm not sure it could hack it in the
general user environment we're supporting with VM. Has anybody thought
about a serious comparison? I think everyone might be interested in
the results.
--------------------------------------------------------------
A great many of our users who use both CMS and UNIX express fervant
preference for UNIX. None of these people are professional pro-
grammers.
--------------------------------------------------------------
I would be the first to admit that UNIX is far from a perfect system.
It does have many advantages over CMS, however, for both the
professional programmer as well as the novice user. Here are some of
my favorites:
1. The File System. There is no question that UNIX achieves its
greatest degree of user-friendliness through its use of a single
integrated file system. CMS suffers greatly through two problems in
its file system: First, the inability to share data in a natural
and convenient manner at a file level, and second in its flat file
structure. Have you noticed that once a minidisk swells to more
than 300 or so files that it becomes unmanageable? The CMS
filename-filetype convention is nice, but when I have 150 SCRIPT
files on my disk the utility of the filetype as a structuring aid is
called into question. By the use of directories, UNIX enables me to
structure the files under my ownership in such a manner that ls (the
UNIX equivalent to LISTFILE) never has to display more than a
screen's worth of data. Humanly this is much more manageable than
having to stare at pages of LISTFILE output (even if it is displayed
fullscreen via FILELIST).
2. Modularity. In UNIX, the fundamental programming concept is the
tool. How many times have you cursed (albeit silently) under your
breath at a CMS command for not supporting a STACK option which
would enable you to use the output of one program as the input of
another? If you're into CMS command writing, how many times have
you cursed at having to re-write that same STACK code in each and
every one of your commands? One of the big differences between CMS
and UNIX is that CMS assumes that the output of a program is
destined to be read (or printed) while UNIX assumes that the
consumer of the output of one program is most likely to be another
program. This results in a (some would say too) large collection of
primitive functions which enable the experience, and even the
not-so-experienced UNIX user to accomplish a task by combining
programs in novel ways rather than continually writing new
programs.
3. Control. How much discussion has there been in recent years
concerning "padded cell" environments? UNIX is DESIGNED around the
concept! A padded cell can be as open or as closed as its author
desires (the UNIX command interpreter, the shell, is an "open" cell)
but there is no such thing as a CP mode to trap the unwary or
confuse the innocent.
--------------------------------------------------------------------
Things that I do like are
1. The 'pipe' system for sending output from one command to the next.
Incidentally I do know of an internal IBM program that does this
for CMS!
2. The fact that each program runs in its own process so that
any program can call any other program (but watch out for
problems if both try to process the same file!)
3. The file system. The tree structure certainly makes management
of a large number of files much easier, but I miss the file types.
File sharing is easy because of this structure, but read/write access
is not so easy.
We have both UNIX and CMS, CMS is currently far more popular but UNIX
has not been around all that long yet.
--------------------------------------------------------------------
I think its interesting how level of expertise reflects in our opinion
of the virtues/vices of something. One of the primary vices of UNIX IS
the weird command language. For example:
cat <filename> ---- type out a file on your terminal
rm <filename> ---- delete the file
grep ... <filename> ---- search file for a pattern
Admittedly, the commands DO other things (ie. they are more flexible
than the simple description I've provided) but, in fact, this is their
main use. Also, I shouldn't have used < and > because thats how the
shell decides where to get the input and place the output for
commands. Another major problem is the coding of option flags; for
example, I find syntax like: "xyz somethingorother -x -n -t -pns"
v-e-r-y frustrating. HOWEVER, it is the very terseness of the command
and the ability to specify options in a shorthand way that seasoned
UNIX users love.
The biggest complaint about 327x systems most UNIX hacks have is the
inability of the editor, because of the hardware, to deal with each
character as it is input. This ability is what gives UNIX the power to
support a full screen editor in a text manipulation sense. That is, a
single keystroke can be used to mark, pick up, move, or otherwise
operate on a block of text. It also gives the ability to support truly
interactive programs such as games (I've seen ROGUE, SPACE INVADERS,
and even PAC-MAN) on UNIX systems. Its impressive that it can be done,
and I can't imagine the tedium of even APPROACHING that level of
interactivity (?) on a 327x. Its also EXTREMELY expensive to do i/o
that way. If you look at what a player or two of one of those games
can do to a system (an i/o interrupt per byte, remember) you quickly
realize why you don't let management catch you at it on prime shift.
Furthermore, I really like Xedit, and I don't think it lacks anything
in the power required to do the editing function. Except for word
processing applications, byte at a time control seems excessive to
me..., certainly unrequired for professional programmers, or even
authors using a formatter (nroff and troff, by the way, insert format
control words just like script, so I don't know what the fancy editor
buys you there either).
I agree with the comment on reliability. Things seem to break for odd
reasons (my UNIX colleagues will string me up if they read this), and
the machine (the one I'm most familiar with at the moment is a VAX
11/780 with 4Meg of memory -- I think this is about a 158-III) doesn't
seem to be able to stand up well to a large user community. 25 users
or so and things get perceptably slower (although to be fair,
performance is consistently good right up to that point).
As for the padded cell, yes, the shell is the perfect (ultimate) cell.
Its perfection lies in its flexibility. But how much different is that
from CMS, really, if you view CMS as a command processor... a shell of
its own. If you think of CMS as a shell, by the way, its not hard to
extend the analogy that CMS is what TSO should have been, therefore,
run CMS in an MVS address space.
I agree with [XXXXX] that not enough has been said about that other VM
component ... CP. When it comes down to it (despite that fact that
CMS managed to turn out pretty well), CMS might have been as bad as
TSO, or as good as UNIX without influencing what is undeniably the best
feature of VM, the virtual machine architecture itself. In no other
system can I have online users running CICS, ROSCOE (in an OS guest),
CMS, UNIX (in a UTS guest) and provide decent service to them all. Not
only that, but make them as independant of one another as possible,
where none can perceptably hurt another. All that, plus provide a
non-intrusive test environment for systems programmers.
--------------------------------------------------------------------------
I have talked with some people that use UNIX, some really like the file
system, in preference to CMS minidisks. Others say they can never find
their files in UNIX because of the directory structure that contains
the files.
--------------------------------------------------------------------
A few points regarding some of the issues raised in the last few
appends: First, ANY command language you're not used to is going to
seem a bit strange at first. This is due both to the confusion of the
new as well as a desire to retain one's old command framework. cat
stands for catenate and does more than perform a 'type' function.
However, one of the advantages of UNIX is that it is trivial to create
whatever synonyms you wish for commands.
...UNIX can be criticized for its often cryptic commands, but you DO
get used to them. Command options are admittedly inconsisent, but then
again the same can be said for CMS (some commands support a STACK
option, others don't, for example). I agree that raw-mode (the ability
to field every keystroke from a terminal) is very expensive, but it is
very nice to be able to operate in this manner on occasion (how often
have you had to explain how to use the RESET key on a 327x to an
impatient user?)
----------------------------------------------------------------
Herb Chong...
I'm user-friendly -- I don't byte, I nybble....
UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdcsu!herbie
CSNET: herbie%watdcsu@waterloo.csnet
ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa
NETNORTH, BITNET: herbie@watdcs, herbie@watdcsu
POST: Department of Computing Services
University of Waterloo
Waterloo, ON
N2L 3G1 (519)885-1211 x3524
--
Herb Chong...
I'm user-friendly -- I don't byte, I nybble....
UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdcsu!herbie
CSNET: herbie%watdcsu@waterloo.csnet
ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa
NETNORTH, BITNET: herbie@watdcs, herbie@watdcsu
POST: Department of Computing Services
University of Waterloo
Waterloo, ON
N2L 3G1 (519)885-1211 x3524ron@brl-tgr.ARPA (Ron Natalie <ron>) (12/02/84)
> Does anyone know if IS/3 is merely an upgraded IS/1?
IS/1 on the VAX was an under VMS product but they also called the ONYX
and PDP-11 native UNIX versions IS/1. IS/1 was a mildly hacked PWB system.
It was done before there were a whole lot of VAX's around and before 32V
came out (I think). I seem to recall listening to a talk on it at a D.C.
Unix group by Heinz Laclama a long time ago (1978?). Generally, using IS/1
you get the impression that most of the development effort went to changing
the word UNIX to IS/1 everyplace it occurred in the manual.
IS/3 is a mildly hacked System III. Interactive dumped their IS/1 customers
in the cold when they switched. They have attempted to fill in some missing
things in UNIX (fortran, mail, etc...) and have made some reasonable system
improvements but the level of support is still infinitly inferior to IBM.
Such a waste, big blue could have done better.
-Ronrobert@gitpyr.UUCP (Robert Viduya) (12/02/84)
> ------------------- > Although I have not used it, I don't think that VMIX sends UNIX > commands to a "disconnected virtual machine". It runs in a virtual > machine unto itself, much as CMS itself does. I believe that > also means that multiple VMIXes could be running simultaneously > on the same machine, and coexisting with CMS. > I've never actually used VM/IX myself, but I believe the implementation is more like OS/MVS under VM rather than CMS under VM. In CMS, each user has his own virtual machine with his own private copy of CMS. CMS is a single user operating system. The user's terminal is the system console for his virtual-machine. OS/MVS, on the other hand, under VM also has its own virtual machine, but, unlike CMS, is a multiple user operating system. Each user 'connects' (or 'Dials' if you prefer) to the virtual machine and the user's terminal is just that, an ordinary terminal. I've never heard of an operating system under VM that work as a 'disconnected virtual machine' where commands are sent to. Not only would it be slow, but, I believe, it would be almost technically impossible for VM to handle a high load of inter-virtual-machine messages (unless, of course, you used the virtual card-punches and card-readers :-). robert -- Robert Viduya Office of Computing Services Georgia Institute of Technology, Atlanta GA 30332 Phone: (404) 894-4669 ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
marks@Cascade.ARPA (12/04/84)
> I've never heard of an operating system under VM that work as a > 'disconnected virtual machine' where commands are sent to. Not only > would it be slow, but, I believe, it would be almost technically > impossible for VM to handle a high load of inter-virtual-machine > messages (unless, of course, you used the virtual card-punches and > card-readers :-). > -- > Robert Viduya > Office of Computing Services > Georgia Institute of Technology, Atlanta GA 30332 > Phone: (404) 894-4669 When I worked at IBM's Palo Alto Scientific Center, their 370 did exactly what you described above with your ":-)". They ran OS/VS1 (not VS2/MVS, but VS1) in an disconnected virtual machine, and punched jobs to it thru the virtual punches and read output from virtual readers. This makes a lot of sense if you want VS1 to run only batch jobs. My impression is that it's difficult to talk to VS1 directly anyway. Have you ever tried to type OS JCL sitting on-line at a terminal? The system administrator there used CMS to edit a JCL file and punch it to VS1. ---------- Stuart Marks, Computer Systems Lab, Stanford University {ucbvax,decvax}!decwrl!glacier!marks, marks@su-cascade.ARPA
whm@arizona.UUCP (whm) (12/06/84)
IBM has been encouraging us to consider the acquisition of a VM/IX system as
a major computational facility. Several weeks ago I sent off an "unload-and-
run" benchmark tape for testing on a VM/IX system.
Today I was talking to the guy at IBM who is apparently attending to getting
the benchmark tape run and he's run into a little problem: I had inadvertently
included a directory called "kimbo's" on the the tape and to the best of
my understanding, they were *unable* to read the tape because tar couldn't
create a directory called "kimbo's". Further investigation revealed that
the following special characters are allowed in VM/IX file names: period,
comma, underscore, minus sign.
The solution we reached was for me to make a benchmark tape with conformant
names and Federal Express that off to them.
Based on my experience with that tape, I guess I'd like to second the comment
about VM/IX leading the "loser patrol". Having dealt with very early Eunice
systems, it's not beyond the realm of my imagination to imagine those file
name limitations, but it is simply incomprehensible that they'd have no way
to deal with the problem. I mean, how hard could it be to have tar ask for
an alternate file name? Perhaps this is in fact possible, but the person I'm
dealing with didn't know about the feature.
As mentioned, "VM/IX is based on INTERACTIVE Systems Corporation's IS/3, which
is in turn based on UNIX System III, a standard UNIX system developed by
AT&T Bell Laboratories." (IBM GH20-6410-0, VM/IX General Information Manual)
I've had this document for quite some time, but I had never noticed the
part about IS/3. The IBM guys have told us many times that VM/IX is
System III, but for some reason I get the feeling that IS/3 is much like
IS/1, which as I recall was a UNIX on VMS system that provided all the
facilities of UNIX that could be directly mapped into VMS operations or
something like that. I guess it must have had some good points, and I
might have the facts mixed up, but my general feeling about the IS/1 system
was "How can anyone hope to sell that product to knowledgeable users who
want full UNIX capabilities."
Does anyone know if IS/3 is merely an upgraded IS/1?
Bill Mitchell
whm.arizona@csnet-relay
{noao,mcnc,utah-cs}!arizona!whm