Now, you can all go to your corners and start flaming me if you like but
I haven't seen anything in UNIX yet (particularly its speed) that would
convert me. As for its documentation, which I have seen others talk
about, it is absolutely ATROCIOUS. And there is almost NO online help,
unlike IBM's FULL-SCREEN online help about anything you could possibly
need to know. As of yet, I haven't had much chance to play with anything
serious in the way of scripts or command languages on Unix or VMS but I
can tell you that what I have seen endears me even more to IBM's Rexx.
One last thought before I go. A friend of mine works for AT&T as a
programmer and he is using a lot of AT&T 3B machines running Unix and HE
still would take VM/CMS anyday of the week. Perhaps if there was a
machine that was sufficiently fast to handle Unix, I would think about
switching my alignment, but I doubt it. Too many other problems with it
that I see.
--
- Kilroy r...@lscvax.UUCP
'Just what cowpatch is Lyndonville, Vermont in anyway?'
*** Can't deal, &CRASH
An offer we can't refuse. :-) :-)
>seem to have their uses, I haven't seen one yet that can run faster than
>and IBM (even if the IBM had 300 logins and the VAXen were running
>single user).
Well, IBM makes much larger machines than DEC. When the 3090 around
here has 300 users on it, I laugh all the way to the nearest Sun.
>but I will also state that I haven't seen a more user-friendly system
>that still manages to be great for experts as well than VM/CMS.
My first impression of VM/CMS (and I still hold this impression) is
that it's the biggest and best implementation of CP/M ever. :-)
Do you really like not having subdirectories, and having your environment
pretend to be a small machine with a card reader, paper punch,
and a few "minidisks"?
> To me at least, an IBM (4341, 3081,
>3090, etc) running VM/CMS blows away any of Digital's machines, running
>ANY operating system.
>Now, you can all go to your corners and start flaming me if you like but
>I haven't seen anything in UNIX yet (particularly its speed) that would
>convert me.
Try a Sun4. In terms of interactive response (roughly, how long it
takes the machine to respond to a carrage return) the Sun4 blows
an IBM 3090/200 away.
> As for its documentation, which I have seen others talk
>about, it is absolutely ATROCIOUS. And there is almost NO online help,
>unlike IBM's FULL-SCREEN online help about anything you could possibly
>need to know.
Really? At PSU the computer center felt the need to rewrite almost
all of the IBM help screens to make them usable.
FULL-SCREEN? What kind of output does unix or vms help give you?
(Hmmm, looks like a full screen to me :-)
At least under unix, when you hit return at the bottom line the screen
SCROLLS, rather than sending the cursor to the top for another go round.
CMS: Now which function key is it to get the next screen? F8? Gads, I'm
on an HDS rather than a 3270, so it's...ummm....f10! no... uh...
> As of yet, I haven't had much chance to play with anything
>serious in the way of scripts or command languages on Unix or VMS but I
>can tell you that what I have seen endears me even more to IBM's Rexx.
Rexx is not bad. Try ksh and get back to us.
>One last thought before I go. A friend of mine works for AT&T as a
>programmer and he is using a lot of AT&T 3B machines running Unix and HE
>still would take VM/CMS anyday of the week. Perhaps if there was a
>machine that was sufficiently fast to handle Unix, I would think about
>switching my alignment, but I doubt it. Too many other problems with it
>that I see.
3B? How about, say, Amdahl? Or Cray? They make mainframe-and-bigger
machines, and they run unix.
Kilroy extols the virtues of VM/CMS over Unix or VMS...
The claim that CMS is fast is a red herring being as Unix runs on the
same hardware as CMS (even concurrently with CMS, you can be logged
into both), unless you're referring to something you're not
explaining.
CMS has its virtues and its vices. One vice has been IBM's insistence
on treating VM and CMS as a second-class product, this has been
getting better recently I hear. One can't really argue with things
like not introducing SNA/VM until years after the MVS version was
available. Then again, not too many of us probably have any use for
SNA, so it may not be that important except as a symbol of IBM's
relative priorities internally. I think anyone who deals with IBM
knows that VM/CMS has always been a "nuisance" product to them. Sort
of like CMS is to MVS in IBM what Ultrix has been to VMS in DEC.
System administration under CMS can be a nightmare. For example, disk
space is allocated in a fixed manner to each user account when the
account is created. This means, for example, if you get 10MB of space
you get all of it committed to your account immediately and to get
more they have to re-format your mini-disk (back up your files, build
a new mini-disk, restore them.) In Unix parlance it would be like
having a separate disk partition for each user, no sharing, no dynamic
allocation.
They don't have any directory structure of disk files, the closest you
can do is have access to more than one mini-disk at once which again
is more like mounting flat partitions than a directory systems, more
like a bunch of MS/DOS floppies.
To share files across user mini-disks you need the READ and/or WRITE
password to the disk. There's no per-file permissions, either you give
away everything or nothing. Not an ideal situation from a security
point of view.
There are public mini-disks where software images are kept and these
are set up so everyone can mount them.
If any other user on the system does use write access to your home
mini-disk then you won't be able to mount it for yourself, basically
you won't be able to login.
XEDIT has its features, it's not terrible to use, nothing to crow
about, sort of like VI basically tho not really because IBM terminals
aren't full duplex so commands aren't interpreted until you hit ENTER.
It's interesting to make a bunch of changes and then hit ENTER only to
have them rejected because you typoed somewhere, even tho some of them
showed up on your screen up till then, then were undone, maybe
partially depending on where the error was detected.
REXX is like DCL or Unix shell programming, I guess whichever bizarre
one you figure out you tend to defend. I wouldn't particularly defend
any against the other, the mysteries of REXX are no less arcane than
the other two (stack stack where's my stack?) They're all very handy
for simple usage.
As far as the wonderful CMS documentation, yes, IBM does a very
professional job, I'm not sure if we're talking about style or content
really, some folks can be wow'ed by style. IBM's documentation makes
VMS's look small and compact, I'm talking perhaps 100 shelf feet for a
basic doc set, real handy. And again UNIX is the only O/S of the three
which has generated any popular press titles in bookstores. Students
generally just have to suffer w/o documentation or use centrally
located copies.
The on-line CMS stuff isn't bad at all, it can get you thru even w/o
documentation, at least basic stuff like using the editor. I'm not
sure it's enough to support a programmer however, that's where these
vendor help facilities always are weak although I can't say I've used
the on-line programming help much.
I don't think CMS is the wave of the future, so what's the point really?
-Barry Shein, Boston University
>Perhaps if there was a
>machine that was sufficiently fast to handle Unix, I would think about
>switching my alignment, but I doubt it. Too many other problems with it
>that I see.
Is a Cray fast enough? it does run Unix. The Cray is faster than any
IBM mainframe, therefore Unix is better than VM/CMS, right? (I'm using your
own rationale).
The speed of the machine has nothing to do with whether you prefer Unix
or IBM's VM/CMS. You should be comparing an IBM mainframe running VM/CMS
with the SAME machine running Unix. And yes, you can run Unix on IBM
mainframes.
Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekr...@ulysses.att.com
One of my professors had a great quote when the topic of operating
system "speed" or "efficiency" came up:
"How do you measure efficiency? For some it how much
gets done per CPU cycle, but for others it is how much
you get done in a week."
He liked Unix a lot.
--
Steve Friedl, KA8CMY ARPA/CSNet: fri...@vsi.uu.net *Hi Mom*
uucp email : { kentvax, uunet, attmail, ihnp4!amdcad!uport }!vsi!friedl
"Too bad we judge others by their actions and ourselves by our motives"
Another thing I've heard is that UNICOS (Cray's UNIX) is HUGE and SLOW
(compared to COS); besides, are you really going to run a program that
takes 5 hours (of CPU time) to run interactively? We have a Cray X-MP/24
running COS at the UT System CHPC (Center for High Impedance Computing)
that is backed up for WEEKS on some of the larger job classes. There are
some jobs which *couldn't* be run under UNICOS (on this machine) bacause
UNICOS would take up more memory than COS.
As for IBM's VM/CMS -- I don't happen to be graced with a 32xx terminal
so doing some things are a little more painful for me, I get to do
*character I/O*... oh boy! Where is PA1 on my keyboard anyway? But
seriously, you's got to learn some obscure stuff on any system, right?
OK, so why does it take 2 (or is it 3) commands to print a file on a
different printer from the last one? Why does FORTVS not know where to
find the basic FORTRAN libraries? Why is it that if I want to use a
graphics library for this run, I have to give a command (GLOBAL?, I forget)
which include ALL libraries (inluding the ones I think should be defaults
and I shouldn't even have to know the names of) instead of being able to
just add to the list?
I don't use our IBM much, and as a novice on that system I find it quite
frustrating. I guess the same could be said for other systems I don't
use much, like TOPS-20 (but wait, that's the most user friendly system in
the world, isn't it?). I do get along with COS (although requiring
periods at the end of the command seems a *bit* old fashioned) and UT-2D
(anyone know what that is?) and, of course UNIX.
> Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
--
William {Wills,Card,Weekly,Virtual} Reeder ree...@emx.utexas.edu
Scholars who study dinosaurs say there were some smart dinosaurs and lots
of stupid dinosaurs. Those smart dinosaurs came along early, but in the
survival wars, please note, the stupid dinosaurs won.
DISCLAIMER: I speak only for myself, and usually only to myself.
Oh no! Who left the door to the Beamer cage open?
Ralph Kennedy {hplabs,husc6,rutgers}!hao!noao!asuvax!kennedy
Engineering Comp. Serv. {allegra,decvax,ihnp4,oddjob}!--^
Arizona St. Univ. (through hao is fastest)
Tempe, AZ 85287 csnet: ken...@asu.csnet
[ this is not pertaining to the version of unix which runs native-mode on
a 370, but rather the mixed-breed product IBM is currently pushing out
the door. your mileage may vary ;-) ]
i recently had the misfortune to have to deal with 370/ix on a 9370. aside
from the size of the system, about 800MB of software and such for 370/ix
and VM underneath it, the ASCII terminal subsystem leaves much to desire.
for starters, the console (and terminals also i believe) run in line mode,
as oppossed to character mode. the <SEND> key must be pressed for each
batch of input to be sent.
i/o is fast, as is the case with most IBM mainframes i've run on. the
commands are fairly complete, and the software seems to work. but that
infernal line mode makes using simple things, like vi, next to impossible.
at last i heard, IBM had shipped about 40 systems with 370/ix and was
not able to support them for spit. big blue obviously is not too willing
to jump on the Unix bandwagon just yet.
- john.
--
John F. Haugh II SNAIL: HECI Exploration Co. Inc.
UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600
"You can't threaten us, we're Dallas, TX. 75243
the Oil Company!" (214) 231-0993 Ext 260
>at last i heard, IBM had shipped about 40 systems with 370/ix and was
>not able to support them for spit. big blue obviously is not too willing
>to jump on the Unix bandwagon just yet.
Well, IBM just announced a few days ago AIX (Unix) for a variety of
their hardware: 3090s, 4381s, 9370s and PS/2-386s. AIX includes the
so-called Transparent Computing Facility (TCF), which is really Locus
(distributed, transparent processing, process migration, etc.).
I think IBM said this was a strategic program product
I would call that a first step toward jumping on the Unix bandwagon...
Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ
UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekr...@ulysses.att.com
Oh yeah? Well, if it's so great, how come you're posting news from a
Unix machine? :-)
--
David L. Smith
{sdcsvax!jack,ihnp4!jack, hp-sdd!crash, pyramid, uport}!sdeggo!dave
sdeggo!da...@amos.ling.edu
Sinners can repent, but stupid is forever.
"IBM supports UNIX the same way rope supports a hanging man."
Hmmm..
Louis A. Mamakos WA3YMH Internet: lo...@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming
So that's what happened to Locus? Swallowed by IBM. Now that it's
emerging again, will it still run different vendor's machines? Or is
it now an IBM-only system?
--
Dick St.Peters
GE Corporate R&D, Schenectady, NY
stpe...@ge-crd.arpa
uunet!steinmetz!stpeters
>I think IBM said this was a strategic program product
>I would call that a first step toward jumping on the Unix bandwagon...
Well, I understand that at UniForum, an IBMer stated publicly something
to the effect that as far as IBM was concerned, UNIX was spelled "AIX".
It is also my understanding that AIX was described (by IBM) as a
"strategic program product".
However, when I attended SHARE (a user group for companies that have any
of several IBM 370-type mainframes running some flavor of either MVS or
VM) during the first week of March, I happened across a rather curious
session.
It was about yet *another* variant implementation of UNIX from IBM;
naturally it is different from all others that have been offered so far.
It is called "IBM/4.3" -- a port of BSD4.3 for the Reduced Technology :-)
PC. It seems quite interesting; it seems to be based on some of the
work done at CMU for Andrew (and some of that code is part of IBM/4.3).
However, it is only to be marketed to the academic community...!
At least IBM/4.3 -- unlike the 370-based flavor(s) of UNIX that IBM
offers -- can have the "man" pages online.... (Of course, with IBM/4.3,
you'd probably have them on a server.)
Somehow, I think I will be rather skeptical of IBM's stance on UNIX for
some time yet to come.... (I guess -- considering that my present
employer insists on using IBM equipment -- it's just as well that I'm
supporting MVS/XA, rather than UNIX... at the present time....)
Oh, yes: I think this discussion may be somewhat far afield from
comp.wizardry.... Mail is welcome, though.
david
--
David H. Wolfskill
uucp: ...{trwrb,hplabs}!felix!dhw68k!david InterNet: da...@dhw68k.cts.com
You missed pointing some major problems with shared CMS mini-disks.
Each user's CMS caches the directories of all attached mini-disks.
This means that if you attach my disk, and I re-compile a program,
you will for some time continue to get the old copy. I once saw
a case where a friend asked when I was going to correct a bug he
had reported; I was surprised because I'd done so a week earlier.
But he had remained logged in for the entire week, and his CMS was
still using the old copy.
This isn't nearly as much fun what happens to you when my changes
reach the point that a disk compaction occurs. Your in-memory copy
of my directory is now totally bogus. The result is often a crash
of your CMS (which at least has the effect of forcing you to login
all over, thus refreshing your copy of my directory :-).
There's another gotcha that bit me on several occasions. CMS has
knowledge of record formatting of files, and you must declare the
format (record size, and whether it's fixed or variable) when you
create a file. There is a 'feature' of CMS that causes the attributes
of a file to be ignored if there is already a file with the same
name in ANY attached mini-disk. Instead of your chosen attributes,
those of the existing file are used. For an example, suppose you
ask to create a file with 136-byte records, but there is already
an identically-named file in a system library with 132-byte records.
You won't get any error; your records will just be silently truncated
to 132 bytes.
Furthermore, there is a 'feature' that causes a seek followed by a
write to a variable-record-length file to silently discard the rest
of the file. Every record written is followed by an EOF. Suppose
you create a fixed-record-length file (in which random seeks and
writes work properly), but there is a variable-record-length file
with the same name in a system library. Your file will be silently
created as variable-record-length. Seeks and writes will appear
to work, but file truncation will occur after every such write.
The solution is to write a creation routine that generates names until
it finds one that doesn't exist in any attached mini-disk, creates the
file with that name, and renames it to the desired name. IBM people
will suggest this with a straight face, as if it were a reasonable
way to use the programmer's and the computer's time.
Another good 'feature': If you create, say, a variable-record-length
file of 200-byte (max) records, you can then write records of any
length from 1 to 200 bytes. When the creating program closes the
file, the close routine replaces the record length with the length
of the longest actual record. Suppose that was 140 bytes. If you
then run a program that seeks to the EOF and tries to append a record
of 150 bytes, the record is silently truncated to 140 bytes. The
solution to this one is to make sure that you pad at least one record
to the full 200 bytes.
This may be your idea of a well-designed system; it isn't mine.
BTW, note that IBM hasn't yet discovered the uses of the number zero.
You aren't allowed to create records of 0 bytes. At least you get an
error from that one, but it means occasional silly code to test for
empty records, and append a space. Not a big deal, perhaps, but it's
one more gotcha to slow down your job and your program.
You also get an error if you create a file and try to close it before
writing any data. If you exit anyway, the file won't exist. A null
file is as illegal as a null record.
Unix, of course, has its share of such sillinesses. But compared to
CMS, it is a paragon of mathematical reasonableness. Most trivial cases
actually work correctly. On the other hand, recent releases have been
getting more clever about trying to prevent you from saying things like
"rm *", so given enough time, Unix will probably come closer to CMS in
the gotcha competition. Consider that csh disallows null commands, so
you can't create an empty file any more by just saying ">foo", you need
to type "echo>foo". A future release will probably disallow echo without
args. Sigh.
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
Chuck
Disclaimer: No opinions are expressed in this posting.
>Oh yeah? Well, if it's so great, how come you're posting news from a
>Unix machine? :-)
>
Oh no, you caught me. You must be just TOO smart for me. I am posting on
a UNIX machine because that happens to be the only one that I can get my
hands on at the moment. It is not a matter of CHOICE, believe me. But I
also don't believe in ignoring ANY machine just because it isn't running
the software of choice. If it is there, I use it. Hell, I worked on 4
Prime machines at one point, all running Primos. THAT operating system
is truly braindead! (Okay, now all the Prime lovers out there can hate
me too.)