--- Forwarded mail from Larry Byler <[log in to unmask]>
and posted with his permission...

Hi all,

I've been lurking and not contributing to the discussion up until now, so I
thought I'd put in a couple of responses to Jeff's questions.

[...]
Jeff Vance wrote:
>Questions / observations:
>-------------------------
...
>2) Who should cleanup system vars that haven't been deleted when they
>were suppossed to?  A reboot will.  Should this be a task that the system
>manager needs to do?  Should a system var be automatically deleted
>when its creator dies (doesn't seem good for IPC usage)?

I can think of scenarios that would want the vars to remain, and others
that would want them to be deleted.  If you need both types of behavior,
all you can do, it seems to me, is make the behavior configurable (sort of
analogous to the ;RESTART option on a job card).  This could happen when
the variable is created (option), or, more dynamically, anywhere during
its lifetime (generic command that assigns a behavior to a specified
variable (or variables -- list, wildcards, ...??)  I suspect it would be
easier (and would probably satisfy the 80-20 rule) to bind its behavior
at creation time.

>3) Should there be any restrictions on who can create system vars?
>Remember one of the benefits of system vars is IPC.  I looked at all
>possible capabilities (BTW, remind me what CS capability is??) and none
>really seem to apply.

I think so.  IPC cuts both ways.  Do you want to support IPC between
totally unrelated processes or process trees?  To me, system vars means
just that -- system vars, available (required if HIDE=no) for all users
on a system.  Anything that affects all users should be managed only by
SM users, IMHO.  Allowing users of lesser capabilities to create system
vars risks aliasing/destruction/hiding of desirable vars, with consequent
degradation (or even malicious destructive effects) of the system.  Or
perhaps I'm reading more into your question than you intended.

If you want vars for IPC between related or possibly unrelated (but
controlled) processes, it seems to me we're back to ACDs and the can of
worms *that* opens.  I'd also refer you to Scott McClellan's earlier
(well-taken) KISS comments.

>4) Should there be any restrictions on who can set read/write/delete
>access to the system var they created?

See my answer to 3).  I believe only SMs should create system vars.  If
there is more than one SM user, I believe they should have equal access
to all system vars.  Admins aren't stupid, and they run their systems to
best serve their user base.  Among other things, it's good job security.

>Is there a need to be able to alter any characteristic of a system var
>once it is created (other than its value)?

I don't understand this question?  Do you mean, is it necessary to change
the scope of an existing variable (system <==> job/session <==> ???).  Or
its access rights?  I wouldn't think so.

>5) How do you create a system var and guarantee that no one else already
>has it defined at a different scope?

You can't, unless you create/define it in SYSSTART.

>I don't think you can without deleting
>the vars in the other scopes.

I agree.  And I'm not sure it's such a bad thing to leave the "legacy"
variables in those other scopes.  Consider:
o   If you define a new system var, it's probably not going to be a spur of
    the moment decision, but one undertaken only after careful planning,
    notification of all your users, and updating of any affected applica-
    tions (such as those which may use the identically named variable at a
    different scope).  So the situation may not arise at all.
o   Even if it does, the cure (deleting the vars) may be worse than the
    disease.  Change the nature of a var in a running application, and
    you risk all kinds of bizarre behavior.  You also need careful locking
    strategies to prevent concurrency problems.  It's bad enough that the
    next user of the program will see a redefined var, which may not work
    like s/he expects.  See the previous bullet.

>And do you really want the CI going to all
>account var tables, all job/sess var tables, all local var tables for
>all users and checking if a var exists or not?

I sure don't.  You would need to do this for each new variable you create.
On a 500-1000 user system, this would take forever, not to mention the
locking problems I alluded to above.  You might have to lock down the
entire system while you searched all those tables.  It could easily become
a high availability issue.

...
>-----------------------------------------------------------------------> time
>|no sysvars  |set sysvar   |jobs sets     |set new      |new jobss
>|            |S1           |own V1 var    |sysvar V1    |can't set V1
>reboot      sysstart      multi-users     |(HIDE=no)    |
>             T0            T1             T2            T3
>
>T0: if S1 set as HIDE=no then all new job/sessions will be unable to create
>    a job/sess or local var named S1.  Therefore all new jobs will refer to
>    the system level S1 when they reference S1.
>
>T2: V1 can be set as a system var even though there are jobs logged on
>    that have already defined a job/sess var named V1. Jobs prior to T2
>    will reference their own V1, whereas jobs logging on after T2 will
>    reference the system V1.  IS THIS OK?

I think so.  See my earlier comments.  I think any other approach leads to
undesired corner cases and quickly becomes unmanageable.  Again, a good
sysadmin doesn't create system vars on a whim.  Those that *are* created
should come after thorough analysis of their effect on a system.

Now suppose you want to configure a var according to some system dynamic
which is not known until after the system has been up for some time.  Yet
you don't want variables of lesser scope to hide your system level var.
My take on this is to create your var in SYSSTART (with HIDE=no, if I
understand your syntax correctly), giving it an agreed-on value that says
"this is an unconfigured value, I will be updated later".  When the
desired value is known, the SM user modifies the var appropriately.
This can be done interactively or in a job.

>T3: All new jobs beyond T2 cannot create a more local V1 (HIDE=no) and
>    thus they will reference the system V1 when they reference "V1".

Wouldn't be an issue in the scenarios I described.

>6) It seems desireable to be able to override a var of a higher scope.
>Eg. a script sets a local value for HPPATH, or a system var is defined
>as a default value, but users may create a more local var to effectively
>override the system var.  It also seems reasonable to be able to defeat
>this override abilty.  I have defined the HIDE parameter for this
>purpose.  HIDE=yes means it is ok for this var to be overridden (*not*
>overwritten) by a var of the same name in a more local scope.  HIDE=no
>means this is not allowed.  Even with HIDE=no question 5 above is
>relevent!

I agree that system vars should have this flexibility, and it was one of
the ideas I proposed in my original design document (along with some vars
that no one, not even an SM, could change -- these were primarily active
functions).  The choice (HIDE or not) is up to the SM.

But if you define all HIDE=no vars in SYSSTART, question 5 ceases to be
an issue.

>7) Should there be a way to override the natural hierarchy of var de-
>referencing, which is: look first for local vars, then for job/sess vars,
>next for account vars (maybe?), and last for system vars?  If yes, do
>you like the idea of SYSVAR(varname), ACCTVAR(varname), JOBVAR(varname)
>functions vs. a more general SCOPEVAR(varname, "scope") function? vs.
>a qualifier in the varname itself, eg. !varname{scope} or !varname:scope?

My first take on this was No there shouldn't.  Scoping is scoping.  Then
I read a little farther into your question.  I like your generic SCOPEVAR
approach rather than the separate (SYSVAR, ACCTVAR...) interfaces.  Not
only does it save interfaces (commands, intrinsics, whatever), but it's
the most easily extensible if you discover new scopes.

But you should consider carefully just what you want to be able to do
with this interface.  Read only?  Modify?  Who can do which?  Does it
provide an end-run around enforced values of system (or any scope)
variables?

Having said all that, I believe that hierarchical scoping should be the
*default* behavior, that is, if you don't specify this special interface
(whatever its permissions eventually become), you search locally first,
then succeedingly higher, until you get to system level.

>8) Do you think it will be a common error to initially define a local
>var (say j) and then later in the script accidently use SETVAR j rather
>than SETLOCVAR j?  If so, what is a good way to prevent this error?

I haven't followed the earlier discussion as closely as I should, so
I'm not sure what the issues are here.  But my uneducated guess is
that programming languages don't provide any support in this area, so
we need not either.  Good design will avoid this kind of problem; I
don't think we need to build in any special robustness for it.

>9) Does question 8 apply to system vars?

Not if system vars are managed properly -- but I confess, I mean
"proper management" according to the Byler gospel above.

>10) Do we need to delete a var from all possible scopes at once?

Interesting question.  I hadn't thought about it.  I can see where
it might be desirable to delete multiple scopes at once (such as
an abnormal script abort which leaves several levels of vars below
it in limbo otherwise).  If you include this, I would modify "all
possible scopes" to incorporate a list and a range specification,
along these lines:

        level1, level2, level3   Deletes only the specified levels
        level1..levelN           Deletes the (inclusive) range
        level1..                 Deletes level1 and everything below
              ..levelN           Deletes levelN and everything above
              ..                 Delete 'em all.

all of the above subject to whatever permissions you impose on the
user doing the delete.  For example (according to the Byler scenario),
a non-SM user could specify ..levelN, but would either get an error
(nothing deleted), a warning (only deleted levels this user had access
to), or no notification (and deletion of accessible levels).  In no
case would any system var be deleteable by this user.

This whole thing is pretty much off the top of my head, so it may not
withstand review by all you guys (and gals, for Donna).  But I hope
it provides food for thought and sparks some useful discussion.

-Larry "Sysvars 'R' Us?" Byler-

--