Forwarded with Donna's permission:

On Sep 26,  9:47pm, Donna Garverick wrote:
> Subject: Re: (Fwd) Design for System CI vars (long)

> i wanted to throw my 2-cents worth in to this discussion.  i would
> *really* like a command that would tell me the properties of a ci
> variable.  like whether it's string, integer or boolean, whether it's
> changeable or not - stuff like that.  it can be really frustrating
> when dealing with hp variables or variables set by third-party s/w to
> know exactly whats what.

I agree.  I was thinking of an enhancement to the SHOWVAR command.  For
instance:
   :setvar aa 1
   :setvar bb "2"
   :showvar aa,bb
    AA = 1
    BB = 2

You can't tell that BB is a string and AA is an integer.  What if...

  :showvar aa,bb ;format=detail

VarName       Type      Scope     Owner        Access       Value
AA            INT       JOB                                 1
BB            STR[1]    SYS       MANAGER.SYS  R-only       2

STR[n] means the type is a string of n bytes.  Other types could be
BOOL, JCW.  Other access could be: W-only, RW-acct, RW-sys, ??
(Paul's idea of system and account level functions makes this part easier...
but you may still need to be able to display the functions.)

Obviously the columns won't line up with long varnames, but you get the idea.

I think that we may need to keep track of the creator of a var to be
able to allow account members to have access and to allow the AM to modify
it.

> my ignorance may be showing here - but how
> can a variable be set so that it can't be changed?

Can't be done today. Once you set up a var whether via a system logon UDC,
an account logon UDC or whatever, the var lives in the JOB/SESSION
domain of the user logging on.  And that user can change the var (or delete
it).  Now this assumes that you are creating a new var.  If you are
setting a predefined HP var in a logon UDC (like HPSYSNAME or HPPATH)
then the user cannot delete it but they can still change it.  This is
one of the benefits of system/global vars.

OTOH, the user may wish to create some of her own vars-- maybe in a
script or JCL file.  Today she has to consider that she may be overwriting
a var that was previously set up for her by the system mgr.  With
local vars this situation goes away.

> perhaps i'm out in
> left field, but i did want to speak up    - donna

Not at all (I'm a lefty myself :) and thanks for the comments,

Jeff Vance, CSY

--