> -----Original Message-----
> From: Mary DeGallo
>
>    this is the basics, when somebody asked I was stuck.
>
>    I login by saying:
>
>   SomeSystem> HELLO MDEGALLO.TEST.FINANCE

Actually, there is an error in what you've shown above (trivial to you and
I, but computers are rarely as forgiving...)  Basically, the two seperators
used are PERIODS and COMMAS -- due to the way MPE assigns users and
accounts, there will be only ONE period in the logon string.  Your example
could either be

   MDEGALLO,TEST.FINANCE

or

   MDEGALLO.TEST,FINANCE

which would have significantly different meanings to the computer.  However,
you then ask (and note):

>     What is MDEGALLO?
>     What is TEST?
>     What is FINANCE?
>
>    I explained that it is Session.User.Account format.
[which implies the first variant above]
>    But I myself was not clear

Well, you've basically need to assign each word to each part, and you'll
have answered your question as written, i.e.,

  MDEGALLO is the SESSION
  TEST     is the USER
  FINANCE  is the ACCOUNT

But, as you note, knowing what each portion corresponds to doesn't
necessarilly convey "understanding", especially since a "unix" logon (or
even a "windows" logon for that matter) would consist of one part: the USER
part only.

MPE allows for more "fine tuned" access than the unix/dos/windows model of
two levels (the "super" user and "mere mortals" for the rest).  MPE, being a
business-oriented OS, actually models the system access similar to a "real
life" business unit: the "boss" [ceo] is the ultimate authority on what goes
on within the company; likewise on the HP, the "system manager" is the
"boss".

Now to give you some "real world" parallels:  In a "really big"
organization, it is quite unlikely that the CEO would concern himself with
the hiring and firing of the janitors, telephone operators, or cafeteria
staff; yet within a "unix" environment this is exactly the case: the "root"
user is the only authority permitted to create & destroy any OTHER accounts
(users) within the system.

In "real life", the CEO would hire & fire top level "managers": one for the
cleaning crew, front desk, and cafeteria.  These managers would, in turn,
hire the actual people who push brooms, answer phones, and serve meals.
Under MPE, the same is true: the MANAGER.SYS user creates various "accounts"
[CLEANING, FRONTDSK, CAFE] and a "manager" user within each account
(traditionally MGR, but it could be anything up to 8 chars in length).
These managers have the authority to create additional users BUT they are
restricted to creating users only WITHIN the account they manage -- you
generally don't expect the cleaning crew to answer the phone or cook a
meal...

In addition to the above, you might even have some "specialization" within
the ranks of the cleaning crew -- someone might focus on cleaning windows
while another pushes a trash cart and a third runs a vacuuum cleaner...
Under MPE, the MGR.CLEANING would create the "users" WINDOW.CLEANING,
TRASH.CLEANING, and VACUUM.CLEANING.  Also, in "real life", you generally
don't hire "just one janitor"  [I'm talking about LARGE organizations
here...] and, in fact, the actual person might change fairly often, although
the position doesn't.

MPE allows a similar parallel as well: the "session" name portion (which is
completely optional so far as MPE itself is concerned) can be used to
differentiate two users who use the same "user.account" portion of a logon.
Thus, you could have BERT,WINDOW.CLEANING and EARNIE,WINDOW.CLEANING.  Both
have the same task to accomplish, but there are more windows to clean than
either of them could handle by themselves, hence the ability to specify
exact names.

MPE also allows for different GROUPS -- this is a way to subdivide an
ACCOUNT.  Using the above example (again), we can differentiate this to:

   BERT,WINDOW.CLEANING,INSIDE
and
   EARNIE,WINDOW.CLEANING,OUTSIDE

You might also have noted above I said that "MPE considers the SESSION name
to be OPTIONAL".  In the "plain vanilla" flavor, this is true, however you
can get third party utilities (SECURITY/3000 or SAF/3000 comes to mind) or
even an HP-supplied product (HP SECURITY MONITOR) which would allow to you
to ENFORCE not only the use of "session" names, but the ability to provide
individual passwords  (back to the real world: both BERT and EARNIE would
have the SAME keys to the building, but they might also have to have a BADGE
that identifies them to a guard or security scanner; one that would let BERT
on the inside OFFICES to clean the insides of the windows, while EARNIE's
would let him onto the ROOF to access the exterior cleaning scaffold...)

Now, back to your specific example (and the two variants I mentioned above):

   MDEGALLO,TEST.FINANCE
would refer to your logon as a "test" user in the finance account, while
   MDEGALLO.TEST,FINANCE
would refer to your SPECIFIC logon in the TEST account, but using the
FINANCE group.  Both of these are perfectly valid (and, in fact, quite
likely) BUT they depend on how your system manager has segregated the
system -- does the application drive the data, or does the data drive the
application?  In the first case, you are more likely to log on in the
APPLICATION's domain (account) and run the program from within that account
(xxx.FINANCE).  In the second case, you will probably log on to an
account/group set up to warehouse the data, and run the programs from
another location (i.e., log on as xxx.TEST and run prog zzz.PUB.VENDOR)

Tom

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *