variable scoping

• all CI variables are job/session global, except the following:HPAUTOCONT, HPCMDTRACE, HPERRDUMP, HPERRSTOLIST, HPMSGFENCE

• easy to set “persistent” variables via logon UDC

• need care in name of UDC and script “local” variables to not collide with existing job/session variables

  • _scriptName_varname -- for all script variable names. Use:deletevar _scriptName_@ at end of script
  • Can create unique variable names by using !HPPIN, !HPCIDEPTH, !HPUSERCMDEPTH as part of the name, e.g. :setvar _script_xyz_!hppin , value

• save original value of some “environment” variables

  • :setvar _script_savemsgfence hpmsgfence :setvar hpmsgfence 2

Previous slide

Next slide

Back to first slide

View graphic version

• The variables that are not job/session global reside in a local CI data structure, and thus are unique to each CI. If you run a child CI program it can have a different value for these variables, and any settings you do in that CI are not reflected when you exit back to the root CI.

• Since (almost) all CI variables are scoped global to the job or session environment, you can set/create variables in logon UDC, scripts etc. and these variables are available to the job or session. User variables are not automatically deleted when a script or UDC ends.

• Since (almost) all CI variables are scoped global to the job or session environment, you may need care in choosing a unique variable name. If you have a variable named XYZ defined from the CI, and you execute a script that sets XYZ and then deletes it before exiting, your CI set XYZ variable is gone. For this reason, it is generally important to use script variable names that have a decent chance of being unique to that script. A convention I use is to prefix all script variable names with the name of the script. For example, if my script is named CH and I need a counter variable named “j”, I will named it _CH_J in my script.