Jeff Vance wrote:
>> Need for System CI Variables:
> -----------------------------
> Why can't MSG files work?  Perceived greater overhead, more complex, perhaps
> not transient enough (system variables will disappear on a reboot).  Of
> course MSG files can hold more data than a CI variable, which is limited
> to 1024 bytes. (Conventions can be used to "chain" together many system
> variables.)
 
I disagree (for my interest).  MSG files imply a one-to-one
relationship, and while MSG files can do this (and we've done it) my
interest is a one-to-many pathway of communication (multiple instances
of an application, multiple applications within a package, or multiple
packages across the system).
 
 
> B. We need to be able to show one or more variables in two ways.
> We need to see which variable would be referenced if I did a !varname.
> Is there a local varname, job/session varname, system varname or none?
> We may need to see "varname" at each scope that it is defined.  E.g.,
> here is the local value for varname, here is the job/session value for
> the same name, etc.  We may need to see more details than SHOWVAR reveals
> today, e.g., var type (int, boolean, string, JCW), var scope (system,
> job/session, local, CI-only [like HPMSGFENCE]), var security (for system
> variables), var creator/owner (for system variables).
 
Take a "horizontal analysis" and look at Posix environment variables.
This would solve many of your "scope" concerns (it's local or
exported).  Posix environments inherit the CI vars of the invoking CI
(logon shells) and resolution is fairly well defined.  You seem to be
taking a "lexical context" approach where you are associating common
names with different environments (CS term is "overloading") and trying
to define default behavior.  Heck, steal some Perl code and have as many
variable namespaces as you wish (System=>somevar, Session=>somevar,
Process=>somevar, Script=>somevar, etc) and even get into messing with
the variables of external environments (modifying locals in another
scripts locals).
But my own opinion, let's not get too complicated.  My primary need is
for the ability to set system variables (like the HP@ variables) so that
any process on the system can read them.  Your local variables are
convenient, but by definition they are more of a convenience that a
defined need.
 
Be careful about your overloading rules, or you'll get very complicated
not only in your coding, but also user understanding, consistency, and
intuitive elegance generally afforded by MPE.
 
Jeff Kell <[log in to unmask]>