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)", or as it was
done in the old days, a "TELL #Jnnn; Anyone Home?" and checking for
CIWARN 1627?  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.

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

> 3) Should there be any restrictions on who can create system vars?
> Remember one of the benefits of system vars is IPC.  I looked at all
> possible capabilities (BTW, remind me what CS capability is??) and none
> really seem to apply.

I seem to remember CS was Communications Subsystems.  No, no
restrictions.  Sort of the GETRIN/FREERIN approach.

> 4) Should there be any restrictions on who can set read/write/delete
> access to the system var they created?  Is there a need to be able to
> alter any characteristic of a system value once it is created (other
> than its value)?

Don't know.  I don't have an opinion.

> 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 deleting
> the vars in the other scopes. And do you really want the CI going to all
> account var tables, all job/sess var tables, all local var tables for
> all users and checking if a var exists or not?  I doubt it, so does this
> matter?  System vars created from the sysstart file have a much higher
> chance of being unique -- see timeline below.
>
> -----------------------------------------------------------------------> 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
>
> T0: if S1 set as HIDE=no then all new job/sessions will be unable to create
>     a job/sess or local var named S1.  Therefore all new jobs will refer to
>     the system level S1 when they reference S1.
>
> T2: V1 can be set as a system var even though there are jobs logged on
>     that have already defined a job/sess var named V1. Jobs prior to T2
>     will reference their own V1, whereas jobs logging on after T2 will
>     reference the system V1.  IS THIS OK?
>
> T3: All new jobs beyond T2 cannot create a more local V1 (HIDE=no) and
>     thus they will reference the system V1 when they reference "V1".

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.

> 6) It seems desireable to be able to override a var of a higher scope.
> Eg. a script sets a local value for HPPATH, or a system var is defined
> as a default value, but users may create a more local var to effectively
> override the system var.  It also seems reasonable to be able to defeat
> this override abilty.  I have defined the HIDE parameter for this
> purpose.  HIDE=yes means it is ok for this var to be overridden (*not*
> overwritten) by a var of the same name in a more local scope.  HIDE=no
> means this is not allowed.  Even with HIDE=no question 5 above is
> relevent!

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.  RIN locking gets around this,
but makes datacomm single-threaded for the job/session process tree, and
causes really nasty problems when NS "drops" a connections the the NS
operation *never* times out (which happens all to often).

Perhaps another question should be, how can the programmer define the
locality of an MPE/subsystem defined variable (like DSERROR, etc.)?  Or
should these variables be process-local?  I can think of instances where
I'd like these variables of definable locality, but if I am not allowed
to change the locality, I'd go for process locality.  That way the
process could set a job/session local variable to their DSERROR value.

> 7) Should there be a way to override the natural hierarchy of var de-
> referencing, which is: look first for local vars, then for job/sess vars,
> next for account vars (maybe?), and last for system vars?  If yes, do
> you like the idea of SYSVAR(varname), ACCTVAR(varname), JOBVAR(varname)
> functions vs. a more general SCOPEVAR(varname, "scope") function? vs.
> a qualifier in the varname itself, eg. !varname{scope} or !varname:scope?

Hmmm.  Each has its advantages.  I don't have a clear preference.

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

> 9) Does question 8 apply to system vars?

Going with my prior comment, no.

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

If the SM deletes "j" from all scopes, what happens to all the batch jobs
and sessions that currently have a local "j" variable?  If deleting from
all scopes is an option, will there be an option to include specific
jobs/sessions by "jobsesname,username.acctname" and/or by "#Jnnn" and/or
"#Snnn" and exclude certain jobs/sessions?  How will deleting an account
level variable work?  Will SM be able to delete all account level
variables for all accounts with one command?  Will there be inclusion and
exclusion lists for "jobsesname,username.acctname" and/or "#Jnnn" and/or
"#Snnn"?  What can of worms have I opened?

> THANKS AGAIN!
>
> Jeff

Hope you're not sorry you asked!  ;-)

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.