[Info-vax] "Shanghai Stock Exchange" and OpenVMS

[johnwallace4 at yahoo.co.uk]

On Jan 28, 4:24 pm, billg... at cs.uofs.edu (Bill Gunshannon) wrote:
> In article <-r-dndyy7LwI6x3UnZ2dnUVZ_uedn... at giganews.com>,
>         "Richard B. Gilbert" <rgilber... at comcast.net> writes:
>
>
>
> > AEF wrote:
> >> On Jan 28, 1:46 am, Michael Kraemer <M.Krae... at gsi.de> wrote:
> >>> AEF schrieb:
>
> >>>> New! From IDG books: DOS for Dummkopfs.
> >>> That should be "Dummköpfe", but Umlauts are not everybody's
> >>> strong points.
>
> >> That's what it is in English. I even checked atwww.webster.com. Do
> >> you expect me to write "Deutschland" instead of "Germany"? "Republique
> >> francaise" instead of "France"?
>
> >>> Back to the point: Neither VMS Help nor Unix man pages
> >>> are appropriate for learning either OS from scratch.
>
> >> The VMS User's manual is.
>
> >>> They are meant as a reminder for forgotten keywords and such.
> >>> If you have no clue about those OS, both help systems
> >>> are next to useless.
>
> >>> I had to work on VMS before I knew Unix and found
> >>> VMS, its filesystem and its HELP less intuitive.
> >>> So Unix was a progress.
>
> >> I find the man pages dense and visually difficult to read (an example
> >> of poor typography). And the ones I have usually show several versions
> >> of the same command with the differences specified in the name of the
> >> command via different paths. You know: path1/cp, path2/cp, etc., where
> >> path1 and path2 may be very similar in appearance. Which one is the
> >> one I will be running if I just specify cp? (This is intuitive?)
>
> >> Someone at work showed me a website which reformmated the man pages
> >> into something much easier to read. Can't be just me who finds the
> >> original man pages visually difficult to read.
>
> >> Also, I find English words much more intuitive and actually mostly, if
> >> not partly, self explanatory. I don't find that to be the case for 1-
> >> and 2-letter commands and options. VMS commands and qualifiers and
> >> keywords and such are mostly self-evident as to what they more or less
> >> do or specify, aside from the fine details.
>
> >> VMS terms are like those in photography: What does the enlarger do? It
> >> enlarges (the image)! What does the developer do? It develops film or
> >> photographic paper. What does the focusing knob do? What does the stop
> >> bath do? It stops the developer from developing. The fixer bath
> >> "fixes" the film or print so that you can turn on the light without
> >> destroying the image. And then there's the print washer and the print
> >> dryer. Can you guess what they do? Now suppose they were instead named
> >> by Unix type abbreviations. You'd have no or little idea what any of
> >> them are or do without looking them up. Now, admittedly, the existing
> >> photographic terms aren't fully self-explanatory, but at least you get
> >> a pretty good idea of what they do (well, to varying degrees). OK,
> >> "lens" isn't self-explanatory at all; you have to learn that one! And
> >> "focusing" may be a challenge for some.
>
> > Unix was meant to be easy to type!  Ease of learning it was definitely
> > secondary if it was considered at all!!
>
> Not "easy" to type.  It was designed to be curt.  Does anyone here actually
> remember how slow a real teletype was?  (I do, because I was a real teletype
> operator before I became an IT professioanl. :-)
>
>
>
> > If you are at all familiar with Unix, you know that the early pioneers
> > worked with some very primitive teletype equipment, specifically, the
> > model 33.  Those who have used the model 33 will understand,
> > intuitively, the brevity of Unix commands.  For those who have not, the
> > model 33 required, by modern standards, extreme force to operate the
> > keyboard.  
>
> Umm...  No.  As someone who spent day after day typing on one, it did
> not require any force.  It did, however, require rythmn.  If you tried
> to type out of rythmn all the force in the world won't make the keys
> go down.
>
> >           There was no tiny switch underneath the key cap; it was
> > levers, wheels and gears!  
>
> Driven by electric motors so if you were in rythmn with the machine it
> was really quite nice.  I still tend to type with rythmn rather than
> speed.  (I also type in the dark and that drives my wife nuts!!  :-)
>
> >                           There was only ONE case, uppercase!  I
> > believe it was automagically converted to lower case and you had to
> > "escape" anything you wanted left in uppercase.
>
> > There is no reason other than tradition to continue this barbarous
> > practice but tradition is a powerful force.
>
> And, as I have repeatedly stated here, if you don't like it, one of
> the strengths of Unix is you can change it.  I have used a system
> that had an "MSDOS shell" that mimiced MSDOS pretty well.  I have
> personally written a shell that mimiced the UCSD-Pascal menu system.
>
> Adaptability is one of Unix's greatest strengths.  Which, brings up
> the question of why no one has done it?  Guess the people who actually
> use Unix like it the way it is.
>
>
>
>
>
> >> Well, I'd think the photographic terms, as they currently exist, are
> >> more intuitive, right?
>
> >> The file systems are another story. I haven't learned how you can have
> >> different disks in the same single file system. As a user I suppose
> >> that's fine, but in VMS the system manager can set up logical names to
> >> reference directories so that the user (or even the programmer in many
> >> cases) need not be concerned with what the underlying device is.
>
> > A unix user need not concern himself with the underlying storage media!
> > VMS users are accustomed to seeing physical devices, each with its own
> > filesystem.
>
> > In Unix, there is only ONE filesystem starting a "/" or the "root".  The
> > actual files may be on the one and only disk or on several different
> > disks.  Physical disks are mounted at "mount points" which look, to VMS
> > users, like directories.  The directories used as mount points are
> > normally empty since mounting a device on that mount point will overlay
> > any directory entries present.  The Unix user need not concern himself
> > with the details of which device(s) actually contain his files.
>
> >> Being intuitive is not the end-all be-all. What can you do with the OS
> >> is also important. Of course we _were_ discussing looking stuff up,
> >> but you referred to "progress", which opens up a whole new can of
> >> worms.
>
> >> Some things in Unix I find very cool, like using output of one program
> >> as input for another.
>
> > VMS can do that too!  Old line VMS people tend not to use it much but
> > it's there.  See HELP PIPE.
>
> A late addition, though.  Wonder where they got the idea?  (and the name!)
>
>
>
> >> But VMS has some very cool things, too.
>
> > Indeed it does.  Starting with using English words like COPY, PRINT,
> > DELETE, CREATE. . .  etc, as commands.  
>
> Which is only a good thing in an Anglo-centric world.  :-)
>
> >                                         It requires a little more typing
> >   but that is not a hardship for anyone who has learned to type and is
> > not using a Model 33 teletype.
>
> And there is no reason why Unix can't do the same.  Well, except maybe
> for the fact that Unix users don't want to.  :-)
>
>
>
> > It makes the commands easy to remember.  
>
> I have never had a problem remembering Unix commands.  And I used to go to
> larger conferences than DECUS that were full of people who had not problem
> remembering them.
>
> >                                          The syntax is standard.  
>
> Unix syntax was pretty standard, until the GNU idiots decided to do
> things their way rather than the Unix way.
>
> >                                                                  Rather
> > than having each program parse its own command line, DCL does it for
> > you.
>
> Considering that the program has to interpret the parameters, I don't see
> how DCL parsing it is a good thing.  What does DCL then pass to the actual
> program?  Of course, if that's what you want, there is no reason why Unix
> can't have a shell that parses the command line, using english options, and
> then issues the needed Unix command to get the job done.  except for the
> fact that Unix users apparently aren't interested in it enough for anyone
> to actually write one.  :-)
>
> >       AIRC, you call a subroutine that returns the neatly parsed bits and
> > pieces.  I didn't use it much.  It was easier to have the program prompt
> > for the information it needed; if it needed anything.
>
> You mean like Unix does?  :-)
>
> bill
>
> --
> Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
> billg... at cs.scranton.edu |  and a sheep voting on what's for dinner.
> University of Scranton   |
> Scranton, Pennsylvania   |         #include <std.disclaimer.h>  

"Unix syntax was pretty standard"

O'really?

Standard between what, standard between which Unixes? The one you're
personally accustomed to, presumably?

In the mid 1980s, a few years after I left the ASR33s behind,  SystemV
and BSD couldn't even agree on how many parameters were in the system
call to open a file (the app I was involved in had to run on both, as
well as on VMS).

I seem to recall a few more differences between Sys V and BSD,  in
command syntax as well as in APIs and programming models. If there had
been a single consistent set of commands, APIs and programming models
across the various Unixes, there'd have been no need for the Single
Unix Specification, no need for Posix, no need for X/Open, no need for
OSF... got the idea yet?