On Oct 30,  4:53pm, Ken Sletten B894 C312 x62525 wrote:
> Subject: sysvar ex., plus mini survey:  My votes.

snip...
> Given that at our site we allow only a small, select sub-set of
> users to access MPE, from our perspective we would say
> that ALMOST anyone should be able to set a system var;  i.e.:
> just about everyone we let access MPE.  But having a least a
> minimal filter would be good.  Off the top, maybe just requiring
> a little more than IA, BA capability would do it.  So I'll vote:
>  ------------
> o I WANT ANYONE TO BE ABLE TO SET A SYSTEM VAR     _____
>
> o I WANT RESTRICTIONS ON WHO CAN SET A SYS VAR     _XXX_
>   -  SM CAN SET A SYSTEM VAR                       _XXX_  (obviously)

Ooops!  Another typo for me.  I meant to say "**Only** SM can set a sys var"
for this item.  Of course the SM will be able to delete, modify and create
a *global* var.

NOTE: I am now using the phrase "global variable" rather than "system var"
to reduce confusion between predefined HP vars that are often called
system vars, versus what we're discussing here, namely a common, global
storage mechanism for CI variables which are (potentially) accessible from
all processes.

> *AND*
>          _____
>   -  CAPABILITY-BASED RESTRICTION ON WHO CAN SET
>           A SYSTEM VAR (fill in cap(s)__need ND, SF, and
>                                                         (maybe) PH__
>
> ... OR, alternatively, if you want to add a new "SV" (save var)
> capability, I guess that would be O.K. to....  But if using
> existing capabilities that would normally be given to "power
> users" and/or programmers anyway was done, it would be
> one less extra thing to have to set, while still providing the
> "filter".  Your call on what's best in this case.
> .....  If I really want to get esoteric here, maybe also CS; since by
> one stretched interpretation system vars could be considered a
> "Communication Subsystem"....  The exact capability is maybe
> not so important, but rather that it should be something that a
> site would normally not give to its lowest or lower level MPE users...

I guess the choice boils down to do you want to overload existing caps? or
do you want a new cap.  A new cap could be more general than Save Var --
it could be some kind of ok-to-use extra-memory cap, or something like this.

> I don't think we need auto delete either.  For one thing, there
> are too many times when the decision on the "life" of a system
> var will be a dynamic thing, and / or a user will change his / her
> mind 10 times before actually doing it, depending on other criteria.
>

> >WHAT ARE THE ADVANTAGES OF CI ACCOUNT LEVEL VARIABLES ??
>
> The ability to use the same acctvar name in different accounts may
> indeed be the only advantage of acct vars;  but in many situations that
> could be a significant plus.  Example:  Our site (and I'm sure others)
> has complete duplicates of our production accounts in a test account.
> Being able to move everything over to a test account "as is" is a BIG
> advantage.  Having to edit scripts to change the name of system
> variables would be a *real* pain.

Excellent point.  Another possible advantage of acct vars is that *if*
creating global vars requires SM or OP (ie high) caps then acct vars
(which I assume can be set by the AM) permit less privileged users to create
them and this is good, IMHO.

Jeff Vance wrote:
> >3) If you define/declare a local var (x) a subsequent SETVAR x will set
> >the local var and *not* a job/sess var named x.
> >    --- or ----
> >4) If you define/declare a local var (x) a subsequent SETVAR x will set a
> >job/sess scoped x, and the only way to modify the local x is via SETLOCVAR.
> >VOTE PLEASE:
>
> ....Hmmmm...  I don't see this as a totally obvious choice, but
> if it's one way or the other, I will say:

I've gotten about a 50-50 vote so far.  That's not particularly good, but
I thought of the way that I'd prefer to use local vars in my scripts.
[ Remember there are 10 ways to create a CI var today: :setvar, setvar(),
:input, input(), :setjcw, HPCIPUTVAR, PUTJCW, SETJCW, :calc <<sets HPRESULT
var>>, the new word() function ]

I'd introduce a new command, call it DEFINEVAR for now.  This command
lets you define the scope for a var or list of vars.  The syntax could
look something like:
   DEFINEVAR [PRIVATE=varname or list] [LOCAL=varname or list]
this syntax can easily be expanded to include new scopes, whatever...

where PRIVATE means the var lives only in the environment that it is defined
and LOCAL means that the var lives where it is defined but is inherited
by called scripts and/or children processes.  In both cases the var is auto
deleted when the creating process/script terminates.

After the scope of a var has been defined, any of the above 10 ways to set
a var will operate on the local/private var.  In other words, you can define
the scope of a var once then use all the existing mechanisms to set
that var  - no new mechansims (like :setlocavar, setlocavar(), inputloc(),
etc.) are needed.

What do you think

> thanks for asking,

You're very welcome,

Jeff Vance, CSY

--