To: Jeff Vance <[log in to unmask]>
From: [log in to unmask] (John Korb)
Subject: Re: Ex. using system and local vars
On Tue, 29 Oct 1996, Jeff Vance wrote:
>On Oct 29, 4:17pm, John Korb wrote:
>> Subject: Re: Ex. using system and local vars
>> On Tue, 29 Oct 1996, Jeff Vance wrote:
>>
>><snip>
>>
>> > Questions / observations:
>> > -------------------------
>> > 1) If the job above is aborted before passing the critical step it will
>> > hang the monitor job, and the system var won't be deleted.
>>
>> Hmmm. Couldn't that be cured by a "if JOBEXISTS(!jobnum)",
>
>Yes, or I was thinking of jinfo(jobid, item) where "exists" is one of the
>items.
That would be even better - much more useful!
>> I'm not too concerned about the system variable not being
>> deleted, but guess if there is a scopy for who can read/write the
>> variable, there could be a "LIFE=SYSTEM" or "LIFE=EOJ" to indicate that
>> the job is to survive until the system is shut down, or only until the
>> job/session terminates.
>
>Yes, I have considered a parameter to SETSYSVAR to indicate when this var
>gets *automatically* deleted. Possible values are: NEVER, when creator
>process terminates, when creator job/sess terminates, maybe others?
>Should this concept also apply to account vars?
I'm not sure. It would be nice for it to be consistent, but I'm not
convinced that this feature would be necessary at the account level.
To me it is something needed at the system level, but may be overkill
at the account level. If it is needed at the account level, set it
at the system level instead.
>The tradeoff is extra complexity vs. the value of a feature. In this
>case my vote is to not do it: 1) it doesn't solve the problem since
>the creator of the var can specify NEVER or just omit the LIFE=parm.
>2) therefore someone will still end up periodically checking if there
>are extraneous system vars [sidebar: how do you know a system var is
>extraneous? Do I need to keep track of last access date/time, who is
>accessing the var, etc. Sounds too much like LISTF... and overly complex.]
I guess my concern is that on systems that are shut down once every few
months, the number of system variables could grow to a point where the
operation of the system (or system variable feature) is adversely affected.
Date and time of last access? No, I doubt that the overhead would be worth
the benefits. Perhaps LIFE=parm should default to deleting the variable
when the job/session creating it terminates, sort of like TEMP files and
file equates. LIFE=parm would be more like a "SAVE" option. Oh no,
another can of worms. Would a "PERM" option that would allow saving the
system variable (and its value) across system shutdowns and restarts be
worthwhile? I can think of a couple of instances within the Navy's
applications where such a system variable would be useful, and easier to
work with than using redirection to save a value to a file (with EVERY
write to the variable!).
>The above sidebar may support those who feel that system vars should *only*
>be set by the system manager (SM capability), despite the restriction this
>places on IPC uses.
Allow any user to create a system variable, just as any user can GETRIN.
However, somehow there should be a limit as to how many system variables
any single user can "own". Why? I worked in an academic setting for a
number of years and I can just imagine some student running an "experiment"
to see how many system variables he/she can create and messing up the
system for all users. (Jeff Kell, what do you think?)
>> > 2) Who should cleanup system vars that haven't been deleted when they
>> > were suppossed to? A reboot will. Should this be a task that the system
>> > manager needs to do? Should a system var be automatically deleted
>> > when its creator dies (doesn't seem good for IPC usage)?
>>
>> I guess that since you can FREERIN, perhaps the creator or SM could
>> logically be able delete the system variable (unless the "SCOPE=SYSTEM"
>> tack is taken, in which case that might not be acceptable).
>
>I think that an SM user will be able to delete a system var regardless
>of the access rights on that var and regardless of whether or not anyone is
>accessing the var. For non-SM users we either say they can't delete (an
>maybe can't write) any system vars, or we provide some kind of simple access
>list/rules.
Hmmm. Delete the variable while users are accessing it? I don't know.
What about a "delete pending" state? I'm not sure how the file system
handles "delete pending" on iX systems, but on the classic systems, if
there are multiple accessors of a file and one user FCLOSEs with DELETE,
the file exists until the last user closes the file, then is deleted
(or at least that is the way it used to work). When files (and variables)
"disappear" while an application is running, funning things (usually
unanticipated) happen. I'd feel more secure if either a variable in use
could not be deleted, or if the variable were placed in a "delete pending"
state.
>> > 3) Should there be any restrictions on who can create system vars?...
>> I seem to remember CS was Communications Subsystems. No, no
>> restrictions. Sort of the GETRIN/FREERIN approach.
>This is my inclination too. A good argument against this is that you will
>need some sort of access restrictions -- even if it is ok for all processes
>to read the sys var, you don't want all processes to write/delete it. Also
>with anyone able to create a sys var you will increase the chance of wasting
>space due to extra sysvar that weren't deleted, and eventually running into
>name conflicts. Today I need at least SF capability to save a file.
>Do we need SV (save var) capability.
Access restrictions: As in read, update, delete? Would delete be able to
override the LIFE=parm? What kind of scope? Similar to POSIX permissions?
Similar to ACDs?
>> > 5) How do you create a system var and guarantee that no one else already
>> > has it defined at a different scope? I don't think you can without....
> -----------------------------------------------------------------------> time
>> > |no sysvars |set sysvar |jobs sets |set new |new jobss
>> > | |S1 |own V1 var |sysvar V1 |can't set V1
>> > reboot sysstart multi-users |(HIDE=no) |
>> > T0 T1 T2 T3 ...
>> I like your timeline as-is. Don't go checking the whole system to
>> "grandfather" old variables - that could confuse executing jobs. Let the
>> SM initialize the variables in the SYSSTART file if necessary.
>
>Agreed.
>
>> > 6) It seems desireable to be able to override a var of a higher scope.
>> >... It also seems reasonable to be able to defeat
>> > this override abilty. I have defined the HIDE parameter for this
>> > purpose....
>>
>> Yes! But what about MPE (or subsystem) defined variables? Case in point
>> being:
>> NSCIERR
>> NSCIWARN
>> DSLINE
>> DSERROR
>> which I personally would like to make PROCESS LOCAL. When a single job
>> (or session) manipulates communications links and has (or tries to have)
>> two or more connections open, the "job/session global" nature of the
>> above variables makes it difficult for an individual process within the
>> job/session process tree to make sure the system variable values are
>> valid for the operation they performed.
>
>Agreed! This is one the main benefits of local vars. For your need
>the local var needs to be inherited by called scripts and children processes,
>so that all "tasks" in your environment that are concerned about DSERROR
>will see the same var.
>Also we need to be able to HIDE=yes the above predefined vars, so that you
>can define them locally. Then when dscopy calls HPCIPUTVAR or PUTJCW these
>intrinsics will detect that there is a local var and will set that one.
>I think that this implies that HIDE=yes must be the default for all var
>creation.
So there would be variables local to the PROCESS as well as variables local
to the Job/Session, as well as Account variables and System variables? I'm
stressing PROCESS level as we have communication "server" job streams with
a couple dozen DSLINEs open to other systems and sharing DSERROR with other
processes in the job/session causes a nightmare. If I CAN hide the
Job/Session DSERROR and have a unique DSERROR variable for each process in
the Job/Session, that would be fantastic! Note that this is really only
necessary for MPE and subsystem defined variables.
>> > 8) Do you think it will be a common error to initially define a local
>> > var (say j) and then later in the script accidently use SETVAR j rather
>> > than SETLOCVAR j? If so, what is a good way to prevent this error?
>>
>> I guess I presume that SETLOCVAR would set ONLY a local variable,
>> SETACCTVAR would set ONLY an account-level variable, and SETSYSVAR would
>> set ONLY a system-level variable,
>
>Yes.
>
>> and SETVAR would default to the
>> SETLOCVAR scope so as to try to be consistent with the current SETVAR.
>> Hmmm. At some point the programmer has to take some responsibility. Let
>> it happen.
>
>You could say that SETJOBVAR and SETVAR are the same, since today SETVAR
>only sets job/sess vars. Or, you could say that if SETVAR finds the var
>already exists at a certain scope it just sets it at this same scope.
>Probably need to exception the system scope in this rule. This is
>analgous to how I describes HPCIPUTVAR and PUTJCW above. In summary:
>once a var is created at a certain scope (and not later defined in a more
>local scope) then all setvars apply to that scope. Is this OK??
I'm confused. Are you saying that if I create a local variable, SETVAR
will use the local variable because I set it? Does that mean that if
there was an account level variable and I set a system level variable,
SETVAR would change the system level variable rather than the account
level variable because I created the system level variable (and did
not create the account level variable)?
>> > 10) Do we need to delete a var from all possible scopes at once?
>>
>> No. We've survived "PURGE MYFILE" and "PURGE MYFILE,TEMP" so we can
>> delete it from multiple scopes as well. I can see further options
>> required if deleting from multiple scopes.
>
>I didn't word my question well enough. Is there a need for a process to
>be able to delete all scopes of one or more vars within the current
>environment -- not for other users on the system. IOW, if I want to
>set a system var as HIDE=no so that it cannot be overridden *and* I want
>to make sure that I (not everyone else) don't have a var of the same name
>at some other scope already how should I do this?
>1) deletevar foo;allscopes
>2) deltevar foo;acct deletevar foo;local deletevar foo;acct etc.
>3) deletevar foo deletevar foo deletevar foo ... til I get an error.
>
I guess in that case option 1 makes more sense.
>> Hope you're not sorry you asked! ;-)
>
>Absolutely not. Thanks again,
>Jeff Vance, CSY
...and thank you!
John
--------------------------------------------------------------
John Korb email: [log in to unmask]
Innovative Software Solutions, Inc.
The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.
|
