Hi All,
 
This is my reply to Michael Gueterman, which I forgot to make public:
 
--- Forwarded mail from <[log in to unmask]> ("Jeff Vance")
 
From: "Jeff Vance" <[log in to unmask]>
Date: Thu, 29 Aug 1996 22:57:18 -0700
To: Michael L Gueterman <[log in to unmask]>
Subject: Re: Design for System CI vars (long)
Cc: [log in to unmask], [log in to unmask]
 
Hi Michael,
 
On Aug 29,  4:33pm, Michael L Gueterman wrote:
> Subject: Re: Design for System CI vars (long)
> Jeff,
>
>   Overall, the "high level" sounds great, but I have a question
> concerning your definition of a "local variable" below:
snip...
> Unless I'm misunderstanding, then you could not programmatically create
> a "local variable", would that be true?
 
Yes this is how I (somewhat arbitrarily) defined local variables.  However
this definition is open for debate.  Jeff Kell and Duane Percox have a need
for process variables like you have described.
 
>  Here is a 'true life' scenario
> that "local variables" (maybe defined differently :) would help:
>
> 1.  A father process (program a) creates multiple child processes (program
b).
>     All variables created (currently) by 'program b' are accessible to all
>     processes from it's father on down each process tree branch.
 
Yes, this is the scope of what I called job/session variables.  This is the
only scope available today for user-defined vars.
 
> 2.  Unless 'program b' is specifically coded to create 'uniquely named'
>     variables (maybe by using it's PIN), the usage of those variables by
>     any of the 'children' is suspect.
 
Agreed.
 
> What would help here is the ability for a process to create a "process tree
> localized" variable that would be available to the process that created it,
> and any of "its" subsequent children.  If a subsequent child process creates
> a "like named local variable", it would start the process anew from that
point
> forward.  Any "process tree localized" type variables created by peer
processes
> would be unavailable.
 
This is very close to the UNIX export variable model.  In most UNIXes and in
POSIX each variable created belongs soley to the process that created it,
unless
it is explicitly exported.  Once a var is exported it is accessible to the
creating process and all of its descendants -- but not to peer processes.
 
>   This situation comes up daily for my major client.  The ability to do
"local
> variables" in the script would be handy, but its programmatically where I can
> see the most use for it currently.
 
The implication being that you want to be able to programmatically create
inheritable process variables, probably via the HPCIPUTVAR intrinsic.
 
> Not to seem pushy, but how about a similar
> functionality for FILE equates?
 
Has been asked for before.  Have you looked at AIFCHANGELOGON recently?  It
was enhanced to create process local file equations and a process local JIT.
I would prefer to defer process local file eqs for now...
 
Thanks for your comments,
Jeff
 
--
 
 
---End of forwarded mail from <[log in to unmask]> ("Jeff Vance")
 
--