Re: more environment variable questions

["Urbanek, Marty" <Marty_Urbanek@xxxxxxxxxxxx>]

That makes good sense, Scott. Thanks. -Marty

------------------------------

date: Fri, 07 Mar 2008 12:21:20 -0600
from: Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
subject: 

The *SYS level environment variables are (more or less) default values 
for the job-level ones.   In general, software never looks at the system

level ones.  (I'm generalizing -- it's certainly POSSIBLE for software 
to look at the system-level ones, but it's not the normal way of doing 
things.)  Programs normally only read the job-level variables.

The first time that a program accesses a job-level environment variable,

all of the system-level ones are copied into that job.   In this way, 
you can say that a job's environment variables start out with the values

defined at the system-level.   Or, as I prefer to think of it: 
system-level variables are the "default values", and job-level ones are 
the actual variables used by software...

When you submit a job with CPYENVVAR(*YES), it tells the SBMJOB command 
that the newly created job SHOULD NOT get it's defaults from the 
system-level variables.  Instead, it should get it's defaults from the 
job that's running the SBMJOB command.   So the job-level variables are 
copied from one job to another.   If you specify CPYENVVAR(*NO), then 
they are copied from the system-level ones as usual.

So if there's a system-level variable and you don't want it used, you 
have to follow these steps:

     a) Use RMVENVVAR to remove it from the current job.

     b) Submit with CPYENVVAR(*YES)

Specifying CPYENVVAR(*YES) prevents the new job from being initialized 
from teh system-level ones.  Instead, it's initialized from the 
submitting job's variables -- and since the envvar was removed from the 
submitting job, it won't existed in the submitted one either.