Hi all,
Below are a couple of examples using system and local CI variables.
I just made up new commands and new parameters where I needed to.
I tried to describe the behavior within the script comments.
Admittedly these examples are biased to system/local vars and may not
reflect real life scenerios. That's where hopefully you can help.
Please pretend that you magically have system level and any kind of
local variables that you need and email back examples showing your
use of these new types of CI variables. Or, if you give me real-life
situations that needs system or local variables, I will try to write
scripts to solve your particular problem.
Even if you don't have time to read the examples, can you skip to the
end and look at the questions?
Thanks very much,
Jeff Vance, CSY
==========================================================================
In my examples all uppercase indicates something new.
Example 1: system level logon UDC that counts successful logons by
each unique user.account
---------
usercount
option logon, no break
# This UDC extracts the user.account logon name and increments a
# system var of the same name. Format: "user_acct"
#
# use a local var so we don't need to bother deleteing it at the end
SETLOCVAR UsrCntName hpuser+"_"+hpaccount
# if UsrCntName exists increment count, else create it
if bound(!UsrCntName, "SYSTEM") then
SETSYSVAR !UsrCntName, !UsrCntName + 1
else
# make sure UsrCntName doesn't already exist at some other scope
if bound(!UsrCntName) then
# var is defined somewhere other than system level, so delete it
# from all scoping levels
DELETEVAR !UsrCntName; ALLSCOPES
endif
# create a unique UsrCntName that lets all users read it but only
# lets users with AM, SM, OP or anyone in the payroll acct write/del it
# HIDE=no means no one else can create a var of the same name (even at
# a different scope). Note, there is no way to alter these characteristics
# other than deleteing the var and re-creating it.
SETSYSVAR !UsrCntName, 0; [log in to unmask]@; WRITE=AM,SM,OP,@.payroll; HIDE=no
endif
Example 2: one job monitors the progress of other jobs and then performs a
task that can only be done when all the other jobs have passed "step_4".
-----------
(monitor job - job has no special capabilities)
job .....
SETLOCVAR critical_step, 4
# get list of jobs to monitor.
# define local vars before calling script below
SETLOCVAR joblist, ""
SETLOCVAR jobcnt, 0
# the getjobs script returns a list of job numbers in the supplied var
xeq getjobs joblist, jobcnt
# joblist is a local var but can be passed to other scripts. The format is:
# "J123 J234 J345 ", etc. These are the same names used for the
corresponding
# system vars that contain the step that each jobs is processing. jobcnt rtns
# the number of jobs in joblist
# For each job in 'joblist' examine its current step. Once all jobs are
# beyond the critical step then start the XYZ processing.
SETLOCVAR i, 1
while i <= jobcnt do
SETLOCVAR thisjob word(joblist," ", i)
# if 'thisjob' exists then check step, else process next job in joblist
if bound(!thisjob, "SYSTEM") then
# retreive thisjob's job step. There could be "Jnnn" vars defined
# more locally but we just want the system level value.
SETLOCVAR thisstep, SYSVAR(!thisjob)
##############################################
## Question: is the ability to override the natural hierarchy for var
## dereferencing a good idea? The SYSVAR() function does this.
##############################################
# extract the actual step #. Format is: "step_#"
SETLOCVAR thisstep ![word(thisstep, "_", -1)]
if thisstep > critical_step then
# thisjob is ok, process next job from joblist
SETLOCVAR i, i+1
else
# thisjob exists but is not past the critical step, so pause
pause 30
endif
else
# thisjob does not exist - get the next job from joblist
SETLOCVAR i, i+1
# Note: don't use setvar here else you have just set a job/sess
# var instead of incrementing this local var
endif
endwhile
# Once we get here we know that all remaining jobs are past the critical
# step so it is ok to do XYZ !
xeq xyz
eoj
(a job being monitored - job has no special capabilities)
job ...
# construct the system var name to hold "my" current step
SETLOCVAR mystep "J"+hpjobnum
# make sure I can set this system var
continue
SETSYSVAR !mystep, "test_0"; [log in to unmask]@
if hpcierr <> 0 then
tellop Can't set system var !mystep. Job is terminating
eoj
endif
# start step 1
SETSYSVAR !mystep, "step_1"
...
...
# start step n
...
deletevar !mystep ;SYSTEM
####################
## Why not deletesysvar ??
####################
eoj
# start step 1
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.
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)?
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.
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)?
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".
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!
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?
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?
9) Does question 8 apply to system vars?
10) Do we need to delete a var from all possible scopes at once?
THANKS AGAIN!
Jeff
--
|
