Hi Ken,

First, thanks for taking the time to provide your feedback!

On Dec 10,  7:23am, [log in to unmask] wrote:
...
        > >SHOWVAR [varname [, varname, ...]]
> >        [FORMAT=brief | scope | detail ]
> This looks fine, with format=brief as the default.  Provides excellent
> backward compatibility.

Yes.  format=BRIEF is the default format -- unless you specify a scope,
such as "acct:varname" or "natural:varname" or "@:varname, in which case
the default format is SCOPE.

> Regarding the format=scope output, you wrote,
> >scope       - Same as brief except the scope is shown in the variable
> >                   Ex: p:A1 = 2
> >                       a:A2 = 2
> >                       p:B0 = 0
> >                       j:B1 = 10
> >                       g:G = 5
>
> This may be picky, but I would like to see the scope print either in full
> or as a keyword instead of one-letter identifiers.  What if you come up
> with another scope identifier in the future that would best be suited to
> having the same first character?  Also, the output is much more readable
> by human beings.  My example,
>                     priv: A1 = 2
>                     acct: A2 = 2
>                     priv: B0 = 0
>                     job : B1 = 10
>                     glob: G = 5

I would like the displayed scope names to be the same as the user can type
when "qualifying" a varname with an embedded scope in the name, eg. acct:FOO.
Currently we have a long and short name for each scope: g or global, a or acct,
j or job, p or private ("priv" may be confusing).  I don't mind abbreviating
global as "glob" as above.  The formatting you've shown looks nice, with
the colons lined up and the extra spacing, but this is not the syntax for
embedding the scope in a varname.  Does this matter to anyone?  As Jon has
mentioned, what if we show the full scope name in the format=detail output,
and leave the abbreviated, concatenated form as is in format=SCOPE?  Another
possibility is to show scopes as per Ken, and define another format whose
output can be executed as a script that sets all the vars shown.  Eg.
  :showvar name;format=script
        setvar a:acct_var,"str_value"
        setvar g:glob_var, integer
        setvar j:jobvar, boolean
etc...

> >  ============= QUESTION ================
> >  Do you like each flag having its own column position vs. concatentating
> >
> >  flags like the TYP column in LISTF,2?
> >  Would you prefer a blank to indicate the flag is not present (as shown
> >  vs. say a lowercase flag letter for the same meaning?
> >  Like "u" means unique.
> I prefer the former format, where the access is positional.  This allows
> for easier parsing if required.  Again, I'd like to see the scope expanded
> to english words.  Otherwise, why not use I, S, B, J for variable types.
> Ha!  Let's be consistent.

Good point.  The reason I choose long names, like "boolean", for the var
type is because there was enough room due to the string var type also
including the str length, e.g. "str[1024]".  This makes the type field width
9 characters, which easily holds "integer", "boolean" and "jcw". If I
omit the lengh of string var values then I can make the type width 4 chars.

> Regarding the operation...if the user doesn't have read access to
> a variable, and they perform a showvar command, a CI error should be
> issued with the good old error message,
>
>    Variable not found in variable table. (CIERR 8106)

If this is truely an error and you are using "natural" scoping then the
search for 'varname' stops on the 1st read error.  This is our choice: we
can ignore read errors and continue looking for 'varname' in the next
scope (assuming scope=natural or scope=@), or we can stop on the 1st
read error. FYI, the DISKUSE command ignores read errors in computing disk
space.

> Next, I believe that the bound() function will have to address the scope
> issue.  If you are ultra cautious, you will want to check to see if
> you can modify a variable before doing so, rather than check cierror
> in post-processing error code.  That is, it is probably more elegant
> (from a CI programming standpoint) to do the following,
>
>   if bound(myvar,write) then
>      setvar myvar "foo"
>   endif
...
Agreed.  My proposed bound() function now is:
   bound(varname [,"read" | "write] [,rtn_scope])
where:
  'varname' is the name of the var that may or may not exist - the scope may
     be prefixed to the varname, eg. scope:varname.
  "read" means the caller must have READ access to 'varname' - else FALSE
     is returned even if 'varname' exists.  "read" is the default.
  "write" means the caller must have WRITE access to 'varname' - else FALSE
     is returned even if 'varname' exists.
  'rtn_scope' is the name of a CI var that will hold the scope that 'varname'
     was found in when TRUE is functionally returned.  This is useful for
     unscoped var names or when the scope is "natural". The default is to
     not return the scope of 'varname'.

> Here's a good question:  to be backwards compatible, which will be the
> default value for the scope in the bound function?

The default scope for 'varname' in the bound function is "natural", meaning
look at private -> job -> acct -> global.  This is where either ignoring or
enforcing read errors is important.  This default is compatible since today
there are no vars except in the JOB scope, so when you create a var in
a different scope you are explicitly enabling the new features.

> It may be obvious, but which method would you use to view only global
> variables?  I don't want to see other variables in a different scope...
> (just for this example!)  It would be neat if you could do
>
>   showvar @;scope=global

showvar g:@    or   showvar global:@    will work with any format.  The
default format in this case would be format=scope. Is this acceptable?

Thanks for your comment,
Jeff

--