[This note has been sent to the following InterNet address(es):
[log in to unmask]]


Jeff Vance posted a long note (mostly snipped) :

Jeff,

The thread is getting too long and complicated to reiterate all the points so I
will summarise my feelings on the matter.

The original idea , I believe, was for system variables (similar to the HP@
system variables) to be available to System Managers to enable variable values
to be freely available across the system. Just looking at this aspect for a
moment, it would seem fairly straightforward to implement this feature with the
system variables created and deleted by the user  with SM capability. This
infers that all cleanup would be carried out manually similar to the creation
and purging of a file. Possibly there should be a parameter on SETSYSVAR which
can ensure an existing system variable is always overwritten if the same name
is used or can not be overwritten without a confirmation. I see no need for
automatic deletion of system variables and would prefer , personally, that the
variable values be preserved through a system reboot.

>o I WANT ANYONE TO BE ABLE TO SET A SYSTEM VAR     _NO__

>o I WANT RESTRICTIONS ON WHO CAN SET A SYS VAR     YES
>  -  SM CAN SET A SYSTEM VAR                       _YES_
>  -  A LIST OF USERS CAN SET A SYS VAR             __NO___
>  -  CAPABILITY-BASED RESTRICTION ON WHO CAN SET
>          A SYSTEM VAR (fill in cap(s)_____SM_____________
>  -  OTHER   _____________________________________________________


>WHAT ARE THE ADVANTAGES OF CI ACCOUNT LEVEL VARIABLES ??
>________________________________________________________________________

I'm not sure. I think that the System Variables could handle most requirements
by using suitable naming conventions so they would be redundant (in the
interests of keeping it simple).

>Let me try to clarify.
>1) The *only* way to set system vars is with the new SETSYSVAR command (and
>either a new intrinsic or an enhancement to HPCIPUTVAR).
>2) If you don't do anything different SETVAR works exactly as it does today,.
>namely setting job/sess vars accessible to all processes in your job.session.
>3) If you define/declare a local var (x) a subsequent SETVAR x will set
>the local var and *not* a job/sess var named x.
>   --- or ----
>4) If you define/declare a local var (x) a subsequent SETVAR x will set a
>job/sess scoped x, and the only way to modify the local x is via SETLOCVAR.

>VOTE PLEASE:
>  I PREFER CHOICE 3      ___YES______
>  I PREFER CHOICE 4      ____NO_____   (it doesn't make sense to vote for
both!)

Just my $0.02 .

Cheers,
John Dunlop

Work : [log in to unmask]
Home : [log in to unmask]
Web  : http://www.tcp.co.uk/~jdunlop/index.html

STD Disclaimer : These are my thoughts and do not represent those of anyone
else.