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

[Bill Gunshannon]

In article <-r-dndyy7LwI6x3UnZ2dnUVZ_uednZ2d at giganews.com>,
	"Richard B. Gilbert" <rgilbert88 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 at www.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
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>