Jeff,

Wow, that's quite a bit to take in.  Anyway, here are my initial
thoughts on your questions:

>----------------------------------------------------------------------------
>Appendix F.
>----------------------------------------------------------------------------

>================= QUESTION ===================
>* Possibly a more intuitive name for job/session vars is "user",
>  since the user (and all processes run by the user) has full access
>  to all of these vars.

Can we have a write in candidate of "LOCAL"?  Barring that,
I'd stick with jobses.

>================= QUESTION ===================
>Is it acceptable to treat all parms like private vars?  Specifically,
>is it ok to refer to a parm as:
>   if parm = "abc" then ...  ?
>Is it ok to modify a parm, like:
>   setvar parm1, value
>Noting that this can break scripts that rely on creating a JOB
>var with the same name as a parm.

That's a hard call.  I've always wanted the parms to act like regular
variables, and now that I've got the vote, I'm not so sure anymore!
I've always tended to set variables to the parm values right up
front in my CMD files, and then forget about the parms.  So this
wouldn't affect those CMD files, but I'm sure there are cases where
there would be a conflict.
  Being the consummate user, can we have the behavior determined
by another OPTION parameter, defaulted to 'NO', keep them separate?
If that's out, then I'd through my vote to 'YES', treat them equally, and
I'll be prepared to hunt for problem CMD's.

>================= QUESTION ===================
>If a script has a formal parm of the same name as a ";UNIQUE" variable
>(could be global, acct or job) is it ok to execute this script?  As
>a more extreme example, assume that we have migrated HPSUSAN from today's
>JOB scope to be a true global and ;unique var.  Assume a script has a
>formal parm named HPSUSAN.  I can pass this script vany value for its
>HPSUSAN parm.  Is this ok?

Irregardless of the answer to the prior question, I'd say "NO" to this.  Even
though this 'could' cause a backwards incompatibility, I want the assurance
that if I set a variable to be 'global' and 'unique', that it's not going to be
overridden.
If you let your above example happen, then unscrupulous users
could exploit that to run unlicensed software (assuming the software solely
based it's security on the value it received from the HPSUSAN variable, and
it has not yet been enhanced to explicitly check for the scope of 'global').

>================= QUESTION ===================
>What does SHOWVAR <no argument> mean? (today we show all non-predefined vars).
>- Should it mean the same with scoping?  If so, how do we distinguish var FOO
>which may be listed 4 times (once per possible scope).
>- Another interpretation is "show all vars I created", which again could
>span many scopes.  However, this interpretation would less likely show
>many acct or global vars (unless the user created them??).
>- A third possibility is "show job/session vars I created" (which is literally
>what is done today), meaning an implied jobses: scope.
>
>Follow on questions: does this behavior ("show vars I created") need a way to
>be explicitly specified, like a ;USER | PREDEFINE option?  This would allow
>you to use pattern matching separately from controlling the above behavior.

#3, "show job/session vars I created"

  Having an option to show what variables "I" created might be useful, but
how are you defining "I" in this context?  The MPE/iX User.Account currently
logged into?  Maybe adding an optional ;USER[=user.account] syntax where
user.account defaulted to the current logon user and account would be nice.

>================= QUESTION ===================
>What does SHOWVAR @  mean? (today we show all vars).
>- Should it mean the same with scoping and display all vars at all scopes?
>- Should it just show all vars that it would "naturally" discover using the
>scoping hierarcy rules.  This means that if we show a private var FOO then
>we don't display a JOB, ACCT or GLOBAL foo.
>- Should the jobses scope be inferred in SHOWVAR @?

Show all "naturally" discovered variables.
If you want ALL variables, use SHOWVAR @:@, or an explicit
scope for all variables discovered there (e.g. SHOWVAR j:@).

>================= QUESTION ===================
>What does DELETEVAR @  mean? (today we delete all deleteable vars).
>- Should it mean the same with scoping and delete all "deleteable" vars at
>all scopes?  This means if there was a private, job and global FOO var, all
>three FOOs would be deleted.
>- Should it just delete all vars that it would "naturally" discover using the
>scoping hierarcy rules.  This means that if we delete a private var FOO then
>we don't try to delete a JOB, ACCT or GLOBAL foo.  We still need to search
>all vars in all scopes.
>- Should the jobses scope be inferred in DELETEVAR @?

Same logic as for SHOWVAR.  If you want to get rid of 'foo' in all
scopes, how about DELETEVAR @:foo?  All variables would be
DELETEVAR @:@ (global and account variables would only get
deleted assuming appropriate ACD privileges, no errors returned
for those you couldn't delete since they were not explicitly requested).


And a Question of my own:

Can I recursively de-reference on the RHS if I enclose the
scope:variable combination in square brackets?

For example, let's say I set my prompt to be "!!hpcwd" so it changes
dynamically as I roam about.  Now let's assume that hpcwd is set at
the jobses scope when I logon.  If I run a script that set's p:hpcwd to
"xyzzy", I don't want my prompt becoming "xyzzy" (not that I would
probably see it during the running of the script, but that's beside
the point :), I want it to reflect my current working directory.  If I
can't explicity declare the jobses scope when I define my prompt,
I'll be out of luck (I think :).  Any ideas?

Thanks for the opportunity!

Michael L Gueterman
Easy Does It Technologies
email: [log in to unmask]
http://www.editcorp.com
voice: (509) 943-5108
fax:    (509) 946-1170