HP3000-L Archives

November 1996, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Vance <[log in to unmask]>
Reply To:
Jeff Vance <[log in to unmask]>
Date:
Thu, 7 Nov 1996 09:19:44 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (64 lines)
Hi John,

On Nov 1,  5:02am, John Dunlop wrote:
...

> 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.

It is true that the very original idea (back about 6 years ago) was to
have global privileged vars (meaning you need SM to set, delete them) with
the main use oriented towards security.  When I started thinking about
this more I had trouble seeing how any kind of security can be enforced by
global vars (regardless of what restrictions we place on them) since anyone
can choose to ignore the var (may still be useful for account level logon
UDCs as long as the AM follows the SM wishes).  With very few
good security examples I started thinking about exposing some of
unix's shared memory features via CI variables: i.e. letting processes
communicate with other via global vars (IPC).

> Just looking at this aspect for a moment, it would seem fairly
> straight forward 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.

Yes this is a simple and clean rule -- but will it satisfy our customer's
needs for global vars??  I don't know the answer but if enough people say
"yes" then I'll shut up :)

> 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.

I hadn't thought about any kind of confirmation when a global var is
modified?  Of course you will want to be able to defeat that as well.
As far as surviving reboot, this would require that all writes are flushed
to disk which could get pretty expensive.  What if you had a command or script
that saved vars and could restore vars after reboot??

snip...
> >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_____

Have you read my DEFINEVAR idea?  Basically you can establish the scope of
a var before setting it.  Then any method of setting a var (ex, :input,
:setvar, :calc, :setjcw, input(), setvar(), word(), HPCIPUTVAR, etc)
sets the var at the right scope.

thanks for your thoughts!
Jeff


--

ATOM RSS1 RSS2