HP3000-L Archives

November 1996, Week 1

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:
Ken Sletten B894 C312 x62525 <[log in to unmask]>
Reply To:
Ken Sletten B894 C312 x62525 <[log in to unmask]>
Date:
Tue, 5 Nov 1996 11:29:00 P
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
Jeff after me after Jeff:

>I guess the choice boils down to do you want to overload existing caps?
or
>do you want a new cap.  A new cap could be more general than Save Var --
>it could be some kind of ok-to-use extra-memory cap, or something like
this.

Hmmm..... That makes sense.....  Generally I've got no problem
with a new cap;  I was just thinking that there are getting to be a
lot of different caps:  Right now a LISTUSER MANAGER.SYS on
my system shows:

CAP: SM,AM,AL,GL,DI,OP,CV,UV,LG,PS,NA,NM,CS,ND,SF,BA,IA,PM,MR,DS,PH

That ends in column 67 on my screen...  If we add too many more, we
the CAP line in LISTUSER for MANAGER will run over 80 char....   :-)

>> The ability to use the same acctvar name in different accounts may
>> indeed be the only advantage of acct vars;  but in many situations
that
>> could be a significant plus.  ............

>Excellent point.  Another possible advantage of acct vars is that *if*
>creating global vars requires SM or OP (ie high) caps then acct vars
>(which I assume can be set by the AM) permit less privileged users to
create
>them and this is good, IMHO.

Yes;  our site would definitely want all the AM's to be able to
create acct vars in their respective accounts.....  In fact, AM
by definition should include acct var CAP (I think that's what
you were saying above)....  Actually, in our environment we
would clearly want to be able to selectively allow more than
just AM to create acct vars;  but not everybody.

>I'd introduce a new command, call it DEFINEVAR for now.  This command
>lets you define the scope for a var or list of vars.  The syntax could
>look something like:
>   DEFINEVAR [PRIVATE=varname or list] [LOCAL=varname or list]
>this syntax can easily be expanded to include new scopes, whatever...

I like it.

>After the scope of a var has been defined, any of the above 10 ways to
set
>a var will operate on the local/private var.  In other words, you can
define
>the scope of a var once then use all the existing mechanisms to set
>that var  - no new mechansims (like :setlocavar, setlocavar(),
inputloc(),
>etc.) are needed.

Even better.  What you just said sounds like the best way to do it to
me..

Ken Sletten

ATOM RSS1 RSS2