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

[Richard B. Gilbert]

AEF wrote:
> On Jan 28, 11:44 am, billg... at cs.uofs.edu (Bill Gunshannon) wrote:
>> In article <b9489278-4168-437b-85e5-fff095da5... at l38g2000vba.googlegroups.com>,
>>         AEF <spamsink2... at yahoo.com> writes:
>>
>>
>>
>>> 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).
>> As I have said in the past, (and aparently at least Michael agrees) it's
>> all a matter of opinion as I find quite the opposite.
> 
> OK.
> 
>>>                       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?)
>> It is to people who use Unix for a living.  And, apparently college
>> freshman.
> 
> OK, it was late night when I've been posting these things. OK, it's
> the one that's in the PATH. I'm just starting and for some reason I'm

Not quite.  It's the one that occurs FIRST in the PATH!

You can ask which version will be run.  The command, logically enough is 
"which".  "which mumble" will tell you /usr/sbin/mumble (or whatever 
mumble is found first in searching the path.

> just not in the Unix PATH frame of mind yet. (Maybe it's in part
> because I hate the PATH trains!) But why the multiple versions of some
> commands? Why the following?
> 
> SYNOPSIS
>      /usr/bin/ls  [-aAbcCdeEfFghHilLmnopqrRstuvVx1@] [file]...
> 
>      /usr/xpg4/bin/ls  [-aAbcCdeEfFghHilLmnopqrRstuvVx1@]
>      [file]...
> 
>      /usr/xpg6/bin/ls  [-aAbcCdeEfFghHilLmnopqrRstuvVx1@]
>      [file]...
> 
> Why three versions?
> 

How about because: in the beginning there was AT&T unix.  AT&T gave a 
copy to the Computer Science Department at Berkeley!  The comp sci 
students wrote their own versions of things and added entirely new 
things; and then there was Berkeley Unix (BSD).

For the last thirty-five or forty years these two versions and their 
descendants have been exchanging genetic material in ways that would 
make a stock breeder blush!

Every vendor has to make his Unix somehow "better" than the others which 
mean that things get rewritten and things get added.  Sometimes things 
got fixed.  Usually something else got broken.  Unix was never 
"designed" it just grew!

>>> 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.

You're not the only one.  But tradition is a powerful force!

>>> Also, I find English words much more intuitive and actually mostly, if
>>> not partly, self explanatory.

Use VMS then.  I do!  I also use Solaris 8, Solaris 9, Solaris 10, and 
Red Hat Linux.  Sometimes a task is more easily done on one of these 
than on VMS.   Sometimes the reverse is true.

I'll continue to use the tools that get the job done with a minimum of 
effort (and collateral damage) whatever their origin.

>> Once again, matter of opinion. And really rather Anglo-centric, don't
>> you think?  So, then, how useful was VMS in Germany or France?

Did you ever think that perhaps there is a German version of VMS?  One 
that speaks to the natives in their own barbarous tongue?  I'm pretty 
sure that there is a Japanese version of VMS that types Nihongo in kata 
kana.  Likewise, German, French, Italian, Hebrew, Arabic. . . .  Would 
you believe any language that there is a sufficient market for?  (There 
are something like 7,000 known human languages, some of them spoken by 
only a few dozen people.  It's not possible to support them all but I 
suspect that most of the major languages are supported.  I doubt that HP 
would support 700 languages, let alone 7,000 but I have no trouble 
imagining a dozen or two of the major languages.



> 
> How useful is the term "awk" in any language! At least VMS words are
> somewhat self-evident in one language! In what language are cp, rm,
> mkdir, awk, sed, mv and such just normal words? So by your criterion,
> Unix isn't useful in any language!
> 
>>>                               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.
>> Nothing about computers is "self-evident".  It's a business with its own
>> jargon and terminology.  I mean, why do those doctors use words like
>> "apendicitis" and "carcinoma"?  Why don't they just use English like
>> everyone else?
> 
> To keep us in the dark. You see, the doctors take a special course to
> write illegibly and the pharmacists take the corresponding course to
> decode it! Actually, there is a real need for such strange words as
> normal English words simply don't suffice for all the numerous medical
> terms needed. The same isn't true for CLI commands. We're not talking
> organic chemistry or here.
> 
>>> 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?
>> And let's not forget the F-stop!  :-)  yeah, that's real self-evident.
> 
> Yep. Touche'.
> 
>>>                                     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.
>> And if I were a professional photographer, I would have done that in the
>> process of becoming a professional photographer.  What's your point?
> 
> I'm not really sure. I think we've gotten to the point where none of
> us actually know just what we're arguing over. In this instance I was
> trying to show through photography what it's like in another context
> to learn new terms if said terms are described in "English words" as
> VMS is. As I said, not all photography terms are self-evident, and
> some are only partly self-evident.
> 
>>>                                          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.
>>> Well, I'd think the photographic terms, as they currently exist, are
>>> more intuitive, right?
>> Those of us who are not into photography would tend to disagree.  :-)
>> I have a number of cameras.  I used to develop my own pictures and
>> even used a lot of experimental high-speed film back inthe old days.
>> (I did a lot of sport photography.)  But I have never been as interested
>> in it as, say, my brother.  As a result, most of my cameras now languish
>> on the shelf while I do what photo taking I do with a $100 Kodak digital
>> I got on sale at the PX.
> 
> OK, whatever.
> 
>>> 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.
>>> 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.
>> Yeah, Unix is still "progressing" and VMS is languishing in the a corner
>> somewhere waiting for HP to finally pull the plug on the life support
>> system.
>>
>>> Some things in Unix I find very cool, like using output of one program
>>> as input for another. But VMS has some very cool things, too.
>>>> And, since you mentioned physics labs a few posts ago:
>>>> in these facilities one usually has a local primer
>>>> for newbies. Anyway one will need only a very small
>>>> subset of an OSs capabilities to do physics work.
>>> It's only reasonable anywhere a user starts work to have a local
>>> source of how to get started, be it a tutorial session; a newbie
>>> manual, "local guide" (Latex style name), a primer, or whatever you
>>> want to call it; or something else. And that's true more generally:
>> We used to do that, but found it unnecessary more than a decade ago.
> 
> Need specifics here. Do users not have to be given usernames and
> passwords, for example? Users who have never used Unix before somehow
> become instantly productive on day 1? I suppose these users could also
> do brain surgery on day 1 without having gone through medical school.
> Just look it up what you need with Google!
> 
>>> When you start a job, someone shows you around, right? And show's you
>>> the ropes, so to speak, right? And what you're expected to do, right?
>> Not anytime lately.  I am a professional and when I am hired it is
>> expected that I will walk up to my desk and begin functioning right
>> away.  That's what separates the professional from the intern.
> 
> Sorry, bad term: "the ropes". I meant that you are told which desk is
> yours, what your phone number is, where to get your badge, what your
> responsibilities are, what software is running on what, what your
> usernames and passwords are, whom you report to, etc. I suppose you
> show up on day 1 with this all telepathically absorbed or you Google
> it.
> 
> Again, apologies for using the wrong term. I was thinking more
> generally.
> 
>> I have been doing this professionally for over 30 years.  I have had
>> to learn new langauages, new OSes and new architectures.  No one has
>> ever offered to hold my hand.  I have been given tasks and, as a
> 
> That's what I should have said instead of "showing you the ropes"
> which, come to think of it, isn't totally inappropriate. "The ropes",
> besides just being given some tasks (which I would think would have to
> include particulars of your new work environment that you almost
> certainly wouldn't know ahead of time), could be a description of how
> things work at your new workplace. When I started work at a particular
> non-profit organization in the 90s, "customers" and employees had to
> fill in forms and they had people type in this form data on a machine
> similar to a keypunch, but it uploaded the data to an IBM machine, on
> which we ran some secret commands dictated to me by a guy who looked
> and talked like Elmer Fudd, then copied the massaged data to a 9-track
> tape, loaded that tape on a tape drive hooked up to a pdp11/70 (of
> which we had four for various purposes), which from there was
> Permitted to a VAXcluster, which then ran through some third-party,
> possibly home-grown app, and then finally something was printed on the
> old green-bar paper which would never fold properly on its own. And
> then there was the secret box buried God knows where in the cabs on
> which you had to use some really strange incantation of commands and
> various knob settings for different modes (all of which were cryptic)
> to broadcast to the users that things were down and intentionally
> write that the machine was expected to be up in an hour (we put down
> an absolute time, not "1 hour"), when we in fact knew that it would be
> several hours at best. So we had to update it every hour. I asked my
> supervisor if we could just be honest about it say "sometime later
> today" but he said no, we have to do it this way.
> 
> Now you are going to show up to work day 1 and somehow already know
> all this? You're going to waste "precious company time" trying to
> learn this on your own? Are you going to pour through manuals we
> didn't have (well, maybe we did) about an IBM OS from the distant past
> with disk drives taller than most people just to figure out what the
> three or four secret commands you need are instead of letting Elmer
> Fudd simply tell you? You're going to find that secret, tiny box and
> the correct keyboard (or whatever it was) on your own while employees
> are left in the dark as to when the system will be back up. (Which, as
> you just read, was the case anyway! But at least they got _some_
> message.)
> 
> It's things like this and which desk is yours and all that other stuff
> above that I meant by "showing you the ropes". I didn't mean that you
> become a Unix apprentice. I meant that you are shown the particulars
> of your new work environment. Again, I apologize for having used the
> misleading term.
> 
>> professional, I have been expected to accomplish them.  And, at least
>> up to this point, I have been very successful at doing that, which
>> is probably why I have never had to worry about being unemployed.
> 
> Well, be happy you have a job at all with today's Financial Debacle!
> 
>> 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.
> 
> Ain't it the truth: Tyranny of the majority.
> 
>> University of Scranton   |
>> Scranton, Pennsylvania   |         #include <std.disclaimer.h>
> 
> AEF
>