On May 1,  5:25pm, Jeff Woods wrote:
...
> It sounds to me like the most useful ones are also the easy ones to get.
> Those you list are hard to see seem to be of little use or are available
> via other mechanisms already.  I strongly suspect that user-defined
> variables are the major reason for access to system variables from other
> sessions.

This is the kind of feedback I'm looking for.  If most feel this way then
it may be worth doing the enhancement; otherwise it is probably not, at
least at this time.

> How about providing a filter for SHOWVAR which allows the user to select
> which set(s) of variables are visible to the user.  And the functions and
> process-local types can be unimplemented until such time as a business case
> is made to justify the need for them.

The only existing filter is invoked by the absence of the varname argument.
That is, user defined vars output alone can be seen iff you don't specify a
varname. If, however, you want to see all user defined vars starting with the
letter "H" you're out of luck.

I've previously proposed the possibility of filtering vars by user-defined
vs. pre-defined.

> The only other thing which would be
> needed is to define which class each HP-defined variable is in so there is
> no confusion over whether it should be seen by this "remote showvar"
> mechanism.  It seems that understanding that HPMSGFENCE is process-specific
> but HPPATH session-wide are things which should be explicitly documented
> anyway (if they aren't already, which is entirely possible ;).

This is the part that makes me uncomfortable.  It seems unreasonable to
ask our system managers to know what kind of CI var they can and can't
request for another job.  The differences in var scope and storage
location are part of an internal design that should not need to be so
apparant to the users.

> So implement the easy ones, default to showing just the user-defined ones
> (similar to the default SHOWVAR today anyway) and provide a way to ask for
> the other sets if and when they become available (which would presumably
> initially include the entries from the variable table, but not the others).
> We get 90% of the benefit for 10% or so of the effort and we define an
> extensible mechanism to add the others if and when needed and at the same
> time document why the missing ones are missing so there's no
> misunderstanding or confusion.
>
> I'll step back now and let everyone blow holes in my idea.

I like the idea but am waiting for some more feedback.

> P.S.  I suggest Jeff just go implement this in a way that doesn't break
> anything (I think that's easy this time since without some new keyword the
> old behavior will be preserved) and not ask what the exact syntax should
> be....

ok (assuming that it gets implemented -- just testing the water right now...)

regards,
Jeff Vance

--